The Most Demanding Role in Product
6 reasons why Platform Product Management is the most demanding role in product, and why it demands more than a technical PM.Every product has their own challenges.
High growth products are like riding a rollercoaster that’s on fire - everything is urgent!
B2B you’re selling to someone who doesn’t even use the product.
And internal products are riddled with politics.
But I’ve always found managing platforms to be on another level!
I’d even go as far to say that managing platforms are the most demanding product role you can do and I want to break down why in this week’s newsletter.
1. You don't have a direct line to the customer
Think about an everyday product - like a popular app - there’s one product and one set of users.
Platforms aren’t like this and many platform teams make the mistake of treating themselves the same by treating internal teams as their ‘users’.
Platforms are enablers.
They enable other teams to deliver products and features to their users. This means you need to understand both those consuming your platform (other teams and engineers building on top) AND understand their end users too.
This makes the job more complex.
You now have two sets of users - two vastly different users.
If you don’t do this you will end up being an order taker. Because you don’t understand the teams using your platform or the end-user outcomes they’re trying to achieve.
This is the unlock to becoming proactive - being able to stitch together different end-user needs and reverse it back to things that your platform can enable for products across the organisation.
2. 10x more stakeholders
If having to do discovery with both internal teams and end users wasn’t enough additional work, platforms often have more stakeholders to manage.
This is because platforms usually serve multiple product lines across the business. Each of those product lines will likely have their own set of stakeholders that you now need to engage with.
And as a result the number of stakeholders can grow quickly!
This demands more of you as a product managers in terms of communication, influencing and stakeholder management.
FYI, if you're looking to sharpen your stakeholder management chops, I have a Stakeholder Management course plus loads of free content on the topic. Here are a few worth a look:
3. Impact is Lagging (and outside your control)
Because platforms are enablers - i.e they enable other teams to serve customers with their products.
Outcomes are often lagging.
There’s a time delay between building a new platform capability → teams adopting it → using the platform to produce something → shipping that new thing to customers.
This makes outcomes a little bit tricky because ultimately we care about the end customer and business impacts but that’s not something you can control - and it can easily be months between a new platform capability and end customer outcomes.
Of course we can’t wait months to measure impact. So we need to break outcomes down into leading indicators that we can track and get earlier feedback on.
This can sometimes be easier said than done. It’s not always straightforward since there’s a bit of cause-and-effect between platform work and end customers. Not to mention navigating boundaries between what you own as a platform and what the product teams own.
To give an example, I’ve been working with a Platform PM in the Product Mentorship for the last year now and we’ve spent a good couple of months working together on this.
We’ve gone from:
High level business outcome: cost savings
Customer outcomes: stability → more uptime → fewer bugs and issues.
Product Team outcomes: better observability → incident detection → fewer incidents
Leading indicators: adoption → mean-time-to-acknowledge → mean-time-to-resolve → # of P1 and P2 incidents → etc.
Workshop with a Platform PM to break down the business outcome of "cost savings" into leading indicators.
And this matters because, you need to be able to explain how what you’re doing enables outcomes for the end customers and business.
4. Intangible
Platform work is largely invisible.
As a result platforms can’t speak for themselves. There’s often no UI, nothing visual to help communicate the work.
There's no demo where everyone in the room goes "ah, I get it."
Instead it’s often APIs, JSON files and a bunch of intangible work like infrastructure and backend code.
This means that Platform PMs need to be great storytellers!
This is something I see a lot of product leaders get wrong. They assume because platforms are technical they should put their most technical PM on it. And whilst the technical background is no doubt important to manage a platform, without strong communication and storytelling platforms often end up under-funded, unused, and struggling.
I experienced this recently with a client. I’ve jumped back into a fractional IC (individual contributor) role the last couple of months and I had to present to the c-suite on the AI platform work we’re doing. Which meant trying to explain to a room full of non-technical people the importance of evals, fine-tuning, all this invisible work that’s necessary to improve the accuracy of an agent. When on the surface nothing has changed. The agent is just more accurate and reliable so there was a lot of storytelling to do to explain what we're doing, why it's different, and why it matters.
Side note: this is another reason why point 1 is so important. The more you understand your end users, not just the teams using your platform, the better storyteller you’ll be. You’ll be able to draw the line all the way from something visual and customer-facing to your platform - i.e. “Here's what the customer is trying to achieve, here's how that team solves it, and here's where the platform fits in.”
5. You can't mandate internal adoption
When you ship to the open market, adoption naturally follows the diffusion of innovations.
And that’s because you can’t force customers to adopt your product.
But internal products and platforms are different.
You can force adoption but this is usually a recipe for disaster.
How many internal products or platforms are truly loved? They’re often the thing employees complain about the most.
But you shouldn’t treat a platform any differently than you would rolling out a new customer-serving product. There’s no reason why you can’t run a pilot, leverage early adopters’ feedback and iterate until you have product-market-fit internally.
The only reason why organisations don’t do this is often because of executive pressure to roll it out faster. Which makes platform product management hard. There will generally be internal pressures to skip all this and have a ‘go live’ date where everyone is enrolled onto the new platform.
You need to influence that and try to allow word of mouth to spread adoption, not executive mandates.
6. Versioning and backwards compatibility
Lastly as your platform grows and extends you’ll start to roll out new versions.
However, some of these versions will require teams to make changes to adopt it.
This can quickly become a dependency nightmare - chasing every team and lining them all up for the same release date - and as soon as one team is not ready, everyone is held hostage.
Don't do this.
Instead, introduce versioning and backward compatibility.
This means having more than one version of your platform (or features within it) running at any given time.
For example, say you build v2 but everyone is still on v1 rather than teams having to deprioritise everything to move onto your new version and you having to play release manager to organise it, you can ship v2 and keep v1 running.
This decouples the dependency between you and other teams.
And yes it has its own cost as you need to now carry multiple versions in production at once but it’s often far less painful than having to keep everyone in lockstep.
At the same time you also don’t want this to get out of hand and maintain 20 versions at once, so you need to put boundaries around it.
Here's my preferred way of handling this: give teams a window, not a date. Instead of "everyone moves to v4 on this day," say "v2 will be sunset in six months." Now each team has a window to upgrade on their own schedule. A team buried in work this quarter can pick it up next quarter. It’s their responsibility to manage, freeing you up from having to play release manager.
This means you need to have a policy here. Do you support three versions at once (v2, v3, v4) and that's your window? Longer? Shorter? There's no universal answer, but it’s something you need to define before it gets out of hand.
Treating Platforms as Products
This is the heart of treating your platform as a product.
A lot of what you need to do as a Platform PM is adapt your product craft to the context.
You need to adapt techniques like:
Jobs to be done applied to both internal teams that use your platform - what job do they hire your platform to solve? As well as, still applying JTBD to their end users - what jobs do your platform help enable?
Stakeholder Management to deal with the complexity of having many different stakeholders across the business.
Storytelling for a platform that is intangible and complex.
Go-to-market, launch and user adoption tactics like product launches, pilots, beta programs, etc to internal users.
I could go on but all this is to say that you need to be good at these skills in the first place before you can take on managing a platform.
Platform Product Management requires you to be good enough at the foundations that you can adapt them.
This is why it’s a senior role and putting someone junior on a platform is not setting them up for success.
I’ll leave it there. This could honestly be a 2 hour live stream or a full course on its own (which if you’re interested in me doing either - hit reply and let me know because I can).
Hopefully this gives you a clearer picture of why Platform Product Management is genuinely harder.
If you’re a Platform PM reading this, I hope this helps you be more effective.
And if you know a Platform PM who should read this, forward it to them (it helps this newsletter but it’ll also help them - win-win!)
Thanks for reading!
/Ant
