👋 Hey there, this is one of my more serious posts where you get something I hope you find interesting about product management, tech, or climate change, sign up😊.

I was recently asked for advice on how to approach quantifying your value as a product manager (PM). I thought about how I do it personally and quickly realised I had some thinking to do (here follows said thinking).

For the sake of brevity I’m only going to talk about the first step of quantifying value, setting the KPIs (key performance indicators). How exactly you could measure these things is a much longer article. And if you want to read context behind the question first, jump to the last heading ‘A non-typical environment’, otherwise, let’s get into it.

Summary

Defining (good) KPIs for a product is hard because to do it well you need to know exactly what you want to achieve (why you’re setting KPIs at all) and then you need a good idea of what would contribute to attaining that achievement. These things might seem straight forward enough, but getting it right is hard. My hypothesis is that this applies to defining KPIs for people too.

When we try to apply KPIs to ourselves, or other people, to do it well we have to first understand what we want to achieve, and then think about how we can contribute to that goal. Simple, right?

Understand what you want to achieve

As a PM, the goal is to make the product you are managing successful. So the first step is to define what success means for the product. It could be generating a certain amount of revenue, it could be growth in user base, efficiency gains, climate impact, calls per minute, rpm, pokemon caught, whatever. You first have to understand this, write it down, and bring it to every meeting you have with senior people.

Usually the best way for a PM to come up with this is to ask leadership what they think success means. But that’s not helpful if we’re thinking in the past tense to quantity past value, so instead we need to look at what you think success would mean for the product and then you can validate it later.

Let’s say I’m a PM on Twitter’s blue tick verification thing. Elon might define success for that feature to be generating 30% of the companies revenue in 6 months. Now for the company, that’s a solid KPI, revenue growth coming from the blue tick. And the PM should know the status of that KPI at any given time, it’s important, but that’s not a good metric for understanding the value of a PM.

The success of reaching that 30% goal depends on a lot of contributing factors. Something that broad doesn’t isolate specific value coming from one source. So we need to good deeper and look at what contributions a PM can make.

How Product Managers contribute to that goal

The job of a PM is to deliver business impact by ‘marshaling’ the resources of your team to identify and solve the most impactful customer problems.

The PMs job is to deliver on the product goals, in our example case, to deliver that 30% of revenue, so let’s start by breaking down the role of a PM. I like to break it down into three aspects:

1. Shape the product: Harness insights from customers, stakeholders, and data to prioritize and build a product that will have the most impact on the business.
2. Ship the product: Ship high-quality product on time and free of surprises.
3. Synchronize the people: Align all stakeholders around one vision, strategy, goal, roadmap, and timeline to avoid wasted time and effort.

To understand the value a PM can bring we can look at these three things. How can a PM shape the product to align with the businesses’ definition of success for the product? How can a PM ship said product to reinforce that definition? And how can a PM get the right people onboard and behind them in achieving the goal?

Shape the product

Now we can start to ideate on ways to measure value. Let’s keep on our Twitter blue tick example for a bit longer. How can our theoretical Twitter PM shape the product to align with the businesses’ definition of success for the product? First things first we need to think about the revenue stream.

So like a good PM they talk to as many customers/users as they can, they talk to stakeholders, and gather the data they need to establish a revenue stream. Well, that’s it, that’s the first thing we know we want to achieve, how can they as a PM contribute to it? By doing the right amount of user and market research. How can you measure that? Maybe it’s number of user interviews until the right option is made clear.

And if we assume Twitter’s PM did this right they landed on an $8 fee. How can we continue to shape the product towards the business’ goal? Well that’s a revenue stream covered, but 30% of it means we need a lot of users at $8 a tick. So let’s define the problem and work with UX design to solve it. There are two aspects to this product, the blue tick itself, but also the verification process. The problem is we need to make getting verified easy, so we can make lots of money, but not so easy that we defeat the purpose of being verified at all because anyone can do it.

These are now two more things you can measure as a PM. Increase in user satisfaction of the blue check (iterating on the design) and increase in user satisfaction with the verification process. Not necessarily more verified users, although that would be good, as a KPI its too broad to measure a PMs value.

And this is where our example runs out of milage because someone didn’t do this at twitter and the whole things a mess. But hopefully you can see my point, first, look at how you can shape the product towards the business goal and then see how you can measure your contributions.

Ship the product

It’s a PMs job to generate business impact by shipping a reliable, high quality product. Now, it’s difficult to measure a PMs value here for a number of reasons. Unless you’re a special PM, you don’t actually contribute to the code or the technicalities that make something high-quality, and you don’t have much control over the reliability of said code, or even the infrastructure that it sits on.

