Problem Statement Templates That Force Clarity

A strong problem statement names four things in a single sentence: the specific person who has the problem, the moment it hits them, what's blocking them, and how they cope with it today. The five templates below are ready to copy, each built for a different moment — a first draft, a customer interview, an internal budget ask, or a pitch deck.

Quick Answer: Start with the core who/outcome/obstacle/workaround template for your first draft. Switch to the job story format once you're interviewing real customers, the gap statement for internal memos, the operational breakdown for pitching inside an existing company, and the pitch-ready version for investors. Every field has to come from evidence — if you can't fill a blank without guessing, you're not done with problem discovery yet.

The 5 problem statement templates

Each template below asks for the same underlying facts in a different order, because the order changes who it's for. Copy one, fill every bracket from something you've actually observed, and treat an empty bracket as a signal to go find more evidence rather than something to fill in with a guess.

1. The core structure — user, outcome, obstacle, workaround

[Specific user] is trying to [achieve outcome], but [obstacle] gets in the way, so today they [current workaround].

Use this for your very first draft, right after your first handful of conversations. It's the cheapest gut check there is: if you can't name a real workaround, you likely haven't found a real problem, just an assumption dressed up as one.

2. The job story — situation, motivation, outcome

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

Job stories, a format that grew out of Jobs-to-be-Done thinking, are written in the customer's voice instead of yours. That makes this version the one to read back to an interviewee directly and ask, "Did I get that right?" — a question the other templates don't lend themselves to.

3. The gap statement — current state to desired state

[Audience] currently [pain point] when [context], which costs them [consequence]. They want [desired outcome] instead, but [existing alternative] doesn't get them there because [reason].

Reach for this one when you're writing for someone who needs convincing rather than someone who lived the problem — a co-founder, an internal stakeholder, a memo. Naming the cost of the status quo is what makes inaction feel expensive.

4. The operational breakdown — what, who, when, impact, cause

[What] is happening to [who], occurring [when or where], resulting in [measurable impact]. The likely cause is [suspected cause], and it matters because [business consequence].

This structure borrows from process-improvement work rather than startup culture, which is exactly why it lands better with a budget owner or operations lead than a pitch-deck sentence would. If you're building inside an existing company rather than from scratch, this is the version your boss will recognize.

5. The pitch-ready problem — audience, pain, alternatives, gap

[Audience] struggle with [pain] every [frequency]. They currently rely on [existing alternatives], which fail because [gap]. Nobody has built a real solution for this audience yet.

This is the shape closest to the "Problem" box in Ash Maurya's Lean Canvas, from his book Running Lean — the discipline of naming existing alternatives before you ever mention your own product. It forces you to prove the gap exists instead of asserting it, which is exactly what a slide in front of an investor needs to do.

What each field in a problem statement actually needs

Every template above is really asking for the same five ingredients, just in a different order. Get these five right and any template above will read as sharp; get them wrong and no template will save you.

• Who — a specific role, company stage, or life situation, not a category. "Solo bookkeepers serving eight or more small-business clients" is usable; "small business owners" is not, because it can't tell you who to interview next.
• Context — the recurring moment the pain shows up in, not the general job. "Closing out the books at month-end" is a context; "doing their job" is not.
• Pain — the actual cost, in time, money, risk, or embarrassment, stated concretely enough that a stranger watching the person work could verify it themselves.
• Current workaround — what they do about it today, however clumsy. If this field is empty, either you haven't looked hard enough or the problem isn't urgent enough for anyone to have bothered coping with it yet.
• Success measure — an outcome you could watch for and confirm from the outside, not a feature you plan to ship. "They stop manually re-typing numbers between two tools" is a success measure; "they use our app" is not.

Filled example: one idea run through all 5 templates

Here's a hypothetical example, worked through every template, so you can see how the same underlying facts shift shape depending on who's reading them. Say you're looking at independent bookkeepers who each serve eight to fifteen small-business clients, and you've noticed several of them mention losing hours every month reconciling receipts that clients send by email instead of through any shared system.

