# Outcome Review > Runs a post-launch review of a shipped PRD against its success metrics, interviewing the user on metric movement, assumptions, and decisions, then publishing an outcome-review page to Confluence and updating linked artifacts. - Skill: `sdiamante13/outcome-review` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds add sdiamante13/outcome-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/sdiamante13/outcome-review/raw - Safety review: CAUTION (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning, Product Analytics, User Research - Tags: Confluence, Decision Log, Jira, Metrics, Outcome Review, Prd, Retrospective - Author: SDiamante13 (https://skillmd.com/u/sdiamante13) - Updated: 2026-08-22 - Page: https://skillmd.com/skills/sdiamante13/outcome-review --- # Outcome Review — did it work? ## Prerequisites - A PRD that has shipped (or reshaped) exists in Confluence. - **jira plugin** (required); **Atlassian MCP** authorized. - Ideally, access to whatever dashboards / data the brief's success metrics depend on. Load references: - [references/persona.md](../../references/persona.md) - [references/cagan-methodology.md](../../references/cagan-methodology.md) — outcomes over output. - [references/interview-tactics.md](../../references/interview-tactics.md) - [references/artifact-templates/outcome-review.md](../../references/artifact-templates/outcome-review.md) - [references/confluence-destinations.md](../../references/confluence-destinations.md) - [references/decision-log.md](../../references/decision-log.md) ## Step 1 — Locate the PRD and brief From `$ARGUMENTS`: PRD page ID or title. If none, CQL-survey the user's shipped PRDs: ``` creator = currentUser() AND label = "prd" ``` Filter client-side for `status = shipped` or `status = ready-for-tickets` (for PRDs where tickets are filed but the work hasn't been explicitly marked shipped). AskUserQuestion if multiple. Read PRD → extract `brief_ref` + `linked_jira` + `linked_decisions`. Read the brief → extract the success metrics and the four-risks assumptions. Fetch each linked Jira ticket's current status via `getJiraIssue`. Produce a short summary of which shipped and when. ## Step 2 — Session scratch Seed `${CLAUDE_PLUGIN_DATA}/sessions//outcome-review.md` from template. Pre-fill the brief's success metrics and current Jira states. ## Step 3 — Interview ### Q1 — Metric movement AskUserQuestion, based on the brief's primary success metric: - "Yes — the metric moved in the intended direction and at roughly the expected magnitude" - "Partially — some movement but below target, or in the right direction on a leading indicator without the lagging indicator following" - "No — the metric did not move (or moved the wrong way)" - "Too early — we don't have enough data yet" - "Can't tell — the instrumentation / data is missing or noisy" ### Q2 — What the data shows Open text. *"In specifics: what did you actually see?"* Push for numbers, not impressions. Push for *sources*: a dashboard link, a query result, a report. If the answer is *"I haven't looked,"* note that as a follow-up item — this review is premature and should be rescheduled. ### Q3 — Assumptions: which held? Walk through the brief's four-risks assumptions one by one. For each: AskUserQuestion: - "Held — the assumption turned out to be correct" - "Broke — the assumption was wrong, and we can say in what way" - "Untested — the feature didn't stress this assumption enough to know" Open text follow-up: *"What happened? What did we learn?"* ### Q4 — Decisions: which resolved? For each decision page in the PRD's `linked_decisions`: Read the decision page → show the user the original `risk_accepted` text. AskUserQuestion: - "Confirmed — the risk we accepted did not cause problems (or the gap was closed in practice)" - "Invalidated — the risk bit us, in the specific way described or differently" - "Still pending — we can't tell yet" Open text follow-up for the "what actually happened" detail. These answers will update each decision page's `outcome` field in Step 6. ### Q5 — What would we do differently? Open text. Look for concrete process or scoping lessons, not vague *"we should have done more research"* platitudes. Push for specifics: *"What specifically would you change about how you ran this?"* ### Q6 — What's the next step on this feature? AskUserQuestion: - "Ship as-is, monitor — done for now" - "Iterate — plan V2 based on what we learned" - "Reshape — the outcome suggests the solution should change materially" - "Kill / roll back — the outcome doesn't justify the maintenance cost" - "Too early — revisit in " This becomes the `next_step` note at the bottom of the review. ## Step 4 — Summary + sentiment Show the user the full review. Ask for edits. Sentiment + free-text prompt. ## Step 5 — Publish to Confluence Default: PE › *Retrospectives* (ID 352157716), label `outcome-review`. Resolve helper, render, `createConfluencePage`. No `draft` label (outcome reviews are one-shot artifacts — either published or not). ## Step 6 — Update linked artifacts 1. **Brief Page Properties:** set `status` to `shipped` (if reviewed) or `reshaped` / `killed` based on Q6. Add a link to the outcome review. 2. **PRD Page Properties:** same status update; add link to outcome review. 3. **Each decision page:** update `outcome` to match Q4 answer; add a link to the outcome review in its body. 4. **Jira tickets (if user confirmed):** optionally append a comment on each linked ticket pointing to the outcome review. ## Step 7 — Telemetry Log session via MCP `updateConfluencePage` per [references/telemetry.md](../../references/telemetry.md). Skill = `outcome-review`, artifact_type = `outcome-review`. One extra signal worth capturing: did this outcome review change the decision-log outcomes? If yes, that's a real data point for the spike-learnings doc — append an entry under the "Hook-acceptance feedback loop" dimension noting whether the decisions we forced to be recorded paid off. ## Never - Never skip Q4 (decisions resolved). The whole point of the decision log is to close this loop. - Never let Q1 "Yes" through without Q2 specifics. A yes without data is a wish. - Never write an outcome review that simply says *"it shipped, everyone seems happy."* If the interview produces no specifics, that is itself the finding — record it and propose next steps to instrument the feature. - Never silently downgrade an invalidated assumption. Flag it visibly so V2 planning sees it.