How to Write a Problem Statement for a Startup

Most first-time founders can describe their product for ten minutes without pausing for breath. Ask them to describe the problem in one sentence and they freeze. That's backwards, and it's expensive. According to CB Insights, 42% of startups fail because they built something nobody wanted. Not because the code was buggy. Not because the design was ugly. Because no real person had the problem the founder assumed they had.

A problem statement is the fix. It's one or two sentences that force you to name who's hurting, what they're trying to do, and what's stopping them. Get it right and every decision after it gets easier: what to build, who to sell to, what to ignore. Get it wrong and you'll spend a year polishing a solution to a problem that doesn't exist. This guide walks through how to write a problem statement that actually holds up, with a formula, a template, real examples, and the traps that catch new founders.

What is a startup problem statement?

A startup problem statement is a short, specific description of a real problem a specific group of people has, written without any mention of your solution. It names the customer, the goal they're chasing, and the obstacle in their way. Nothing else.

The "without any mention of your solution" part trips people up. Your problem statement is not "people need an app that does X." That's a solution wearing a problem costume. A real problem statement stands on its own even if your company never gets built. Think of it as the thing that's true about the world whether or not you show up. "Freelance designers lose hours every week chasing late invoices" is a problem. "Designers need invoicing software" is you sneaking your product in early.

The discipline of separating problem from solution is the whole point. When you write the problem cleanly, you can test whether it's real before you commit a single line of code or a single dollar.

Why does your problem statement matter so much?

Your problem statement matters because it's the single assumption everything else depends on, and it's the assumption first-time founders are most likely to get wrong. If the problem isn't real, no amount of execution saves you.

The numbers back this up. Roughly 90% of startups fail, and first-time founders have only about an 18% success rate. The leading cause across nearly every study is the same: no market need. Founders fall in love with a solution, skip the part where they confirm the problem, and build in a vacuum. A sharp problem statement is the cheapest insurance you can buy against that. It costs you an afternoon. The alternative costs you a year.

There's a second reason it matters. A clear problem statement aligns everyone. Your cofounder, your first hire, your early users, even you at 2am when you're tempted to add a feature nobody asked for. When the problem is written down and agreed on, scope creep gets easier to resist. You can hold every idea up against one sentence and ask: does this serve the problem, or am I just bored? Most founders I've watched succeed could recite their problem statement from memory. The ones who struggled usually couldn't, because they never wrote one.

What makes a good problem statement?

A good problem statement is specific, customer-focused, evidence-based, and solution-free. Vague problems produce vague companies. The tighter your statement, the sharper everything downstream.

Here's what separates a strong one from a weak one.

It names a specific group. "People" is not a customer. "Small business owners" is barely better. "Solo Shopify store owners doing under $10k a month in revenue" is a real segment you can find, interview, and sell to. The narrower you go early, the faster you learn.

It describes an actual goal, not a feature wish. Your customer isn't trying to use your dashboard. They're trying to get paid on time, hit a deadline, or stop losing customers. Anchor the statement to the outcome they care about.

It points to a concrete obstacle. What specifically blocks them? Time, money, knowledge, tools, a broken process? "It's hard" is not an obstacle. "They have to manually copy data between three systems every Friday" is.

It carries evidence of impact. How often does this happen? How much does it cost them in time, money, or stress? Real numbers beat adjectives. "Twice a month" and "roughly four hours each time" tell you far more than "frequently" and "a lot."

If your statement is missing any of these, it's not wrong yet. It's just untested. Which is fine, as long as you know that's where you are.

How do you write a problem statement, step by step?

You write a problem statement by researching a real customer first, then filling in a simple formula, then cutting everything that smells like a solution. The order matters. Most founders write the statement first and research never, which is how you end up confidently describing a problem nobody has.

Start with the formula. The cleanest version is this:

[A specific person or group] is trying to [achieve a goal] but [is blocked by a specific obstacle], which costs them [measurable impact].

Now work through it in four moves.

First, talk to real people before you write a word. Run five to ten customer conversations. Don't pitch. Ask what their week looks like, where they get stuck, what they've tried, and what they're spending to work around it. The goal is to hear the problem in their words, not yours. If you can't find people who light up when you describe the pain, that's your answer before you've built anything.

Second, find the pattern. After a handful of conversations, themes repeat. Same complaint, same workaround, same hack with a spreadsheet. That repetition is the signal. Write down the obstacle that keeps coming up, not the one you assumed going in.

Third, dig for the root cause. The first problem people name is usually a symptom. Ask "why" a few times. "I'm losing customers" becomes "they churn after month two" becomes "they never finish onboarding" becomes the actual problem worth solving. Don't stop at the surface.

Fourth, write it, then strip out your solution. Draft the sentence using the formula. Then read it again and delete anything that hints at what you're going to build. If the word "app," "platform," "tool," or "software" appears in your problem statement, you've contaminated it. Cut it.

When you're shaping the customer side of this, it helps to map who you're actually talking about. You can do that on paper, in a Notion doc, with a customer persona template, or in a planning tool like Foundra that walks first-time founders through defining the problem and the customer before they build. The medium doesn't matter. The discipline does.

What does a problem statement template look like?

A problem statement template gives you a fill-in-the-blank structure so you're not staring at a blank page. Here's the formula broken into parts, with the question each part answers.

