Why "Starting with the Problem" Isn't What You Think

November 7, 2024

by Jonathan Simmons, Founder

The False Start

"We start with the problem."

I hear this all the time. Teams genuinely believe they're problem-focused. They have problem statements. They hold discovery sessions. They talk to users.

But when I ask "what problem are you solving?" here's what I hear:

"Users need a better dashboard"
"We need to improve the checkout flow"
"Customers want mobile notifications"

These aren't problems. They're solutions disguised as problems.

Solution-First Thinking

Here's how solution-first thinking works:

Someone has an idea ("we should build X")
They reverse-engineer a problem to justify it
They call it "starting with the problem"
They build X
It doesn't work as expected

Sound familiar?

The tell is in the language:

"We need [solution]" → Assumes the solution
"Users want [solution]" → Projects solution onto users
"Customers are asking for [feature]" → Treats feature requests as problems

Real problem-first thinking sounds different.

What Actually Starting with the Problem Looks Like

Solution-first: "Users need better notifications" Problem-first: "Users miss critical events and take action too late, which costs them money"

Solution-first: "We need a dashboard" Problem-first: "Decision-makers can't trust our data, so they make choices based on gut feel instead of evidence"

Solution-first: "Customers want a mobile app" Problem-first: "Our users need to take action while away from their desk, and our mobile web experience is unusable"

See the difference? Problem-first describes the pain without assuming the solution.

The Five Levels of Why

When someone comes to you with a solution disguised as a problem, dig deeper:

Client: "We need email automation." You: "Why?" Client: "To nurture leads." You: "Why aren't leads being nurtured now?" Client: "Sales doesn't follow up consistently." You: "Why not?" Client: "They don't have time, and they forget." You: "Why is that happening?" Client: "They're overwhelmed with unqualified leads and can't prioritize."

Now we're getting somewhere. The problem isn't "we need email automation." It's "sales is drowning in unqualified leads and can't focus on the valuable ones."

Email automation might help. Or you might need better lead scoring. Or a dedicated SDR. Or better qualification criteria upfront.

You can't know until you understand the actual problem.

The Symptoms vs. Root Cause

Most "problems" teams identify are actually symptoms:

"Our app is slow" → Symptom
"Users abandon tasks before completion" → Symptom
"Customers are churning" → Symptom

The root cause is deeper:

Why is the app slow? (Architecture? Queries? Scale?)
Why do users abandon? (Confusing? Too many steps? Requires info they don't have?)
Why are customers churning? (Not seeing value? Bad onboarding? Wrong target market?)

Starting with symptoms leads to surface fixes. Starting with root causes leads to actual solutions.

How to Find the Real Problem

1. Observe behavior, not just opinions

Don't ask: "What features do you want?" Ask: "Show me how you do [task] today."

Watch where they struggle. Where they work around your product. Where they give up.

Behavior reveals problems. Opinions reveal preferences.

2. Look for pain, not just inconvenience

Not every friction is worth solving:

Pain: "This causes me to lose money/time/sleep"
Inconvenience: "This could be slightly better"

Solve pains first. Ignore most inconveniences.

3. Quantify the impact

"How much does this cost you?"

In time?
In money?
In missed opportunities?
In stress?

If they can't quantify it, it might not be a real problem.

4. Validate it's widespread

One customer's problem might be an edge case. Ten customers' problem is a pattern.

How many people have this problem? How often? How severely?

5. Understand the workaround

"What do you do today when this happens?"

Workarounds reveal:

How urgent the problem is
What solutions they've tried
What constraints they're working within
Whether your solution needs to integrate with existing workflows

The Problem Statement Test

A good problem statement:

✅ Describes pain, not solution
✅ Identifies who experiences it
✅ Quantifies the impact
✅ Explains why it matters
✅ Doesn't mention features or tech

Bad problem statement: "Users need a better way to manage their tasks."

Good problem statement: "Project managers spend 2 hours a day manually updating status reports because task information is scattered across 5 different tools. This delays decisions and causes them to miss deadlines."

See how the second one makes you understand the pain without prescribing a solution?

Why This Is Hard

Starting with the problem is uncomfortable because:

It requires admitting you don't know

It's easier to say "build this feature" than "let's figure out what's really broken."

It takes longer upfront

Discovery feels slow. But building the wrong thing is slower.

It challenges assumptions

You might discover the problem you thought you had isn't the real problem.

It requires killing ideas

When you understand the problem deeply, you realize half your solutions won't work.

But discomfort is the price of building the right thing.

The Pivot Moment

Here's when I know a team has shifted from solution-first to problem-first:

They stop saying:

"We should build X"
"Users want Y"
"Let's add Z feature"

They start saying:

"We've validated that users struggle with X because of Y"
"The core problem is Z, which costs them $N"
"Here are three ways we could solve this—let's test assumptions before building"

The conversation changes from pitching solutions to diagnosing problems.

What Changes When You Start with Problems

Better prioritization

When you understand root causes, you can prioritize by impact instead of loudest voice.

Simpler solutions

Often the real problem has a simpler solution than the one originally proposed.

Faster validation

You can test if a problem is real before building anything.

Higher success rate

Solutions designed for real problems get adopted. Solutions designed for imagined problems don't.

Less wasted effort

You build less, because you understand what's actually needed.

The Problem-First Workflow

Someone proposes a solution ("we should build X")
Ask why ("what problem does X solve?")
Dig deeper (keep asking why until you hit root cause)
Validate the problem (talk to users, watch behavior, quantify impact)
Explore solutions (maybe X, maybe Y, maybe something simpler)
Test assumptions (prototype, validate, learn)
Build the right thing (the solution that solves the validated problem)

Most teams skip steps 2-6 and go straight from 1 to 7. Then wonder why adoption is low.

When to Trust Feature Requests

Sometimes users ask for a feature and they're right. When?

They can articulate the underlying problem clearly
Multiple users independently describe the same pain
They've tried workarounds and they're all insufficient
They can quantify the value of solving it

Even then, the feature they request might not be the best solution. But the problem is probably real.

The bottom line: Saying you "start with the problem" doesn't make it true. Most teams start with solutions and work backwards to justify them.

Real problem-first thinking is uncomfortable. It requires questioning assumptions, digging deeper, and sometimes discovering you've been solving the wrong problem.

But it's the only way to build products that actually matter.