Stop 03 · User Research & DiscoveryTopics · 9/12

Problem Validation

In short

Most failed products solved a problem nobody really had. Problem validation checks that the pain is real, frequent and worth fixing before you build anything.

Confirming a problem is real, common and painful enough to solve before investing in a solution — the step most commonly skipped by teams eager to start building.

The purple blob stands at a street corner clicking a tally counter as people walk by.

Think of it like this

Before opening a juice shop

Before renting a shop, you stand at the corner for a few afternoons with a tally counter. How many people walk past? How many look thirsty? Where do they buy drinks now? Then you decide.

Watch it happen

Asking about the past, not the future

You

Student

When did this last happen?

1/6Ask about a real recent event. Questions about the future get polite, made-up answers.

The big ideas

What you need to know

Past behaviour beats opinions

"Would you use this?" gets a yes from everyone. "What did you do last time?" gets the truth.

Frequency matters

A problem that hits weekly is worth more than one that hits once a year.

Look for spending

If people already spend money, time or effort on workarounds, the pain is real.

Patterns, not one voice

Hear the same pain from several people in your target group before you trust it.

Save yourself the pain

Common mistakes

Oops

Pitching your idea and asking "would you use this?".

Do this instead

Don't mention your idea. Ask about their life and the problem first.

Oops

Counting compliments as validation.

Do this instead

Compliments are free. Look for commitment: time, money, or a request to try it early.

Your mission

Validate one problem in a day

~45 min

Quick check

Which question gives the most reliable evidence that a problem is real?

Go deeper

1Practice separating a 'problem statement' from a 'solution disguised as a problem'.
2List 3 ways to validate a problem cheaply before writing a line of code.
3Learn to recognize when a stakeholder is pitching a feature, not a validated problem.