Start With the Problem, Not the Solution
The most common mistake in product design is jumping straight to solutions. Here's why deeply understanding the problem first leads to better products and fewer costly pivots.
There's a pattern that plays out in nearly every product team. A stakeholder walks in with an idea. The idea sounds reasonable. The team moves fast—wireframes appear, engineers start estimating, a sprint begins. Three months later, the feature ships and nobody uses it.
This isn't a failure of execution. It's a failure of diagnosis. The team built the right solution to the wrong problem.
Solutions feel productive. Problems feel slow.
The human brain is wired to jump to solutions. When someone describes a problem, we start pattern-matching immediately—pulling from past experience, similar products we've used, ideas we've been wanting to try. This feels like progress. It isn't.
Spending time in the problem space feels uncomfortable because there's nothing to show for it. No mockups. No tickets. No demos. But this discomfort is exactly where good design lives. It's the gap between "we're building a faster notification system" and "people are missing critical information because they've tuned out our notifications entirely"—two very different problem statements that lead to entirely different solutions.
The five questions worth sitting with
Before any design work begins, it's worth forcing yourself to answer these clearly:
Who specifically has this problem?
Not "users." A named segment, a persona, a role. The more specific, the better the design.
What are they trying to accomplish when they hit this problem?
The job-to-be-done is almost always more important than the feature request itself.
How are they solving it today?
If they're solving it at all—even badly—that tells you what a solution needs to beat.
What would "solved" look like for them?
Not for the product, not for the business. For the person experiencing the friction.
What's the cost of not solving it?
Problems with low cost aren't problems worth solving. Prioritization lives here.
The problem statement is a design artifact
A well-written problem statement does something remarkable: it makes the right solution obvious. When you've truly understood the problem—who has it, why it matters, what they've already tried—the design constraints snap into focus. Features that seemed important fall away. Trade-offs become clearer.
A good problem statement also acts as a filter for every decision that follows. When the team disagrees on a design direction, return to the problem statement. One option usually maps to it more directly than the other. When scope starts to bloat, return to the problem statement. The additions that don't serve it aren't features—they're distractions.
"If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." The point isn't literal—it's that the ratio most teams use is inverted.
What changes when you get this right
Teams that do this well ship less and achieve more. Not because they work slower, but because they waste less time building things that don't move the needle. The product becomes more coherent—not a collection of features, but a set of answers to a specific set of human problems.
User feedback becomes easier to interpret. When a user says "this isn't working," you have a reference point. You can ask: did we solve the problem we set out to solve? Did we even understand the problem correctly? The honest answer is often no—and that's not failure, it's learning.
Practical ways to slow down before speeding up
You don't need a full research program to do this well. A few habits help:
Write the problem before showing designs. Make it a team norm that no mockups are shared until someone has written a clear problem statement that the team has agreed on. This takes fifteen minutes and saves weeks.
Separate problem sessions from solution sessions. The moment someone opens Figma, the conversation shifts from "what problem are we solving" to "should the button be here or there." These are different conversations that shouldn't be mixed.
Ask "why" one more time than feels comfortable. When someone says "we need a better onboarding flow," ask why. When they explain, ask why again. You're not being difficult—you're finding the actual problem beneath the surface request.
The teams that build products people love aren't necessarily faster or more talented. They're more honest about what they don't know before they start building. That honesty is the foundation of everything that follows.