Discovery To Demo Bridge

Purpose & When to Use

Most demos fail the same way: the rep shows everything the product does and hopes something sticks. The buyer leaves with indigestion — a blur of features, no clear line back to a problem they care about. A good demo is the opposite. It is a short, sharp proof that a specific, quantified pain has a specific fix. Every screen shown answers the question the buyer is actually asking: "will this solve my problem, and is it worth the money?"

This skill bridges discovery and demo. It takes what you learned on the discovery call and turns it into a "Why This Demo" plan: for each pain worth showing, it quantifies the cost of the pain, names the root cause, and maps the exact demo moment that proves the fix. Everything that doesn't earn a place goes on a cut-list.

Run this skill when any of these are true:

• You have discovery notes and a demo is the next step.
• Discovery surfaced multiple pains and you must decide what to show — and what to skip.
• A prior demo went long, went wide, and didn't move the deal.
• The buyer (or your manager) is asking "what are we going to cover and why."
• You catch yourself planning a feature tour instead of a proof.

Do not run this if discovery is not actually done — if you cannot name a single quantified pain, the answer is another discovery conversation, not a demo. A "Why This Demo" plan built on vague pain is just a feature tour with a title.

Procedure

Inputs you need

Collect these before building the plan. Where a number or fact is missing, do not invent it — mark it [CONFIRM WITH BUYER] and make confirming it part of the pre-demo follow-up.

• Deal context: company, champion (name + role), deal stage, who will attend the demo.
• Pains stated in discovery — in the buyer's own words, ideally direct quotes or close paraphrases from the call.
• Metrics and baselines tied to each pain — volume, time spent, headcount, deal sizes, cycle length, conversion, churn, cost — whatever lets you size the pain.
• The buyer's desired outcome and what "solved" looks like to them.
• Who is in the room for the demo and what each attendee cares about.
• The product moments you could show that map to these pains (your own knowledge of what proves what).

If you have no quantifiable metric for any pain, stop and treat "get the numbers" as a pre-demo task — see Step 4.

Step 1 — List and prioritize the pains

Pull every pain the buyer raised in discovery and list it in their words. Then rank by two things: how much it costs them (Step 2) and how central it is to the outcome they said they want. You are not going to demo all of them. Aim to build the demo around the 2–3 highest-impact, best-validated pains. Everything else is a candidate for the cut-list.

Step 2 — Quantify each pain in dollars, ARR, or time

For each prioritized pain, put a number on it. Convert the pain into a cost the buyer would recognize: dollars lost, ARR at risk, hours burned, headcount consumed, deals slipped. Use the buyer's own baselines. Show your arithmetic in one line so it is auditable and conservative, not a fantasy figure.

• Weak (no number): "Reps waste time chasing stakeholders over email."
• Strong (quantified): "8 AEs × ~5 hrs/week chasing stakeholders ≈ 40 hrs/week ≈ 1 FTE of selling time lost, on ~$1.2M of pipeline that stalls in email limbo."

If you cannot quantify a pain and cannot get the number before the demo, drop it to the cut-list — an unquantified pain is not a reason to demo anything.

Step 3 — Tie each pain to its root cause

For each quantified pain, name the underlying root cause — the mechanism that produces it — not just the symptom. The demo has to fix the cause, not the surface. This is what separates a proof from a feature. "Deals stall" is a symptom; "there is no shared place where every stakeholder can self-serve, so momentum dies between calls" is a root cause you can prove a fix for.

Step 4 — Map the exact demo moment that proves the fix

For each pain → root cause, identify the single, specific product moment that proves the root cause is solved. Not a feature area — a moment. What will you click, what will the buyer see, and what does that prove? Write it as: pain → dollar impact → root cause → the exact thing I show → what it proves.

• Bad: "Show the deal room feature."
• Good: "Open a live deal room and show a stakeholder we haven't met self-serving the business case — proves the root cause (no shared place, momentum dies) is fixed, which is the ~1 FTE / $1.2M pain from Step 2."

If a pain has no clean proof moment, say so honestly rather than forcing an unrelated screen into the demo.

Step 5 — Build the cut-list

Explicitly list the features and screens you are not showing and why. This is as important as what you show. Anything that doesn't map to a quantified, root-caused pain from this buyer goes here. The cut-list is what prevents indigestion. If a stakeholder asks about something on the cut-list, you show it on request — but you don't lead with it.

Step 6 — Sequence the demo and write the "why"

Order the proof moments by impact, highest first, so the demo earns attention early. Then write a one- or two-line "why this demo" you can send the buyer beforehand: the 2–3 pains you'll prove you solve, in their words, with the stakes. This sets the demo up as a proof session the buyer agreed to, not a product tour they endured.

What it produces

A single "Why This Demo" plan containing:

• Prioritized pains — 2–3, in the buyer's words.
• Quantified impact — the dollar/ARR/time cost of each, with the one-line math.
• Root cause — the mechanism behind each pain.
• Proof map — for each pain, the exact demo moment and what it proves.
• Demo sequence — proof moments ordered highest-impact first.
• Cut-list — features/screens deliberately skipped, with the reason.
• "Why this demo" note — the short message to send the buyer before the demo.
• [CONFIRM WITH BUYER] items — any missing metric or baseline, flagged as a pre-demo task rather than a guess.

What Good Looks Like

A great "Why This Demo" plan reads like a prosecutor's case, not a catalog. Every screen shown traces back to a specific pain the buyer named and a specific number that makes it hurt. The buyer watches the demo and thinks "that's exactly my problem, and they just showed me it's gone" — not "impressive product." The cut-list is longer than the show-list, and that's the point.

Signs it's working:

• The rep can state, in one sentence per screen, why that screen is in the demo.
• The buyer's own metrics show up on the slides, not made-up industry averages.
• Features that don't map to a quantified pain never make it into the room.
• The demo is shorter than the reps' instinct wanted — and lands harder.
• The pre-demo "why" note gets a "yes, exactly those" from the champion.

Signs it's off track:

• The plan is a feature list with pains bolted on afterward.
• Pains have no numbers, or the numbers are round, inflated, and unsourced.
• Every discovered pain made the cut — nothing was skipped.
• Proof moments are feature areas ("show reporting"), not specific clicks that prove a fix.