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
How PMs Say No: Killing Features Without Killing Trust
Most PMs say yes when they should say no — not because they lack opinions, but because they lack organised evidence. Here's the four-part framework for declining feature requests in a way that builds trust instead of burning it.
Product Intuition: How Senior PMs Make Good Calls With Incomplete Information
Product intuition isn't a gut feeling — it's calibrated judgment. Here's the three-level evidence framework senior PMs use to make confident calls when the data is incomplete.
The PM's Decision Log: How to Make Every Product Choice Visible, Searchable, and Accountable
Every product team makes hundreds of decisions per quarter. Most disappear into Slack. Here is the five-field decision log that makes every product choice visible, searchable, and accountable — and the habit that keeps it alive.