I stared at this blank Notion page for at least two weeks trying to develop a comprehensive description of how to make an impact as a Platform Product Manager.

I thought about what I would have liked for someone to tell me three years ago when I started this journey.

I thought about what I enjoyed the most and my achievements. I also thought about my failures and what I learned from them, the organisations I worked in, their culture, and their context. More thinking and less writing, because I wanted this to be a very transparent and actionable piece of content.

As much as I kept my advice generic, some parts might only resonate with some Platform PMs and might only apply to some. After all, in product management, one size does not fit all.

Let’s dive in.

In my initial article, I described the ultimate end goal of a Platform Team as enabling the Product Engineering (or Value Stream Aligned teams) to move faster, efficiently, and autonomously.

So where does that leave us, Product Managers?

We are responsible for managing a platform product’s development, scalability, reliability, and evolution.

How?

• We define the team’s mission, product vision and strategy in line with the company’s objectives.

• We collaborate with internal teams to enable a seamless E2E CX.

• We optimise for developer productivity in a cost-efficient way.

• We are managing technical risk.

• We have to communicate effectively and abstract all the technical jargon.

Let’s look at them in a bit more detail.

Defining the Platform Vision and Strategy

One of the critical areas of impact for a Platform Product Manager is their ability to define a clear product vision and strategy, aligning them with the broader organisation. This involves understanding both the company’s strategic goals and the internal partner’s needs.

Note: Internal Partners = Product Engineering Teams or Value Stream Aligned teams.

We then aim to identify opportunities to develop and evolve the platform product to support those needs and goals. In doing so, we deliver value to the company and our partners, remaining a crucial driver of growth and innovation.

We can use multiple frameworks for this, but I am a big fan of the Product Decision Stack that Martin Erikson presented a few years ago.

Tip: I represented a variation of this below and it’s something I have used and am still using:

Collaboration

This is my favourite topic because I love working with Engineers. In my experience, they are picky, curious, and very creative. Who doesn’t like picky?

As a Platform Product Manager, you have direct access to your partners, making it easier to understand their pain points, and needs and be part of their workflow.

I recommend a few collaboration techniques that have worked well for me:

• Developer Interviews

• Engineering Surveys

• Shadow the Engineers when they build and deploy a change.

• Volunteer to participate in any pair programming exercise in your company – we have a high culture of mobbing (the pairing kind, in case anyone has doubts), so I find my way into those sessions as often as possible.

• Work with them on Usability Testing if you want them to try a new tool.

Tip: You should expect less than 50-60% engagement, but you can find your group of champions and partners and co-create with them.

Optimising for developer productivity

This is such a controversial topic that still attracts much attention. So far, in my career I have experienced various challenges when:

• defining developer productivity and

• measuring it

When in doubt, I always looked for academic research, so I recommend:

• DORA Framework

• The SPACE of Developer Productivity

Below is a clear example of simplifying developer productivity.

” At Harry Potter company PLC we define developer productivity as the level of efficiency and effectiveness of a developer or a development team in producing and delivering software.”

Our goal as a Platform Team in Harry Potter Company PLC is to measure this through

• deployment frequency

• lead cycle times

• satisfaction developer surveys

• time to first deploy

Our baseline is 0 , and we know we are successful when we hit x% in a Q so we can increase our speed to market and reduce cognitive load.

Once you are explicit about that and gather your quantitative and qualitative data, you can prioritise which areas you want to optimise for, be it: tooling, automation, reliability, etc.

The above example is an oversimplification, but I hope it gives you a good idea of what I mean by developer productivity.

This is the time when you, as a Product Manager start thinking more in-depth about Metrics.

Tip: Many factors beyond the DORA Metrics can influence Productivity, including the current engineering processes, culture, and context. Hence, the controversy.

Anything surrounding developer productivity, efficiency, satisfaction, and happiness is a space to watch out for, and I recommend following Software Engineering Research by Abi Noda.

Managing Risk

Managing risk is quickly becoming an area of focus for me because I believe that as a Platform Product Manager, we need to be aware of this and communicate it in a very effective and non-technical way. By risk, I mean:

• Technical debt which could cripple the company and delay going to market for products or features.

• Security and compliance work – we must look at security as another developer-friendly tool and build simple processes and practices. This will be important for finance or healthcare companies that are usually regulated or go through different audit exercises like SOC 2 or ISO.

Tip 1: Try to work with Tech Leads and Engineering Managers to visualise the tech debt across the organisation.

Tip 2: If you have an InfoSecurity Governance function in your company try to push for clear policies which you can work with. Be prepared to negotiate.

Communication

Communication is usually a core skill for Product Managers. Still, it becomes vital as a Platform Product Manager because you have to context switch from talking to Engineers to talking to VPs and C-suite across multiple teams. So you have to learn how to abstract—a lot.

I am guilty of sometimes staying in my Engineering-y bubble and can fall into that slippery slope of using technical jargon. I recommend few tactics:

• Know your audience and write drafts for each type of audience.

• Then re-read and delete half of what you’ve written. At least delete all the technical jargon.

• Do some word counting when presenting or writing for senior folks, mainly focusing on impact. We built x and achieved y. This is how it impacted the objectives, or this is what metrics we moved.

• When doing presentations, I recommend rehearsing them a bit in advance. I learned this during my time at Ministry of Justice – it worked wonders!

• Be very clear and focus on intent.

I recommend one article and one podcast on the topic, but there is a lot of content on effective Communication.

All these areas above are huge topics, and I’d like to tackle each of these individually as part of a series of articles, including some basic frameworks and examples. I might also interview other Platform Product folks so stay tuned!

I hope you found this useful and don’t forget to ping me for feedback and subscribe!!