The Experience Outcome Layer

Install the distinction that protects every later exercise. Most experience-first programs die here, because the team buys a tool before they can define the thing the tool is supposed to measure.

The Outcome layer is not any one of the three XLA data types (X, O, T) — it is a verdict. It is the second ledger that asks “Did the thing the work existed for actually happen?” You assemble it from X/O/T data, but the verdict is the artifact, not the telemetry. It is not CSAT, not a sentiment survey bolted onto a ticket, and not a DEX platform purchase.

Exercise 1.1 — Draw the boundary. Write the one-sentence difference between CSAT and the Outcome layer, then the exact sentence you will say when a skeptical CIO asks “isn't this just a rebranded CSAT survey?” Trade with a partner and attack each other's sentences for hidden sentiment-survey assumptions.

You cannot proceed until your sentence survives a partner who is trying to prove your outcome layer is just a survey in a costume.

Turn one silence into one measurable outcome-attached signal. Work at the unit level first, because a layer is just many units stacked, and a team that cannot instrument one outcome cannot instrument a thousand.

Every outcome unit needs exactly three fields attached: the outcome unit (stated in the business's language, not IT's), the moment of truth (the timestamp at which it is graded pass/fail, when T_impact lands), and the value at risk Y (honest and directional, the number that earns the next meeting). Score failures with the bleed taxonomy — clean / Drag / Workaround / Failure.

Exercise 2.1 — Instrument one real silence. Take one Amber silence from your three Deep-Dive conversations and fill the worksheet: outcome unit, moment of truth, value at risk, service-ledger verdict, outcome-ledger verdict, and the gap between the two.

If your two verdicts are the same color, you have either picked a Green silence or written the outcome in IT's language. Rewrite the outcome unit until a business-unit lead would recognize it as theirs.

Build three outcome metrics, at least one structurally insulated against gaming by either IT or the business. This is the segment that separates an honest layer from a new watermelon.

The watermelon effect — green outside, red inside — is not exclusive to service metrics; a badly designed outcome metric grows its own rind (the support-buffered system). The defense is a design property: a non-gameable metric cannot be moved by being nicer, closing tickets faster, or surveying happier people. The reference design is a friction-time metric — productive time lost per critical user per month, derived from telemetry — and SRE error budgets (99.9% SLO → ~43 min/month) anchor outcome targets in numbers engineers already defend.

Exercise 3.1 — Design your three metrics for the journey you instrumented in 2.1. Run each through the gaming-insulation test: movable by desk behavior alone, survey-dependent, cross-referenced to telemetry. At least one must pass all three.

If none of your three metrics is gaming-insulated, you have designed a future watermelon. Replace your weakest metric with a telemetry-derived friction-time metric before moving on.

Specify the minimum instrument that produces the conversation, at your organization's actual maturity — not the one a vendor would sell you. The implementation differs by tier; the conversation it produces is identical.

The discipline mistake is to skip your tier and build the one above it — a 20-person shop that buys the multinational's telemetry layer has bought vendor capture and will abandon the layer inside a year. Most teams below 5,000 seats can build a credible first layer from tooling they already own: native endpoint analytics for telemetry, bundled ITSM survey tooling for the subjective signal, two ticket fields and a recurring meeting for the verdict. Lead with the cheap layer. Earn the expensive one.

Exercise 4.1 — Spec your minimal stack. State your tier honestly, then specify where the second ledger lives, the telemetry signal from tooling you already own, the subjective signal and how you cap its bias, the verdict artifact, and the one thing you will not buy yet.

If your spec includes a new platform purchase and you are below Tier 4, write the sentence that justifies it against the vendor-capture math. If you cannot, cut it.

Run the dual-ledger review, and inoculate against the failure modes that turn a real layer back into theater.

The layer is not the dashboard — it is the harder conversation the dashboard makes possible. With the second ledger on the table, IT explains why a green workflow had three near misses and the business-unit lead explains why the spreadsheet workaround was not flagged earlier. That friction is the work. Ownership does not move: the layer is not a blame instrument, it is a shared instrument to mitigate bleed. The three failure modes are experience-washing, sentiment theater, and the support-buffered system.

Exercise 5.1 — Run the review (role-play in threes): IT manager, business-unit lead, and an observer with the failure-mode checklist run a ten-minute dual-ledger review. The observer flags every slide toward theater (a number admired but not acted on) or washing (a survey treated as the whole verdict). Rotate.

A passing review ends with one concrete action — a backlog change, a queue reallocation, a shared-boundary adjustment — traceable to the outcome ledger, not the service ledger.

Design a 90-day plan to stand up an outcome layer for your own organization (or the supplied scenario), then defend it before a review panel speaking in the CTRL ALT PRESS voice — the Operator, the Architect, the Strategist, and the Editorial Voice.

A professional-services firm, 1,200 remote employees, traditional service-first ITIL shop. Technical SLAs report 99.2% compliance; the most recent engagement survey rated IT 5.4/10. The CIO has heard “XLA,” thinks it is a passing trend, and asked you directly whether it is just a rebranded CSAT survey. You have 90 days, a $25,000 tooling ceiling, no new headcount, and you may not disrupt active service-desk operations.

• One high-value, high-friction persona and their weekly journey, with the moments of truth marked.
• A minimal outcome layer sized to the org's tier, using existing telemetry plus describer-labeled (not bare-Likert) sentiment capture.
• Three outcome metrics; at least one mathematically insulated against gaming.
• A distributed governance model using existing people — who sits in the review, who can move a backlog, on what cadence.
• The business case that answers the CIO's exact objection, linking the layer to reduced productivity loss in the value-at-risk unit.
• The three most likely failure modes for this specific environment, with technical and behavioral counters for each.

Scored 0–5 across six dimensions: diagnostic clarity, tooling parsimony, metric design, organizational realism, failure-mode literacy, and CIO defense. Pass ≥ 18/30; distinction ≥ 24 with no dimension below 3.