CCA Professional M4: Stakeholder Engagement & GTM

• 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:

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:

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 → Review

A 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:

1. Acknowledge the intuition ("This is exactly the kind of task AI is often good at...")
2. 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")
3. 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")
4. 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:

1. Name the four POC-to-production gap dimensions ("A demo hides four things...")
2. 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")
3. 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")
4. 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