Discovery-to-demo bridge

Purpose

Most demos fail the same way: the product's features are shown, and the buyer leaves with a blur. A demo that proves a quantified pain has a specific fix is different. This skill converts discovery into a short plan: which two or three pains to prove, what each costs, the root cause, the exact moment in the demo that shows the fix, and what to leave out.

When to use

• Discovery is done and a demo is the next step.
• Discovery raised several pains, and the rep must choose.
• A previous demo went wide and did not move the deal.
• The buyer or a manager asks what the demo will cover and why.

Do not run this if discovery is incomplete. If no pain can be quantified, the next step is another discovery conversation, not a demo.

Route elsewhere when:

• The question is the demo script or its talk track. Use demo-builder.
• The question is the business case for the buyer's finance team. Use roi-business-case.

Inputs

• Deal context: company, champion and role, stage, and who attends the demo.
• Pains from discovery, in the buyer's words where possible.
• Baselines for each pain: volume, time, headcount, conversion, cycle length, cost.
• The outcome the buyer wants, and what "solved" looks like to them.
• The product moments that could prove each fix.

Missing numbers are marked [CONFIRM WITH BUYER] and become a pre-demo task. They are not estimated.

Procedure

1. List the pains in the buyer's words. Rank by cost and by how central each is to the outcome they described. Build the demo around two or three, at most.
2. Quantify each pain. Convert it to a cost the buyer recognizes, with the arithmetic on one line. Keep the figure conservative and auditable. An unquantified pain goes to the cut list.
3. Name the root cause for each quantified pain: the mechanism that produces it, not the symptom. "Deals stall" is a symptom. A root cause is something a product change can actually fix.
4. Map one demo moment per root cause. Show the single screen or action that proves the fix. Prefer a moment that shows the outcome over one that shows a feature.
5. Build the cut list. Every feature not tied to a prioritized root cause is cut, with the reason. Keep it visible so the rep can defend the omission.
6. Write the Why This Demo plan. Open with the buyer's pain and its cost, then the proof sequence, then what is deliberately left out and where it can be shown later if asked.

Output

• The prioritized pain list with quantified cost, arithmetic shown, and sources.
• Root cause per pain.
• Demo moment per root cause, in running order.
• The cut list with one-line reasons.
• Open [CONFIRM WITH BUYER] items to resolve before the demo.

Quality bar

Every pain in the plan has a number and a source, or is marked for confirmation. Every demo moment traces to a root cause. The cut list is at least as long as the proof list. Watch for demos planned from features, pains with no baseline, and plans that try to prove five things.