A fundable problem slide names a specific customer, states the recurring pain they feel, shows the workaround they currently tolerate, and backs it with one quantified consequence, whether that's cost, time lost, or how often it happens. Everything else on the slide is decoration. Get those four pieces right and the rest of the deck gets easier to pitch.
TL;DR:
- A problem slide must precisely identify a customer, their recurring pain, the current workaround, and a quantifiable cost or hours lost.
- Investors expect a clear narrative linking market triggers, specific customer behavior, and measurable pain without vague language or unsupported market figures.
- Using bottom-up calculations based on real customer data, such as cost per clinic or transaction losses, is more convincing than large top-down market size estimates.
- Validating the problem requires targeted interviews with end users, purchasers, and operations, focusing on actual behavior and existing spend on solutions.
- The problem and solution slides should be directly connected through consistent language, emphasizing the specific shortcoming your product addresses based on real evidence.
Table of Contents
- What investors expect: the five questions a problem slide must answer
- Three-slide micro-template: status quo → why now → quantified pain
- How to quantify the pain: simple formulas and a worked example
- Gathering rapid customer evidence: interview checklist and behavioral tests
- Phase-0 workflow: how Klaritea turns one-liners and interviews into a slide-ready problem narrative
- How to tailor problem slides to different audiences
- How to link the problem slide effectively to the solution slide
- Author Karl's quick dos and don'ts when reviewing problem slides
- Try Klaritea to build a validated problem slide faster
- FAQ
- Sources
What investors expect: the five questions a problem slide must answer
Investor guidance from Y Combinator converges on a simple sequence: name the customer and their pain, show the current workaround, explain why that workaround falls short, and connect the pain to a market worth pursuing. Solutions stay off this slide entirely. That sequencing exists because investors are not grading your writing, they're testing whether a real behavior change is likely.
Five questions map directly onto slide elements:
- Who is the customer, described specifically enough that someone in the room recognizes them.
- What are they trying to get done when the pain hits.
- How do they cope with it right now, without your product.
- Why does that workaround fail them, in cost, time, or risk.
- Will they actually pay to make the pain go away.
Vague language kills this fast. "Small businesses struggle with communication" answers none of the five questions. "Dental clinics with 3 to 8 chairs lose appointment slots to no shows because front desk staff call patients manually" answers all five in one sentence, because it names the persona and the task they're failing at.
One slide is enough when the pain and workaround fit in a single clean visual. YC's design guidance pushes for large type and obvious headlines precisely because a crowded slide signals an unclear thesis. When the story needs more than that, a compact 2 to 3 slide narrative beats cramming detail into one, and the next section gives you that exact structure.
Pro Tip: If you can't fit the customer, pain, and workaround into one sentence each, the problem isn't settled yet, no matter how good the slide looks.
Three-slide micro-template: status quo → why now → quantified pain
When a single slide feels thin, YC's Series A guidance supports splitting the problem narrative into three compact slides rather than cramming everything onto one.
- Status quo slide. A declarative headline stating the pain as fact, a one-line persona description, and a single vivid workaround example. Template: "[Persona] currently [does X workaround] to deal with [pain], costing them [unit of cost]." Example: "Clinic managers juggle three spreadsheets and a shared inbox to track no shows, losing track of who confirmed."
- Why now slide. A specific trigger, technical, regulatory, or behavioral, with a date or source. Template: "Since [date/event], [persona] has had to [new behavior] because [trigger]." Example: "Since telehealth reimbursement rules changed in 2023, clinics have had to track two booking systems instead of one."
- Quantified pain slide. A per-customer cost formula paired with a bottom-up beachhead market estimate. Template: "Each [customer] loses [EX] per [year/month] to this problem. Across our initial segment of [N] customers, that's [BY]."
Keep the visual load light on each:
- One headline, one persona line, one number or quote per slide, nothing more.
- A small source note in the corner (publication or date) builds credibility without cluttering the slide.
- Charts only when they show a trend; a single bold figure usually beats a chart for this content.
Sequoia's guidance reinforces the same order: customer and pain first, workaround and shortcoming next, market sizing last, always tied back to the same customer segment named on slide one.
How to quantify the pain: simple formulas and a worked example
Two formulas cover most problem slides. For time lost: hours spent per week × loaded hourly rate × 52 weeks gives an annual cost per customer. For lost revenue: failed transactions or churned customers × average transaction value gives direct revenue impact.
Worked example: say a clinic's front desk staff spends 5 hours a week manually confirming appointments, at a loaded rate of $25 an hour. That's 5 × 25 × 52 = $6,500 lost per clinic per year. Multiply that by an initial beachhead of 400 clinics in your target region and the pain is worth $2.6 million annually to that segment alone, a number Sequoia's deck guidance treats as more persuasive than any unsupported total addressable market figure.
A bottom-up beachhead number built from a real per-customer cost is more convincing to investors than a top-down market size with no visible assumptions, according to Sequoia's pitch deck framework, because every assumption is checkable.
Build your beachhead TAM the same way:
- Define the initial customer segment precisely (not "all clinics," but "independent dental clinics with 3 to 8 chairs").
- Multiply segment size by your per-customer cost or willingness-to-pay figure.
- Show the math on the slide or in a note, not just the final number.
What not to do: never present a huge top-down figure like "the global healthcare market is worth $4 trillion" without showing how your segment connects to it. Investors ignore numbers they can't trace back to a real customer.
Gathering rapid customer evidence: interview checklist and behavioral tests
Five to fifty interviews are enough to validate a problem slide if you talk to the right mix: the end user who feels the pain daily, the purchaser who controls budget, and anyone in operations who manages the workaround. Each role reveals a different piece of the puzzle, and purchasers especially tell you whether money will actually move.
Ask about behavior, not opinions. Useful questions include: "Walk me through how you handled this last time it happened." "What have you tried that didn't work?" "What does this cost you today, in money or hours?" Compliments don't predict sales; described behavior does.
Sequoia's PMF framework treats pilot commitments, signed letters of intent, and existing spend on clunky workarounds as stronger evidence than warm feedback, because they require the customer to act, not just agree.
- Interview end users for the daily pain, purchasers for budget reality, and ops staff for workaround mechanics.
- Ask how they handle the problem now, what they've already tried, and what it costs them.
- Treat a pilot agreement or an LOI as real signal; treat praise alone as noise.
Pro Tip: A prospect who's already paying for a messy workaround is a stronger problem-slide data point than ten people who say "yeah, that sounds annoying."
Phase-0 workflow: how Klaritea turns one-liners and interviews into a slide-ready problem narrative
We built our platform around the idea that a problem slide should come out of a structured model, not a blank page. You type a one-line idea, and a clarity lens pulls it into a defined customer profile, a stated pain, and the assumptions behind your market sizing, while other lenses keep those same facts connected to your feature list and operations.
An AI advisory board challenges the numbers you enter before they reach an export, so a beachhead TAM or a cost-per-customer figure gets questioned early rather than in the investor meeting. Outputs include clarity scorecards, a printable report, and slide-ready copy you can drop straight into the templates above.
How to tailor problem slides to different audiences
The same pain statement needs a different frame depending on who's reading it. Investors want the five-question structure above: customer, pain, workaround, shortcoming, willingness to pay, because they're deciding whether to fund behavior change at scale.
Internal stakeholders, like a cofounder or an early engineer, need less persuasion and more precision. They already believe the problem exists; what they need is the exact mechanism (where in the workflow the pain hits, what data proves it) so they can build the right first feature instead of a generic one.
Customers themselves rarely see a "problem slide," but the same pain statement shows up in your pitch to them, usually stripped of market sizing entirely. A customer wants to hear their specific situation described accurately, not a TAM number, so the persona line from your status quo slide does double duty as sales copy when you adapt it.
The discipline that makes this easy is keeping one underlying pain statement and rewriting only the framing around it. If your core sentence, "clinic managers lose 5 hours a week to manual appointment confirmation," needs three different versions for three audiences, that's a sign the sentence is solid. If it needs three different pains, the problem itself probably isn't settled yet.