Stitched together, that becomes: Solo freelance designers want to get paid on time without chasing clients, but they track invoices manually across email and spreadsheets, which costs them three hours a week and leaves about 20% of invoices late.

Look at a few more across different markets so the pattern sticks:

Early-stage SaaS founders want to forecast their cash runway, but they rebuild fragile spreadsheets every month, which means they often discover they're low on cash weeks too late.

New parents want healthy weeknight dinners, but meal planning eats 30 minutes they don't have, so they default to takeout four nights a week.

Independent gym owners want to fill off-peak hours, but they have no easy way to message members last-minute, so empty 2pm classes cost them thousands in unused capacity each month.

Notice what's missing from every one of these. No product. No feature. No "imagine an app that." Just a person, a goal, an obstacle, and a cost. That's the whole job.

What are the most common problem statement mistakes?

The most common mistakes are hiding your solution inside the problem, picking a problem that's too broad, and writing from your own head instead of from customer evidence. Each one quietly guarantees you'll build the wrong thing.

The solution-in-disguise mistake is the big one. "Restaurants need a better reservation system" already assumes the answer. Strip it back: "Small restaurants lose tables because no-shows go unfilled and walk-ins get turned away." Now you're free to discover the right solution instead of marrying the first one you thought of.

The too-broad mistake feels productive because a huge problem sounds like a huge market. It isn't. "People struggle with their finances" is unsolvable as written. You can't interview "people." You can't market to everyone. Narrow until the statement describes someone you could literally go find this afternoon.

Then there's writing from assumption. This is the deadliest because it feels like work. You sit at your desk, imagine a customer, and write a beautiful problem statement they've never confirmed. The fix is boring and it works: go talk to ten real humans first. If you skip this, you can review the playbook on running good customer conversations over in the validation guides at foundra.ai/key-reads/ before you write a single sentence.

A few smaller traps worth naming. Listing five problems instead of one, so nothing gets the focus it needs. Describing the problem in industry jargon your customer would never use. And quantifying with adjectives instead of numbers, where "huge pain point" hides the fact that you have no idea how often or how badly it actually hurts.

How do you validate your problem statement?

You validate a problem statement by testing whether real people recognize it without prompting and whether they're already spending time or money to solve it. If they are, the problem is real. If they shrug, it isn't, no matter how good your idea feels.

Start with the language test. Describe the problem to people in your target segment and watch their face. Do they finish your sentence? Do they say "oh my god, yes"? Or do they nod politely? Genuine pain produces interruption. People can't wait to tell you their version. Polite agreement is a warning sign.

Then look for existing workarounds. The strongest signal that a problem is real isn't enthusiasm, it's effort. If your future customers are already cobbling together spreadsheets, paying for a clunky tool, hiring someone, or doing the job manually every week, they've proven the problem matters by spending resources on it. A problem with no workaround is often a problem nobody actually has.

Finally, put a number on it. How many people in your segment have this? How often does it bite them? What's it costing them now? You don't need a perfect market-size model to sanity-check whether the math could ever work. A rough estimate, or a quick pass through a market-size or TAM calculator like the free ones at foundra.ai/tools/, tells you fast whether you're looking at a real business or an interesting hobby. Validate the problem before you build the solution, and you've already done more than most of the startups in that 42% ever did.

Key takeaways

• A problem statement names a specific customer, their goal, the obstacle in their way, and the cost, with zero mention of your solution.
• 42% of startups fail from no market need, which makes the problem statement the cheapest insurance you can buy.
• Use the formula: [specific group] is trying to [goal] but [obstacle], which costs them [measurable impact].
• Research real customers first. Five to ten conversations beat any amount of solo brainstorming.
• The biggest mistakes are hiding your solution in the problem, going too broad, and writing from assumption instead of evidence.
• Validate by checking whether people recognize the problem unprompted and whether they already pay or work to solve it.

FAQ

How long should a problem statement be?
One to two sentences. If it runs longer, you're probably describing several problems at once or smuggling in your solution. Tighten it until a stranger could read it once and understand exactly who's hurting and why.

Should my problem statement mention my product?
No. The product belongs nowhere near it. A problem statement describes something true about your customer's world whether or not your company exists. Once the word "app," "tool," or "platform" appears, you've stopped describing a problem and started pitching.

What's the difference between a problem statement and a value proposition?
A problem statement describes the pain your customer has. A value proposition describes how your product relieves that pain and why it's better than the alternatives. You write the problem statement first, then build the value proposition on top of it once the problem is validated.

How do I know if my problem is big enough to build a business around?
Check frequency, intensity, and reach. A problem that's painful, happens often, and affects a findable group of people is worth pursuing. A problem that's mild, rare, or limited to a tiny crowd usually isn't, even if a few people love your idea.

Can I have more than one problem statement?
Start with one. A focused company solves a single problem extremely well before it expands. If you've got a list of five, rank them by how often and how badly each one hurts, then pick the sharpest. You can revisit the others once you've earned the right.

When should I rewrite my problem statement?
Whenever your customer conversations contradict it. Your first draft is a hypothesis, not a verdict. If real people keep describing a different obstacle than the one you wrote, update the statement to match what you're hearing. The map should follow the territory, not the other way around.