But you do have influence over the priorities, the ‘documentation’, and the culture around shipping the product. PMs should have a way of establishing priorities, I personally use the WSJF methodology with a side of common sense and ‘taste’ (if you know you know). So how quickly, or completely, do these priorities get implemented? How certain are you that these priorities are the right priorities? Where’s the proof? This is difficult to measure, but I think it would make a great KPI for a PM.

By ‘documentation’ I don’t just mean the technical stuff, I mean the tutorials, the user videos, the marketing, the emails you send to the company internally, et al. This ‘documentation’ is part of the product. Unless you have a flawless UX (impossible), it needs to be good. How satisfied are users with your docs? How many questions are you getting before a certain documentation thing vs after? How many people make it through your technical stuff before zoning out? If your product is exceptional but no one gets it, it sucks.

Finally, culture. Culture is notoriously hard to measure, but is an essential part of developing a product. Whether the culture is ‘in the office all the time, burn out or get fired’ or ‘Yipee code’, it doesn’t exist unless you live it. Given the product’s definition of success, how can you shape the culture to achieve it? Maybe you can measure employee satisfaction on your team? Maybe you can look at the number of crying emojis in retros? This one’s about shipping the product so how can you measure just how well your stakeholders, (devs, management, users, designers etc) believe in what you’re shipping?

Sync the people

Last, but certainly not least, it’s on the PM to sync the people. It may or may not be the PMs job to set the vision or the strategy, but it is absolutely on them to get the people behind it. Believe it or not, behind every product that you love, there are people who put the work into it.

This comes in two parts. For people to stay in sync about something it needs to be continuously crystal fucking clear, otherwise things diverge and you start getting lots of wasted time and effort. And secondly, people need to believe it. If you’re spouting something people don’t understand or worse, think is stupid, then you’ll see divergence quicker than you can say quidditch.

So here we are, two more things that could be good PM KPIs. Clarity within and without the team. How aligned is everyone on the plan, on the vision, on what you’re doing and why you’re doing it? And then, do they believe? Are they actively contributing to discussions about the future, are they talking to you about their concerns, their ideas, do they care? Again, difficult to measure, but I can’t do everything here.

Conclusion

In conclusion it seems like I disagree with some of the ‘standard’ ways of measuring PM performance. I do not think it’s necessarily a good idea to tie the PMs value directly to the success of the product goals. That is very easy to get confused. Instead, I think we need to look deeper at the role of the PM and start mapping the role to KPIs that contribute to the success of the product goals. Then, ultimately, if the PM performs on those KPIs it is (or should be) more likely that success is achieved.

What KPIs do I think are good to start with? Well:

• Quality and completeness of user/market research. It’s very important to note that I don’t mean ‘amount’ of research, 100 user interviews with the wrong people or the wrong questions would be nonsense.
• User satisfaction of particular features. If you’re actively measuring this you can start to track how your actions and contributions affect this number.
• Roadmap alignment with the user’s priorities. How can you prove that what you’re wanting to build is the best thing? It’s all well and good saying you’ve got all the top priorities right just because your boss says so, but frankly, your boss is probably wrong. I think how you would measure this is very dependent on the product so get yourself a pen and paper and start brainstorming.
• Documentation quality, in all its forms? This could be as simple as are the mistakes or the legacy sections decreasing, or as involved as measuring user satisfaction with particular pieces of documentation.
• Team alignment. Does everyone get it? Are you spending enough time and effort making sure everyone gets it? Is your team asking about the future, telling you their concerns, their ideas, their dreams? Why not? And what are you doing to improve it?

I think if nothing else this is a solid start. Admittedly they’re all tricky to measure, and the exact metrics are going to vary from product to product, but I think they make sense. I’m going to start thinking more about these things.

A non-typical environment

For the sake of the discussion, here’s the context to the original question. The product this person manages does not generate revenue (so can’t measure that), it’s an internal system that the company uses to manage a lot of internal stuff that was developed long before there were good third-party alternatives. And the company they’re in is not a tech company. It’s a big company that wants to ‘go digital’ but is very much built differently. The concept of a ‘classical’ Product Manager didn’t really exist until a year or so ago.

All that is to say that the leadership don’t exactly know ‘how to software’ and it seems like they hired product managers because that’s what it says to do, not because they necessarily understand why. In a more ‘techy’ environment this kind of question wouldn’t need to be asked because people would already understand the value, and managers would have set targets/KPIs (key performance indicators) that illustrate the value they want the PM to bring.

Thanks for reading. The best way to support this newsletter is to sign up ✍️ share it 🤝 and get your friends to sign up too 😎 That’s what this lovely purple button is for 👀