Market, don't mandate.

Internal facing product management, and the captive audience

One of the key differences between consumer facing product management and platform or internal facing product management is the concept of the captive audience.  Users or prospective customers of a consumer product will either decide if it is worthwhile by paying for it explicitly; either with their time or their money.  If they don’t like it they have lots of options to use instead, probably including your direct competitors.  If you are building a platform or tools which are intended to be used within your company, your prospective customers have their choices restricted.  They are supposed to use your product, they might even be explicitly mandated to do so. You have a nominal monopoly.

But it’s not that simple.  When you are building tools or platforms for engineers to do their job, if you introduce a new tool that they don’t like, they won’t want to use it.  The problem your platform product is supposed to solve isn’t new to them.  They’ve been solving it in a different way for a long time. They are probably very aware of the different options available, the pros and cons and the best practices.  They are well equipped to do their job well without, or maybe even in spite of your platform or tool.  Even if you can explicitly mandate that the engineers (your customers) use your platform product, that doesn’t directly translate into adoption.  They could push back because what you’re offering simply is not good enough, or they might drag their feet because they don’t want to use it.  They could say ‘not now’ for prioritisation reasons and be completely justified.

On the other hand, there can be very good reasons for centralising and standardising the tech stack and infrastructure in medium-to-large tech companies.  You can get reusability benefits, you can reduce the cognitive load needed to work on different components, the technical components will work nicely together.  These benefits represent an improvement on a global objective function, whereas teams choosing their tech stacks and tooling autonomously may only enable them to do a great job optimising for their local priorities.  These local optimisations might be a net negative on the global level, especially as you scale.  It’s an important tradeoff to consider between autonomy and standardisation.

So simply mandating that an inferior platform product be used doesn’t work very well, but at a higher level your organisation might need the global benefits that having standardised tech will bring.  It is the responsibility of a platform product manager to ensure alignment of these incentives, so optimising globally is also optimising locally.  In other words, the product that you provide should actually be the best tool for the job for your internal customers.

But the responsibility doesn’t end there.  Once you’ve built a product that successfully aligns incentives, the trick is to get your customers to see that too.  It’s such an easy mistake to assume this is obvious.  As the product manager for this platform, you are problem obsessed and understand very well why it is in everybody's best interest to use your product.  That’s not the case for your customers.  If they don’t understand why using your platform is the right thing to do, you’ll have the same problems trying to mandate adoption, no matter how good the product is.  This is now a marketing task. Market to your captive audience.  Help them believe.  Scale up adoption of your product as well as your impact without friction.  Market, don’t mandate.

We hope you enjoy the discussion!