Pitching
How to Write a Pitch Deck Solution Slide
Explain what changes for the customer, map each promise to product evidence and separate current capability from the roadmap.
What you will learn
- Map a product mechanism to a specific problem
- Choose evidence appropriate to development stage
- Keep roadmap promises out of current-capability claims
Write a pitch deck solution slide by showing how a specific customer completes the previously stated job differently. Explain the mechanism and the useful result, then mark what works today versus what is planned. A list of features is not an explanation of a solution.
Start with a reviewed problem statement, current product evidence, and permission to share any screenshots or examples. This lesson teaches a single slide’s argument, not the entire product demo or deck.
Keep the same customer and job
A problem about a coordinator’s handoff should not suddenly become a solution for enterprise analytics. Carry the customer, moment and desired job across both slides. Sequoia’s solution prompt asks what makes the value proposition compelling. The exercise below turns that question into a checkable mechanism.
Use a simple before/after sequence: input, product action, customer decision. Show where human judgment remains. If the product prepares a suggestion for approval, do not present it as automatically executing the final action.
Translate features into changes
- Name the customer’s current step and failure.
- Describe the product action in concrete verbs.
- Explain what the customer can now see or do.
- Attach proof of current behavior.
- Separate future functionality and unmeasured outcomes.
- Choose one clear visual, not a mosaic of unreadable screenshots.
A real screenshot can prove that a view exists; it does not prove time saved or revenue gained. A prototype can demonstrate a proposed interaction if clearly labeled, but it is not evidence of a deployed product.
Work the solution map
Fictional example: Dockline’s problem is finding the approved drawing before releasing a fabrication job. The first solution draft says: “AI-powered collaboration, analytics and seamless automation.” It names a category rather than explains a change.
Completed problem-to-solution map
| Problem step | Illustrative product action | Customer result | Evidence boundary |
|---|---|---|---|
| Compare email attachments | Display linked versions beside the job | Coordinator can inspect version context in one view | Prototype walkthrough, not deployed usage |
| Ask which version is approved | Show the recorded approval and its owner | Coordinator sees who must confirm release | Demonstrated with synthetic records |
| Release job | Require coordinator confirmation in the proposed flow | Human owns the release decision | No claim of autonomous approval |
A stronger headline is: One job view connects drawing versions with approval context. Supporting text: “The coordinator reviews the recorded approval before confirming release.” A visible “Prototype” label preserves the development status.
Do not add “cuts mistakes by 80%” or “works with every fabrication system” without real evidence. A future ERP connection belongs on a labeled roadmap, not in a current-capability screenshot.
Choose the right kind of proof
Evidence supports different claims
| Proof | Can support | Does not establish by itself |
|---|---|---|
| Labeled prototype | Proposed interaction | Production availability or reliability |
| Current product walkthrough | Observed behavior under shown conditions | Universal performance |
| Defined customer test | Measured result in its actual scope | Every customer outcome |
| Architecture explanation | How a mechanism is designed | Customer adoption |
Use the weakest necessary claim that still communicates real value. Precision can make an early product more credible than pretending it is complete.
Copy, test and refine
Same customer / job as problem slide: [ ]
Current step and failure: [ ]
Product input → action → customer decision: [ ]
Current / prototype / planned status: [ ]
What the customer can now do: [ ]
Evidence / conditions / source: [ ]
Unmeasured outcome or limitation: [ ]
Headline and one supporting sentence: [ ]
Visual / permission / development label: [ ]Show the problem and solution slides together. Ask a new reader to describe what changes. If the response is “it uses AI,” the mechanism is still vague. If the reader thinks a prototype is live, fix the status label.
- The solution answers the stated problem.
- The mechanism uses understandable actions.
- Human decisions and limits are visible.
- Current capability and roadmap are separate.
- Every outcome claim has matching evidence.
Continue with an investor demo script when the interaction needs more explanation.