Problem Statement Pitch Deck: How to Write a Problem Slide (Before/After Examples & Script)
A pitch deck problem statement (your problem slide) should make one customer’s difficulty understandable in 20–40 seconds. Name who is affected, what they are trying to do, how they do it today, and where the workflow breaks.
5 min read · By Axiom Lab · Published · Updated
Who is in the room
Use this when introducing a product to investors or explaining why a project deserves attention. The slide establishes the problem; it does not need to include the full product pitch or a market-size calculation.
Plan enough time for the listener to understand one workflow. In a short deck, this might be a single slide and 20–40 seconds of explanation. Rehearse the complete deck instead of treating that range as a rule.
A specific person struggles with a specific task, and we can show what we know about it.
| Format | Duration | Best use & goal |
|---|---|---|
| Elevator pitch | 30s (~65–75 words) | First introduction or referral; name the problem and earn a follow-up conversation. |
| Async pitch video | 60–90s (product range: 30–180s) | Sent before a meeting; stands on its own with problem, solution, proof and dated request. |
| Live deck pitch | 5-min live talk + Q&A | Demo Day or formal review; cover unit economics, assumptions, risks and live questions. |
What to say, in order
- PersonWho is affected?
- Current workflowWhat happens today?
- FrictionWhere does it break?
- Evidence and limitsHow do we know?
Person
Choose a role in a context, such as a workshop manager receiving stock. “Everyone” is too broad to guide a product decision.
Current workflow
Show the existing sequence or workaround. Respect the reasons people use it; the current process may work well in some situations.
Friction
Point to a missed handoff, duplicate entry or uncertain decision. Use an observation rather than an adjective such as inefficient.
Evidence and limits
Add the source and scope of your observation. If you have not researched the problem, display the research question instead of a fabricated statistic.
Before and after: a problem statement
ILLUSTRATIVE REWRITE
Before
Inventory is broken. Every business wastes time and money.
After
A workshop manager records deliveries on paper before updating a shared spreadsheet. We need to verify whether this handoff causes missed updates.
The revision identifies a person, task and research question. It avoids turning an untested idea into a claim about every business.
Fill the brackets
If a bracket has a missing fact, cut the sentence. Do not invent a number to make the line sound finished.
- Customer
[Specific role] needs to [task] in [context].
- Today
Today, they use [current method] and move through [short sequence].
- Difficulty
At [step], [observed friction] occurs.
- Evidence
We learned this from [permissioned source, date and scope]. We still need to test [unknown].
Worked example: mapping a stock-receiving task
Fictional teaching scenario. The workflow below is a hypothesis to investigate, not a finding from customer research.
Start with a neutral workflow: receive a delivery → write down the item count → update the shared spreadsheet. A simple three-step diagram is enough to locate the proposed problem.
Mark the possible handoff: does the spreadsheet update happen immediately or at the end of the day? Present this as a question until you have observed the task or spoken to the people responsible.
If you obtain permissioned research, replace the question with a precise, bounded observation. State the number and type of participants and how you collected the information. A small interview sample does not establish market prevalence.
Finish the slide with what needs verification: whether the handoff causes errors, whether the cost matters and whether the manager wants to change the process. The next product slide should address this task directly.
What to have ready
A permissioned observation
The current alternative
A consequence you can support
A matching product step
Choose the visual that matches your evidence
Use a workflow diagram when the difficulty is a handoff. Use a labeled screenshot when the issue is visible in an interface. Use a chart only when you have actual comparable measurements, with units and sources.
An interview quotation needs permission and context. It can show how one participant described a problem, but it does not prove that all buyers have it. Avoid stock photos of frustrated people as a substitute for explaining the task.
Where it goes wrong
Opening with a huge unsupported number
Dismissing the current solution
Make it a film
Put the verified problem, source notes and matching product workflow into your project brief before turning the explanation into a video.
A project video runs about a minute, in three chapters: the painful situation, the solution, and the advantages. You submit the name, the audience, the situation, the solution, how it works, the evidence and the next step, and you can upload a plan, a deck, a PDF or photos. Select Start to analyse the material. On the film page, review the suggested length and select Confirm and start to proceed. Do not include a result you cannot source. A film is delivered only after it passes checks, and charged only once delivered.
During the beta, a new address needs an invite code. If you do not have one, write to sales and ask for access.
FAQ
How do you write a problem statement in a pitch deck?
Write one sentence naming the specific role and task, one sentence showing their current workaround sequence, one sentence pinpointing the step where errors or delays occur, and one sentence stating your bounded evidence or open research question.
What belongs on a problem slide?
A specific customer, their task, the current method, the friction and any evidence you can substantiate. Keep the product solution for the next part of the story.
Can I write one before customer interviews?
Yes, as a hypothesis. Label the uncertain points and use them to plan research. Do not invent interview quotes, percentages or observed losses.
Should I combine the problem and solution?
You can if the relationship remains clear and readable. For a complex workflow, separate slides usually give you more room to explain the evidence.
Sources and editorial notes
- Sequoia Capital · Writing a Business Plan
Questions to cover when explaining a business, including the customer problem and alternatives.
These references provide related principles. The sequence, timings and fill-in scripts on this page are Axiom Lab's editorial suggestions, not endorsements by those organizations or measured fundraising or sales results. Adapt them to the audience's requirements and replace placeholders with verifiable facts.
Our public demonstrations use fictional projects and include their actual inputs and transcripts; they are not customer evidence. View the production notes · Editorial and corrections policy