# 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.

Free checklist for sales reps. Topic: [Demos & Product Storytelling](https://www.peerlab.ai/library/topic/demos-product-storytelling/). Published by PeerLab in the [Sales Enablement Resource Library](https://www.peerlab.ai/library/). Source: https://www.peerlab.ai/library/discovery-to-demo-alignment-checklist/

## 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
