Your OKRs keep failing because they're masquerading as strategy.
It's not about writing better OKRs - it's about having a strategy that makes OKRs worth writing.
After mentoring dozens of PMs through this exact challenge, here's the framework that actually works:
1/ First, let's understand what strategy isn't:
• A collection of targets
• A list of initiatives
• A set of KPIs
Strategy is a coherent set of choices about where to play and how to win.
Everything else - including OKRs - flows from these choices.
2/ The dangerous pattern I see in most product organizations:
Leadership: "We need 30% growth"
Teams: *scramble to break this down into quarterly OKRs*
Result: Fragmented efforts that don't compound
This isn't strategy - it's wishful thinking dressed up in methodology.
3/ Here's what actually works:
Before touching OKRs, answer these questions:
• What unique value can we deliver?
• Where do we have advantage?
• What capabilities do we need?
• How will we build them?
THIS is strategy. OKRs measure progress against it.
4/ Example from a real product team I worked with:
Bad "Strategy":
"Increase NPS by 15 points through better UX"
Better Strategy:
"Win in mid-market by solving integration pain through API-first architecture, starting with top 3 enterprise systems"
See the difference?
5/ The transformation framework:
Step 1: Map Your Playing Field
- List all possible segments
- Identify unique advantages
- Find underserved needs
- Spot capability gaps
6/ Step 2: Make Clear Trade-offs
- Choose specific segments to serve
- Decide what you won't do
- Identify key capabilities to build
- Define your unique approach
This is where most teams get stuck. They try to do everything.
7/ Step 3: Build Strategic Capabilities
- Focus on 1-2 key capabilities
- Create learning loops
- Measure progress systematically
- Adjust based on evidence
NOW we can talk about OKRs.
8/ Using OKRs properly:
- Measure progress on capability building
- Track strategic position improvement
- Monitor competitive advantage growth
- Guide resource allocation
Not: Random growth targets hoping for magic.
9/ Common objections I hear:
"But my executives want growth targets!"
Yes, and you'll hit them more reliably with real strategy than wishful OKRs.
10/ For product leaders:
Your job isn't to enforce OKR compliance.
It's to:
• Build strategic capabilities
• Make clear trade-offs
• Guide resource allocation
• Measure what matters
OKRs should serve strategy, not replace it.
11/ "But we need to move fast!" - I hear this a lot.
A PM I mentored felt pressure to "move fast" with OKRs, but instead:
1. Mapped capabilities in a day 2. Identified a key integration gap 3. Realigned the team 4. Met goals quicker
Speed via clarity
12/ Immediate actions you can take:
Today:
• Map current capabilities
• List explicit trade-offs
• Identify strategic gaps
This Week:
• Share analysis with team
• Get alignment on 1 key capability
• Design measurement system
Next Sprint:
• Start capability building
• Measure progress
• Adjust course
13/ For executives pushing hard for OKRs:
"I want to ensure our OKRs drive real growth. Can we spend 2 hours mapping our strategic position to make them more effective?"
This reframes the conversation from compliance to results.
14/ Real talk: You don't need months of strategy work.
You need:
• Clear choice of where to play
• Explicit trade-offs
• Focus on key capabilities
• Systematic measurement
I've collected practical frameworks for this exact challenge in prodmgmt.world
• • •
Missing some Tweet in this thread? You can try to
force a refresh
When execs say “just whip up the PRD by tomorrow,” most junior PMs say yes... and immediately set themselves up to fail.
I did this for years until a principal PM taught me how to bridge the gap between speed and quality.
Here’s the 4-part framework I wish I had on day one:
1/ when your exec says "we need that prd by tomorrow, it shouldn't take more than a few hours" but you know it needs days of work, you're experiencing the classic product estimation gap.
2/ veterans know this happens because executives and product managers operate with different mental models of documentation.
executives think about prds as: 1. a simple description of what to build 2. a checkbox for process compliance 3. something that should be quick to produce
That was me 3 years ago, overwhelmed by 5 unfinished PRDs.
My ADHD brain struggled with the usual "sit down and write" method every PM book suggests.
Here's what finally worked after many failures:
1/ The Voice Note Method
Stop trying to write perfect prose immediately. Instead:
• Walk around and talk through your thoughts
• Record voice notes explaining the problem/solution
• Use Otter or Rev or many other similar apps to transcribe
• Clean up the transcription
Your brain works better in motion. Use it.
2/ The Screenshot Journal
Instead of trying to remember everything:
• Take screenshots of important Slack discussions
• Capture whiteboard photos
• Screenshot key metrics
Create a Miro board as your "evidence board"
Later, writing becomes connecting dots instead of recall