Core structure: Independent bookkeepers managing multiple small-business clients are trying to close the books accurately each month, but receipts arrive scattered across email, text, and photos with no consistent format, so today they manually re-key each one into a spreadsheet before they can reconcile anything.

Job story: When a client sends me a stack of receipts by email at month-end, I want to get them matched to transactions without re-typing every line by hand, so I can close that client's books in an afternoon instead of a full day.

Gap statement: Independent bookkeepers currently spend hours per client re-keying receipts from email and text messages when closing monthly books, which costs them billable time they can't invoice for. They want receipts to land in one reconciled format instead, but general accounting software doesn't solve this because it assumes receipts are already digitized and categorized correctly.

Operational breakdown: Manual receipt re-entry is happening to independent bookkeepers during monthly close, occurring across every client relationship where receipts arrive unformatted, resulting in several unbillable hours per client per month. The likely cause is that clients have no consistent way to submit receipts, and it matters because it caps how many clients one bookkeeper can profitably serve.

Pitch-ready problem: Independent bookkeepers struggle with unformatted receipt intake every single month. They currently rely on manually re-typing numbers from email and text photos into a spreadsheet, which fails because it doesn't scale past a handful of clients. Nobody has built a real solution for this audience yet.

Notice that the underlying facts never changed. What changed is which fact leads the sentence — the workaround leads in the core structure, the cost leads in the gap statement, and the competitive gap leads in the pitch-ready version. That's the entire point of having five templates instead of one: the audience decides the order, not the facts.

Which template fits which stage

Picking the right template mostly comes down to two questions: how far along is your evidence, and who has to read the sentence next. The table below maps both.

In practice, most founders write two or three of these for the same problem at different points — a core structure sentence in week one, then a pitch-ready version once they're fundraising. Keeping the underlying facts consistent across versions is more important than picking the "right" one on the first try. If you want a place to hold the fuller evidence behind whichever sentence you land on, a one-page problem brief is the natural next document once the statement itself is solid.

Key Takeaways

• A problem statement needs four things in one sentence — a specific person, the context they hit the problem in, what's blocking them, and how they cope today.
• An empty workaround field is a warning sign — if nobody has tried to cope with the problem yet, it probably isn't urgent enough to fund a business.
• The audience decides which template to use, not the stage of your idea — a core structure sentence for yourself, a job story for interviews, a gap statement for stakeholders, an operational breakdown for internal pitches, a pitch-ready version for investors.
• The underlying facts should stay identical across templates — only the order and framing change based on who's reading.
• Naming existing alternatives before your own solution, as the pitch-ready template does, forces you to prove a gap exists instead of just claiming one.
• A problem statement is a testable claim, not a mission statement — it should be specific enough that new evidence could prove it wrong.
• Rewriting the sentence is normal and expected — each rewrite should narrow the audience and sharpen the obstacle, not just reword the same vague claim.

Frequently Asked Questions

What is a good problem statement example for a startup?

A good example names a specific person, their context, their obstacle, and their current workaround in one sentence — for example: "Independent bookkeepers managing multiple clients lose hours each month manually re-keying receipts scattered across email and text, because no consistent intake format exists." It's specific enough that you could go find the person it describes.

How long should a startup problem statement be?

One to two sentences, ideally one. If explaining the problem takes a full paragraph, it usually means you're describing more than one problem at once, or you're including background context that belongs in supporting notes rather than the statement itself. Force yourself to cut it down — the compression is what proves you actually understand the problem.

What's the difference between a problem statement and a mission statement?

A problem statement names a specific, testable, unmet need that a defined group of people has right now, built from evidence you can point to. A mission statement is broader and aspirational — it describes what your company is trying to achieve over time and doesn't need a workaround field or a specific audience to be valid. You need a problem statement before you build; a mission statement can come later.

Do investors want to see a problem statement on a pitch deck slide?

Yes — it's typically the first substantive slide after the title, and it's usually where a pitch either earns attention or loses it. The pitch-ready template exists specifically to compress a problem statement into deck form: name the audience, the pain, what they use today, and why it falls short, all before you introduce your own product. Investors are checking whether you understand the problem more than whether you've described your solution well.