Why Most Product Strategies Aren't Strategies
Why Most Product Strategies Aren't Strategies
Three Scenes. Same Problem.
Scene 1: A product team sets OKRs. "App engagement +40%." "Service tickets -30%." Ambitious. Measurable. Everyone nods. Nobody asks: Why are tickets high? What exactly prevents engagement? The OKR is set. The diagnosis is missing.
Scene 2: A CTO announces the new direction. Last year: Agile Transformation. This year: AI First. Next year: Platform Thinking. Every label sounds like progress. But the question stays the same: What's actually the problem? Nobody asks. So next year brings the next label.
Scene 3: The strategy deck is done. 40 slides. Customer-centric. Data-driven. Innovative UX. Sustainable value creation. Remove the buzzwords and one sentence remains: "We're building a product." Everyone knew that already.
Three scenes, three variations. But always the same mistake.
The Step Everyone Skips
In 19 years of product development, I've seen this pattern in every industry. Health tech, IoT, insurance, e-commerce, public sector. The details change. The pattern doesn't.
It looks like this:
"We have a problem" - straight to - "Let's do X"
In between lies a step that almost everyone skips: The diagnosis.
Not the analysis. Not the discovery board. Not the stakeholder interview. But the decision: What exactly is the problem here? Not the symptom. Not the assumption. The problem.
Diagnosis means: from the entire complexity of a business, naming the one thing that determines success or failure. That's not a workshop outcome. That's a judgment call.
And that's exactly why it gets skipped.
Why Diagnosis Is Uncomfortable
Diagnosis creates disagreement.
When someone says "Our problem isn't the team, it's the architecture" - someone feels attacked. When someone says "We don't need a new feature, we need a decision" - someone has to make that decision.
OKRs create consensus. Everyone nods at "engagement +40%." Labels create momentum. "AI First" sounds like the future. Buzzwords create agreement. Nobody argues against "customer-centric."
Diagnosis creates none of that. It creates clarity. And clarity is uncomfortable because it means: we have to decide something. And let go of something else.
What Works Instead
Product strategy that deserves the name has three parts. Not five. Not twelve. Three.
1. Diagnosis: What's the Problem?
Not "we need to move faster." But: What exactly stands between today and the goal? Is it the architecture? The team structure? A missing decision? A regulatory hurdle?
Diagnosis reduces complexity to what matters. "Everything is hard" becomes "this is the bottleneck."
2. Direction: What Do We Rule Out?
A good strategy doesn't just say what you do. It says what you don't do. It's a guardrail, not a finish line.
"We focus on the German market and postpone US expansion" - that's a direction. "We want to grow internationally" - that's a wish.
The difference: A direction rules something out. A wish rules nothing out. That's why the wish feels better. And that's why it doesn't work.
3. Coordinated Action: What Works Together?
Individual measures aren't strategy. Strategy emerges when measures are aligned.
When the product team builds features, but the sales team sells something else, and marketing tells a third story - then everyone has a measure. But nobody has a strategy.
Coordination is the most underestimated part. Not because it's hard to understand. But because it means departments have to talk to each other. And agree.
The One Question
All of this boils down to one question:
"How do you know it works?"
No product launch without a clear answer to:
- What's the one lever that determines success?
- What costs do we save - and how do we measure it?
- How much time do we gain compared to the original plan?
- What risk do we take off the table?
- Does it run without me?
Five questions. None of them answerable without diagnosis.
Ask these questions before the first feature is planned, and you save months. Skip them, and you build faster - but the wrong thing.
→ The 5 Questions for Product Success
Not a Framework. A Decision.
This isn't a new model. Not a canvas. Not a template.
It's a decision: Do I start with the diagnosis - or with the solution?
Most start with the solution. Because it's faster. Because it feels productive. Because diagnosis means admitting you don't understand the problem yet.
My job starts right there. Not at the deck. Not at the OKR. Not at the framework.
At the question everyone skips.