User Solutions vs User Problems Framework
By Dennis Chow · 7 min read
I watched a product team spend six months building a "dark mode" feature. Users had been asking for it in every feedback channel. The Jira ticket had 247 upvotes. Leadership approved the roadmap commitment.
Three months after launch, adoption was at 11%.
The real problem? Users were experiencing eye strain during long sessions because the product required constant context-switching between high-contrast data tables. Dark mode was the solution they imagined. The actual problem was information density and navigation flow.
This happens more often than most PMs admit. We confuse the solutions users propose with the problems they experience. And that confusion costs us months of development time building the wrong things.
Why Product Teams Confuse User Solutions with Problems
Users are brilliant at experiencing problems. They're much less reliable at diagnosing them.
When someone says "I need a dashboard," they're not describing a problem. They're pitching a solution. The problem might be: "I can't see project status without asking three people" or "I'm surprised by blockers in standups" or "My manager asks questions I can't answer." Each of those problems might lead to very different solutions than a dashboard.
The confusion happens because solutions are concrete. They're easy to picture, easy to prioritize, easy to put in a roadmap. Problems require interpretation. They're uncomfortable to sit with. They demand follow-up questions.
Most product teams are also structurally incentivized to move fast. A customer asks for CSV export — you add it to the backlog. It's clean. It's measurable. It feels like progress.
But speed in the solution space often means waste. You build the CSV export and later discover they actually needed automated reporting to a BI tool because their analyst was spending full days reformatting CSVs. You solved the stated request while missing the underlying job.
The User Problems vs Solutions Framework Explained
The framework is deceptively simple: separate problem space exploration from solution space execution.
Problem space is where you live in the user's world. What are they trying to accomplish? What's blocking them? What's the cost of that friction? You're not evaluating feasibility or debating implementation. You're building a complete picture of the problem before you touch a design tool.
Solution space is where you live in product execution. What should we build? How should it work? What's the technical approach? This is where most PMs are comfortable — it's the traditional product development process.
The critical insight: you can't evaluate solutions until you've fully mapped the problem. But most teams skip the problem space entirely, or spend maybe one discovery call there before jumping to wireframes.
In practice, the framework means staying in problem space until you can articulate:
- The job the user is trying to complete
- The current workaround or failure mode
- The frequency and cost of that failure
- The outcome they're measuring success against
Only then do you move to solution space and ask: what's the smallest thing we could build to solve this problem?
How to Identify Real User Problems (Not Disguised Solutions)
The tell is usually in the language. Solutions sound like features. Problems sound like situations.
Solution language:
- "We need an API"
- "Can you add filtering to this table?"
- "I want to duplicate this workspace"
Problem language:
- "Our dev team can't access this data in their tools"
- "I can't find the accounts I'm looking for in this view"
- "I have to rebuild the same structure every quarter"
When you hear solution language, your job is to rewind the conversation. The question I use most often: "Walk me through the last time you ran into this. What were you trying to do?"
Then I shut up and listen for the actual situation. Not what they think would fix it — what was happening when they felt the pain.
You're looking for the moment before they started problem-solving. That moment contains the real problem.
Another pattern: if you hear the same solution request from multiple users but their contexts are completely different, you're definitely looking at disguised solutions. Three customers ask for "better notifications." One is missing time-sensitive updates. One is overwhelmed by noise. One wants to route different alerts to different tools. Same solution request, three unrelated problems.
From Problem Space to Solution Space: A Practical Workflow
Here's how I actually run this in practice:
Week 1-2: Problem space immersion Talk to 8-12 users. Don't bring mockups. Don't bring prototypes. Just ask them to show you their current workflow. Watch where they switch tools, pause to think, curse under their breath, or apologize for "the messy way we do this."
Document the problem statements in their words. I keep a running doc of direct quotes. "I rebuild this view every Monday because I can't save filters" is infinitely more valuable than my interpretation of their workflow.
Week 2-3: Problem clustering
Look for patterns across conversations. Are these the same problem or different problems that sound similar? I usually find 3-5 distinct problem clusters even when users all requested the same feature.
For each cluster, write the problem statement without any solution implications. "Users can't track status changes over time" not "Users need a changelog."
Week 3-4: Solution evaluation Now you can brainstorm solutions. With clear problem framing, you'll often find you can solve the same problem multiple ways — and some are 10% the effort of the original feature request.
This is also where you can spot problems that don't need product solutions at all. Maybe they need documentation. Maybe they need workflow changes. Maybe they need a Loom video.
Week 4+: Build and validate Ship the smallest version that solves the problem. Watch actual behavior, not surveys. If usage doesn't match the problem intensity you saw in discovery, you either built the wrong solution or misunderstood the problem.
Common Mistakes When Applying This Framework
The biggest mistake is treating this as a phase gate. "We did problem discovery, now we're in solution mode forever." Real product work oscillates constantly. You're validating problems while building solutions. You're discovering new problems while shipping features.
The second mistake is thinking problem space work means you never talk to engineers until you have perfect requirements. Your tech lead should be in problem space conversations. They'll spot constraints and opportunities you'll miss. They'll also catch when you're drifting back into solution-talk.
Third mistake: spending three months in problem space because you're anxious about getting it wrong. At some point you have to make a call and ship something. The framework isn't about certainty — it's about not skipping straight to building the first thing users mentioned.
Finally, the most subtle mistake: documenting problems but never actually using that documentation to challenge your roadmap. I've seen teams do beautiful discovery work, write elegant problem statements, then completely ignore them when a stakeholder asks for a specific feature. The problem space work only matters if you're willing to say "that solution doesn't match any of the problems we've validated."
Most roadmap conversations are secretly solution-space arguments. Someone wants feature X, someone else wants feature Y, and you're debating which to build first. If you can reframe the conversation around the problem — what job are we trying to solve and for whom — the solutions often become obvious. Or you realize you're solving for completely different user segments and need to make an explicit strategic choice.
The teams that use this framework well aren't the ones who do it perfectly. They're the ones who catch themselves when they're discussing a feature request and ask: "Wait — what problem does this solve again?"
That one question, asked consistently, is worth more than any discovery template.