How to link the problem slide effectively to the solution slide
The handoff between problem and solution is where most decks lose momentum. YC's guidance is explicit that the problem slide should name the shortcoming of the current workaround and stop there, leaving the solution slide to answer that exact shortcoming point for point.
Practically, this means your solution slide's opening line should echo language from the problem slide. If the problem slide says clinics "lose track of who confirmed" using three spreadsheets, the solution slide should open with how your product replaces those three spreadsheets with one view, not with a generic feature list.

Avoid introducing a new persona, a new pain, or a new metric on the solution slide. Every number on the solution slide should trace back to a number the investor already saw on the problem slide: if the pain was $6,500 lost per clinic per year, the solution slide should show how much of that you recover, not a different, unrelated benefit.
The strongest decks treat the problem and solution slides as a single argument split across two frames: tension, then release. Investors are tracking whether you understand the shortcoming well enough to have built the right fix, and a mismatch between the two slides is one of the fastest ways to lose that confidence.
Author Karl's quick dos and don'ts when reviewing problem slides
The three mistakes I see most often: a persona so vague it could describe anyone, a workaround described as "nothing" when customers are clearly paying for something, and a market number with no visible math connecting it to the customer on the slide. Each one is fixable in under ten minutes.
Before any investor meeting, run this check: can you point to the sentence that names the customer, the sentence that names the workaround, and the single number that proves cost or frequency? If any of those three is missing or buried in a paragraph, fix it before you walk in.
Expand to two or three slides only when the trigger ("why now") needs its own evidence, not just because you have more to say.
— Karl
Try Klaritea to build a validated problem slide faster
Getting the customer, pain, workaround, and metric onto one slide is faster when they're already connected in a working model instead of scattered across notes and interview transcripts. Our Clarity lens keeps those four pieces linked as you edit, and our exports turn them into slide-ready copy without a rewrite.

