Individual
Checklist
Free
Discovery-to-Demo Alignment Checklist
A pre-demo checklist that forces every feature you're about to show to trace back to a specific pain a specific stakeholder named in discovery, so the demo speaks to their problem instead of touring your whole product.
How to use it
Complete the pain-to-feature mapping table for every attendee before you touch your demo environment, then run through the removal and rehearsal checklists the day before the call.
What's inside
- Discovery-to-demo traceability check
- Per-stakeholder pain-to-feature mapping table
- Demo sequencing rules
- Generic-tour removal checklist
- Proof-point preparation per stakeholder
- Objection pre-emption check
- Rehearsal and transition checklist
- Post-demo alignment confirmation
Work through this before you build a single slide or click into the product.
Step 1: Traceability Check
- I can name, for every attending stakeholder, the specific pain they described in their own words during discovery
- I have not invented or assumed a pain for anyone who hasn't actually told me one: if I don't know their pain, they get a short general overview and a question, not a personalized segment
- I have re-read my discovery notes in the last 24 hours (not relying on memory)
Step 2, Per-Stakeholder Pain-to-Feature Mapping
| Stakeholder Name | Role | Stated Pain (their words) | Feature/Capability That Addresses It | Proof Point | Time Allocated |
|---|---|---|---|---|---|
Fill one row per attendee before building the agenda. If a row can't be filled, that's a signal: go back to discovery, or don't feature that person's segment prominently.
Step 3: Demo Sequencing Rules
- Demo opens with the pain in their language, not a product overview ("You told me [X]: here's how that plays out differently")
- Sequenced by stakeholder priority, not by how the product is built internally
- Each stakeholder's segment lasts no longer than their actual level of interest justifies
- Highest-priority/highest-influence stakeholder's pain is addressed in the first third of the call
Step 4: Generic-Tour Removal Checklist
- Removed any feature from the agenda that doesn't map to a row in the pain-to-feature table
- Removed "let me show you everything the platform can do" framing entirely
- Cut any slide/screen that exists only because "customers usually like to see this" without a named pain behind it for this audience
- Confirmed total demo length matches what was actually agreed, not padded to fill a default meeting slot
Step 5: Proof-Point Preparation
- Selected one proof point (case study, reference, stat) per major pain: ideally from a company that looks like theirs
- Proof points are specific ("Company X cut onboarding time from 6 weeks to 9 days") not generic ("customers love this")
- I know which proof point maps to which attendee and I'm prepared to reference it directly to them by name
Step 6: Objection Pre-Emption
- Reviewed discovery notes for any hesitation, concern, or competitor comparison raised and built a direct answer into the relevant segment
- Prepared a specific answer for the Technical Evaluator's known concern rather than a generic security slide
- Prepared a specific answer for anyone flagged as a Skeptic/Blocker
Step 7: Rehearsal & Transition Checklist
- Rehearsed the transition sentence between each stakeholder's segment out loud ("That covers what matters to [Name]: now let's look at what this means for [Name]'s team")
- Confirmed who's driving the demo environment and that it's loaded with data/scenarios relevant to their industry, not default demo data
- Have a fallback plan if a technical issue occurs (screenshots/recording of the key moments)
Step 8: Post-Demo Alignment Confirmation
- Ended by asking each stakeholder directly whether what they saw addressed what they'd told me mattered ("Did that land for what you're dealing with, or did I miss something?")
- Captured any new pain or concern raised during the demo itself for the next call
- Confirmed next step with a date before ending the call