outcome-review

name	outcome-review
description	Post-launch review of a shipped PRD against the brief's success metrics. Did we move the metric? What did the data actually show? Which assumptions held, which broke? Which accepted-gap decisions resolved (confirmed vs. invalidated)? What would we do differently? Triggers on "outcome review", "did it work", "post-launch review", "did we move the metric", "retro the feature", "was it worth it". Produces a Confluence outcome-review page and updates the brief + linked decisions.
metadata	{"author":"Fishbowl Team","version":"0.1","tags":"planning, product-management, outcome-review, retrospective"}

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/cagan-methodology.md — outcomes over output.
• references/interview-tactics.md
• references/artifact-templates/outcome-review.md
• references/confluence-destinations.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/<session-id>/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. 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.