Problem statements

Write the problem so a new teammate could understand it without the Slack thread. Keep solutions out of the statement. Then add a hypothesis only after the problem is clear, with kill criteria so zombies do not stay on the roadmap forever.

Template:

For [persona / segment]
who are trying to [job / goal]
the problem is [obstacle / failure]
which causes [cost: time, money, risk, emotion].
Today they cope by [workaround].
We believe this matters because [evidence: quotes, counts, $].

Then the hypothesis:

We believe that [solution sketch]
for [persona]
will [outcome metric]
because [causal logic].
We'll know we're wrong if [kill criteria].

Walking through AP clerks

Bad: "Build AI invoice categorization."

Problem statement: For AP clerks at 50–200 person companies who code 200+ invoices/week, the problem is manual GL coding that takes ~45 seconds per invoice and errs ~5%, causing month-end rework. Today they use rules in the ERP plus Slack questions to accounting. Evidence: 12 support tickets/month, 4 sales calls lost to "automation" competitors, median clerk overtime 6 hrs at close.

Hypothesis: If we suggest a GL code with ≥90% acceptance on the top 20 vendors, coding time drops 50% and overtime hours fall; kill if acceptance is below 60% after 3 weeks with 10 pilot users.

That is ready for a PRD. "Build AI invoice categorization" is not.

This week: dump ten roadmap items into a table. Rewrite each as a problem statement or mark "solution only — needs problem." Score the top five with a PM or designer in 30 minutes. Pick one high-scoring problem and schedule two user interviews before writing a PRD.

In interviews (product sense), start with the problem space and who experiences it before proposing features — interviewers reward disciplined framing.

Common mistakes

• Skipping kill criteria so zombies stay on the roadmap forever.
• Solution in the first line. If it names a UI, rewrite.
• Evidence that is only a compliment. Need quotes, counts or dollars.

Check yourself

What makes the AP-clerk statement a problem rather than a solution? It names persona, job, obstacle, cost, workaround and evidence — no UI.

Acceptance is 55% after 3 weeks with 10 pilots. What happens? Kill (or pivot). That was the pre-declared bar. Staying is a zombie.

Key takeaways

• Write problem statements without UI; add hypotheses with kill criteria.
• Evidence is quotes, counts and dollars — not "they'd definitely buy that."
• Roadmap items that cannot be rewritten as problems are solutions in disguise.

Further learning

The Mom Test (Rob Fitzpatrick)How to talk to customers & learn if your business is a good idea when everyone is lying to you.The Mom Test

YC session with Rob Fitzpatrick on talking to customers about their lives, not your pitch:

Map: problems worth solving.