How to Write a Problem Statement You Can Build Against

A problem statement is the bridge between research and building. Get it right and the first version of your product almost writes itself. Get it wrong and you build a feature nobody asked for.

Most founders never write one. They carry a vague idea in their head, and every conversation about it drifts. A written statement forces the drift to stop.

What a problem statement is for

It is not a mission or a pitch. It is a test: can you describe one buyer, one situation, one obstacle, and one cost, precisely enough that a solution suggests itself?

If a statement could describe ten products, it is too broad. If it names a feature, it has jumped ahead. The goal is to describe the problem so clearly that anyone reading it could propose a sensible fix.

The four parts

Write one sentence with these four ingredients:

1. Who — a specific buyer, defined by their situation, not their demographics.
2. The job — what they are trying to accomplish.
3. The obstacle — the specific wall they hit, quoted from real evidence.
4. The cost — what the obstacle costs them today, in time, money, or risk.

Shape it like this: “When [situation], [buyer] is trying to [job], but [specific obstacle], which costs them [cost].”

The obstacle is the part founders fudge. “It is hard” is not an obstacle. “They export a CSV every Friday and reconcile 200 rows by hand” is.

Bad and good examples

• Too broad. “Small businesses struggle with invoicing.”
• Too feature-shaped. “Freelancers need an AI invoice generator.”
• A real statement. “When a freelance designer finishes a project, they are trying to get paid on time, but they have to chase the client over email for weeks, which costs them hours each month and sometimes the payment entirely.”

The third one tells you what to build (a way to get paid without chasing), who for (freelance designers), and how to know it works (the chase stops, the payment arrives sooner). It also tells you what not to build: anything that is not about getting paid without friction.

Where the words come from

Do not invent the language. Pull it from the evidence:

• The obstacle is a quote from a forum or review.
• The cost is a number someone mentioned, or that you can estimate from their described routine.
• The job and situation come from the switch interview you ran, or from the pattern across threads.

This is why collecting verbatim quotes matters. A problem statement built from your own phrasing drifts back toward your assumptions within a day. One built from a quote stays anchored, the same principle behind pain point research.

Tighten it until it hurts

A first draft is always too long. Tighten with these passes:

• Cut adjectives. “Very time-consuming” becomes “takes four hours a month”.
• Cut the market. “SaaS founders” becomes “solo founders launching their first paid product”.
• Cut the solution. If a noun from your product slipped in, remove it.
• Read it aloud. If it sounds like marketing copy, it is too smooth; make it sound like the buyer.

When the statement is tight, the next step is mechanical: turn each part into a requirement. The obstacle becomes the core feature to remove, the cost becomes the value in your pricing, the job becomes your landing page headline. That translation is what turning a complaint into a feature spec is about.

FAQ

How long should a problem statement be?

One sentence, with a short supporting paragraph of evidence. If it needs a page, you have not finished narrowing.

Should it mention my solution?

No. The moment a solution appears, the problem bends to fit it and you lose the ability to judge whether the problem was real.

What if I cannot name a specific obstacle?

Then you have not found the problem yet, only a theme. Go back to the evidence and look for the moment things go wrong, described concretely by a real person.

Can one product have several problem statements?

It can, but start with one. A single sharp statement is easier to validate. You can add a second once the first is proven, not before.

How do I check that mine is good?

Show it to five people in the target group and ask if it describes their situation. If they correct a word, write theirs down. If you would rather start from tested problems, run a report for 2.99 EUR and read the strongest validated signals, each with a quote, then write the statement from those.