How do you write a startup problem statement?

The fast version

Use the Jobs-to-be-Done switch format:

“When [situation], I want to [motivation], so I can [outcome].”

Example:

“When I’m prepping for a client call 30 minutes before it starts and realize I have notes scattered across Notion, Apple Notes, and email threads, I want to surface the most-relevant snippet in one place, so I can sound prepared instead of scrambling.”

Three components:

1. Situation: a specific moment you can picture. Not “users want X”; an actual scene.
2. Motivation: what they want to do. Verb-led, behavioral.
3. Outcome: the underlying job. What success looks like to them.

The statement should make a specific person feel a specific moment. If it’s abstract, rewrite.

The four tests every statement should pass

1. The situation is real. Could you describe the moment in three sentences and have your buyer nod? If yes, real. If they say “kind of, but…” you’ve got the wrong moment.

2. The buyer can identify the moment. When you read the statement aloud to a target buyer, do they say “yes, that’s me last week”? If yes, you’ve got it. If they say “interesting, sometimes” you’ve got a generic.

3. The outcome is measurable. Could you tell, after the buyer used your product, whether the outcome was achieved? If yes, measurable. If the outcome is vague (“feel better about my workflow”), you can’t tell whether the product worked.

4. At least 3 unrelated buyers describe the same problem in similar words. This is the Mom Test signal. Without 3 unrelated buyers, you have a hypothesis; with 3, you have a pattern.

If you fail any of these, the problem statement isn’t ready. Either talk to more buyers (most common cure), or rewrite the statement using the verbatim phrasings from the interviews you’ve done.

Where founders go wrong

1. Writing the statement before talking to buyers. Almost guarantees you’ll get the situation wrong. You imagine a moment that’s plausible to you; the buyer’s actual moment is different.

2. Including the solution in the problem statement. “Users want a Slack integration that…” is not a problem statement; it’s a feature description. The problem is what the user is doing without the integration.

3. Multiple jobs jammed into one sentence. “When I’m at my desk OR on the road OR in a meeting…” means you’ve got 3 distinct situations, each with different motivations and outcomes. Split them.

4. Vague outcomes. “Feel productive,” “have more time,” “be successful” are too abstract to test. Replace with measurable outcomes: “produce a report in under 10 minutes,” “find the customer’s last conversation in under 30 seconds.”

5. Treating the problem statement as a product brief. It’s not. It’s a frozen description of the buyer’s situation. The product brief evolves; the problem statement stays stable. If you’re rewriting your problem statement weekly, you don’t actually understand the problem.

How ShipFit operationalizes this

ShipFit’s stage 4 (How to Win?) expects a JTBD switch statement as input. The system pressure-tests the statement against:

• The above-the-line pains from stage 3 (does the statement actually capture the pain?)
• The buyer persona from stage 2 (does the situation fit this specific buyer?)
• The competitive landscape (does the outcome differentiate from existing solutions?)

If any of those don’t line up, ShipFit kicks the statement back. The output: a JTBD statement defensible enough to scope V1 against.

Further reading

• The Jobs-to-be-Done framework, the full method this question operationalizes.
• The Mom Test framework, the interview discipline that produces the verbatim phrasings the statement should use.
• Buyer Persona Canvas, the persona work that anchors the “who” the statement is about.