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.
The Solution Trap: Why the Best PMs Spend 80% of Their Time on the Problem
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
Most "AI Features" Shouldn't Be AI Features. Here's the Test That Tells You.
Most "AI features" shipped in 2026 are rules engines wearing an AI costume. Here's the four-question test to run before you spec one — and what it looks like when a feature fails all four.
The Product Velocity Illusion: Why Shipping Faster Hasn't Made Your Roadmap Better
AI collapsed the time it takes to build a feature, but not the time it takes to decide what to build or validate that it worked. The Three Clocks framework shows product teams where their real bottleneck moved — and how to stop mistaking build speed for progress.
Your Next User Might Not Be Human: A PM's Framework for Agent-Ready Products
Software is quietly picking up a second audience — AI agents acting on a human's behalf. Here's a framework for auditing whether your product actually works for both.