- Duration: 90 minutes
- Prerequisites: None: this is the foundation module
- Primary Metric: Discovery Audit
- Frameworks: 5 (Artifact Inquiry, Inversion, Problem-Space Deep Dive, Shadow Stakeholder, Hot Seat Simulation)
The "cleanly scoped" RFP
A 20-page RFP arrives with detailed specs, a clear timeline, a named budget. Clean scopes hide the constraints that matter. Run Artifact Inquiry before drafting a response and reshape the proposal around the absences.
The stalled QBR
An active customer has gone quiet for six months. You have 30 minutes to figure out what changed. Use Inversion directly: "If this engagement winds down in six months, what's the most likely reason?"
The late-stage competitive deal
Three-vendor evaluation. Your technical case is strong. Customer goes silent. Late-stage deals are won on Discovery Audit, not architecture: the architect who surfaced the right Shadow Stakeholder six weeks ago has already had the closing conversation.
Common Misconceptions About This Module
- "This is a soft-skills module." Discovery skill is the single highest-leverage technical capability in pre-sales. The frameworks are diagnostic instruments, not communication tips.
- "I already do discovery." The Discovery Audit metric exists because almost no one does it to standard. Three constraints in three categories is a measurable bar most architects miss.
- "The customer will tell me what I need to know." Customers tell you what they're comfortable saying. Shadow Stakeholders, fragile budgets, and political resistance are precisely what they don't volunteer.
- "Inversion is just risk planning." Risks go in a register; constraints reshape the solution. Inversion happens before architecture is designed.
- "Shadow Stakeholders are an enterprise problem only." Mid-market and SMB customers have them too: smaller orgs make them easier to surface, not absent.
Artifact Inquiry
Systematically examine existing artifacts:RFPs, org charts, past proposals, architecture diagrams, meeting notes:to expose the gaps between what is written and what is real. The questions you ask about what is absent from the artifact are more valuable than what is present in it.
Documents are political artifacts. Every RFP is the residue of internal negotiation: what was included, what was cut, who got named, who got omitted. When you ask about an absence, customers almost always know exactly why it's absent.
Before any first meeting where customer materials were sent in advance, and whenever you inherit a stalled engagement.
Inversion Method
Instead of asking “How does this succeed?” ask “What would guarantee this fails?” Inversion, borrowed from Charlie Munger, surfaces unstated organizational constraints, political minefields, and budget realities that forward-looking discovery questions never reach.
Inversion bypasses optimism bias. Asking "what does success look like" gets the polished narrative; asking "what does failure look like" gets the actual operating model: political tensions, prior failures, the people who can derail it.
Around minute 8–12 of a discovery meeting: after enough rapport for honesty, before enough commitment to feel defensive.
Problem-Space Deep Dive
A structured discipline that does not enter Solution Space until you have articulated three business constraints that were not in the original ask: one financial, one organizational, one timeline/risk. The discipline: do not offer a solution until you have heard the financial framing from the customer, not from yourself.
Customers narrate in technology terms because that's the language IT speaks: but the constraints that kill projects live one layer above, in finance, politics, and time. The three-category checklist gives the customer permission to talk about money, politics, and time as standard topics: not as confessions.
Every customer engagement before solution design. Especially when a brief feels "too clean" or the customer says they already know what they want.
Shadow Stakeholder
Every deal has decision influencers who never appear in the technical meeting: procurement, legal, a departing CTO, a skeptical board member. The Shadow Stakeholder framework maps this hidden influence network using the Veto, Budget, and Downstream Ownership questions.
Org charts capture formal authority; they almost never capture informal influence. Shadow Stakeholders are veto holders by relationship, not by role. The diagnostic questions let sponsors surface them without admitting their own authority is partial.
In any engagement involving more than two internal teams, and any time a deal that was progressing smoothly suddenly goes quiet.
Hot Seat Simulation
Role-play the hardest possible objection you expect:with a peer playing the skeptical VP of Finance or the resistant architect:before the real meeting. The simulation reveals where your discovery is thin, where you are relying on assumption rather than evidence.
Discovery skill degrades under social pressure. The Hot Seat is engineered to produce that pressure on demand: high repetition, immediate feedback, struggle held just above current capability: so the architect can fail safely.
Before any high-stakes real engagement, and as a quarterly refresher when you haven't run a structured discovery in 60+ days.
A 14-hospital RFP, a $4.2M budget, and a clinical informatics shadow stakeholder no one named
Situation
Cascade Health Network: a 14-hospital regional system in the Pacific Northwest: sends a 32-page RFP for a clinical data lake to support population health analytics. Budget cited: $4.2M over 24 months. Sponsor: Robert Chen, VP of Analytics. The brief looks clean. Architecture is in scope. Six IT and Analytics names are listed. No clinical or compliance representation appears anywhere.
Move 1: Artifact Inquiry, before the first meeting
Absence audit surfaces the structural gaps: no Chief Medical Officer, no Chief Compliance Officer, no business event behind the "18-month go-live," and a four-bullet generic risk list that ignores HIPAA audit readiness, BAA structure, and de-identification governance. Working hypothesis going into the first meeting: this is an IT-driven initiative without clinical or compliance buy-in.
Move 2: Inversion at minute 8
"Robert, if we look at this 18 months from now and the platform is built but no one is using it: what most likely happened?" Robert pauses, then names the prior failure: the last data warehouse went unused because the clinical informatics team didn't trust the data lineage. They built a shadow system instead. One sentence yields an organizational constraint, a Shadow Stakeholder lead (clinical informatics), and the institutional memory shaping current resistance.
Move 3: Problem-Space Deep Dive (minutes 12–45)
Financial: phased capital across two fiscal years, gated by an FY1 milestone, with CapEx/OpEx category mismatch on cloud consumption. Organizational: Dr. Helen Vargas leads clinical informatics, reports to the CMO, holds informal veto, has not been engaged. Timeline/Risk: Joint Commission survey window opens in 11 months and creates a blackout period; CMS quality reporting tightens in 14 months.
Move 4: Shadow Stakeholder Mapping
Veto question, budget question, downstream ownership question yield: Dr. Vargas (clinical veto), the CMO (her chain), 14 Directors of Clinical Operations (downstream owners), the CFO (formal stop authority), and the Joint Commission survey team (external regulatory observer). None of them were in the original RFP.
Outcome
The reshaped proposal: Phase 1 is a 10-month data lineage governance foundation co-designed with Dr. Vargas's team, satisfying the FY1 milestone gate and the prior-failure trust gap. Phase 2 expands clinical use cases under CMO sponsorship, paused during the Joint Commission window. Commercial structure: 3-year Reserved Instance to convert OpEx into CapEx-friendly procurement. Embedded clinical data governance steering committee. The proposal that lost the deal was a 24-month architectural masterpiece. The proposal that won the deal was the one shaped by discovery.
The mid-market manufacturer where the budget was about to expire
Situation
600-person specialty parts manufacturer asks for an Azure IoT proposal to instrument 14 production lines. Stated need: reduce unplanned downtime by 20%. Sponsor Janet Albright, VP of Operations, has $1.1M earmarked. The brief reads frictionless.
Move
One 60-minute Deep Dive surfaces three constraints not in the brief. Financial: the $1.1M lives in a continuous-improvement pool reviewed every June; unspent funds get clawed back: and it is March. Organizational: three plant managers were not consulted and have not granted sensor placement access during peak runs. Timeline/Risk: Polaris is in year two of an ISO 9001 recertification cycle; the audit submission window closes in October.
Outcome
Instead of the 14-line full deployment Janet asked for, the architect proposed a single-line proof-of-value (Line 7, lowest disruption), an instrumented dashboard live by June 1 to clear the budget review, a workshop with all three plant managers in week two, and a documentation package built to ISO 9001 audit format. Janet signed in two weeks. The losing proposal: submitted by another vendor: was a 14-line architectural masterpiece due in nine months.
The inherited engagement: and the one phone call that saved six months of work
Situation
You inherit a stalled half-built data lake project at a regional utility. The previous architect left the company. The handoff is a 40-page architecture document with detailed Synapse and Data Factory designs and eight names: all IT and Engineering: on the stakeholder list.
Move
The absence audit names what the document refuses to: zero Regulatory Affairs presence in a utility data project (structurally impossible), a "production go-live Q4" with no FERC reporting cycle anchor, and a three-bullet risk list with nothing on regulatory data lineage or NERC CIP classification. Before any internal meetings, the architect calls the Director of Regulatory Affairs directly.
Outcome
Her first sentence: "Nobody told me you were doing this." The previous architect had built six months of work on infrastructure that would have failed her sign-off. The recovery: pause architecture, run a regulatory data lineage assessment with her team, redesign the data classification model. The engagement was saved by an absence audit and one phone call: not by any technical insight.
The silent acquisition that the inversion question almost missed
Situation
200-person ISV wants to add real-time analytics to their flagship product. CTO Devin Park is enthusiastic. Architecture is straightforward. Budget is approved. Every signal points to a clean engagement.
Move
Inversion at minute 10: "If this is sitting unused 18 months from now, what happened?" Long pause. Then: "Honestly? I'm worried we're going to get acquired before we ship. There's a process running right now. If the buyer doesn't want this feature, we kill the project. I can't tell you more than that." That single sentence reframes the engagement: not architecturally, but commercially.
Outcome
The architect proposed a 90-day proof-of-value scoped so any work product would have standalone value to a future acquirer. Devin's general counsel approved on those terms. The acquisition closed seven months later. The new owner kept the feature. Without the inversion, the engagement would have been built as a multi-year roadmap that died in due diligence.
Pre-Mortem Discovery
This exercise applies the Inversion Method to a hypothetical project scenario before discovery begins.
- Read the fictional project brief provided in the module folder (M01_Discovery_Workbook.pdf, Section A). Do not skip ahead.
- Imagine you are reviewing this project 6 months from now, and it has catastrophically failed. Write down 10 specific causes of failure:organizational, technical, financial, political, and timeline-related.
- For each cause, write the discovery question you did not ask that would have surfaced it.
- Select the 3 most likely failure modes. Rewrite the project brief to address those risks explicitly.
- Compare your rewritten brief to the original. What changed? What did the original assume was safe to leave unstated?
Filled-in example: Polaris Industrial pre-mortem
Scenario: $1.1M Azure IoT proposal, 14 production lines, "fast deployment" requested.
Three highest-leverage failure modes the architect surfaced:
- The budget evaporates before the dashboard is live. Discovery question not asked: "When is this budget pool reviewed, and what happens to unspent funds at that review?"
- The plant managers refuse sensor placement during peak production runs. Discovery question not asked: "Have the three plant managers agreed to the deployment schedule, and has anyone walked the floor with them?"
- The instrumentation change blocks the ISO 9001 recertification. Discovery question not asked: "Are there active audit or recertification cycles that this change must be documented against?"
What the original brief assumed safe to leave unstated: that "fast deployment" was a preference rather than a hard fiscal-calendar deadline; that the VP's sponsorship implied her plant managers' assent; that operational change could happen outside an audit cycle without notification. None of those were true.
Artifact Deconstruction
Apply Artifact Inquiry to a real RFP. Use the sample document in the module folder or a sanitized version from a recent engagement.
- Read the RFP once through without annotating. Get the surface-level picture.
- Read it again. This time, for every requirement statement, ask: “What constraint or assumption is this statement protecting?” Highlight at least 5 implicit assumptions.
- For each assumption, write the discovery question you would ask to surface it as an explicit constraint before you respond to the RFP.
- Classify each assumption as: Financial, Organizational, Technical, or Timeline/Risk.
- Share your list with a peer. Ask them to add any you missed. Discuss the two that feel hardest to ask aloud.
Filled-in example: financial services data warehouse RFP
Five implicit assumptions and the discovery questions that surface them:
- Assumption: Finance does not need to be a stakeholder on a financial data warehouse. Question: "Who in Finance has reviewed this scope, and is the CFO's office aware of the migration window?" Category: Organizational.
- Assumption: "Q3 go-live" is a technical preference. Question: "Is there a business event behind the Q3 deadline: an audit cycle, a board reporting season, a product launch?" Category: Timeline/Risk.
- Assumption: "Standard project risks apply." Question: "How is data quality and PII handling managed today, and what changes when this lands in the cloud?" Category: Technical (with regulatory implications).
- Assumption: Data Governance is implicit in the project. Question: "Who owns data governance today, and have they reviewed this scope?" Category: Organizational.
- Assumption: Budget is approved and stable. Question: "Is the funding capital or operating, and which fiscal year does the spend land in?" Category: Financial.
Hardest to ask aloud: the Finance question: because the customer never named Finance and the architect would be revealing they noticed the absence. The right framing is collaborative: "Most data warehouse projects this size end up needing CFO buy-in on the consumption model. Has anyone in Finance been part of the conversation?"
Shadow Stakeholder Map
Use a real or recent deal (names sanitized if needed) to practice mapping the full influence network.
- On paper or a whiteboard, draw every person who attended technical meetings or was named in communications. Circle them.
- Now draw the people who were mentioned but never present: someone’s manager, procurement, legal, a past vendor, a board member with an opinion.
- For each non-present person, write one sentence: what do they want from this project, and how might their interest conflict with the stated project goals?
- Identify which shadow stakeholder had the most power to block or redirect the engagement. Did you account for them?
Filled-in example: Cascade Health Network shadow map
| Name / Role | Influence Type | Status | Required Action |
|---|---|---|---|
| Dr. Patel, Chief Medical Informatics Officer | Veto on clinical workflow changes | Mentioned twice in passing; not yet engaged | Sponsor introduction within 2 weeks; clinician UX demo before architecture lock |
| Linda Russo, VP of Compliance | Regulatory veto (HIPAA, state reporting) | Aware; not yet briefed on architecture | 30-min review of data residency model before any RFP response |
| Hwang & Sandoval, Clinical Operations Directors | Downstream owners of rollout | Unknown to project team | Surface via sponsor; listening sessions before pilot site selected |
| Tom Brennan, CFO | Year-2 capacity expansion signoff | Year-1 only approved | Year-2 business case written before pilot is live, not after |
Highest-risk shadow stakeholder: Dr. Patel. He is the only one of the four who can convert technical concerns into a board-level governance question, and the only one whose silence at this stage will read later as "no one asked me." Smallest first step: a 20-minute introductory call requested through Robert Chen with a one-line agenda: "how clinical informatics shaped the prior data warehouse failure and what would change this time."
Rate yourself honestly based on your most recent discovery engagement or the exercises above. Ready means you can do this reliably under pressure. Developing means you can do it with preparation. Not Yet means this is a gap to close before moving forward.
These are the calibration errors managers and self-raters make most often on this module. Read them before you finalize your rating.
- Rewarding articulate explanation as if it were practice. A participant who can describe the Inversion Method beautifully in a debrief is not necessarily Ready. The rubric measures behavior in customer-facing situations: not vocabulary. If your only evidence is articulate self-description, the ceiling is Developing.
- Conflating personality with capability. Extroverted, confident architects often surface constraints faster because customers open up to them: but they also enter Solution Space sooner because they are uncomfortable with silence. Quiet architects may surface fewer constraints in real time but probe more deeply once they engage. Rate the behaviors, not the social style.
- The "they meant well" inflation. Effort is not the standard. The Discovery Audit is. If you tried hard but found 1 of 3 blockers, the rating is Developing: not Ready: regardless of effort.
When in doubt, rate down. A false-positive Ready determination produces a participant who plateaus below where they need to be. A false-negative produces one more cycle of practice. The asymmetry favors caution.