Learnings as a Platform Product Manager

3 weeks ago I started as a platform product manager responsible for managing a highly used and relied upon tool used by~1900 users.

This is what I have learnt —

1. Value proposition and being able to define “value” is even more important on platform products as your are enhancing something that is built for a wider market and not bespoke to your needs.
2. Know your users — When building a new service or a feature, we always start with user needs. However, when supporting a platform it becomes even more important to know your users, their roles, their usage of the tool, average time taken to carry-out certain tasks, average lead time for the support staff etc. This has allowed me to carryout a high-level capacity planning and what the team might look like as the users scale-up or scale-down.
3. Learning to gracefully say ‘no’ is one of the most important things a product manager do. As a platform team, managing multiple products (tools), serving thousands of different users with varying needs, prioritising becomes even more important. One of the first things I did as a PM on this role was to define a Product Roadmap with high-level goals. These goals make it easy say ‘no’ to stakeholders ever growing demands and wants.
4. You do not have control over the UI or a lot of the user experience provided by the tool. Unless selected correctly, your users are pretty much stuck with the UI that comes out of the box. This creates challenges for the product team who want to be known for their “service” rather than the “tool”. E.g., the product team should be known for ‘providing and supporting analytics on digital services that will help enrich the service’ and not ‘team that supports google analytics’.
5. You do not have a MVP user journey to follow — When supporting a service, the on-going nature of the job is what makes it interesting. You are not necessarily working towards a single MVP or minimum-feature to deliver value, instead you are looking at the entire service, user-experience, all different channels of communications and meeting needs of all users.
6. It is easy for users to start using the tool in a way it was not envisioned. This can happen due to multiple reasons, however, can happen easily in fast paced environments and fast changing markets. Supporting such evolved needs can be tricky because you’re trying to do something the tool is meant for. However, this is where new offerings and exciting change in direction lies — do we need an additional service/ tool for this offering, do we need to alter training and support offerings etc.,
7. Metrics, metrics, metrics! If the team does not have baseline metrics, start collecting now. It is never too late. For all the different tools my team is supporting, I have started collecting: availability, lead time, data quality, fail rate, uptime, average time spent on BAU/ maintenance activities, average time spent on change requests, types of users and their active level, net promoter score, cost of ownership etc., All of this will allow the team to show tangible value and will be a great story to tell to the stakeholders backed up with evidence.
8. Since the main product is an off-the-shelf product, the way you go about defining the roadmap and product strategy is slightly different than what I have learnt with SaaS.
9. I have never known supplier management like I have known as a Platform Product Manager. The relationships with users and business stakeholders is emphasised time and time again. However, there isn’t much about managing suppliers and account managers of the tools. Suppliers want to sell you more (upgrades, new features, new support process), however, you have to balance that with — your future roadmap, vision for the overall service offering and lifeline of the tool in your organisation.
10. When things go wrong on such a heavily relied upon platform — There is no hiding. In my week 3, I got to experience system outage during peak hours. The best thing to do — take it on the chin and explain what happened, why and metrics to show before and after incident, and a postmortem to re-strategise.