Discovery → Demo
A repeatable method for the work between "the customer showed us their current state" and "we showed them what it could be."
Built from a real Dynamics 365 engagement. All customer specifics have been removed — this is the method and the technical playbook, not an account handoff. Bring your own customer data.
Why this exists
Most of the cost in a discovery-to-demo cycle is not the demo. It is:
- getting every source into one place (email threads, two different transcripts, live captions, screenshots)
- separating what the customer said from what we inferred
- building demo data that is realistic enough to be believed
- building the artefact without silently shipping bugs
- not over-committing on dates before you know what you're building
This skill front-loads the failure modes so you don't rediscover them.
Phase 0 — Decide what kind of session it was
| Session type | What you bring | What you take away |
|---|---|---|
| Reverse demo (customer presents their current state) | Nothing. No slides, no demo. | Screenshots, friction points, vocabulary |
| Discovery call | Questions | Requirements, personas |
| Art-of-the-possible demo | The demo | Reactions, objections |
If it's a reverse demo, do not bring a demo. The customer is the presenter. Your job is to ask, capture, and stay quiet. Read references/01-source-ingestion.md before the session so capture is set up in advance.
Phase 1 — Ingest every source
Do not start writing until you have all of them. Partial ingestion produces confident, wrong conclusions.
Typical source set: - The email thread (often months long, often the origin of the ask) - The official Teams transcript (authoritative) - Live captions you captured yourself (lossy — see below) - Screenshots pasted during the call - Any internal debrief afterwards - Prior related sessions
→ Full retrieval ladder, including what to do when the customer organised the meeting: references/01-source-ingestion.md
The single most important ingestion rule
An official transcript supersedes live captions everywhere they disagree.
Captions mis-attribute speakers, drop numbers, and truncate. If you built findings from captions and the official transcript arrives later, re-verify every number and every quote. Expect to correct at least one thing you were confident about.
Phase 2 — Write two documents, not one
| Document | Audience | Contains |
|---|---|---|
| BRIEF | Your account team, before the next meeting | Decisions, risks, recommended posture, what to say and not say |
| FINDINGS | You, and whoever inherits this | Every quote, every number, every source, in full |
Keeping them separate is what makes the BRIEF short enough to actually be read.
→ Structure, evidence discipline, and confidence marking: references/02-findings-and-brief.md
Evidence discipline (non-negotiable)
Every number carries a source and a confidence level:
- ✅ Verbatim — quoted in an official transcript
- 🟡 Caption-sourced — heard, not confirmed. Never quote externally.
- 🔴 Inferred — your arithmetic. Label it as yours.
When you catch yourself writing a compelling number, ask where it came from. The most persuasive figure in a findings pack is often the least verified one.
Phase 3 — Find the constraints that must shape the demo
Before designing anything, hunt explicitly for these. They kill demos that ignore them.
1. Compensation coupling. Ask: does anything in this design change who gets paid? Record ownership, territory, portfolio membership and delivery timing are frequently compensation inputs. If your demo reassigns records or shares them, you may be proposing a pay cut. Design around it (e.g. hierarchy-based visibility that leaves the owner field untouched).
2. Prior failed adoptions. Count them. Ask "what have you already tried?" Every failed internal project tells you what you must not lead with. If dashboards, task tracking and a quotes view all failed, then a data-entry-first story will fail too.
The rule that follows: the system gives before it asks. Data capture is a byproduct, never the request.
3. Incumbent tools with an owner. There is usually an incumbent (BI platform, reporting stack, another CRM) with a named internal sponsor. Never attack it. Show native capability and let the customer draw the comparison. Write your position down before someone says it live.
4. Where the data actually lives. "Can AI tell me what to do next?" reduces to "is the data reachable?" Map the sources, the integration surface (APIs, semantic layers) and the swivel-chairs. Integrating beats replicating.
5. The persona you missed. There is almost always one — the person who shows up but isn't in the system. Ask "who touches this process but has no login?"
Phase 4 — Gate before you build
Do not commit to a demo date until the customer has approved a written persona / experience definition.
The gate document says: here are the personas, here is what each needs to see and do, here is what a great experience looks like. The customer confirms or corrects it. Then you build.
Two reasons this matters: 1. It prevents building the wrong demo confidently. 2. It converts "when can we see it?" into a shared dependency rather than a date you owe.
Ship personas with no date attached. Timing gets confirmed internally after the gate closes.
Phase 5 — Build the demo dataset
A concept demo fails on unrealistic data faster than on missing features. Names, amounts, dates and category mixes must look like the customer's actual business.
→ Build order, and the Dataverse quirks that will otherwise cost you an afternoon: references/03-dataverse-demo-data.md
Deliberately build gaps into the data, not just successes. A dataset where every account is healthy has no story. Seed dormant accounts, category gaps, stalled deals — the things your demo screens are meant to surface.
Phase 6 — Build the artefact
Pick the lightest thing that carries the story.
| Artefact | Use when | Effort |
|---|---|---|
| HTML concept demo | You need to show a reimagined experience fast, in the customer's own UI shell | Low — hours |
| Canvas app | The customer must click it themselves, or you need it to live in their tenant | Medium |
| Configured model-driven app | You're proving it's standard product | Higher |
→ HTML concept demo pattern (customer shell + presenter notes rail): references/04-html-concept-demo.md
→ Canvas app authoring via pac CLI, including the non-obvious blockers: references/05-canvas-app-via-pac.md
Bias to "no customisation" claims you can defend. If the story is "this is standard product," every screen must actually be standard product. Note where you've taken licence.
Phase 7 — Verify before you believe it
This phase is where most of the quality comes from, and it is the one most often skipped.
→ references/06-verification-checklist.md
The headline rules:
- A build tool accepting your artefact is not verification. Packagers and importers accept broken content routinely.
- Round-trip everything. Pack → unpack → confirm your change survived.
- Check cross-screen consistency. If screen A says "8 accounts with a gap" and screen B computes 6, the customer will find it.
- Test the interactions, not just the render. Click every filter, count the rows.
- Check file timestamps after a build. Tools that "succeed" without writing anything are common.
Anti-patterns
| Don't | Do |
|---|---|
| Build findings from captions alone | Wait for the official transcript; correct yourself when it arrives |
| Quote a striking number because it's striking | Mark its source and confidence; verify before external use |
| Lead with data capture | Lead with something that returns value on day one |
| Attack the incumbent tool | Show native capability; let them compare |
| Promise a demo date in the room | Gate on an approved persona doc first |
| Assume the packager validated your work | Round-trip and test |
| Design around one persona per role | Look for the unregistered human in the process |
Files in this skill
SKILL.md this file — the method and the gates
references/01-source-ingestion.md retrieval ladder: email, transcripts, captions, attachments
references/02-findings-and-brief.md two-document structure, evidence discipline
references/03-dataverse-demo-data.md demo dataset build order + Dataverse MCP quirks
references/04-html-concept-demo.md the HTML concept-demo pattern
references/05-canvas-app-via-pac.md canvas app authoring via pac CLI (the hard-won one)
references/06-verification-checklist.md how to catch your own bugs
scripts/extract-docx-text.py pull clean text out of a .docx transcript
Provenance
Distilled from a Dynamics 365 discovery engagement: a customer reverse-demo session, two meeting transcripts, a live-captions capture, ~20 screenshots, a Dataverse demo dataset, two HTML concept demos and a five-screen canvas app. Customer-identifying content has been removed.