How OKRs connect Business Outcomes to Work items that teams deliver
Dheeraj Pershad is the Lead Product Manager at Broadcom Inc. and the co-founder at ProductCamp Hyderabad – the first and only unconference (no registration fee, no selling) in Hyderabad that is focused on all key product development stakeholders. He is a public speaker and product manager by profession, experienced across Product Management, Product Sales and Product Development. In this Voices of OKRs piece Dheeraj explores how OKRs connect business outcomes and execution of product teams.
When I recently ran a survey asking executives in my network what would they like to get if they had a magic wand, 70% responded – “clarity of what my execution teams are building” and “how that aligns to moving business metrics in the direction that matters”.
On the contrary, when this question was asked to the execution teams themselves from a similar lens, 90% responded – “they would like to have visibility into how the work they do, helps business grow and earn $s”.
You see what is happening here – both executives and execution teams that work on two opposite ends of the spectrum in building products, are essentially battling with the same problem of “help us connect the dots”. Well, the focus of this article is to examine this issue and see how OKRs enable and help with solving this problem.
Putting on my product manager hat here – I will explore how you can use the OKR framework to differentiate product goals from business goals that executives care about. I will also focus on how you can align Key Results to product goals, thereby building a clear understanding of how even the smallest things contribute in the big picture.
At the end of the day, you survive when you reduce costs and run a profitable business. It doesn’t matter what features you build. What matters is the value that your customers derive from your products and the price they are willing to pay for your solution to their problems.
So, let’s get started:
1. Distilling Business Outcomes
What executives and business leaders care for and define as their goals for the year is traditionally in the form of business metrics that help move the needle. These can predominantly be broken down into top line and bottom-line goals and not tied to an individual product alone in the portfolio.
Let’s take an example from a recent product I managed as a Product Manager. The organization I worked for, had a multitude of business verticals that had 50+ enterprise products and the business goal for the year was to ensure we run each product at a minimum of 55% profitability. This is how it read – “each product in our portfolio should contribute to 55% or more towards profitability”. What’s important to note is that the Business Goals are generic to the organization, and it is the job of the Product Manager to distil them into relatable product outcomes/ goals.
When we try to distil this business outcome that executives care for, profitability is a measure of both the ability to earn revenue (top line) and the ability to cut costs (bottom line). So essentially you would first need have a clear understanding of what the revenue of your product is, what segment of customers it comes from, what the overall costs are, what the fixed and variable costs are so that you can act accordingly.
2. Drawing parallel Product Outcomes
Once you have distilled your business outcomes and understand what enables you to get to them, the next important step is to decompose and tie them to definitive product outcomes. This is where a marriage between business goals and customer value comes into play. As a product manager, it becomes important that you align the business goals to definitive product goals.
Let’s go back to our example, before I go further, let me give you some more context. The product had 4 pricing tiers:
- Free tier, for up to 5 user accounts
- Basic: 3$ per user
- Advanced: 6$ per user
- Enterprise: 9$ per user
So if we were to go back to the business outcome, as a PM you need to clearly understand how much revenue you make and what your costs are. All so that you clearly know what your profitability percentage is. In my case, we were at a revenue of USD 700k with costs in the range of USD 500k, meaning a ~29% profitability. Hence, I had to be creative in terms of improving my top line, as well as reducing costs to meet the annual 55% operating profit. Remember, we are still not yet talking about what features to build in the product to cater to customers.
So, if we decompose the business goals and divide them into definitive product goals, our product goals are broken into the following themes:
- Increase Revenue by 20% (from USD 700k to USD 840k)
- Reduce costs by 20% (from USD 500k to USD 400k)
- Minimize customer churn (to <2% per month)
These could also be drawn as themes or epics in your product backlog. If you do the math, this would help me grow my profitability from existing 29% to approximately 55%.
P.S: The revenue, cost and profitability numbers are hypothetical and do not represent the actuals for the products I managed.
3. Defining Key Results
(which are SMART – specific, measurable, achievable, relevant and time bound)
Now that you have connected the dots from business to product goals with high level themes and epics, the next logical step is to define Key Results, specific to the product that you manage. These Key Results are what you will measure to determine if you have been successful in meeting your goals.
Let’s go back to our example and take each theme/ product goal we defined above and break it down into KRs:
Do note how each of the KRs defined above follow the rule of being SMART – Specific, Measurable, Achievable, Relevant and Time-bound.
4. Deriving features for your KRs and the corresponding stories
Having reached a point where you have clearly defined SMART Key Results to drive your product outcomes, now it kinds of becomes easier to convert and tie them to features that your teams can start looking to build. Then the teams can start breaking them down into stories and churning them to deliver on the desired product outcomes.
Make sure at this point in time you involve other members from your triads. These typically include architects, UX designers and engineering leads. This is where you get very specific about the product that you manage, although the Business Objectives were very generic in nature when you started.
Let’s extend our example to see how features shape up:
5. Driving a shared vision
Following the above approach of starting from Business Outcomes, tying them to relevant Product Outcomes means that you have automatically made it clear for everyone in the organization how even the smallest button added to a screen contributes towards moving the needle. Moving the needle in improving the top line or cutting down costs and thereby, helping reduce the bottom line.
In the spirit of transparency and making sure this reaches your teams, it’s always advisable to present the whole exercise of arriving at OKRs and corresponding features to your teams as part of your quarterly planning meetings as well as ensuring the same information is reflected in your agile planning tools. This is how a consolidated view of the above exercise looks like and is a good way to present to teams as well:
Most of the agile planning tools like Rally or Jira provide a mechanism to create a hierarchy of work items. You can leverage this structure to create the Business Outcome -> Product Outcomes -> Key Results -> Features -> Stories view.
After all, using OKRs is not all that complicated, but very powerful when done right!
Looking to get started with OKRs? Try Gtmhub FREE for 7 days!