A pitch deck is read in roughly three minutes by an investor who has already read four others that morning. Within that window, two questions are decided: is this a real problem, and do these founders understand it. Everything that follows on slides four through ten — the market sizing, the traction figures, the team backgrounds, the ask — exists to support whatever conviction was established on slides two and three.
This is why the problem slide is consequential out of proportion to its visible weight. It is not a setup for the solution. It is the case the entire document is making.
The most common error
The mistake most founders make on the problem slide is treating it as a hurdle to clear before reaching the more interesting material. The slide reads as if its author wanted to get past it quickly — three or four bullet points, each generic enough that they could apply to any company in the broad category.
"Customer success teams struggle to retain customers."
"Existing tools are reactive, not predictive."
"Churn is costly for SaaS businesses."
Each statement is true. None of them advances the case. An investor reading this slide learns nothing about how the founder thinks. The slide could have been written by ChatGPT in fifteen seconds — and increasingly, it was.
What a strong problem slide does
The strong problem slide proves three things in sequence:
First — that the problem exists, in a specific form, for a specific person. Generic pain is invisible. Particular pain is memorable.
Second — that the problem is large enough to merit the capital being raised. Not via a TAM calculation (that comes later) but via the human dimension. How many people. How often. How much money or time is being lost.
Third — that the existing alternatives have failed, and why. Not by listing competitors — by explaining the mechanism of failure. What about the current solutions is structurally insufficient, not merely poorly executed.
Customer success leaders at mid-market SaaS companies discover that an account is about to churn weeks after the decision has already been made internally. By the time the renewal call lands on a CSM's calendar, the budget owner has already mentally moved on. The conversation is a formality.
Existing CSM tools — Gainsight, ChurnZero, Catalyst — are built for the conversation that happens at renewal, not the months of disengagement that precede it. They measure outputs, not signals.
The result is a class of mid-market SaaS companies losing customers without warning, at significant cost per logo per year.
The difference is not length. The difference is specificity — and any rewrite of your own slide should be grounded in research you can defend, not figures borrowed from an essay. The second version above contains a structural argument about why existing tools fail; the surrounding numbers in your version should come from your own customer interviews, market reports, or operational data.
The four-line structure
If reduced to a template, the strong problem slide has four parts:
Line one — the symptom. One sentence stating what the customer experiences. Concrete, specific, ideally with a number.
Line two — the consequence. What it costs the customer in money, time, opportunity, or risk.
Line three — the why. Why existing solutions fail. Not "existing solutions are not as good as ours" — the structural or technological reason no current option addresses the symptom.
Line four — the bigger picture. The market or industry-level statistic that proves this is not a niche concern.
Some decks compress these into a single dense paragraph. Some spread them across three or four slides. The format is less important than the discipline.
What to omit
The strong problem slide also has the discipline to leave things out.
Omit the solution. No mention of what you have built. The temptation to foreshadow the answer is the impulse that kills the most problem slides. Trust the reader to wait.
Omit competitors. Naming them belongs on the competition slide, slide seven or eight. The problem slide is about the pain, not the marketplace.
Omit jargon. If a competent reader outside the industry could not understand the problem, the problem is not actually being described. Specialist language is the writer's tell that they are insecure about the strength of the underlying claim.
Omit hedging. "Often" and "sometimes" weaken the statement. Either the problem is real, or it isn't.
The acid test
Show your problem slide to someone outside your industry. Ask them to summarize the problem back to you in one sentence, in their own words.
If they can — without using your slide's exact phrasing — the slide is working. If they cannot, the slide is failing, regardless of how confident you feel about the words.
This is the single most useful test, and most founders never run it.
"The problem is the only part of the deck the investor will repeat to their partners. If it cannot be repeated, the company cannot be funded." — A senior partner at a Tier 1 firm, recounted on condition of anonymity
A closing observation
The problem slide is the only part of a pitch deck that founders consistently under-revise. They polish the design of every slide. They rewrite the ask three times. They rebuild the traction chart at 11 PM the night before. The problem slide stays as written in the first draft — usually weak, usually generic, usually unrevised — because founders implicitly believe everyone already understands the problem they are solving.
The investor does not. The investor has read four decks today, will read three more tomorrow, and is mentally testing whether yours is the one that will deserve the next hour of attention.
The problem slide is what decides that.
Diagnose your problem slide in your browser.
Paste your deck text into the free diagnostic. It scores the problem slide separately against the eleven criteria institutional investors apply on a first read. No signup, no email, no telemetry.
Run the diagnostic →Further reading
- Twenty-three pitch decks that closed capital — annotated reading
- The canonical ten-slide outline — annotated
- The Cold Outreach Playbook — placing the finished deck in the right inboxes