Start on our Free plan to build the connected model, then move to paid exports and AI advisory credits when you're ready for a deeper stress test.
- Start with your one-line idea and let the Clarity lens draft the customer and pain statement.
- Run the AI advisory board on your workaround and cost claims before you trust the numbers.
- Export the clarity scorecard and printable report once the model holds up.
FAQ
What should a problem slide always include?
A fundable problem slide names the customer, states their recurring pain, shows the workaround they use today, and includes one quantified consequence like cost or hours lost. YC's Series A guide keeps solutions off this slide entirely.
Should the problem slide include market size?
Market sizing belongs in the opportunity story, but only when it's built bottom-up from the same customer segment named on the problem slide. Sequoia's deck guidance warns against large top-down numbers with no visible assumptions.
How many slides should the problem take up?
One slide is enough when the pain and workaround fit cleanly in a single visual; a 2 to 3 slide narrative covering status quo, why now, and quantified pain works better when the story needs more room. YC's design guidance favors simplicity over cramming detail onto one slide.
How do I prove customers actually want this solved?
Pilot commitments, signed letters of intent, and existing spend on a clunky workaround are stronger proof than positive interview feedback. Sequoia's PMF framework treats these behavioral signals as decisive during diligence.
Can I use examples from famous companies as templates?
Famous examples like Airbnb or Mixpanel are useful for understanding structure, not for copying word for word, since TechCrunch's analysis notes they work because each ties a clear problem to a defined audience with quantified impact, not because of their specific wording.
Sources
- How to build a great Series A pitch and deck | Y Combinator
- Sequoia Capital pitch deck guidance | StartupFundraising
- Problem slide analysis | TechCrunch
- Writing a business plan | Sequoia Capital
