--- name: "discovery-to-demo" description: "End-to-end playbook for turning a customer discovery or reverse-demo session into an evidence-based findings pack, a realistic Dataverse demo dataset, and working concept demos (HTML and/or canvas app). Use when the user says discovery-to-demo, 'I just had a reverse demo', 'turn this transcript into findings', 'build a demo dataset for this customer', 'build a concept demo', 'what did we learn in that session', or is preparing a persona/experience document before committing to a demo. Covers sou" --- # 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.