Discovery — The Core Skill
Everything downstream — the demo, the POC, the business case — is only as good as what you actually learned here.
Discovery is not a form to fill in; it's a conversation engineered to surface things the buyer hasn't fully articulated even to themselves. Split it deliberately into two tracks that often need separate calls with separate audiences:
Business discovery
- What's the cost of this problem today, in their numbers?
- Who else is affected, and how do they measure success?
- What happens if nothing changes in 12 months?
- What's driven this to become a priority now?
Technical discovery
- What does the current architecture / process actually look like?
- What must integrate, and what are the constraints (security, data residency, scale)?
- Who owns the systems this would touch, and are they in the room?
- What has been tried before, and why didn't it work?
Use open questions to surface the problem, then narrowing questions to quantify it — the same S→P→I→N logic from Module 07 applies directly. Resist the pull to start solutioning mid‑discovery; the moment you pitch, the buyer stops disclosing and starts evaluating, and you lose access to the harder, more honest answers.
Capture it so it's usable
A simple four‑column capture grid, filled live or immediately after, turns a conversation into deal evidence: Problem stated → Business impact (quantified where possible) → Desired outcome → Who cares / owns it. That grid feeds MEDDPICC's Metrics and Implicate‑the‑Pain fields directly, and becomes the spine of your solution narrative in Module 09. The full question bank, organised by category, is Template 1.
That preparation is exactly where AI earns its keep first. The sheet that follows this module is a practical toolkit for where it actually helps across the whole pipeline, not just here.