OKR Driven Product Management

Rob Sanchez

I’ve been listening to the Product School podcast during my runs and workouts the last few months. Many of the episodes have been good enough to listen to twice and some have even been good enough for me to take notes on them once I’m back home. This particular episode featured the Google Payments Product Manager Ethan Harry. His approach towards Objectives and Key Results and how they contribute to and guide the product vision is right on the money. I only hope I can do him justice with this breakdown. This episode was posted by Product School on September 6th 2022, and I’ve turned my notes into the article below.

To begin, we define a Product Manager as one who is responsible for delivering tangible concrete outcomes or values to/for the organization. The Product Manager is responsible for maximizing the value created by the team and for bringing the vision down to the team level.

Value and outcome can be measured in different ways but is often assessed by looking at User Count, Revenue, Cost and of course the all important Customer satisfaction. These exact measurements vary based on the product and the industry.

The Product Manager’s role is to consistently deliver the aforementioned value. To do this successfully, a PM needs to align with their stakeholders both internal departments and leadership as well as external customers and market forces like regulatory bodies.

Consistent value isn’t good enough though, the real secret here is to deliver the “Right” value. Value that meshes well with the business strategy and company culture. Empowering small teams (Scrum Teams) allows everyone on the team to feel a sense of ownership and to be excited and inspired by the vision. When everyone on the team owns the product then everyone does their part in laying a strong foundation to ensure the future success of the product.

As quick as this was to read for you it’s much more difficult to enact in the real world. Product Management is a lifelong pursuit towards this “Ideal”.

This pursuit of the “Ideal” is where frameworks come in. They can be used to get PMs and Organizations closer to perfection.

Here’s how things tend to work out in most organizations if OKRs aren’t the focus. Imagine a scenario where I have cultivators who need to take clones from a mother plant. They track down the mother needed and enter the number of clones taken to keep their inventory counts accurate. For the sake of the article, let’s say we as the PM want to improve this process. The first thing to be done is to define success. What do we mean by “improving” the process? One example could be Action Time, this action to Take Clones should be possible to complete quickly, under 1 minute. We’ll work with our customers and stakeholders to get sign off before the next step.

With company sign off, now we’ll build a prioritized roadmap for this feature and those other features affected. To do this, we’ll list out all of the features and define the goal of the change. Remember our goal is to reduce the time it takes to complete a Take Clones action. We’ll keep that goal in mind and prioritize our list of features and changes based on that. Now as long as the pieces all fall in place we “should” be able to deliver on the roadmap. Success right?

This is close but still far from the “Ideal” we discussed earlier. The features being created are sets of hypotheses, in that they are proposed and set based on limited information available at that time and used to investigate further. In our example here, we may be thinking about listing Mothers to be cloned in a list ordered by date stamp. The idea is that this will improve the time it takes to complete the Take Clones action. But we don’t know for sure that it will create the outcome we’re after.

This ambiguity can lead to features with impacts that are harder to measure and maybe even far from the goal. For example, if we want to add a scan functionality to allow users to Take Clones faster that feature may or may not help and it gets hard to decide what we’d need to measure to learn if it does.

This is where we as PMs want a more confident product strategy one that can drive the outcome we’re after in every phase of the product development lifecycle. That my friends is where OKRs come in, Objectives and Key Results.

The Objective is the outcome we’d like to achieve, in our example that would be “Reduce the time users spend taking clones.” The Key Results are the milestones or sub-outcomes that when achieved move the needle on the main outcome. To come up with KRs think, “What needs to happen in order to X?” where X is the Objective. Continuing our example, we’d say “What needs to happen to reduce the time users spend taking clones?”

Example Key Result: Reduce time to find the Mothers that need to be cloned (Measured in seconds)

Notice that we haven’t decided on any features yet here, we’re only breaking down the outcomes so that they’re granular and measurable to more easily track them. Defining the outcomes allows us as PMs to map features to each one of them down the road.

Key Results must be measurable, quantifiable and measured. Having clear measurements defined before moving on allows us to align stakeholders and the rest of the company on the strategy and justification for the hypotheses. In other words, when our goals are broken down into clean and concise measurements it’s much easier to explain and garner support from stakeholders. This also keeps the PM grounded by connecting them with the true business outcomes. It’s easy for a PM to start dreaming and innovating but without the connection to the outcomes that work may not be focused enough for success. With our goal now set as an Objective with a few Key Results, let's look at how this strategy moves beyond ideation and planning through the rest of the life cycle.

Before doing so, let’s return to our original example of only setting a goal with features to accomplish it. The next stage would be to build, refine and prioritize the backlog of features. The top items on the backlog would be taken to a quarterly planning meeting with all engineering teams, stakeholders and leadership. If agreed on, then the next step would be building and ultimately launching the committed features. This is relatively fine, but not as close to that sweet “Product Management Ideal.”

Adding OKRs to the mix provided a strategic foundation in all steps of the life cycle. If we take our defined OKR, now the next step is to build the backlog. This is not done in a silo; this is done with the team. Put the Objective up along with the Key Results and allow the team to brainstorm features and ideas focusing on only one KR at a time. Bringing the team in here is valuable for so many reasons but the main one is that it fosters creativity and allows the team to grow in the solution space around their product.

The team used for these brainstorming sessions needs to include stakeholders from all other departments involved to help create the best overall product. Depending on the product and objectives being discussed other teams may be invited along with leadership to contribute to the innovation and planning. This creates a diverse perspective that can stumble on amazing ideas. However the PM should make sure to focus the group on one KR at a time to avoid things spiraling out of control.

Next we’d rinse and repeat until the group has brainstormed features for each KR. Our result is a backlog, albeit a very organized one. Each feature on the backlog now maps directly to a measurable Key Result that ultimately affects the Objective.

