Last week I marked my 4th-year Product-anniversary. Although it doesn't seem like a lot, during this time, I was:
fortunate to launch and grow a massive operational product from scratch,
work on tooling for data scientists,
do a super complicated infrastructure migration,
and find my passion for what I like to call the Platform Space.
Here is the deal: I also realised I spent 75% of my Product career (to this date) as a Platform Product Manager. So I asked myself what did I learn and how I could use this to help others. I am still learning, so the aim is to bring others on the journey!
While it's been the worst of times and it’s been the best of times, to quote Dickens, there are a few things I also observed:
The role is slowly becoming A Specialist - why, though?
Not enough good quality content
No clear frameworks or case studies that PMs in the position can use
Very little guidance
A lot of buzzwords and fluff going around (in my honest opinion!)
That's because Product folks and companies really need to understand the value of building internal platforms and tooling as products. They also need to understand the impact of a Product Manager in that role.
Let's start with the basics:
On Platform as a Product
To this day, I think Evan Bottcher gave one of the best definitions of a Platform as a Product in Martin Fowler's blog:
Another great definition comes from Brandon Chu, ex-Shopify:
“A product is building something to ship to customers, a platform is building a place where other builders or creators can build things to ship to customers.”
Who are we building the Product for?
The internal product engineering teams. These can take so many shapes, but are more generically called value stream aligned teams. There is already ample content on team topologies; I won't cover that in this article. But you can read more about it here.
What is the ultimate end goal of a Platform Product?
That depends on the context of the organisation, the domain, the size, the culture, the products they are building, and many other things.
The direction is also given of course by the Product Vision. I will cover this
At a high level, there are critical areas for which Platform Products are optimising, and in my view, those are:
security
a good (if not great) Developer Experience
scalability
cost
The usual approach for internal platforms was to build it, and developers or internal teams will just have to use what's available.
Of course, that's ultimately the cardinal sin for (any) product manager, even more so for a Platform PM.
Also, this approach is laughable because you can't invest heavily in your customer-facing products without having a solid foundation.
Would you build your own house on a shaky foundation?
Companies that want to innovate, ship secure software quickly, have tighter feedback loops, and ultimately win in this highly competitive tech industry can't afford to treat their internal platform like an after thought, so enter the Platform Product Manager.
Much as we like to think this is a new function, it really isn't. Tech pioneers like HP championed this role 30 years ago. Marty Cagan started his Product career in a similar role. Let that sink in.
It's getting more focused now because our life is inundated by various tech platforms.
Enter the Product Manager
Before giving my own definition for the role, I asked my mentor, John (who works in a similar space) how he would define it.
His feedback is below:
I'd split my definition into 'what we do' and 'why it matters.' We provide leverage to product development organisations by allowing product teams to move fast and not break things.
The why is that those product teams spend more time delivering value to their customers and less time-solving common problems like managing infrastructure and tooling.
Think about it this way:
if the purpose of the Product Engineering team is to solve problems for customers in a meaningful and valuable way
the goal of a Platform team is to enable the Product Engineering teams to do that faster and in an autonomous way.
We are building for builders. I have tried to illustrate the point below:
It sounds complex, maybe more than it needs to be, but ultimately our role is just like any other Product role: build products that solve a real problem.
If anything, we are in a very fortunate position because our users are a Slack message away and, in 90% of the cases, extremely willing to help you improve things.
I love interacting with developers because they always think about solving problems and often give you highly unfiltered feedback.
How to make an Impact as a Product Manager?
This is something that I am incredibly passionate about, and it's on my mind constantly.
As you read at the beginning of this article, my mentor John split the answer to my question in: what we do and why it matters.
I'm going to cover this extensively in a future article. Still, ultimately, the most significant impact we can have as Product Managers of a Platform product is to build with developers and for developers, enabling the organisation to scale fast.
Just because it's a somewhat more complex product, we are still solving real user problems. So this takes me to the last point.
The question that gets thrown away the most is: Do I need to be technical to do this role?
My answer is no, but in my experience and personal view, you must be technically curious to understand the basics. Not everyone needs to read AWS, GCP, or Azure for breakfast but try to ask questions, be curious and shadow the developers when they try to ship code or set up their tooling.
That's where the magic happens. For me, at least.
One piece of advice I would give a PM thinking about trying this out is finding a mentor. Find a mentor anyway, regardless of what type of Product you work on. It will help you immensely.
Resources
Useful terminology.
In the Product and Engineering world, you will find Platform teams under different names, such as:
Foundations
Developer Experience
Developer Tooling
Infrastructure and Tooling
Product roles are advertised as
Platform Product Manger (here you have different variations from Associate to Senior)
Staff or Principal Product Manager - Internal Tooling (very rare)
Technical Product Manager
Pay attention closely to the job description and look out for
API Product Manager
Data Product Manager
Unfortunately some companies create a mesh of all 5 resonating in complete chaos. I’ve been there. I’ve also interviewed for those roles and usually you can get some red flags from the JD.
Useful resources
Books:
An elegant puzzle: Systems of Engineering Management , by Will Larson
Podcasts:
The Engineering Enablement Podcast, hosted by Abi Noda
- - super insightful
People I follow:
Hope you enjoyed this. ‘Till next time when we will take a closer look at Impact!
Nice one! Very interesting read!
Congratulations on the mailing list! Definitely a topic area to build on with your newsletter.