What are your most important KPIs you track as a Product Owner?

What key performance indicators do you track and which ones do you report to upper management?

4 Replies

  1. Work on 2 sprints at any point of time (1 on requirement sprint and 2 on development sprint).
  2. Ensure we have maximum stories being picked for a sprint
  3. Ensure that the Scrum Evaluation Team is abreast of all the activites of the sprint and meet all their objectives
  4. Take active part in the Scrum of Scrum meetings.
  5. ensure sprint burn down chart is slope
  6. Should be able to draw velocity of the team and ensure the scrum team is closing stories at the given rate.
  7. Marketing strategy and detailed marketing plan as part of the product planning to sales folks.
  8. Training to the new joiners on the previous releases.

@sudhindra, is there one KPI which has your special attention? And do you report all these KPI's to upper management? Thanks for replying.

@ernst: Point 2, 5 and 7 are vital! Me and my team report on all the above KPI's to the upper mgmt!

For me, the most vital PO KPIs are related to how your product ties back into the business. For an external tool it should: sales, customer satisfaction with the product, delivery and deployments (in Time or Instances), etc. The KPIs then reflect how your product is succeeding with it's purpose and shows how you are doing as a product manager. As a former number cruncher, KPIs should be based around things that can be measured qualitatively, or if it is vital to have a qualitative attribute then there needs to be agreed quantitative method of measuring those results (app store ratings for customer satisfaction example).

Granted it is sometimes hard to connect what the team is doing and how they influence the above KPIs which is important to make sure the team feels they are succeeding. Burndown and Velocity are important so the team knows when they are kicking ass and from what I've seen the Scrum Master usually has a big hand in measuring this. From there, depending on your product, you can measure: up time, number of bugs generated, meeting release dates. For a qualitative measurements: is the team happy, did they hit their quarterly, and did they make their sprint goals.

In the previous example for team happiness you can turn the qualitative attribute into a quantitative measurement by looking at events planned, team survey, inter-team kudos given, etc. Yet there are times when you can just tell when a team is happy or not and this shows that there are places for qualitative measurements as well if used honestly (can be represented on a report with a :) or a :( ). Nothing is worse for a team then seeing their happiness reported as amazing when in actuality they are quite miserable.

Remember that KPIs are a double edged sword because what ever you measure is what you're going to work towards. Our team, though technically an "innovation" team is measured by revenue generated. This then precludes any products we could build that would help the internal logistics of the company despite how much they may help (and there is a cornucopia of opportunity there IMO). If we did pursue that path, the team would get demoralized as they did a lot of great work yet got zero recognition for it.

Tying KPIs to business outcomes is going to help show that your product is successful and get more internal support from stakeholders rather than rote development based metrics. Your team can be productive building the wrong thing and even though they put up great KPIs they get punished from above because what they built didn't really work in the market (which is also demoralizing). Ultimately it's navigating that balance between tech and biz that makes all our jobs so tricky.