Golden Thread

Outcomes

Closed-loop measurement, did the initiative move the metric? Capture baseline, target, actual, learning, and next action.

Outcomes are how the Golden Thread closes. Without an outcome, you've built and shipped, but you don't know if it worked.

What you'll see

Result strip: pending / hit / missed / mixed counts above the table; click pending to see the outcomes still waiting on a review
List view: initiative, ID, result (hit | missed | mixed | pending), metric (baseline → target → actual), feature and release counts, learning, next action, created date
Filter bar: result, created date

Row drawer

Metric: name, baseline, target, actual; shown as baseline → target → actual
Result chip: pick from the enum once the review is in
Learning: what you learned, in your own words
Next action: what changes based on this outcome (free text; nothing is created automatically)
Released date and review-due date
Initiative: the initiative this outcome measures; its features and releases show through that link
Features: the features linked to this outcome directly, which you add and remove here or from a feature's Outcomes row. Features that only come through the initiative are listed beneath, read-only, and are changed on the initiative
release_id, ai_learning and amplitude_link exist on the API but aren't shown in the drawer

Measured outcomes

An outcome can be judged on more than one number, and the numbers can come from your analytics instead of being typed in.

Metric	What it is	Numbers from
Primary	The number the initiative bet on: the outcome's own Baseline, Actual and Target	typed in, or Measure from Amplitude
Guardrail	A number this release must not make worse, such as support tickets or churn	typed in, or an Amplitude event
Supporting	A number worth watching that doesn't decide the result	typed in, or an Amplitude event

Measure from Amplitude (needs Amplitude connected) picks an event from your project's list and counts it per day, before and after the release. Baseline and Actual then fill in on their own and can't be edited; a chart shows each day around the release date.
Add metric adds a guardrail or supporting metric: a name, which way is good (higher or lower), an optional target, and the numbers typed in or measured. A guardrail with no target counts as broken when it moves the wrong way by more than 5% of its baseline.
Each metric shows its status: Met, Improved, Worse, Held, Broken or Pending.
Suggested result. Under the metrics, ProductOS suggests Hit (the primary reached its target and every guardrail held), Mixed (a guardrail broke, or the primary moved the right way but fell short) or Missed, with the reason. Set result applies it; Result never changes on its own.
A target can be a number (500) or a change from the baseline (+20%, -5%).

Common actions

Entity-context shortcuts apply once a row has focus (see Keyboard shortcuts)
ProductSense button in the toolbar to align results and find orphaned outcomes
Link the outcome to its initiative and to features from the drawer; there is no button that converts a next action into a new initiative or feature

When to record

Most teams record one outcome per (initiative, release) pair, ~30 days after the release publishes. The pending node in the result strip lists what still needs a review; review_due_date is stored but nothing alerts on it.

Outcomes API reference: includes outcome metrics
Connecting Amplitude: measure outcomes from your events
OKR page: Key Results link to outcomes via outcome_id
Initiatives page: outcome's parent