Problem Statement Validation SOP

A problem statement validation SOP checks that the one sentence your whole startup rests on is true for the people you plan to sell to, and it takes about a week. You write the problem in a fixed format, read it back to 15 people from your target group and count who says "yes, that's me" without a sales pitch around it. A vague problem statement produces a vague product, vague marketing and a vague pitch. A tested one gives every later SOP a fixed target to measure against.

What is the problem statement validation SOP and when should you use it?

A problem statement is one or two sentences that name who has the problem, when it shows up, how frequently and what it costs them in money, time or stress. Validation means real people from that group recognise themselves in the sentence and add detail you did not write. Stanford d.school calls a close cousin of this the "point of view" statement (user, need, insight), and Ash Maurya's Lean Canvas puts the same idea in its "Problem" box. This SOP adds the test that both of them assume you will run.

Use this SOP:

• Right after your first 10 to 20 customer interviews, when you have notes but no single sentence that sums them up.
• When your team describes the problem three different ways. One tested sentence settles the argument with evidence.
• Before you write a pitch, a landing page or a survey, since all three borrow their wording from this statement.
• After a pivot, when the old sentence no longer matches the new customer.

What do you need before you start?

• Interview notes or transcripts from at least 10 people in one customer group. Without them you are guessing the words.
• A list of exact customer quotes about the problem, sorted by theme.
• 15 fresh contacts who match the profile and have not heard your idea. Recycled interviewees already know your framing.
• A one-page scoring sheet (template below).

How do you run it, step by step?

1. Pull the repeat themes from your notes

Group every quote by the problem it describes. Count how many different people mention each theme. Pick the theme with the most mentions and the strongest emotion as your candidate, and park the others for a problem ranking survey.

2. Write the statement in the fixed format

Use this skeleton: [Customer] who [trigger or situation] struggle to [job they want done] because [obstacle], which costs them [time, money or risk] about [frequency]. Use the customers' own nouns and verbs. If a word came from your pitch deck instead of an interview, replace it.

3. Strip out the solution

Read the sentence and delete every hint of your product. "Need an app to track invoices" smuggles in the answer. "Lose track of unpaid invoices once they have more than 10 clients" describes the problem. A statement that names a solution can only be confirmed by people who already like that solution.

4. Write three variants with different causes

Keep the customer and trigger fixed, then write two more versions with a different obstacle in the "because" clause. Customers recognise their own cause faster than they reject yours, so the variants show you which explanation is real.

5. Read the statements to 15 new people

Run 10 to 15 minute calls or voice notes. Read variant A, ask "How close is this to your situation, from 1 to 5?" and then "What would you change?". Repeat for B and C in random order. Write down every word they add or remove, because those edits are the most useful data you collect.

6. Score recognition, frequency and cost

For each person, record the highest score, the variant they picked, how frequently they say it happens and whether they named a cost before you asked. Unprompted cost is a strong sign. A cost you had to drag out of them is weak.

7. Rewrite once, retest with five more people

Fold the most common edits into one final sentence and test it with five people who have not seen any version. If four of the five rate it 4 or 5, lock the statement and store it where everyone on the team can see it.

Template you can copy

PROBLEM STATEMENT (fixed format)
[Customer] who [trigger/situation]
struggle to [job they want done]
because [obstacle],
which costs them [time / money / risk]
about [frequency].

VARIANT A (obstacle 1): ...
VARIANT B (obstacle 2): ...
VARIANT C (obstacle 3): ...

TEST CALL SCRIPT (10–15 min)
1. "I'm going to read a short description. Tell me how close it is
   to your own situation, from 1 (not me at all) to 5 (exactly me)."
2. "What would you change so it fits you better?"
3. "When did this last happen to you?"
4. "What did it cost you that time?"   (only ask if they did not say)

SCORING SHEET (one row per person)
Name | Best score 1–5 | Variant picked | Frequency they state |
Cost named unprompted Y/N | Words they added | Words they removed

Worked example: freelance translators and late payments

This is an illustrative case. A founder interviews 14 freelance translators and hears late payment in 9 of the calls. Her first draft reads: "Freelancers need a better way to get paid." It names no trigger, no frequency and no cost, so she rewrites it.

Variant A says translators who work for agencies wait 60+ days because agencies batch payments. Variant B blames missing purchase order numbers on invoices. Variant C blames translators' reluctance to chase clients. She reads all three to 15 new translators. Variant B scores 4 or 5 with 11 of 15 people, and 8 of them name a cost unprompted, such as paying rent late or borrowing from family. Five people add the words "rejected by accounts payable" to the sentence.

Her final statement: "Freelance translators who invoice agencies get invoices rejected by accounts payable because a purchase order number or tax field is missing, which delays payment by 30 to 60 days several times a quarter." Four of five fresh testers rate it a 5. She moves on to quantifying what that delay costs.

What should you measure, and when do you stop?

Stop when the final rewrite passes with four of five fresh testers. If no variant passes after 15 calls, the problem is real for some people but your customer group is too wide: split it by role, company size or trigger and retest each half.

Which mistakes should you avoid?

• Writing the statement from your own head. Draft only from interview quotes, or you will validate your own vocabulary.
• Hiding the solution inside the problem. "No easy tool for X" is a product pitch wearing a disguise.
• Testing with people who already heard your idea. They score the founder, and you learn nothing about the sentence.
• Accepting "yes, that's a problem" as a pass. Ask when it last happened and what it cost. No recent example means no real problem.
• Locking a statement with no frequency. A painful problem that happens once a year is hard to sell a subscription against.

How can AI speed this up?

Paste your interview quotes into an AI assistant and ask it to group them by theme, count distinct speakers per theme and draft three problem statements in the fixed format using only words that appear in the quotes. Then ask it to flag any word in the drafts that does not appear in the source text. The test calls stay human: an AI can't tell you whether a translator winced when you read variant B.

For a fast outside read on the sentence before you book calls, run it through the free F/MS idea validator.

Where does this SOP fit in your validation plan?

This SOP sits at the start of Problem Validation, right after interviews. Before it: the customer interview SOP and, if your customer group is still fuzzy, the persona development SOP. After it:

1. Rank this problem against the runners-up with a problem ranking survey.
2. Put a money figure on it with problem impact quantification.
3. Check what people use today with an existing solutions analysis.
4. Map problem, behaviour and solution together on the problem-solution fit canvas.

If you want to practise writing and defending a problem statement with a team, deadlines and mentors, the Fe/male Switch startup game makes it the first task of the first week.

FAQ

What is a good problem statement for a startup?

One that names a specific customer, the trigger that starts the problem, how frequently it happens and what it costs. If a stranger from that group can hear it and say "that happened to me last Tuesday", it is good.

How many people do I need to validate a problem statement?

15 people for the main test plus 5 fresh people for the final rewrite. Aim for 10 or more out of 15 rating it 4 or 5 on closeness.

Is a problem statement the same as a hypothesis?

It is the problem half of your hypothesis. The full hypothesis adds the solution and the result you expect, which you test later with concept tests and experiments.

Can I validate a problem statement with a survey instead of calls?

You can for the recognition score, but you lose the edits people make out loud, and those edits are what sharpen the sentence. Use calls for the first 15 and a survey only to confirm at scale.