How I KPI’d My Way to Success as a Product Manager

As a [relatively] newly minted product manager, one of the things I’ve spent a lot of time thinking about is how to direct my energies effectively. Since being a product manager is one of those nebulous roles (a bit like testing) where it’s not always clear what you should be doing at a given moment, and (assuming you’re not in a junior role) the people around you can’t point you in the right direction either. So, by and large, I’ve been left to figure it out on my own.

One of the ways I’ve tried to frame the work I think I should be doing is by seeking out useful KPI’s. Indicators of how I’m performing in some important areas of product management. Of course, as you might expect for a role that differs for each team, organisation, project or product being worked on – opinions on what is a useful KPI for a given product manager are many and varied.

And in any event, after some time and thought – I realised that KPI’s weren’t exactly what I was looking for. I was trying identify a model for product management that fits the context I’m working in, that I could frame with some indicators or heuristics to ensure I stayed on track. Or to put it another way, if I was straying outside of what I considered to be a useful PM model, and potentially becoming less effective in my work as a result, I would be able to identify it from a resulting dip or skew in metrics from the key performance indicators I had identified.

Having spent no small amount time going through this process myself, I figured it might be helpful to document some of my thinking for others who may find it useful.

A list of KPI’s for Product Managers

First up, a long list of of KPI’s that could be used to measure product manager success. For the record, there’s a distinction to be drawn between product success and product manager success. Though, it’s slight, since you might argue that if the product isn’t successful then the PM can’t can’t be very good either, can they? Lots of PM’s inherit their products though – so while product success is certainly a KPI, it’s only one part of the jigsaw.

  • Product Success – there are many different ways of measuring this. Customer acquisition, retention etc. Monthly Recurring Revenue if you’re a running a SaaS product. Units sold.
  • Deviation of set hours of work – a measure of how many extra hours your teams are working to achieve the product goals. A large variance would show some pretty dire project planning.
  • Planned budget deviation – like deviation of hours, except probably worse from a management perspective.
  • Missed milestones – pertains to roadmapping and backlog management. If you’re missing your own planned milestones, there’s a problem to you can fix somewhere.
  • Product development – is the product actually getting developed? In a good way, or does your team recoil in horror at the point of release?
  • Customer service satisfaction – are you providing the CS team with the information they need to work with customers and keep them happy?
  • Engineering satisfaction – are you providing the engineering team (UX, development, QA etc) with the information they need to develop the product?
  • Marketing & sales satisfaction – are you providing marketing with the information they need to position and sell the product?
  • Financial performance – are you spending more on development and operations than the features you’re developing are earning back?
  • Business support – is the product operationalised, such that the existing business can support it or has the resources and data to be able to grow and do so?
  • Service improvement – a good product can be underpinned by a set of related services (think service plan or finance when buying a car). Do those services exist for your product? How have you improved or helped those services scale?
  • Talking to people – how much time are you spending out in the market? Do you have a good understand of who is using your product and how? What extra features are your customers looking for? What are their pain points, etc?
  • New ideas – what new product ideas or experiments have you come up with?
  • Roadmap planning & development – how’s the product roadmap looking? Is it clear? Did you communicate it to the rest of your team? Is it stable (at least, for the immediately upcoming backlog items?)
  • Launch / Anti-Launch – are you providing all your associated business units with the information they need to launch the product, or to retire previous versions if that’s a thing?
  • Sustainable growth – related to product success and business support. If change and improvements have taken place, are they sustainable?
  • Working well with others – does your team respect and enjoy working with you? PM is a leadership role, so if they don’t, you better fix it!
  • Decision making ability – your teams will look to you for answers and decisions. Do you provide them quickly, or do you procrastinate and equivocate?
  • Strategic thinking – in this context, thinking about the company direction and marketplace influences, and planning the roadmap accordingly is what I’m talking about here.
  • Data driven-ness – to what extent are your decisions informed by data and to what extent are you improving the situation if the answer is “not much”?

My favourite KPI’s

No doubt many more key performance indicators could be added to the list. All the items are useful to some extent, but to try and apply them all would not be very sensible. And applying some of them, depending on the business and product context, may even prove detrimental to your cause. So, what to do?

Well, in true agile fashion – you can experiment with a few and see which ones stick. My own approach to this has been to try and identify some core behaviours that are acknowledged (within the PM community) to be impactful in a good way, and to adopt those. My favourite KPI’s, and those that I anticipate sticking for the foreseeable future, are these:

  1. Data-driven-ness – as mentioned in the list, this metric pertains to how well data is being used to drive my product decisions, and what projects (if any) are in progress or on the horizon to improve the situation where required. Since I’m keenly aware of the need to become much more data driven in my approach to product development, this is a key metric for me currently. And as I’ve mentioned in some of my previous posts, it’s also driving some learning decisions, as I try to get much more fluent with data generally, and in particular how to make it actionable.
  2. Customer-centricity – understanding the domain and market in which your product resides is also critical to PM success. In many ways, I’m quite fortunate since I bring a decade or so of software test management experience to the table. But to rest on my laurels would be a dangerous move. I can’t assume that I know what customers want because I spent x-number of years working with the kind of tools we develop. I need to be on top of current trends and technologies. I need to get out and actually speak to people to understand their wants and challenges. And I need to turn those conversations into, again, actionable insights that feed into my final KPI, below.
  3. Experimentation – as any agilist will likely inform you, experimentation is the road to success. Though likely with many failures along the way. This KPI reminds me that it’s part of my role to identify experiments that we can perform and that will provide us with data (see data-driven-ness). Based on which we can then either make some decisions, or come up with further experiments to try. Having experimentation as a KPI helps remind me to think creatively, and not be afraid of trying new things.

Final thoughts

To the extent they’re useful, I expect the favourite KPI’s I’ve mentioned above will keep me focused on the most important things. If at some point in the future they become not so useful, I reserve the right to discard a KPI – or all of them – and replace them with some new ones. For me, the important thing is to have some points of reference, that help me gauge whether I’m heading in the right direction, or not as the case may be.

My KPI’s don’t have percentage values, or scores – yet. Currently they’re bullet points under which I can identify some actions or projects should I need to. And having them on a report or raising them in a conversation with peers or management means I can get their feedback also. They’re systems, not goals. And with any luck, they’ll help ensure I’m not only a successful product manager; but that I’m also managing an increasingly successful product.

Further Reading

Many of the KPI’s I mentioned above came from articles written by other folk in the PM field. If you want to read the original material, see the links below:

Thanks for reading. Feel free to reach out via a comment or on the socials if anything resonates.


One Comment

Leave a Reply