The Product Owner role (often given different names but generally the same concept) involves prioritising the product backlog with the right vision to maximise product value. Many organisations interpret this “product” quite broadly, while one of Scrum’s core values is “focus.” Unfortunately, this focus is often lacking, causing a Product Owner to work on various “parts” of a product that should actually be separate products. Therefore, having a clear overview of KPIs can help a Product Owner focus on the aspects of the product that positively contribute to these indicators.
What are KPIs and how do they help an organisation?
Key Performance Indicators are the metrics teams or organisations regularly review to ensure they are on the right track or if adjustments need to be made. It’s essential to distinguish them from Performance Indicators. A negative deviation in KPIs requires immediate action, while a deviation in Performance Indicators does not. Often, Performance Indicators are not concretely defined for a product, presenting opportunities for optimisation.
You can compare it to a car: if it’s speeding (km/h) in a speed trap zone, this must be adjusted immediately (KPI). The odometer reading, however, needs to be monitored over a period (PI). In the case of an e-commerce webshop, revenue is monitored. If it deviates from the budget, adjustments are needed. However, if newsletter subscriptions dip significantly during the day, it may not require immediate action. The same applies to less public products like ERP systems or order management systems. If the number of exported orders drops compared to the average (e.g., per minute), it indicates a problem. Similarly, a rise in the number of internal reports about a particular functionality indicates it is not user-friendly and needs extra attention. This can be seen as a performance indicator. An overview of these indicators, also known as a KPI Framework, helps an organisation focus on what is truly important to the business and the optimal customer journey.
3 ways clear KPIs help a Product Owner
1. Stakeholder management
Being able to say ‘No’ is one of the most important aspects of stakeholder management within Product Ownership. Not everything can or should be addressed immediately. This is fundamentally done based on the product vision you have. In practice, this is easier said than done, especially with a generic product. Referring to the organisation’s KPIs can help here. User stories that directly contribute to achieving the KPIs can often be prioritised higher than those that do not. If a user story positively contributes to meeting the targets of a KPI, it can be included in the product backlog. If not, the answer is ‘No.’
The RICE Model as Backup
As a Product Owner, you’re likely dealing with business KPIs such as revenue. The counterargument may be that every user story directly or indirectly contributes to it. It can help to consider other factors like reach (how many users benefit), impact (low, medium, or high positive impact on revenue), confidence (in the previous estimates of reach and impact), and the effort required to implement the user story. These factors together are known as the RICE model. The RICE model is also useful for creating your product roadmap.
2. Gathering and developing ideas
By focusing only on the parts or sub-products that positively contribute to achieving the KPIs, time and space are created in the agenda and backlog of the Scrum team - time and space that would otherwise be spent on unnecessary topics. This capacity can then be used to develop new additions that do contribute to a KPI. More energy can be put into formulating hypotheses, setting up experiments, creating proofs of concept (POCs) and prototypes, and clearly writing out requirements for a minimal viable product (MVPs). Quality over quantity is important here. The Product Owner is responsible for maximising the value of the product, service, or functionality. This growth in value can be measured using KPIs.
3. Incident management
When there’s a report of something going wrong in the production environment, the tendency is to stop all work and have the entire (development) team look into it. But how essential is the failing functionality? Does it have a direct impact on a KPI (e.g., revenue drop because a webpage is down), or can the investigation and bug fix wait until the next sprint (e.g., when a time-tracking application is significantly slower but still usable)?
Get started!
KPIs are not only useful from a financial perspective or as a reward model, but they can also help you as a Product Owner perform your role better and explain your choices. If you want to discuss Product Ownership or how Agile and Scrum can be effectively applied in your organisation let us know!
