Pro-Owner perspective: This document frames your systems as a technical estate — an asset to be stewarded, documented, and bequeathed. Treat these steps as craftsmanship: protect the continuity, auditability, and transferability of your digital legacy.
What it is
A facilitated workshop held within the first week of engagement to establish a shared understanding of current state, desired outcomes, and constraints. Unlike sales discovery, this is technical and operational—focused on surfacing hidden dependencies, undocumented tribal knowledge, and misaligned expectations before they derail implementation.
The session uses a structured canvas approach with four domains: Agenda (what we're solving), Stakeholders (who decides what), Assumptions (what we think we know), and Decisions (what we commit to today). All outputs are documented in real time, validated by participants, and used as the foundation for the engagement contract.
Why it matters
Most failed projects trace back to misaligned expectations set in the first week. Discovery workshops force explicit articulation of implicit assumptions, surface conflicting priorities early, and create a shared operational vocabulary. This prevents the "technical telephone game" where requirements mutate as they pass through stakeholder layers.
Without discovery, you build the wrong thing correctly. With discovery, you surface disagreements when they're cheap to resolve (pre-implementation) rather than expensive (mid-deployment).
How we do it
- Pre-work (2 days before): Collect org charts, current architecture diagrams (if they exist), and a list of "known unknowns" from the technical lead.
- Session structure:
- Agenda domain (45 min): What problem are we solving? For whom? What does success look like? What are the hard constraints (budget, timeline, compliance)?
- Stakeholders domain (30 min): Who has decision authority? Who has veto power? Who needs to be informed vs consulted? Map RACI explicitly.
- Assumptions domain (60 min): What do we think we know but haven't validated? List everything from "users have admin access" to "backups happen nightly." Mark validation method for each.
- Decisions domain (45 min): What can we commit to today? What requires further research? Document reversibility policy for each decision.
- Post-workshop: Synthesize notes, create a single-page "Engagement Contract" PDF, circulate for sign-off within 48 hours.
What you receive
- Stakeholder map: Names, roles, decision authority, communication preferences, escalation paths.
- Technical inventory: Current systems, versions, dependencies, data stores, integration points.
- Assumptions log: Every assumption made, validation method, owner, deadline.
- Risk register (initial): Top 5 risks identified, preliminary mitigation strategies.
- Success criteria: Explicit acceptance gates, measurable outcomes, "done" definitions.
All artifacts delivered as structured documents (not prose), version-controlled, and referenced throughout engagement.
Evidence
Interactive workshop canvas (expandable sections):
- Agenda section: Copyable template with problem statement, stakeholders, constraints
- Stakeholders section: RACI matrix template
- Assumptions section: Validation checklist template
- Decisions section: Decision log with reversibility flags
Download full workshop kit (templates + facilitation guide): [Link]
Failure modes & guardrails
Failure mode: Workshop devolves into vendor pitch
Guardrail: No solutions presented in discovery. If anyone starts pitching implementation approaches, redirect to documenting current state only.
Failure mode: Key stakeholder missing
Guardrail: Postpone session. Discovery without decision authority present creates false consensus.
Failure mode: Assumptions treated as facts
Guardrail: Every "we think" or "usually" triggers an assumption log entry. No exceptions.
Failure mode: Too many decisions made too quickly
Guardrail: Limit commitments to what can be validated in 2 weeks. Everything else goes to research backlog.