Objectives and Key Results (OKRs) are one of the most popular frameworks that many companies use to define success; however, many product teams struggle to use them effectively. We sat down with Jeff Gothelf, Author and Leadership expert, to discuss his latest book, "Who Does What by How Much?" and explore how product teams can better leverage OKRs.
You've recently published a new book about OKRs. What inspired this project?
We've spent the better part of this year finishing and launching "Who Does What by How Much?" It's an opinionated book that puts a customer-centric spin on objectives and key results to make them powerful and useful. The core focus is ensuring that organisations set goals that are human-centric, rather than feature-centric. Ultimately we want companies to build products that solve real needs for real customers in a meaningful way.
Why have OKRs become so widely adopted across organisations?
The popularity of OKRs has risen sharply in the last decade, particularly after John Doerr's "Measure What Matters" highlighted their use at Google. Many organisations were drawn in by the message that "Google uses them, and Bono uses them," leading to widespread adoption similar to how companies have embraced other methodologies like Agile and Design Thinking.
However, “Measure What Matters” wasn't a clear guide to implementing these ideas at scale. While organisations see the value in OKRs and want to emulate successful companies, they often struggle with the deployment and utility of OKRs. This has led to a rash of poor implementation and team burnout across industries.
What does poor OKR implementation look like, and why do organisations often get it wrong?
Until our book, no one had taken a strong, opinionated stance about what good OKRs should look like and, frankly, why they were worth doing at all. We advocate for customer-centric OKRs where the objective is a qualitative statement about a future benefit for customers, and key results are outcomes measuring user behaviour that indicate you have delivered value.
Organisations often get this wrong in two fundamental ways:
- Using Outputs Instead of Outcomes:
- They might set an objective like "become the easiest way to shop for groceries online in North America"
- But then list key results like "launch the mobile app" or "launch the affiliate marketing campaign"
- These are outputs (activities and features) rather than measures of human behaviour that indicate we delivered anything of value
- This essentially rebrands their current goal-setting framework as OKRs without making meaningful changes
- Lack of Discovery Freedom:
- Even when organisations write good customer-centric OKRs, they don't allow teams to do the discovery work required to determine what to build to hit those goals
- Teams aren't given the autonomy to determine which combination of code, copy, design, or marketing will deliver the desired behaviour changes
- When teams find evidence that a prescribed solution isn't working, they're often still required to build it
- This defeats the purpose of outcome-based goals and reverts to traditional command-and-control management
Is training required to get OKRs right, or can teams learn through trial and error?
Some form of preparation is necessary. While it might seem self-serving since I provide training, you can't simply announce, "We're doing OKRs today" and expect success. Whether through books, classes, or formal training, organisations need to educate their entire workforce about what they're doing, why they're doing it, and what success looks like. This becomes particularly critical when implementing OKRs at scale.
How should product teams handle friction from leadership about OKRs?
OKRs should enable objective conversations throughout the organisation. When a team is underperforming, the conversation should focus on what the team has learned rather than where they've failed. If leadership feels OKRs don't align with corporate strategy, the team should be able to tell a compelling story about how their goals support the organisation's higher purpose.
For example, if you're on an authentication team and corporate goals focus on cost reduction, you might explain: "We aim to create the most efficient authentication process in online food shopping. This will reduce call centre complaints about login issues by 90%, decrease password reset requests, and reduce time to first purchase." These outcomes directly connect to cost reduction and profit improvements.
If a team can't tell this story convincingly, then leadership might be right about the misalignment, and the OKRs may need adjustment. The key is that these conversations become objective rather than subjective – focusing on what’s actually taking place within the product the team is building rather than stakeholder opinion.
Should OKRs be adapted for different company contexts?
While the basic formula remains consistent across industries, context matters significantly when identifying customers and users. This becomes particularly important in several scenarios:
- B2B2C Organisations: Customers (buyers) and users (employees or end customers) are different groups
- Internal Teams: Like HR, where "customers" are company employees
- Support Functions: Teams that don't directly serve external customers
For example, consider an HR team implementing an unlimited holiday policy. Their key results might include:
- 15% increase in holiday time taken
- Improvement in general performance metrics
- Increase in employee referrals
However, if they find that people actually take fewer holidays under the new policy, it raises important questions about implementation success and whether the policy achieves its intended outcomes.
What are the best practices for introducing OKRs?
Here are the basic guidelines:
- Number of OKRs:
- Fewer is better - OKRs help focus on the most important things
- Aim for one objective per team
- Limit to 1-3 key results (maximum 4)
- Multiple OKRs mean multiple priorities, forcing daily decisions about what to ignore
- Review Cadence:
- Weekly: Team-level progress checks and learning discussions
- Monthly: Updates with immediate stakeholders
- Quarterly: Comprehensive review with key stakeholders to assess progress and potential priority shifts
- Team Composition:
- Small teams (5-7 people): Whole team can write OKRs together
- Larger teams: Have representatives from product, design, and engineering draft OKRs and get team feedback
- Cross-functional collaboration is essential, but too many voices can complicate the process
How can organisations get started with OKRs?
The most common question is where to start, especially in large organisations. The key is to start small and scale gradually:
- Begin with a small team (6-10 people)
- Run a 12-week experiment
- Give them a specific project and help set OKRs
- Allow them to figure out how to work within your company's context
- Use successful results to justify scaling to more teams
- Address scaling challenges as they arise
Don't worry about enterprise-level OKR tracking software until multiple teams have successfully used OKRs. The key is to win small, gather evidence, and use that to drive broader adoption.
How can OKRs help AI initiatives?
Rather than asking how AI can help OKRs, we should consider how OKRs can help AI initiatives. OKRs provide an objective lens for evaluating AI implementations by focusing on:
- The specific problem being solved
- Who it's being solved for
- Expected behaviour changes
- Measurable value delivery
This approach helps organisations avoid implementing AI for its own sake and instead focus on delivering real customer value. When leadership pushes for AI implementation, teams can use OKRs to guide the conversation toward concrete outcomes and user benefits rather than just checking a box.
The framework helps teams ask critical questions:
- What problem are we solving?
- Who is it for?
- What behaviour changes do we expect?
- How will we measure success?
This objective lens ensures AI implementations actually add value rather than just following trends.
Comments
Join the community
Sign up for free to share your thoughts