George from 🕹prodmgmt.world Profile picture
May 19 15 tweets 3 min read Read on X
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
 

Keep Current with George from 🕹prodmgmt.world

George from 🕹prodmgmt.world Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @nurijanian

May 20
I almost quit product management after being torn apart in a decision meeting:

"You need to pick - either we ship on time or we maintain quality. You can't have both."

What my VP didn't realize: this false dichotomy was destroying our team morale.

Here's the 5-minute framework that changed everything 🧵
1/ Most PMs get trapped in impossible trade-offs:

- Speed vs. quality
- Features vs. timeline
- Innovation vs. stability

We've been taught to "make the hard call" - but what if the premise itself is wrong?

After 100s of painful decisions, I discovered a better way.
2/ The conventional wisdom is broken:

"A good PM makes tough decisions quickly and sticks to them."

This creates rushed decisions based on false constraints.

The hard truth: The most courageous thing you can do is reject the premise of the question.
Read 16 tweets
May 20
Your customer said "Great idea!" and you felt good.

But 3 months and $50K later, they never used the feature.

If this sounds familiar, here's how to never get fooled by false positives in customer conversations again:

A thread on the "5-Minute Truth Technique" 🎯
1/ If a customer compliments your idea, they're probably lying.

Not because they're mean. Because they're nice.

They don't want to hurt your feelings.

So when they say "Cool idea!" what they really mean is "Please stop talking about your solution."
2/ The biggest mistake you can make is describing your solution first.

If you say "We're thinking of building X..."
You've already lost.

The customer will either:
- Be nice (useless feedback)
- Design by committee (dangerous feedback)
Read 15 tweets
May 19
product managers keep making this fatal mistake with technical debt: treating it as an engineering problem.

after watching dozens of products grind to a halt under invisible weight, i discovered a better approach.

here's the exact framework that changed everything:
1/ most pms get caught in this trap:

engineer: "we need to address technical debt"
pm: "not now, we have features to ship"

eventually:

- velocity grinds to a halt
- bugs multiply
- simple changes take weeks
- credibility erodes
2/ the hard truth:

technical debt is not an engineering problem.

it is a product strategy problem.

when engineers raise technical debt concerns, they're really saying: "our foundation cannot support what you want to build next"
Read 11 tweets
May 18
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
Read 18 tweets
May 17
My first year as a PM, I burned bridges by saying 'no' wrong:

- Lost eng team trust
- Damaged stakeholder relationships
- Got labeled as 'not a team player'

Until I discovered this counterintuitive approach to saying no (that actually builds stronger relationships)

🧵
1/ The conventional wisdom is broken:
- "Just say no firmly"
- "Stand your ground"
- "Protect the roadmap"

These create adversaries, not allies.

The hard truth: Your 'no' is probably making you look weak, not strong.
2/ The real problem isn't saying no.

It's that most PMs try to win the current battle (saying no to a request) while losing the war (long-term influence).

I made this mistake for 18 months until I learned this framework:
Read 11 tweets
May 17
"Documentation is killing me"

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
Read 11 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(