Why Platform Product Management is Hard!
Hey I’m Ant and welcome to my newsletter where you will find practical lessons on building Products, Businesses and being a better Leader
You might have missed these recent posts:
- OKRS ≠ Strategy
- Building Effecive Product Roadmaps
- Breaking Product Discovery into First Principles
My day job is helping companies shift to a Product Operating Model.
My evening job is helping product people master their craft with Product Pathways.
Last month, I was asked if platforms should treat internal teams as their customers.
A common question and it illustrates one of the many challenges that platform teams face over their direct-to-consumer counterparts don’t contend with.
In some ways, direct-to-consumer products are straightforward—note that this is not always the case. There are some very complicated consumer products, but we are talking about the majority here.
One of the main simplifications is that you only have one customer.
And to make things even simpler, that customer is also your user.
From a discovery point of view you only have one lot of users to interview - yes some products might get more complex as they may service different user segments but largely I have a single cohort to deeply understand.
Now platforms are (at least) one step removed from this.
A common mistake is treating the platform the same. Defining your users and customers as the teams that consume your platform.
Instead what you really have is a daisy chain. Where those consuming your platform are trying to achieve something for an end user.
Therefore, you need to understand not only the needs, challenges, and jobs to be done of those using your platform but also their end users.
This allows you to understand the bigger picture so that you can build a platform that not only solves your users' needs but also effectively enables them to solve their customers' problems.
Do this well enough, and you’ll be able to move from a reactive team that takes requests from other teams to a proactive one that can anticipate their needs—e.g., “This new API will help you do X to solve this need your customers have. Use it when you’re ready to.”
Unfortunately I don’t see this thinking enough in platform teams I work with and a lot of my work is shifting their philosophy on what a platform team is and their responsibility.
Besides the inefficiencies in the ‘take a ticket’ system or being reactive to other teams needs. There’s a deeper risk. Which is the assumption that the team requesting the platform work has done discovery - and that’s a BIG “if” in some companies.
It’s therefore no surprise that many platform teams quickly become a spaghetti mess and require a lot of back and forth where the original request wasn’t quite right and changes flood in.
Autonomy and decoupling
And perhaps the most impactful change this makes is that we can decouple platform and product teams.
There’s a difference between a platform team being an enabling team and a dependent team.
An enabling platform should be a service that you can draw upon to achieve your goals.
Think of Stripe. You can build upon Stripe to do just about anything you need to in terms of payments and billing.
When you want to introduce a new pricing mode, you don’t go to Stripe and create a ticket for them to build it. Instead Stripe has APIs that you can develop against and yes you might need to do some work on your end but you’re not building your own payment infrastructure. You’re leveraging the platform.
Now a dependent team is the former. You’re literally dependent on the other team to do the work for you (or at the very least make changes so you can).
One of the reasons for this is the fact the platform teams aren’t responsible for the larger picture.
Something I admire about platform-style companies like Stripe and Shopify is how much they understand both the companies using their platform as well as the end users. Shopify knows e-commerce arguably better than anyone, and it shows in how confident they are that they have one of the “The world’s highest-converting…checkout”
“Shopify's overall conversion rate outpaces the competition by up to 36% and by an average of 15%, based on a study completed in April 2023” - Shopify
Now, perhaps Shopify isn’t the exact match to how platforms work within your company but hopefully it illustrates the point of how it could be easy for Shopify to say that conversion isn’t their problem - that’s on the sellers, they own the experience.
However, the underlying philosophy is valid for how we must think about platforms.
A framing I like is to think of platforms as ‘customer-enabling teams’. Meaning that they are still responsible for the end outcome (or at least partly responsible).
If people aren’t using a service on the platform, then that’s your problem as the platform team, not theirs.
This is the same product mindset we would apply to a customer-facing product. If a user isn’t using a feature that’s not the user’s fault or problem, that’s yours! You need to work out why and solve it!
But for some reason we seem to forget about this because those teams are internal and we can tell management that “we did our part. We built it, they’re just not using it…”
All of this is to say that Platform Product Management is hard!
I haven’t had to manage a product myself, but I’ve worked with and coached dozens of platform teams and even helped organizations establish them - so I’ve learned a thing or two and built up a lot of empathy!
It’s not an easy role and this is why product leaders often put their more senior people on these products.
When you're ready, I can help by...
For individuals:
Improve your craft at Product Pathways through:
Self-paced courses on:
Community *COMING SOON* - If you would like to join the alpha/beta, complete this EOI.
Plus FREE templates and guides.
For Companies:
Consulting and Advisory: I help companies drive better results by shifting to the product model.
Private Workshops and Training: I run practical workshops and training coursesfor product teams globally. My training has an average of 4.7/5 rating. Get in touch to talk about your unique training needs.
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…