The Power of Product Names
"Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions."
- Joel Spoolsky, “The Law of Leaky Abstractions”
"The Platform should not increase the cognitive load of the teams using the Platform"
- “What is Platform as a Product” slide 38
In my decade-long career as a programmer, I spent significant cycles thinking and reviewing names given to variables, functions, namespaces, classes, or projects. Good naming makes it easier for others to understand what something does. It facilitates faster troubleshooting and change. Names are valuable for developing "smells" and are fantastic system design and analysis indicators. So naming has fascinated me in their ability to improve effectiveness in broad systems and as warnings that they may not be as effective as we assume.
I want to explore the idea that the product names we use with our internal partners are helpful indicators to gauge the Platform's support of developer efficiency and effectiveness. In addition, the names used for products influence healthy product behaviors downstream in the organization.
The Smell of Shipping the Org: Team Names and People Names
"We aren't shipping the org to our customers. We're trying to ship products and solutions."
- Adam Rogal
Well-designed systems attempt to hide particularly volatile data, and we know that people and organizational structures frequently change for internal platforms. So avoid using internal-to-the-platform names of people and teams with what you ship to users.
Team names and reorganizations frequently occur at corporations and can happen for various reasons. For example, a department in Netflix went from "Engineering Tools" to "Productivity Engineering" and back again as the field discovered its preferred naming conventions. Other examples include budget modifications leading to consolidation and people naturally changing careers.
Besides team names, we also have technology names and a combination of both. For example, I have seen teams such as:
Observability/DataDog/Prometheus team
Compute/Kubernetes/containers team
Pipeline/Jenkins/CircleCI team
Shipping team and technology names leak internal details of the Platform department and are good examples of "shipping the org." Some reasons why this is problematic from a product perspective:
Worse Feedback and Partnerships: Instead of focusing on solutions, needs, and product improvements, it becomes more frequent that the Platform's users critique the department's political structure or technology choices.
Product Management's Role Becomes Closer to Project/Program: Instead of centered around needs and impact, discussions often revolve around technology and design delivery. As a result, typical responsibilities like a product vision and need-based user strategies are less common when you see a PM call themselves the "<TECHNOLOGY> PM."
Costlier Discovery, Coordination, and Change For Partners: The more a partner organization operates coupled to the Platform's internal org structure, the more chaos gets released when that changes -- either when new personnel gets rolled on or off, technologies or architectures change.
On top of that, discoverability becomes worse. Let's say, as a developer, you want to build an app, but all the names provided to you are technology names. How do I accomplish that job?
If our goal is to support efficiency and effectiveness for our technical partners, we want to limit the impact of staffing and organizational changes while improving discoverability of solutions. Providing a well-defined yet flexible product experience with thoughtful names shields the internals of the Platform department.
The Smell of Good Names: Reflecting The User's Goals
"Outside means your customers, while inside refers to your team. Think about all the developers and their needs, first. Only then should you move "inside." If you do this, you're more likely to build something those developers need, than just a cool, new technology."
- Adam Rogal
"A cleverly designed brand name that connects the product to the job can make customers think of the product whenever they think about getting the job done -- so much so that the product and the job may come to be thought of simultaneously."
- Anthony Ulwick, "What Customers Want"
If we ship products, the names of what we ship should reflect their needs and goals. So let's look at a few real-world examples and try to guess what the product does for the end user:
1)
Organization: Foundations
Team: Data Platform
Product: Experimentation Platform
2)
Organization: Core Services
Team: Developer Experience
Product: App Launcher
3)
Organization: Platform Engineering
Team: Enablement
Product: Onboarding and Outreach
4)
Organization: Developer Productivity
Team: Client Application Frameworks
Product: Crash Report SDK
Shared Characteristics
There isn't a one-size-fits-all. So even though the organization and team names differ at each company -- as well as technologies, those organizations hold similar purviews.
Each team delivers multiple products that integrate into one or more Platforms. And the product name doesn't indicate the underlying technology or team structure.
What do I do if I am the PM of <technology name>?
Let's say you are the PM of S3. Start by identifying the users' needs with S3 and, based on that, encapsulate what your team will do to help deliver value to address those problems. Even if it is just that the team provides support as a service around S3, encapsulate the jobs the user needs to accomplish that your team addresses with the product name. The product vision and strategy should reinforce that name and vice versa.
Is this necessary?
While it is possible to provide a compelling set of Platform services by passing-thru technology and team names, I have yet to see it in top-tier Platform product cultures.
A change in name doesn't immediately change the service, but the impact is seen downstream, like a trim tab. So if your organization pivots this way, expect this to cause uncomfortable yet healthy conversations.
What I like about using names as indicators is the low opportunity cost. It's fast to look at and understand where to look next. If a product team cannot point to the product names and those names reflect the job it helps the user accomplish, then that is an easy indicator for improvement.