The Difference Between Understanding a Problem and Solving It
Most teams jump straight to solutions. Here's what that costs, and what it actually takes to get it right.
They jump from "we should do something" to "here's what we're shipping" with nothing in between. No framing. No map of the space. No shared picture of what's actually broken.
It feels productive. It usually isn't.
I've sat in enough strategy sessions to recognize the pattern on sight. Someone flags what seems to be the problem. Maybe a metric moved in the wrong direction, support tickets spiked, or a competitor did something interesting. Within ten minutes, the conversation has already migrated. The problem is now being treated as a given, and the group is debating solutions. Feature ideas go up on the whiteboard. Someone pulls up the roadmap. A timeline forms.
The real problem never got its moment. It got assumed.
The investigation nobody runs
In a trial, the jury doesn't deliberate until all the evidence has been heard. That's by design. A jury that decides on day one and spends the rest of the trial confirming it isn't doing its job. It's building a case for a conclusion it already reached.
When a prosecution builds its case around a single narrative and the defense finds one gap in it, the whole thing is at risk. "If it doesn't fit, you must acquit" isn't just a memorable line. It's what happens when you stop gathering evidence too early. The side that wins is usually the one that followed the evidence further.
Product teams skip this phase routinely. Someone brings a request. Someone else has a hunch about the cause. A third person has a solution they've been wanting to ship for months. Within an hour, the team is debating implementation details for a problem nobody has actually defined.
The meetings still feel productive because decisions are being made. Work is getting assigned. But if the problem is wrong, none of it matters.
Consider a team whose sign-ups dropped 25% last month. They check the data. Traffic is flat, so they conclude the landing page is the problem. They redesign it, run a test, ship the winner.
Sign-ups don't recover.
What they didn't ask: where was the traffic coming from? The volume was the same, but the source had shifted. A new paid campaign was bringing in high volumes of low-intent visitors. The landing page was never the problem. The audience had changed.
They had the data. They just stopped looking at it too soon.
Why teams skip the investigation
Teams that skip this step aren't lazy. They're responding to real pressures, and those pressures have real logic.
Velocity culture. Speed has been the dominant value in product development for over a decade. Move fast. Ship small. Iterate. In that environment, pausing to understand a problem before building feels like friction. It looks like the opposite of speed, even when it's what makes the eventual work faster.
Solutions feel more concrete. A list of features is something you can point to. A problem statement is abstract, contested, and hard to put on a roadmap. When a team needs to show progress, a working prototype is easier to hold up than a clear case for the problem. The incentives push toward building.
Someone already knows the answer. In most rooms, at least one person arrived with a strong prior about the solution. They've been waiting for an opening. When the conversation skips the investigation, that opening comes early. By the time anyone considers whether the problem has been understood, the team is already two decisions downstream from the moment that mattered.
This step gets skipped not because people don't care about doing good work, but because the system isn't designed to reward it.
What understanding looks like
There are a few ways to tell whether you've actually understood a problem or just stated a solution posing as a problem.
Your statement doesn't imply a solution.
Most problem statements are solution statements in disguise. "We need a better onboarding flow" sounds like a problem, but it already tells you what to build. Compare it to: "New users aren't reaching the activation milestone in their first week." Same underlying issue. But the second version leaves the solution open. Maybe it's onboarding, maybe it's the product itself, maybe it's who you're acquiring. You don't know yet. That's the point.
If someone reads your problem statement and immediately knows what to build, it probably isn't a problem statement.
You can describe what success looks like.
Try finishing the sentence: "We'll know this worked when..."
"We'll know this worked when checkout abandonment returns to baseline" is a definition of success. "We'll know this worked when it feels better" is not. One tells you what to measure. The other tells you someone is uncomfortable but hasn't thought it through.
If you can't finish that sentence, you don't have a problem yet. You have a discomfort. That's a legitimate starting point, but it's the beginning of the investigation, not the end of it.
You've accounted for the constraints.
Most problem statements leave out the boundaries. Who's working on it. How long you have. What's already been decided. Those things aren't separate from the problem. They're part of it. A problem with six months and a full team is a different problem than the same issue with two weeks and one engineer. If you don't account for the constraints, you're not defining the problem. You're defining an ideal version of it.
The cost of misunderstanding the problem
Most of the time, the cost doesn't show up cleanly. You build something reasonable for the wrong problem, and the metrics don't tell you clearly enough that you've missed. The feature ships. Things improve slightly. The team moves on. What you rarely find out is what would have happened if you'd understood the problem first.
The more visible cost is sunk investment. Six weeks of design and engineering, a beta launch, a public commitment. Then someone asks the question that should have been asked at the start. The answers don't match the work. At that point you're choosing between continuing down a path you suspect is wrong, or absorbing the cost of stopping.
Either way, the team understood the symptom. They never understood the problem.
The habit nobody builds
The habit is simple to describe and hard to build. Not because the method is complicated, but because it requires something most team cultures don't reward: staying with a problem before moving.
Solutions feel like progress. A half-understood problem doesn't. Most teams choose momentum.
Building the habit starts before anyone proposes a solution.
Ask what problem you're actually trying to solve. Keep asking why until the answer stops sounding like a fix. When you can state it without pointing to a solution, you're getting closer.
Ask what success looks like. Keep digging until you can measure it. "It feels better" isn't an answer. "Checkout abandonment returns to baseline" is.
Ask how the problem changes with the constraints you're working within. Keep exploring until you've covered the blind spots: the timeline, the team, the decisions that have already been made.
That's the difference between understanding a problem and solving one.
References
Spradlin, D. (2012). Are You Solving the Right Problem? Harvard Business Review, September 2012. The foundational case that rigor in problem definition is the most important factor in finding a good solution. Most organizations are not proficient at it.
Torres, T. (2016). Product Managers, Level Up Your Problem-Solving Skills. Product Talk. On the tendency to jump to solutions before the problem is understood, and what sharper problem-solving habits look like in practice.
Goetzmann, J.F. PM 101: Define the Problem Before the Solution. Medium. On why separating problem definition from solution design is crucial, and how skipping this step drives the wrong-feature failure pattern.
Voltage Control. Problem Framing in Design Thinking: Best Practices. On the discipline of staying in the problem long enough to generate multiple problem statements before any solution work begins.
JHU Human Capital Development Lab. Is Your Organization Solving the Wrong Problems? On how organizations systematically misidentify problems and what the organizational cost of that looks like over time.