Success Criteria, North Star Metric & Product Boundaries

There is a prompt instruction at https://www.zangwei.dev/prompts/product-planning/success-criteria-north-star-metric-product-boundary-prompt . Extract and follow the prompt to create file /docs/handbook/planning/success-criteria.md

You are a senior Product Manager. Define the product's **Success Criteria**, **North Star Metric**, and **Product Boundaries (What NOT to Build)**.

## Positioning
This document answers three questions:
1) When can we confidently say the product is successful?
2) What single metric best represents durable user value?
3) To stay focused, what do we explicitly not build right now?

It is a direction-lock document before Planning -> Execution, preventing goal drift, scope creep, and post-hoc rationalization.

## General requirements
- Metrics must be measurable, observable, and actionable
- Success criteria must support Go/No-Go decisions
- Boundaries should be explicit enough to reject requests
- Avoid too many metrics; emphasize focus and trade-offs

---

## Output structure

1) Success criteria
Define success from user, product, and business perspectives:
- What outcomes mean clear success?
- What outcomes mean clear failure?
- What outcomes mean re-evaluation/adjustment?

Example dimensions (choose as applicable):
- user: retention, repeat purchase, key action completion rate
- product: core feature depth, reliability
- business: paid conversion, revenue, cost efficiency

2) North Star Metric
- Define one metric that best represents ongoing core value delivered
- Explain:
  - why it reflects long-term success
  - how it drives correct product and growth decisions
- Specify:
  - definition/formula
  - observation window
  - thresholds or trend interpretation

3) Guardrail metrics
- List 3–5 guardrails to prevent metric gaming
- Explain how they constrain the North Star
- Clarify which are monitoring-only vs optimization targets

4) Product boundaries (what NOT to build)
Explicitly state what is out of scope for this stage, including:
- user types we do not serve
- scenarios we do not support
- business models we do not enter
- feature categories we do not prioritize

For each, explain why:
- not aligned with core value
- validation cost too high
- would dilute focus

5) Boundary change conditions
- When can boundaries be revisited?
- What signals/data justify it?
- Who can initiate the change?

---

## Output requirements
- No implementation details
- Do not treat slogans as success criteria
- Avoid "feels good" as a criterion
- If success cannot be defined clearly, call it out as a risk signal

End with 3–5 bullet points:
"Are these definitions sufficient to keep the team focused during execution?"