Pitching
How to Prepare a Product Demo for Investors
Build an investor demo around one customer job, with an annotated script, evidence boundaries and a practical failure plan.
What you will learn
- Write a customer-job demo script
- Separate demonstrated behavior from unsupported outcomes
- Rehearse an honest fallback and safe presentation environment
Prepare an investor product demo by choosing one customer job, showing the shortest truthful path through it, and explaining what the demonstration proves. Rehearse the actual environment and prepare a labeled fallback. A feature tour can show many screens without explaining why the product matters.
Confirm meeting length, screen-sharing setup, and whether a live demonstration is useful. Use approved synthetic or permissioned data. If the product is a prototype, say so before showing it. Keep sensitive customer records, credentials, inboxes and internal chats out of the presentation environment.
Choose the question the demo answers
Write one sentence: “After this demonstration, the investor should understand how [customer] completes [job] and what remains unproven.” The answer may be a product mechanism, workflow or technical capability. It is not automatically adoption, willingness to pay, reliability at scale or investment readiness.
YC’s presentation guidance emphasizes clarity and rehearsal. Apply those principles to a real product sequence rather than importing a universal meeting script.
Build the smallest complete story
- Set context. Explain who the user is and why the job begins.
- Show the input. Identify what the product receives, including manual setup.
- Show the useful action. Follow one coherent path instead of opening every menu.
- Show the outcome. Identify what the user can now see, decide or complete.
- State boundaries. Disclose synthetic data, prototype behavior, manual intervention or unavailable features.
- Invite the next question. Stop before the demo becomes an uninterrupted lecture.
Do not hide a human-operated step behind a claim of automation. If a system drafts an answer, distinguish preparation, approval and sending.
Work an annotated demo script
Fictional teaching case: Benchline is a prototype for equipment-maintenance coordinators. The proposed demo shows a synthetic repair request becoming an assigned inspection. It does not show Finta functionality or a real customer result.
Completed three-minute rehearsal script
| Segment | Action and narration | What it proves |
|---|---|---|
| Context,20 seconds | “A coordinator receives a pump inspection request and needs an accountable next step.” | The job being illustrated. |
| Input,25 seconds | Open a synthetic request with equipment, site and issue details. | The shown input format, not every possible source. |
| Core path,60 seconds | Review extracted fields, correct one field, select the responsible technician. | The proposed review-and-assignment interaction. |
| Outcome,30 seconds | Show an inspection task with an owner and due date. | A task exists in the prototype, not that maintenance was completed. |
| Boundary,20 seconds | “This is a prototype with synthetic records; dispatch delivery is not live.” | Development status. |
| Discussion,25 seconds | Ask which workflow or technical question the investor wants to explore. | Nothing by itself; makes room for conversation. |
The segments total 180 seconds. This is a rehearsal allocation, not a recommended duration for every investor. If the slot is shorter, remove secondary steps rather than accelerate narration beyond comprehension.
Prepare an honest failure path
Rehearse with the same device, connection, account and screen-sharing mode. Reset data between runs. Test notifications, browser tabs, permissions, zoom and accidental personal information.
Completed fallback plan
| Failure | Prepared response |
|---|---|
| Network unavailable | Show approved screenshots labeled as a recorded walkthrough, not a live run. |
| Expected action fails | State what failed; move to the prepared artifact rather than claim success. |
| Question goes beyond current scope | State the boundary and offer a follow-up with the responsible technical owner. |
| Private information appears | Stop sharing, remove the exposure and follow the team’s incident process. |
A fallback is not a license to simulate a successful live result. Label recordings, prototypes and mock data clearly.
Copy the run sheet and test comprehension
Customer / triggering situation / job: [ ]
One question this demo answers: [ ]
Current / prototype / planned status: [ ]
Approved data and sharing permission: [ ]
Context → input → action → outcome: [ ]
Manual work and limitations to disclose: [ ]
Timing allocation / actual rehearsal: [ ]
Reset procedure / environment checks: [ ]
Fallback and its label: [ ]
Question owner / follow-up: [ ]Ask an unfamiliar reviewer what they saw, who it helps, and what the product does not yet do. If they infer deployed integrations or measured savings that were not shown, revise the narration.
- One complete user job is understandable.
- The demo’s output is not mistaken for a business outcome.
- Data and environment are safe to show.
- The fallback is accurate and labeled.
- The actual run fits the agreed meeting.
Connect it to your solution slide and broader meeting preparation.
Informational disclaimer
We are not lawyers. This article is for general education only and is not legal, tax, accounting or investment advice. Check with your attorney or accountant before acting on it.