The Solution Trap: Why the Best PMs Spend 80% of Their Time on the Problem
Most product teams spend 20% of their time on the problem and 80% on the solution. The best invert this ratio — and ship fewer things that work better.
There is a moment every product manager knows.
A customer complaint comes in. A sales rep flags it. An executive hears it at a conference. And within 24 hours, someone has already sketched a solution.
By the time the PM is in the room, the conversation has moved on from "is this a real problem" to "how do we build this feature." The problem — its scope, its root cause, who exactly has it and how often, what it costs them, what they've already tried — has received about 90 seconds of consideration. The solution will receive six weeks of engineering.
This is the solution trap. And most product organisations live inside it full-time.
Why Smart People Fall In
The solution trap isn't a failure of intelligence. It's a failure of incentives and workflow.
Solutions are concrete. Problems are ambiguous. A feature request has a clear shape: "add a dashboard," "build an export," "send a notification." It can be scoped, estimated, designed, and demoed. A problem is slippery — it requires definition, and definition takes investigation.
Solutions create visible progress. Problem work looks like nothing happening. Talking to customers, synthesising interview notes, mapping assumptions, building a shared understanding of what's actually broken — none of this looks like work to someone watching the roadmap. But shipping a feature that doesn't solve the real problem looks exactly like progress, right up until the moment it doesn't move the metric.
Every system rewards solutions. Jira tracks features. Roadmaps list deliverables. Quarterly reviews celebrate shipped things. The PM who spent three weeks deeply understanding a problem and then concluded it wasn't worth solving has nothing to show at the all-hands. The PM who shipped the wrong feature has a demo.
The Real Cost
The solution trap costs more than wasted engineering cycles. It costs the mental model.
When a team defaults to solution mode, they stop building accurate maps of the problem space. Over time, the product becomes a collection of solutions to imprecisely understood problems — a patchwork of features that each solved something, but never quite the right thing.
This is what produces the experience every PM dreads: a product with 100 features that users don't trust, because none of the features feel like they were built by someone who really understood what the user was trying to do.
Keep reading
Spec Hallucination: The 15-Minute Claim Trace for AI-Written Specs
AI writes specs that sound sourced but often aren't. The Claim Trace is a 15-minute audit that labels every claim Sourced, Inferred, Assumed or Invented before engineering builds from it.
What Counts as Evidence? The Risk Receipt for Value, Usability, Feasibility, and Viability
AI made feasibility cheap to prove. Value, usability, and viability still need their own evidence — and a great prototype demo counts for less than it feels like. Here's the Risk Receipt framework for checking what you've actually retired.
What Product Managers Should Never Delegate to AI
AI can summarize evidence and propose options, but some product decisions should remain human-owned. Here are the judgments PMs should never delegate without review.