# Define The Outcome

Use this reference during Phase 1.

## Order

1. Hypothesis
2. Vertical Slice
3. Acceptance Criteria
4. Validate Assumptions
5. Demo Plan

## Product Owner Review

Before reviewing any Define the Outcome artifact with a human:
- ask `Is a product owner in the room for this review?`
- ask that question separately from artifact approval
- once the answer is known for the current review flow, do not ask it again unless the context clearly changes

If a product owner is present:
- ask whether they agree with each artifact before writing it

If a product owner is not present:
- explicitly record that absence as added product/alignment risk
- make assumptions more conservative
- in solo or async refinement, ask once, record the answer or absence, then proceed without repeating the question on every artifact

## Hypothesis

- Write the hypothesis in a dedicated `## Hypothesis` section above `## Define the Outcome`, not inside the checklist item.
- Identify which of Cagan's four risks the hypothesis primarily addresses.
- Keep the hypothesis outcome-focused rather than implementation-focused.

## Vertical Slice

- Before drafting the slice, search the current backlog and the configured archive for related stories, experiments, hypotheses, acceptance criteria, or outcomes that could sharpen the slice.
- Read `.imdone/config.yml` to find `settings.cards.archiveFolder`; inspect that configured archive path when it exists, and use `.imdone/archive` as the fallback archive location when needed.
- Record the useful prior stories under a dedicated `## Related Work` section above `## Define the Outcome`.
- Link the story files directly in `## Related Work` and add one short note per link explaining why it matters to the slice.
- If no relevant prior work exists, say that explicitly in `## Related Work` instead of leaving the section implied.
- Write the slice in a dedicated `## Vertical Slice` section above `## Define the Outcome`, not inside the checklist item.
- Make sure the story has a clear user- or customer-facing outcome.
- Include appetite with the slice.
- Frame the slice as an experiment:
  - who the user is
  - what behavior changes
  - what the team expects to learn

## Acceptance Criteria

- Write the criteria in a dedicated `## Acceptance Criteria` section above `## Define the Outcome`, not inside the checklist item.
- Acceptance criteria must be binary and testable.
- If criteria are weak, use `references/acceptance-criteria.md`.
- If the criteria still cannot be made binary, narrow the slice before locking it.

## Success Metrics

- Metrics should be specific and easy to verify.
- Prefer observable behavior change over code-path completion.
- Prefer product data tied to user behavior or business outcomes over internal output metrics alone.
- If direct user feedback is plausible for the slice, name how it will be gathered after delivery.
- When the hypothesis claims a user-perception, trust, adoption, or value change, do not stop at implementation verification. Include both:
  - a verification path showing the feature works as intended
  - an outcome-evidence path showing how you will learn whether users actually felt or behaved differently
- If the slice can only measure implementation correctness right now, say that explicitly and record what later user evidence would still be needed to confirm the hypothesis.

## Validate Assumptions

- Write the assumption check in a dedicated `## Validate Assumptions` section above `## Define the Outcome`, not inside the checklist item.
- Name the one thing that would kill the story if false.
- If no product owner is present, explicitly name the missing product decision or stakeholder confirmation that could kill the story if false.

## Demo Plan

- Show setup, key action, and visible outcome.

## Review Behavior

- Ask critical questions when the outcome sounds plausible but still hides product uncertainty, vague evidence, or multiple bundled changes.
- If the story is blocked, check whether the blocker reason is concrete enough to act on.
- If the blocker reason is vague, call that out explicitly as shared-context risk and ask what information is missing, who owns it, and what next unblock step should be captured.
- If the user and story artifacts do not appear aligned, ask a short alignment question before locking the draft in.
- If the user and story artifacts appear aligned too quickly, ask a critical question about failure modes, evidence, or hidden assumptions before locking the draft in.
