Operating With Outcomes

Outcomes are team-scoped objectives derived from the North Star. Each outcome is a durable target state for an external cohort or business condition, with a target, horizon, and accountable owner.

Outcomes keep product judgement honest. Ask The W uses them to show whether decisions from humans and AI agents are moving the North Star or creating work that looks active but does not advance the business.

What an outcome is

An outcome includes:

• name
• summary
• health state
• AARRR stage
• maker list
• single accountable owner
• target value and target date
• suggested action and skip-risk
• causal link to the North Star

An outcome is not a product event, click, internal routine, decision artifact, signal collection event, system reliability readout, or one-off milestone.

Product reference

Find it in Ask The W by opening Outcomes and selecting an outcome, or by following a linked outcome from Decisions. The outcome detail page starts with health, stage, owner, linked source context, and tabs for timeline and refinement.

Outcome status and North Star fit

Outcomes can be active, achieved, abandoned, or archived:

• Active outcomes are open for review and linking.
• Achieved outcomes are complete and less likely to drive current action.
• Abandoned outcomes are historical and useful for learning.
• Archived outcomes are removed from active navigation but preserved for audit.

Each outcome can also be primary, secondary, or stale relative to the current North Star. Use that fit during triage: prioritize primary stalling outcomes with high signal volume, review secondary outcomes when main decisions are blocked, and de-prioritize stale outcomes unless they unlock something urgent.

Outcome health states

Outcome health uses three operating states:

• Accelerating: recent signals suggest the outcome is moving faster or becoming easier to reach.
• Steady: signals support continued progress without urgent intervention.
• Stalling: progress is blocked, ownership is unclear, signals are weakening, or conflicts are clustering.

In triage, prioritize primary stalling outcomes with high signal volume. Review secondary outcomes when main decisions are blocked.

The outcome detail page

Use /outcomes/:id when you need confidence to act. Start with the outcome health, then decide whether the blocker is data, ownership, or priority.

Check ownership, blockers, decision support, 8-week health history, next move, risk, linked decisions, linked outcomes, and maker context.

Good outcome review starts with three questions:

• Who owns it?
• Is it blocked by data, ownership, or priority?
• Are recent decisions helping it, drifting away from it, or contradicting it?

The outcome graph (dependencies, support, conflicts)

The graph shows how outcomes influence one another:

• Dependencies show what unlocks what.
• Blockers show what prevents progress.
• Competition shows where outcomes fight for the same capacity.
• Support paths show what accelerates a target state.

Open the graph from outcome detail, click a node to inspect connected outcome metadata, and open linked outcomes for deeper context.

The matrix view (how to read it)

The matrix view is now represented by the operating view's outcome and decision layout.

Use the combination of outcome list, decision timeline, outcome graph, and maker profiles to identify ownership, contradiction, and weak product judgement in one pass.

This perspective is useful when you need to:

• surface dependencies and blockers
• identify outcomes competing for the same team capacity
• see which teams own unclear decisions
• spot where drift is concentrated before it becomes execution drag

A weekly pass can be simple: filter outcomes by health and freshness, open one or two stalled outcomes with recent conflict, follow linked decisions and maker history, then apply exactly one correction.

Corrections (rename, merge, split, archive)

Use corrections to rename outcomes, edit summaries, reclassify area, override health, replace suggested action, split broad outcomes, merge duplicates, or archive inactive outcomes.

Merge duplicate objectives. Split outcomes that mix unrelated decisions or metrics. Review graph links after structural edits.

Safe correction practice:

1. Correct based on new signals, not preference.
2. Preserve notes and rationale in decision history.
3. Review related graph links after each structural edit.

Use merge when two outcomes represent the same operating objective. Use split when one outcome mixes unrelated decisions, owners, or metrics.

Auto-generated outcomes

Open Decisions -> Outcomes -> Suggest to review proposals based on your decisions and signals. Suggestions never publish without your confirmation.

Generation can reuse onboarding context, source signals, and decision signals. If generation stops early, confirm source health and retry.

When the graph looks wrong

Wrong graph links usually mean stale signals, duplicate outcomes, or an outcome that should be split. Open the outcome, inspect linked decisions, then merge, split, rename, override health, or archive.

If the same confusion returns after correction, look upstream: source material may be too broad, a connector may be stale, or an outcome may be trying to represent a target state and a decision at the same time.