The Problem Slide: How to Anchor a Pitch Deck in Real Pain

Most problem slides in pitch decks are forgettable. They state a generic pain in vague language, gesture at a market that's "broken", and move on to the solution. The investor reads it and feels nothing.

The problem slide is the foundation of the rest of the deck. If the problem doesn't land, everything that follows feels like a solution in search of relevance. This article walks through how to write one that actually moves the room.

Why most problem slides fail

Three failure modes:

1. Generic problems. "Data is siloed across teams." "Communication is broken." "Customers want personalisation." Statements true of every category. They tell investors nothing.

2. Problems no one's actually paying to solve. Real-feeling problems that don't translate into budget. "People should have better mental health" is a problem; investors funding mental health companies are funding ones where someone is paying to address it.

3. Problems framed from the founder's perspective, not the customer's. "We saw an opportunity in X." Investors want to hear about the customer experiencing pain, not the founder spotting a market.

The pattern that works

A strong problem slide has three elements:

1. A specific person experiencing the problem. Not "businesses". A specific role at a specific company stage. "VP of Engineering at a 200-person startup". The more specific, the more credible.

2. The pain in concrete terms — usually money or time. "Loses 12 hours a week to manual reconciliation." "Spends $40k/year on a workflow that should cost $5k." Concrete pain anchors the problem.

3. Why it persists. Why hasn't this been solved? Is the existing tooling outdated? Is the buyer fragmented? Is the workflow too niche for big incumbents? The answer to "why is this still a problem" reveals the wedge.

A worked example

Weak version:

Healthcare data is siloed. Providers struggle to coordinate care. Patients suffer.

Strong version:

Mid-sized US clinics (10–50 staff) lose an average of 14 hours per week per clinician reconciling patient data across three different systems — EMR, lab, imaging. The reconciliation work is done by junior admins or, increasingly, by the clinicians themselves. Each clinic spends $80k–$120k per year on this manual process. Existing solutions either require seven-figure integration projects (out of reach for mid-sized) or are built for hospital-scale workflows that don't fit clinic operations.

The second version says: who, exactly, what they pay, why it's still broken. An investor reads it and feels the problem — they could repeat it back to a colleague.

How to test your problem slide

Three quick tests:

1. Could a stranger repeat the problem accurately after one read? If not, simplify.

2. Does it pass the "vs the alternative" test? The alternative to your product isn't always a competitor. Sometimes it's "doing nothing" or "paying a junior to do it manually". Your problem slide should make those alternatives feel costly enough that your solution is worth paying for.

3. Does the customer character feel real? A problem about "small businesses" is generic. A problem about "the head of operations at a 50-person home healthcare agency" is specific. The specificity is what makes the problem credible.

How long should the problem slide be?

One slide. One paragraph of dense content, or three to five short bullets. Don't take two slides; the meeting will lose energy. Don't skip to two sentences either — the investor needs enough to anchor on.

A useful structure:

• Headline: One sentence stating the core problem.
• Body: 2–3 lines of specific detail (numbers, customer quote, timing of pain).
• Why it persists: One line on why this hasn't been solved already.

The "founder origin story" temptation

Many founders want to tell their personal story on the problem slide. I worked at X, I saw this problem first-hand, I built this company because…

Sometimes this works. Often it makes the problem slide about you instead of the customer.

The fix: if your story is genuinely the right way in (you're a domain expert, you've lived the problem), put one sentence about it on the slide and otherwise let the customer be the protagonist. "Having spent six years as VP Engineering at [Company], I lived this problem daily" is fine. A full paragraph of personal narrative is too much.

Common bad framings to avoid

A few framings that consistently fall flat:

• "There's no good solution." Investors hear this on every pitch. Almost always not true.
• "$200bn industry is ripe for disruption." Top-down market sizing posing as a problem statement. See TAM done honestly.
• "Everyone hates [incumbent]." Maybe true; isn't enough.
• "Customers want [generic feature]." Wants don't pay for software; specific pain does.
• "COVID changed everything." Ageing reference. Find a current shift.

Strong framings to try

• "In the last 18 months, [specific change] has made this problem 10x worse." Anchors urgency.
• "Customers are currently solving this with [comically inadequate workaround]." Makes the gap visceral.
• "The companies that need this most can't afford the only existing solution." Identifies a structurally unserved market.
• "This problem is actually three problems stacked, and no one solves all three." Reveals a category-defining wedge.

After the problem

The slide that follows the problem is the solution. The transition between the two is where founders should be deliberate: the solution should feel like it responds to the specific problem you just described, not like it's a generic product seeking a problem.

If your solution slide could plausibly follow many different problem slides, you've under-specified the problem.

A final test

Read your problem slide out loud to someone who doesn't know your company. Ask them: who has this problem, what does it cost them, why is it unsolved? If they can't answer all three, your slide is doing too little. Rewrite.

The problem slide is short, but it's the slide that decides whether the rest of your deck has gravity. Spend more time on it than you think it deserves.