Platform Product Breaks

Being a platform product manager can be hard. Here are 4 learnings from a recovering platform product manager

Even in the best companies, where teams focus on user value streams, platform teams (and platform product managers!) are necessary. Platform teams are responsible for self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. They are essential for a business unlocking awesome customer outcomes.

Product managers in platform teams have a difficult job. They are further removed from end customers, have to manage more stakeholders, have multiple teams relying on them, and they are rarely seen as a priority for investment by leadership.

If you have the chance to try this role, you should do it - you will learn much faster (even if it's a bit painful).

In this article, I'll talk about some key hard-won takeaways from my past platform PM roles. 

You still need to care deeply about the end users, not just your internal users.

I was pretty excited about my first platform role, to me it meant that I had better access to users. The colleagues I could reach on slack were my customers. I love a good workshop. Now I could throw together workshops to design the product with my users actually in the room. 

To some extent, this is true and an excellent starting point. However, this assumption relies on product teams understanding their end users' needs and effectively conveying them to you. However, this is not always the case! Even when teams do understand their users' needs, user feedback and research gets diluted the further removed from the original source it is. For example, a user may say they frequently travel between the UK and Europe, a product team can translate this into a request to the platform team that users can pay in Euros. On closer inspection this is a mistaken assumption, they only have a UK bank account and were just trying to ask for ease of use when travelling. 

Platform teams are often the blocking dependency for other teams starting work. This means that even when assumptions are corrected, work has already been wasted.

In a platform team, you can see the end user’s needs from lots of different angles and spot trends in ways others can’t. This is a huge responsibility. Not being clued into those end user needs can result in big risks going unnoticed at a company-wide scale. 

Learning:

Platform teams and value stream product teams should collaborate. Work to understand the user's needs and ideate on solutions together. This can look like shared time-boxed discovery, or rotating representatives in and out of each other's continuous discovery efforts. 

Prioritise value over trying to maximise the number of happy stakeholders

Stakeholders are complicated at the best of times. As humans, we often believe our problems are the most important to solve. We have the most context and experience the pain of them more closely. A platform product team has 5 times as many stakeholders, all of whom know it's your job to build the things they need. 

It is easy to fall into reactive mode. You prioritise requests from the angriest stakeholder to get a little breathing space. It’s a hollow victory when a few months later, your product is not hitting the business-wide outcomes. Often making the angry stakeholder angry again. 

In response to this, it is tempting to swing in the opposite direction. Instead of building for one group, create features that benefit the whole business. A platform team is in a great position to conduct discovery and understand trends across internal user needs. This isn’t terrible, and it is often a great starting point to add value fast when you are new to space. However, it makes the assumption that all needs are created equal. They aren’t. They are often just the least controversial. Sometimes the needs of the few outweigh the needs of the many (sorry Star Trek fans). 

For example, a few years ago I worked on a release management and deployment platform. It was responsible for rolling out software updates across lots of different kinds of environments around the world. There were general needs that, if addressed, would have made every user's life a little better. However, the most valuable priorities were for a small number of highside air-gapped environments with mission critical goals. Prioritising their needs was the right call.

Learning:

The big learning for me was that it’s not possible to make everyone happy, especially in a platform role. That’s okay; we spend a lot of our time as PM’s saying no, this is a way you can refine that skill. 

Focus on understanding internal user problems over solutions

As Product Managers most of us have learnt the lesson that users don’t always know exactly what they want. We often get feature requests for things that show us an underlying need that there is a better way of solving. We’ve learnt to “fall in love with the problem not the solution.” (Uri Levine?) 

I completely forgot this lesson when on my first platform team. I assumed that because my users were a part of the business they knew what solutions they needed. This wasn’t always the case. In some cases, they knew what their team needed but they made assumptions about relevance to the rest of the business. In others, they had misunderstood their own needs. This happens more often than you may think. In an ideal world, platform teams exist because they hold special expertise that standard cross functional teams don’t. By focusing on the problem they will often define better solutions than the requesting product team.

Learning: 

Don’t skip out on the problem portion of discovery because of internal confidence in a problem. Do your due diligence on the root problem teams are facing, validate that it’s the most important to solve, and ideate with the platform experts in the room. Engineers with niche expertise can come up with some of the most effective ideas!

Everyone owns the Product Strategy, not just user facing teams 

You may believe that the teams who interact directly with customers will represent the product strategy, and your role is to support them. However, in most companies, teams are incentivised to focus on proving the value of their product or feature set. Teams are actively competing for limited resources and in many cases are “protected” from holistic thinking in order to focus on their specific areas. This can lead to contradictory actions to the broader strategy. As a platform team, you have a unique opportunity to focus on the holistic product strategy. You serve as the last line of defence, ensuring that what you build for others supports that strategy. Platform teams are often able to spot misalignment before the teams in question have even realised it. 

Learning: 

Show interest in the broader product strategy. Think about how the features you prioritise validate or invalidate the strategic direction of the business. Share these decisions clearly and publicly. As mentioned above, you will be saying no a lot. Saying “no, because x is more strategically aligned for y, z reasons…” is much more compelling and encourages others to make trade offs with this mindset. 

This sounds hard... Why would I do this?

Platform PM roles give you exposure to people and problems across the whole business. They can be really motivating when you think about all the teams you are enabling and the value they unlock for their users as a result. Platform roles can also mean becoming fluent in a more complex technology, this is often hard to prioritise in a standard product team. 

Most importantly, you should do it because it's hard! The principles of Product Management remain the same; user focus, fast feedback cycles, and falling in love with the problem. The execution of these principles in a platform role is tougher. If you do go back to direct user facing products, you’ll be an even more effective PM.

---