Now what if you already have a backlog? In that case the brainstorming may not be needed or at least not to the extent that we discussed. The job of the PM now is to take every item on that existing backlog and map them to a Key Result. If they don’t directly map to one then they should be removed from the backlog or moved to the bottom if possible to await future Key Results.

The next thing to do is to verify our telemetry. In software development this is typically accomplished with dashboards and analytics. These can be set up for example to show us a running average of how long users are taking to complete the Take Clones action. This allows us to take an accurate measurement of the action as it is now so that we know how much (or little) we’ve improved it. With that shored up, it’s time to put on the Product Management hard hat and make some fact based data driven decisions on which features for which KR should be worked on and the order to do so. We need to prioritize each KR by the impact it will have on the objective so that we know the relative resources and time to put towards each.

There are of course theories and tools to help with this too. The first is the 80/20 principle (Thanks Pareto!) that states that roughly 80% of the consequences come from 20% of the causes. In other words, we can look at the product to discern which 20% of the features are producing 80% of the revenue or which 20% of the product is contributing to 80% of the customer satisfaction. Outside of this little perspective trick, PMs worth their salt should aim to fail fast. Remember failure in product management is necessary and should not be avoided. Failure validates the hypothesis just as much as success. The quicker a hypothesis can be put to rest we as PMs can start work on the next one. A/B testing can be used for further validation of the planned items if needed.

Alright, we’ve got a clear objective, key results and the backlog to support them. This is where the path may split for some orgs as it relies on the tool chosen for backlog and sprint management. Jira is a very popular solution for many reasons. We’ll use that as the example but OKRs and product backlogs can be mapped to most systems, even a spreadsheet. In Jira, we set our Objective as a high level story like an “Initiative” then below that we’d set each Key Result to an “Epic.” Under the “Epics,” we would link all of the backlog items that were mapped to that KR as individual user stories and development requests.

Time for an OKR driven Product Planning next, this is recommended to be done in 1 or 2 quarter increments (3-6 months). During this meeting, the PM should propose features and specify the numbers on each KR to explain what could be done. In our ongoing (long winded) example, that could be something like this: “During q3 we can make a combination of display and workflow changes to reduce the time it takes to complete the Taking Clones action by ~25 seconds. The goal of this session is to get sign off on committing to the KR specified.

PMs should hold themselves responsible for the actual outcome of the objective and key results, not the features themselves. Because of the methods used before this planning meeting the team will feel ownership over the features as they contributed to them during brainstorming. This allows everyone to see and understand why things are being built, which can sound obvious, but many teams operate in auto pilot and zoom out to ensure understanding of the big picture.

With that completed, it’s time to work! When using Jira, epic burndown charts can be used along with each sprint’s burndown. The velocity chart can be used to measure consistency and many more of the reports provided can help. Look for an article about reporting here in the future. Story Points assigned should follow the weight set to each KR when planning sprints. The prioritization of the KRs should always be in mind while developing to keep planning and strategy aligned while executing and leveraging the OKRs.

Course correct often using the OKRs, if a feature is not contributing to the KR, consider putting it lower on the backlog for now or consider changing the KR. As this is the power in agile, things are always changing as we learn more. PMs should make the KR part of the sprint goals and mention the current focus on daily scrums and weekly backlog refinement meetings. As sprints progress and the backlog burns down, remind the team and stakeholders of the KRs being worked on each sprint and why they’re important. This also provides a solid base to say no to new suggestions and features that can disrupt planned changes.

When incremental pieces of the KR are completed, release them to production. Document the launch date so KRs can be attributed to them later. Remember that most KR won’t be impacted immediately; it takes time for users and the system to prove things one way or the other.

As sprints are closed and completed use the KR from that sprint to drive discussion during the Retro and Review meetings. Baking this learning into the overall process lets a PM continue to evolve and to get closer to the KR we committed to and to the “Product Management Ideal”.

Nothing is more rewarding than seeing the impact of work done against Key Results. This energizes the team and PM. Everyone should be empowered towards achieving this and the long term product vision. By keeping OKRs at the core of everything done, we ensure an outcome driven strategy from day one. They should be used and referenced at every stage of the product life cycle.

Whew, what a read. If you made it this far, thank you. Please remember to start small and simple with these frameworks and processes. Don’t let great be the enemy of good. Get started on it and work each quarter to get better and strive for the “Ideal” via incremental approaches. Don’t force microproritization or waste days of time researching the perfect KR. These things evolve over time so get started and get better.

The last piece to mention would be closing the loop, looking back on the KR. It’s important to look back on KRs and understand the success/failure results to adapt strategy and future OKRs. The best innovations on a product often come from the team closest to the code and to the customer. Encourage creativity and do not stifle innovation. KRs can always be changed as long as they align with the strategy and vision!

Key Results should excite the team but also feel achievable for them. Some organization cultures will work differently but in general teams prefer to succeed without hoping that the planets align. Set OKRs for 1-2 Quarters in advance, some teams and products are more aggressive, but you still need long term targets even if you have a few short ones.

With that, I’ll leave you with a modified 10 step process for OKR Driven Product Management. Please reach out to let me know your thoughts on this, I’m happy to help out and to answer any questions. If you’re interested in working on Agile or Scrum teams, reach out for career or certification advice.

Step 1: Define Objective and Key Results

Step 2: Brainstorm a Backlog for each KR

Step 3: Refine and Organize Backlog to associate product backlog items with KRs

Step 4: Verify that telemetry exists or ways to measure and view the progress towards your defined KRs

Step 5: Build a 3-6 month product plan

Step 6: Execute

Step 7: Launch

Step 8: Measure

Step 9: Close the loop and analyze the previous hypothesis to gauge success or failure

Step 10: Rinse and Repeat while continuously improving