It’s no secret that many companies struggle with Objectives and Key Results. As I wrote before, a very common problem is setting goals for outputs — work to do — rather than for outcomes — positive changes to achieve. This turns OKR into an expensive work planning process, and may lead to nasty side-effects such as feature factories, bloated projects, and massive waste. But outcomes are avoided for a reason: they are often harder to set and to achieve, they require major changes in the way the org thinks and acts, and they’re not at all natural or intuitive. Outcome goals are such a big challenge that some question the entire concept. I regularly see suggestions for hybrid goal systems that focus on “good outputs” that ultimately will lead to outcomes (hopefully).
Are we seeing the end of the outcomes-over-output rule? Have we come full circle back to outputs? In this article I’ll try to convince you that the answer is No. Outcome goals are still the right answer, but you’ll have to understand what you’re working against and how to fix it.
Let’s start with the problem.
The Four Gaps: Mindset, Leadership, Knowledge, Execution
I typically see four types of gaps holding companies back from using outcome goals:
- Mindset gap — people are not ready to let go of outputs
- Leadership gap — we set wrong outcomes, too many, ever changing, top-down only…
- Knowledge gap — we don’t know how to achieve the outcomes
- Execution gap — we’re unable to make progress towards the outcomes
Each gap can slow you down or even get you stuck. All four gaps together can seem insurmountable. It’s tempting to invent a have-your-cake-and-eat-it-too goal system that combines outcomes and outputs. Alternatively you can try to close the gaps with big initiatives: heavyweight processes, developing dev and experimentation infra, replatforming, and so on. Yet another approach is to extend the goal cycle to six months or more. I consider all of these wrong answers as they either avoid the problems, or try to fight them with more output.
Here’s an alternative approach to consider:
- Start using outcome goals right now where you can. For example if the mindset is ripe in some parts of the company, say certain product teams, start there. If you don’t have the infrastructure to run A/B experiments, start discovering your product using surveys, customer interviews, and fake door tests. Don’t wait for some “big-fix” that will take ages and may not really fix anything.
- In parallel work to close the gaps incrementally
- Identify the most important gaps in your area of responsibility: what’s most holding you back today?
- Set goals to reduce the top gaps — where do we want to be in 6, 12, 24 months? What can we measure that will indicate that we’re moving in the right direction? These are self-improvement outcomes. I’ll show you some examples below.
- Make progress through continuous-improvement. Try to make inroads to closing the gap every week, month, and quarter.
We will dive into the gaps and discuss how to close them shortly, but first let’s look at a real-world example.
In my Lean Product Management courses we practice using principles, frameworks and tools that bring modern product management thinking into any org.
Secure your ticket for the next public workshop or contact me to organize an in-house workshop for your team.
HP’s LaserJet Firmware Division Reboot
The book Lean Enterprise offers an instructive case study:
HP’s LaserJet Firmware division builds the firmware that runs all their scanners, printers, and multifunction devices. The team consists of 400 people distributed across the USA, Brazil, and India. In 2008, the division had a problem: they were moving too slowly. They had been on the critical path for all new product releases for years, and were unable to deliver new features: “Marketing would come to us with a million ideas that would dazzle the customer, and we’d just tell them, ‘Out of your list, pick the two things you’d like to get in the next 6-12 months.” They had tried spending, hiring, and outsourcing their way out of the problem, but nothing had worked. They needed a fresh approach.
Activity counting surfaced a clear execution gap: 95% of the team’s time was spent on code integrations, planning, porting code between dev branches, product support, and manual testing, which left just 5% for innovation work.
The leaders of the division proceeded to set the following goals: 1) increase the ratio of innovation work tenfold 2) Eliminate the need to port code between dev branches (which took 25% of overall time when they started) 3) Reduce significantly the time spent on detailed planning.
As you can see these are all outcomes.
Next came the execution. The team faced a set of big, hairy problems. They knew they’ll likely have to rewrite their platform, add automated testing, introduce continuous integrations and deployment, and move to trunk development. All big changes that normally would start with months of planning, followed by quarters-to-years of implementation. But the division took a different approach :
They did not know the details of the path to these goals and didn’t try to define it. The key decision was to work in iterations, and set target conditions for the end of each four-week iteration. … the objectives for the entire 400-person distributed program for a single month was captured in a concise form that fit on a single piece of paper.
Here’s an example:
Source: Lean Enterprise: How High Performance Organizations Innovate at Scale
Again, these are all measurable outcomes.
During the iterations the team didn’t try to enforce strict planning and execution either, but rather relied on product discovery and experimentation to make progress.
The results were nothing short of impressive:
After two years of development, the new firmware platform, FutureSmart, was launched. As a result […] the team was able to achieve “predictable, on-time, regular releases so new products could be launched on time.” Firmware moved off the critical path for new product releases for the first time in twenty years. This, in turn, enabled them to build up trust with the product marketing department.
Three years into the process, the team was in a very different place: Innovation work went from 5% to 40%, time spent on support reduced from 25% to 10%, and overall development costs went down by 40%. Very different from the results of most big improvement initiatives.
Join thousands of of product people who receive my newsletter to get articles like this (plus eBooks, templates and other resources) in your inbox.
Closing the Gaps to Outcome Goals
Next let’s look at each gap up close. I’ll show you examples of both outputs and outcomes for closing each gap, but there are many more options for both.
Mindset Gap
Working towards outcomes goes against many traditional best practices and requires people to change the way they think and act. Leaders (at all levels) should focus on creating a concise set of outcome-based goals, share lots of context, and remove impediments to execution. Product teams should focus less on producing code and more on creating value for users and the business. People will need to coalesce around the outcomes across disciplines and org silos. Trust is a key ingredient. Incentives may have to change.
As long as you don’t change the mindset, people will try to revert to output.
Mindset is not easy to change or to measure. A lot of the change will come with practice, as people get a taste of the new model and start seeing the results. The process to get there may take many shapes, but having clear targets, holding open discussions and retrospectives, and iterating continuously are key to success.
Example outputs:
- Better hiring practices
- Everyone goes through OKR training
- Deploy a new process across the org
- Weekly progress reviews
- Quarterly retrospectives
Example outcomes
- Time spent on planning (measured in person/week per quarter) goes down from X to Y
- Maximum one sales escalation per quarter
- The ratio of outcome key results grows from X% to Y%
- No output-based incentives
- Employee surveys indicate most people are feeling they are working towards clear outcomes, have the necessary context, and understand why these outcomes are important.
Leadership Gap
Even if we agree on the need for outcome goals, we may inadvertently set bad ones. Whether you’re leading a company, a business unit, a group, or a team, you may fall into one of these traps:
- Focusing on the wrong outcomes
- Targeting too many outcomes
- Setting overly ambitious or overly conservative targets
- Fuzzy/unmeasurable outcomes
- Constantly switching goals or moving the goalposts
- Outcomes are set top-down without bottom-up feedback
All of these are serious problems that can defocus us, send us in the wrong direction, and drain people’s trust in the goals.
Underlying these are often some bigger challenges:
- Unclear mission
- Unclear strategy
- Unclear target market
- Unclear top objectives
- Unclear priority between many possible metrics and business KPIs
Closing the leadership gap doesn’t have to start from the top. I’ve seen product organizations lead the charge within, with the rest of the company following later. Every product team should strive to understand its mission and top metrics, and identify what context it’s lacking to make good goal choices. This is good feedback to communicate up the chain of command, and the basis for self-improvement outcomes.
Example outputs
- Do a strategy offsite
- Do a market segmentation exercise
- Conduct market research
- Send managers to leadership training
Example outcomes
- The company is working towards a small set of clear strategic goals/opportunities
- The company has a clear North Star Metric and Top Business KPI.
- Company-level yearly OKRs include maximum 3 objectives with no more than 4 outcome key results each. These OKRs call out the most important things the company must achieve in the following year.
- Every team has a clear area of responsibility, set of core metrics, and (optionally) a mission.
- Every team has quarterly OKRs that include a maximum of four outcomes-based key results across one or two objectives. These again call out the most important things the team has to achieve
Knowledge Gap
Even if we have good, concise goals, we may lack the necessary domain knowledge to achieve them:
- We’re not sure what the top underserved user needs (now often dubbed ‘opportunities’) are
- We’re not sure which customer requests are most important
- We’re not sure what will most help the business
- We’re not sure if we have the right technology
- There are multiple ideas and hypotheses, but we don’t know which one will work best
All of these are solvable through research, experimentation, prioritization, analysis, and iteration.
Example Outputs
- Map out user journeys
- Conduct 20 user interviews per quarter
- Run 30 A/B experiments
- Analyze usage patterns
- Create idea banks
- Start using ICE
Outcomes
- Identify 3 top underserved needs/jobs backed by qualitative and quantitative research
- Identify 3-5 ideas per key-result that are validated at least by assessment and fact-finding.
- No ideas launched without at least medium confidence level
Execution Gap
Working towards outcomes is very different from working towards outputs. Product teams need to get good at research, product discovery, and delivery. Working in short build-measure-learn iteration is imperative. But there’s a long list of reasons why they may not be able to:
- Legacy code
- Lots of maintenance work / tech debt
- Slow integration and launch processes
- Many dependencies
- Missing analytics or experimentation tools
- Lacking user researchers or data analysts
- No access to customers
The execution gap is often the most visible and the hardest to close. It’s tempting to invest in big initiatives, for example replatforming/refactoring projects, but those can easily turn into big output goals that ironically become impediments to closing the gaps. Worse, they’ll give us an excuse to stick to outputs as we wait for the big initiative to finish. Most likely you will have to make some big changes, but it’s best if you’re always working towards short-term improvement outcomes you can measure. Proceed towards those through continuous discovery, experimentation and, discuss the results.
Example Outputs
- Do a reorg
- Build or buy an experimentation / analytics platform
- Install a CI/CD system
- Do a major replatform/refactor initiative
- Hire UX researchers and data analysts
- Adopt Kanban
Example Outcomes
- Grow number of insights gained through idea validation/experimentation per month
- Grow number of evidence-guided product decisions
- Reduce numbers of delayed ideas due to dependencies
- Reduce average time to launch a completed ideas
Conclusion
You need to work on two types of outcomes at the same time:
- Business/user outcomes
- Self-improvement outcomes (mindset, leadership, knowledge, execution)
There may be a chicken-and-egg problem here. We can’t effectively achieve business/user outcomes unless we self-improve, but we have no time to self-improve as we’re very busy with business/user-facing work. The suggestion is to set realistic outcomes for both and to make constant forward-traction. You won’t transform overnight, and you may be in an uncomfortable middle state for a number of quarters, but from month to month you should see an improvement, as will your colleagues and managers. With persistence you’ll pick up momentum and accelerate, and eventually, like the LaserJet Firmware Division, you may achieve a major transformation.
Recommended books:
- Lean Enterprise – Jez Humble, Joanne Molesky, Barry O’Reilly
- Outcomes over Outputs – Josh Seiden
If you wish to up-level your PM skills check out my next public workshops or contact me to organize an in-house workshop or keynote for your team.
