Discovery and Post-Discovery Playbooks

Process and playbooks

Most public sector deals are lost in the first three calls, when a rep trades discovery for a demo.

Discovery: four phases

Phase	What happens	The moves	What "done" looks like
01. Positioning and recon	Earn the right to the meeting before it starts	Stakeholder dossier on who holds budget, who holds risk and who holds the roadmap; a 60-second hook framed on the agency's published mandate; architecture mapping of what they run today; a first estimate of the cost of inaction	We never ask a question whose answer is in the public record. Product relevance is sketched (campus and branch networking, multicloud, observability, SIEM) but not pitched
02. Business and personal impact	Turn a technical symptom into a number and a person	Quantify the cost: outage hours, breach exposure, staff hours lost to manual triage; name the tool sprawl tax across overlapping point products; establish the champion's personal stakes; understand the operational cost to the team, where understaffing and manual triage are consuming capacity that automation is meant to give back	The customer says the number out loud. The champion can explain why this matters to them, not just to the agency
03. Solution and boardroom anchor	Prescribe, do not present	Prescription first, tied to the top three business issues and shaped with the covering engineer before it is said to a customer; competitive displacement framed on consolidation economics, including Enterprise Agreement structure; translate from code to boardroom so the CIO can repeat it to the budget committee; peer benchmarking against comparable states, systems or districts	The champion can carry the business case without us in the room
04. Execution and velocity	Build the team and the path to paper	Multi-role account pod: account executive, systems engineer, specialist, partner; procurement alignment on the vehicle and financing options; a Mutual Action Plan with dates walked backwards from the fiscal close; channel and CRM hygiene so the record matches reality	A named vehicle or a date to name it, a signed Mutual Action Plan, and a forecast entry that survives inspection

These are the two playbooks I coach: four phases to find and quantify real business pain, then three phases to convert it without spending technical capacity we have not earned. The worked example is Cisco's networking, security and Splunk portfolio; the sequence is portable.

Where the SE leads. The systems engineer owns the architecture read in phase one, the aspirational questions in phase two that a rep cannot ask, and the shape of the prescription in phase three before anyone builds anything. In post-discovery the engineer scopes and staffs the proof of value, writes the technical half of the success criteria, and holds the second signature on the gate. Nothing is asked of the engineer until the recon and the business number exist, because that work is the rep's and mine.

Business and technical discovery are one intertwined sequence across four phases, and at each crossing the systems engineer trades an architecture read for the business number the rep has gathered.

Where I have done this

At New Relic I ran this sequence on the Maryland Benefits play, from agency modernization and legacy tool consolidation through to a close through Maryland DoIT procurement.

Post-discovery execution: three phases

Phase	Focus	Mechanisms	Gate to clear
01. Internal pod command and hygiene	Get our own house in order before asking the customer for anything	MEDDPICC profiling of what we actually have evidence for; pod alignment on who owns which persona; specialist and subject-matter expert activation with a scoped ask	Every gap in the qualification is named and assigned, with a date
02. External reciprocity and control	Trade value for commitment, never for free	The discovery-to-demo bridge: the demo answers the top three issues the customer named, nothing else; reciprocal commitments, where each thing we deliver is matched by access, criteria or a date; Mutual Action Plan cadence with both sides' names on it	The customer has given something back at every step: a meeting, a criterion, a procurement contact
03. Commercial architecture and gates	Decide whether this earns technical investment	Dual-key proof-of-value gate signed by both sales and engineering leadership; Economic Buyer interlock on record that meeting the criteria moves this to procurement; multi-persona consensus across the platform team, end users and security	All five proof-of-value entry criteria met, or the proof of value does not start

How this protects engineering time

Every phase above exists so that a systems engineer is asked for hours only when the hours will change an outcome. Recon and impact work is mine and the rep's to do, which means the engineer walks into a meeting already knowing the architecture, the politics and the business number. The prescription phase forces us to choose a shape before we ask anyone to build one. By the time a proof of value is requested, there is a tested champion, written success criteria, an Economic Buyer on record, a path to paper and a hard end date, and two signatures are needed to start it. My job is to tell a customer "not yet." That is not the engineer's job, and I do not put it on them.