Pitching
How to Write a Pitch Deck Problem Slide
Turn customer evidence into a specific problem slide with an annotated example, claim checks and a copyable writing worksheet.
What you will learn
- Translate customer research into a scoped problem claim
- Match evidence strength to slide wording
- Test whether an unfamiliar reader understands the customer job
Write a pitch deck problem slide by naming a specific customer, showing the job they are trying to complete, and explaining what fails in their current approach. Support the claim with relevant evidence. The goal is to make the problem understandable before introducing your product.
Bring customer research you are authorized to use, a description of the current alternative, and a clear initial customer segment. If the evidence is still weak, write a narrower hypothesis rather than inventing urgency or a market statistic. Use the complete pitch-deck guide for the broader deck structure.
Choose one customer situation
“Businesses waste time” is too broad to guide a slide. Name the role, moment, task, current method and consequence. Sequoia’s pitching guidance connects customer pain with existing alternatives. Your own evidence must establish the specific claim.
Separate user, buyer and affected person. A frontline employee can experience a problem while a manager controls the budget. Do not combine their needs into an imaginary average customer. If several segments have different problems, choose the initial segment and keep other cases out of this slide.
Build the evidence chain
- Write the job. What must the person accomplish in a real situation?
- Describe the current workaround. Include doing nothing, manual work or an incumbent tool.
- Identify the failure. Explain a missed handoff, cost, delay or risk without jumping to your feature list.
- Match evidence to the claim. A small interview sample can reveal reported experiences, not market prevalence. A measured workflow observation needs a defined method and period.
- Choose one point. Use the headline for the problem, a simple visual for the workflow, and a concise evidence note for scope.
Keep quotations permissioned and faithful. If a customer described inconvenience, do not upgrade it to “mission-critical” in the deck.
Work a problem-slide rewrite
Fictional teaching example: Dockline is exploring software for small fabrication shops. Its draft says: “Manufacturing communication is broken. Every factory needs AI.” The statement mixes an unmeasured universal claim with a solution before explaining the job.
Completed problem evidence card
| Field | Illustrative content |
|---|---|
| Customer | Production coordinators in small custom fabrication shops. |
| Job | Confirm the latest drawing before releasing a job to the floor. |
| Current method | Check email attachments and a shared folder, then ask the account owner. |
| Failure | The current approved drawing is not obvious at the handoff. |
| Evidence boundary | In this fictional exercise, three coordinators described this handoff; no frequency or market-size estimate is available. |
| Next validation | Observe the handoff with permission and test whether the ambiguity changes release decisions. |
A truthful illustrative headline is: Coordinators struggle to identify the approved drawing at release. Supporting text can explain the email-folder-check workflow. A small three-step diagram is more useful here than a generic frustrated person.
The slide does not claim that all factories have the problem, that drawings are always wrong, or that Dockline has solved it. If using this in a real deck, replace the fictional research with actual verified records.
Copy the problem-slide worksheet
Initial customer / role: [ ]
Situation that triggers the job: [ ]
Job to complete: [ ]
Current alternative or workaround: [ ]
Specific failure and consequence: [ ]
Evidence / method / dates / sample limits: [ ]
What remains a hypothesis: [ ]
Headline stating the problem: [ ]
Visual showing the job or handoff: [ ]
Supporting evidence note and source: [ ]
What this slide intentionally does not claim: [ ]Write three candidate headlines: one describing the failure, one the consequence, and one the customer’s current trade-off. Choose the version best supported by evidence, not the most dramatic language.
Test comprehension and avoid common failures
Show only this slide to someone unfamiliar with the business. Ask who has the problem, what they do now, and what specifically fails. Do not explain the answer first. Record their interpretation and change the slide if it differs from your intended claim.
If they name your product instead of the customer problem: remove solution features. If they cannot identify the customer: narrow the role. If the statement sounds obvious: show the actual workflow failure. If it requires a giant industry statistic: check whether that statistic proves the local problem at all.
- One customer and job are identifiable.
- The existing alternative is represented fairly.
- Consequences are supported or labeled hypotheses.
- Evidence has a scope and source.
- The next solution slide can respond to this same problem.