Exam domain covered: D6 — Stakeholder Communication & Lifecycle Management (14%)
Approximate module runtime: 178 minutes of Anthropic learning content
Discovery: Three Steps
Every discovery conversation follows the same sequence:
- Listen — capture what the stakeholder actually said, verbatim. Don't interpret yet
- Translate — convert their preference words into testable, bounded constraints
- Write it down — produce a translation table row for every item
The translation test: when a stakeholder says "seamless," ask: what would break the experience? That answer is the actual testable constraint. "Seamless" becomes "p95 latency under 800ms" or "no re-authentication required between steps."
Why verbatim capture matters: paraphrasing in the moment changes the stakeholder's words into your interpretation. When you review assumptions with the stakeholder later, they need to recognise what they said — not your summary of it.
The Four Discovery Question Categories
Cover all four before moving to design. Missing any one leaves a gap that surfaces as a production failure or a stakeholder objection after launch.
| Category | What it surfaces | Example question to ask |
|---|---|---|
| Must do | The core capability requirement | "What must the system be able to do on day one?" |
| Must NOT do | Hard prohibitions (regulatory, brand, operational) | "What would make this immediately unacceptable, regardless of how well everything else works?" |
| Must cost (performance SLA) | Latency, throughput, uptime requirements | "What response time would make users abandon the workflow?" |
| Must prove (compliance/audit) | Regulatory, explainability, and audit requirements | "Who will audit this system, what will they ask for, and how soon?" |
The exam trap: a question describing a design process where the architect moved to architecture before collecting "must prove" requirements. A regulatory control that doesn't exist in the design doc can't be retrofitted cheaply. The cost of discovering compliance requirements post-design is architectural — not just documentation.
The Translation Table
One row per discovery item, four columns:
| Stakeholder said | Implied constraint | Architectural decision | Assumption (labeled, with owner) |
|---|---|---|---|
| "Seamless and instant" | p95 < 800 ms | Streaming required; no blocking multi-step routing before first response | Assumes WiFi connectivity; confirm with infra lead |
| "We can't store any customer data" | Zero PII persistence | Stateless session design; no conversation logging | Legal must confirm "any data" applies to audit logs too |
| "The lawyers need to see every decision" | Full audit trail, immutable, queryable | Every model call and tool invocation logged with inputs and outputs | Confirm retention period with legal |
The documentation completeness test: can a competent Architect who was not in the room make a safe change after reading this document? If not — because decisions are missing, alternatives aren't recorded, or assumptions are unlabeled — the document is incomplete. Required elements: decision, rejected alternatives, tradeoff, owner, and evidence (with assumptions explicitly labeled as such, with the person who will confirm them).
Tradeoff Framing — Three Elements
Every tradeoff presented to a stakeholder must contain all three elements:
- Gain — what this option provides
- Give-up — what this option costs or forfeits
- Reversal cost — what it costs to undo this decision after the system is built around it
Why Reversal Cost Changes the Meeting
Gain and give-up are almost always in every presentation. Reversal cost is the element most often omitted — and it's the one that most often changes the stakeholder's decision.
Example:
- Option A: Build on a proprietary vendor platform (Gain: faster time-to-market. Give-up: vendor lock-in. Reversal cost: 8–12 months of re-architecture when the contract ends or the vendor pivots)
- Option B: Build on an abstraction layer (Gain: portability. Give-up: 6 additional weeks of engineering. Reversal cost: near zero — swap the provider, not the system)
A stakeholder who hears only "A is faster, B gives portability" may choose A. A stakeholder who also hears the reversal cost often chooses differently.
Trap 8 — Missing the third element: The wrong answer presents gain and give-up accurately but omits reversal cost. The option with a low per-call cost that's never multiplied by volume, or an option with a low upfront cost that's never paired with the cost of unwinding it later, is this trap in action.
The Outcome Document — Six Fields
The outcome document captures the measurable commitment that justifies the investment. It must contain exactly six fields:
| Field | What to capture | Why it's load-bearing |
|---|---|---|
| Use case + scope boundary | What the system does AND explicitly does NOT do | Prevents scope creep and sets stakeholder expectations |
| Metric before | Baseline measurement, in the same units as the after-metric | Unrecoverable if not captured at the start |
| Metric after | Expected post-deployment value, in the same definition as before | Meaningless without the same-definition constraint |
| Auditable control | The technical mechanism that makes the outcome provable | Makes the commitment verifiable, not just asserted |
| Measurement owner | One named person responsible for tracking the metric | Without a named owner, metrics drift or are never collected |
| Reuse potential | Which other teams or use cases this design could serve | Required for enterprise ROI justification |
The before-metric rule: the baseline is unrecoverable after deployment. Once the system goes live, the "before" state no longer exists. If you skip the baseline, you can never prove the system improved anything — and "we believe it improved" is not evidence.
Under regulatory obligation: the two fields that become load-bearing are auditable control and measurement owner. A regulator asks: "what is the technical control, and who is responsible for it?" Those two fields must survive scrutiny.
The Governance Table
Before any production launch, produce a governance table that maps every production signal to:
| Column | What it contains |
|---|---|
| Signal | The observable metric or event (e.g. daily accuracy below 85%, error rate above 2%) |
| Trigger | The threshold that fires this signal |
| Architect's action | What happens in response (e.g. halt rollout, escalate to review board, trigger root-cause analysis) |
| Scheduled checkpoint | Any periodic external review obligation (monthly compliance review, quarterly audit) |
This table must exist before launch. Governance that is designed after a problem occurs is incident management, not governance. The exam tests this with questions where a stakeholder asks about monitoring "once the system is in production" — the correct answer is that monitoring architecture and governance triggers must be defined during design, not after.
The Entry-Point-Responsibility Map
For systems using multiple Claude entry points (Claude Code for internal tooling, claude.ai Enterprise for knowledge workers, API calls for automated workflows), maintain a map that documents:
- Which entry point owns which task category
- Why that entry point was chosen (and not another)
- Where the boundary between entry points lies
This prevents scope creep between routes — e.g., developers using Claude Code to access production customer data that should only flow through the API-based system with proper authorization.
The Feedback Loop Structure
Observability is not the same as a feedback loop. A feedback loop has five stages:
Signals → Triage → Decide → Act → ReviewA signal is not yet a decision. Receiving a quality degradation alert is a signal. Triaging it to determine whether it is a model-drift event, a data-drift event, or a measurement artifact is triage. Deciding to run a root-cause analysis, roll back, or do nothing is the decision. Acting on that decision is the action. Reviewing whether the action worked closes the loop.
Systems that collect signals but have no triage or decide stage will accumulate dashboards that no one acts on.
Stakeholder Objection Scripts
The exam tests two specific objection patterns:
Objection 1: "Why can't we just use AI for this? It seems obvious."
Answer structure:
- Acknowledge the intuition ("This is exactly the kind of task AI is often good at...")
- Run the four-property feasibility check aloud ("...but let me walk through the properties that determine whether this is buildable as you've described it")
- State the verdict with the specific constraint that changes it ("The task is feasible, but not as scoped — the knowledge boundary means we need retrieval, and the confidence ≠ correctness property means we need a human review gate for decisions above $X")
- Offer the feasible version ("Here's what it looks like with those adjustments")
Objection 2: "The demo looked perfect. Why do we need all these guardrails?"
Answer structure:
- Name the four POC-to-production gap dimensions ("A demo hides four things...")
- Map each gap to the specific failure mode it creates in production ("At low volume with a developer watching, you don't see latency under load, failure modes, or cost at scale")
- Connect each control to the gap it closes ("The retry logic closes the reliability gap; the eval framework closes the quality gap; the circuit breaker closes the cascading-failure gap")
- Offer the minimum evidence needed to skip each control ("If you want to skip the circuit breaker, show me a provider SLA and a graceful degradation design")
GTM and Partner Track Considerations
The Professional exam also covers go-to-market and consulting contexts:
Scenario-specific demo vs generic demo:
- A scenario-specific demo is built against the buyer's own workflow and data shapes → creates confidence
- A generic capabilities demo shows what Claude can do in abstract → creates interest, not confidence
For an enterprise buyer, a scenario-specific demo is the minimum required to move from interest to commitment. A generic demo leaves the buyer doing their own mental translation — which introduces uncertainty.
Outcome document in a consulting context: the same six fields apply, but the "measurement owner" becomes critical for handoff — without a named owner, the client cannot maintain accountability after the engagement ends.
Module 4 Trap Patterns
Trap 1 — Right tradeoff word, wrong conclusion: An answer presents gain and give-up, but quotes the gain as a give-up, or presents the reversal cost as if it's a routine operational cost. The structure looks correct; the content is inverted.
Trap 8 — Missing the third element: Gain and give-up covered; reversal cost absent. The option looks like a complete tradeoff analysis but omits the element that most often changes the meeting.
Designing before discovery is complete: an architect who produces an architecture diagram before collecting all four discovery question categories (must do / must NOT do / must cost / must prove) has built on incomplete requirements. The Professional exam catches this.
Key Rules to Memorise
- Discovery: listen → translate → write it down (verbatim → testable constraint → table row)
- Four question categories: must do / must NOT do / must cost / must prove
- Translation table: verbatim → implied constraint → decision → labeled assumption with owner
- Tradeoff framing: gain + give-up + reversal cost (all three required)
- Reversal cost is the element most often omitted and most often changes the decision
- Outcome document: use case + scope boundary / metric before / metric after / auditable control / measurement owner / reuse potential
- Before-metric is unrecoverable after launch — capture it first
- Governance table maps every production signal to trigger + action + checkpoint
- Governance table must exist before launch, not after the first incident