Give each segment a job
A useful rehearsal structure is roughly 30 seconds for customer and problem, 45 for the product and demonstration, 45 for evidence and economics, 30 for execution status, and 30 for the request. These are planning allocations, not a mandatory formula. Adjust them to the meeting and the product.
Do not spend the first minute on the history of having the idea. The listener needs context quickly. Describe a specific user trying to complete a task and the difficulty that matters. Then connect the product to that difficulty without assuming the audience already understands your technical vocabulary.
Make the demonstration earn its time
Choose one action that makes the benefit visible. Prepare the setup so the audience is not watching assembly or troubleshooting unless that is the relevant task. Explain what they should notice before demonstrating it. If a safe live demonstration is unreliable, use an accurate recorded example and disclose its conditions.
For a hypothetical measuring aid, a 20-second demonstration may show repeatable positioning more clearly than six feature slides. If it requires two minutes of setup, prepare the setup in advance and state that fact. Do not edit out failures in a way that falsely implies performance the actual product cannot reliably deliver.
Use one commercial calculation
Suppose the current scenario has a $35 selling price and $21 in variable costs, leaving $14 contribution before fixed expenses. That is enough arithmetic to explain the economic question in a short pitch. Do not overwhelm the listener with a five-year forecast whose inputs remain unsupported.
State what is known and what is still estimated: a quoted production cost, a small user test, an untested channel, or an assumed acquisition expense. Explain the next experiment that addresses the largest uncertainty. Credible limits make the request more understandable; they do not need to consume the entire presentation.
End with a decision and prepare for failure
Ask for a specific next action appropriate to the audience, such as a technical review or a pilot discussion. Explain what you will provide and what you need from them. Avoid ending only with a broad invitation to join the journey, which leaves the practical decision undefined.
Rehearse aloud with a timer, then practice without slides and with a failed demo. Prepare a plain-language fallback explanation. If interrupted, answer the question and return to the decision rather than racing through every remaining sentence. The goal is a useful conversation, not a flawless recitation of a memorized script.
Prepare answers to the questions most likely to interrupt
Write short answers to five likely questions: who buys it, why the current alternative is insufficient, what has been tested, what it costs, and what you need next. Each answer should identify the relevant evidence and its limit. If you do not know, explain the test planned to find out. Inventing a number under pressure is more damaging than acknowledging a defined uncertainty.
Practice transitioning from an interruption back to the main request. For example, after explaining a preliminary cost range, connect it to the pilot quote you want to obtain. This keeps the conversation coherent without ignoring the question. Do not use every interruption as an excuse to open a long technical appendix; answer at the level the listener requested and offer detail if useful.
Prepare a version with no audiovisual equipment. A physical product, one printed image, and a clear explanation may be sufficient. If the demonstration cannot safely or reliably run in the meeting environment, state that beforehand and use a faithful alternative. The fallback should preserve the same claim boundaries as the full demonstration. Rehearsing this version also reveals whether the presentation depends on animation or dramatic language to conceal an unclear customer benefit.
Record one rehearsal and listen without watching the visuals. If the explanation becomes incomprehensible, identify which missing transition or undefined term causes the problem. Then watch without sound to assess whether the demonstration itself communicates the intended action. These two reviews reveal different weaknesses. Keep the final version within the allotted time without speaking unnaturally fast. A shorter explanation with a clear request usually gives the listener more room to ask the question that actually determines whether the conversation should continue.
Decision checklist
- Does the first half-minute establish a recognizable problem?
- Does the demonstration show one meaningful result?
- Can every number be explained and supported?
- Is the final request specific enough to accept or decline?