Product Management
Reframe How You Think About Users of your Internal Platform
Freshness Warning
This blog post is over 1 year old. It's possible that the information you read below isn't current and the links no longer work.
13 Nov 2023
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Companies are using internal product platforms to speed up development, make user experiences consistent, reduce operational costs, and support various environments, including mobile. One of the key differences in product management of an internal platform is who your end users are. They adopt and use your product for different reasons than an external customer would.
It’s tempting to view the product managers and engineers using the platform as your customers. As product managers, we spend most of the time thinking about customers, so it’s natural for an internal product to think of fellow employees as their customers.
But the concept of a customer comes with assumptions and context that can slow your success as a platform team There’s a huge difference between an actual customer and these internal "customers."
The big difference is that you’re building for a customer of one, and the "customer" should only have one possible supplier. You have built-in users. You’re not creating something and hoping people will use it. You’re creating it in partnership with the product teams to solve specific company and product problems. The product teams aren’t out shopping for the product that best fits their needs, they’re working directly with you to make sure the platform solves their problems.
With a product sold freely in the marketplace, if you don’t build the thing a customer needs they’ll use a substitute. They’ll buy it from someone else, build it themselves, or repurpose something else. They’re free to go elsewhere. And you are free to look for other customers that are a better fit for your product. You’re free to decline to sell to a customer because they’re a poor fit or would be unprofitable to support.
This isn’t true for internal "products." If your internal users reject your offering, you can’t go sell it to others. You can’t fire a bad customer.
In most cases, your customers can shop for alternative solutions. But this isn’t an efficient use of company resources and the company should reject this option. If the company has invested in a central data warehouse, you don’t want the marketing department implementing its own. It’s wasteful and counter to the purpose of creating the central thing.
In a rational world, this means that the platform has a monopoly. The customer only has one choice. They must choose the platform, regardless if competing options would have been a better option for that usage. The company-wide benefit outweighs the local advantages of choosing differently.
As the supplier, this monopoly is even more extreme. You have a market size of one. That means product/market fit is shifted almost entirely to the market side of the equation.
Because of this dynamic, I don’t find the concept of an internal customer useful. The concept of a customer relies on a free market. Internal products don’t have that. If you use the customer mindset, you’ll make product choices that fail.
It’s better to think of your platform’s consumers as partners. You can’t exist without the small pool of consumers, and they’ll waste effort and money without you. It’s a symbiotic relationship.
You have to build what the platform consumers want or your product will not survive. That’s true of any product to some extent, but it’s crucial for internal products.
This doesn’t mean that the consumers of your platform should dictate exactly what features they want and how they want them built. Unless your platform only supports a single product, you still need to balance the competing needs of different platform consumers. (And if your platform only supports one product, then why do you have a platform?)
Partnering to build the product doesn’t imply that the consuming team has control over the platform, or that the platform has complete control over what they build. The platform team cannot be "order takers" implementing the product’s requirements. And the platform team can’t build whatever they want and force the product to adopt them.
Partnering with the consuming teams means learning what technical challenges they face. Understanding what their business needs are. You need to identify things that every product or team is building or will need to build, and then find a way to create those in a common way. And you need to anticipate what teams will need to build several quarters from now, so when it’s time for them to build it, you’re already there with the answer.
If you partner with the products and truly understand their business, you can start creating new value for the products. You’ll be in a unique position to see where all products are going. You can identify opportunities for cross-product product integrations. You can help converge user experiences across products.
Acting this way isn’t something you often do with customers. Customer relationships are transactional, even with the most friendly customers.
When you call your platform consumers "customers" it will encourage a mindset that thinks of them as "other." As outsiders who are using a product instead of a much more symbiotic, collaborative relationship.
Shifting your perspective and treating internal platform users as partners instead of customers will help unlock collaboration and trust between the product and platform teams. This will help spur platform adoption and contributions. It will improve how your platform supports the products.