# North Star Metric: [Product name]

> A north star metric definition: the single metric that best captures the value customers get from the product,
> the tree of input metrics that drive it, the guardrail metrics that must not get worse, and how the metric is
> calculated, reviewed and changed. There is no formal standard; the template follows common product practice (the
> North Star Framework popularised by Amplitude's *North Star Playbook*) in original words. Define each metric
> precisely in a data/metric-definition document and link it here. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Start with the value customers get (section 1), not with the data you already have. Then pick the metric
  (section 2), test it against the checklist (section 3), and only then build the input tree (section 4).
- One north star per product. If two products serve different customers, each can have its own, and the company
  can still have a separate business metric such as revenue.
- The worked example is the fictional note-taking app Tallow Notes, the same company used in
  product/product-vision-strategy and product/pricing-packaging. Its numbers were recomputed and match those
  templates. Replace it with your own.
-->

## Document control

| Field | Value |
|---|---|
| Document ID | [NSM-PRODUCT-NN] |
| Product | [Product name] *Example:* Tallow Notes |
| Version | [0.1] |
| Status | [Draft / Approved / Under review / Retired] |
| Owner | [@head-of-product] |
| Data owner | [@analytics-lead] |
| Approvers / reviewers | [@leadership, @engineering-lead] |
| Linked strategy | [product/product-vision-strategy document ID] |
| Last updated | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@owner] | First definition |
| [1.0] | YYYY-MM-DD | [@owner] | [Approved, baseline recorded] |

## 1. Value the product delivers

<!-- Guidance: Describe in one or two sentences the moment when a customer gets real value. The north star should count that moment. Pitfall: describing value from the company's side ("they pay us") instead of the customer's side. -->

**Core value moment:** [When does a customer get the value they came for?]

*Example:* A Tallow Notes team gets value when knowledge written by one member is used or extended by another, so
the team stops relying on one person's memory.

## 2. North star metric definition

<!-- Guidance: Name the metric, the unit counted, the qualifying behaviour, the time window and the source. Write the full technical definition in data/metric-definition so analysts and dashboards compute it the same way. -->

| Field | Value |
|---|---|
| Name | [Metric name] |
| Plain-language definition | [What is counted and when it qualifies] |
| Unit | [Accounts, workspaces, users, transactions] |
| Time window | [Day / week / month, calendar or rolling] |
| Data source and owner | [Table or event, @owner] |
| Metric definition document | [Link to data/metric-definition] |
| Baseline | [Value, date] |
| Target | [Value, date] |
| *Example:* Name | Weekly collaborating workspaces (WCW) |
| *Example:* Definition | Workspaces in which at least two different members each edited at least one shared note during the calendar week (Monday to Sunday, UTC) |
| *Example:* Unit | Workspace |
| *Example:* Source | Event `note_edited` with workspace and member IDs, excluding internal and test workspaces |
| *Example:* Baseline | 4,200 in the week to 2026-09-27 |
| *Example:* Target | 6,000 by 2027-12-31 |

## 3. Checklist for a good north star

<!-- Guidance: Test the candidate metric against each question and record the answer. If it fails more than one, reconsider. Keep rejected candidates in the table so the choice can be explained later. -->

| Question | Answer for the chosen metric |
|---|---|
| Does it reflect value received by customers, not only value captured by the company? | [Yes / No, why] |
| Is it a leading indicator of revenue and retention? | [Evidence] |
| Can product teams influence it within a quarter through input metrics? | [Yes / No] |
| Is it understandable by everyone in the company in one sentence? | [Yes / No] |
| Is it hard to game without delivering value? | [How it could be gamed and the guardrail] |
| Can it be measured reliably and quickly (weekly)? | [Yes / No] |

| Candidate | Why rejected *(Example)* |
|---|---|
| Monthly active users | Counts single users who never collaborate, so it rewards the personal-notebook use the strategy moves away from |
| Notes created per week | Easy to inflate with empty or duplicate notes; does not show value to a team |
| Monthly recurring revenue | Lags value by months and teams cannot move it directly |

## 4. Metric tree: input metrics

<!-- Guidance: Break the north star into three to five input metrics that teams can move directly and that together explain most of its change. Prefer a decomposition that adds up (an identity) over a loose list, so you can see which input moved. Assign each input to one team. -->

```mermaid
flowchart TD
    N["North star: weekly collaborating workspaces (WCW)"] --> R["I2 Retained from last week"]
    N --> A["I1 Newly activated this week"]
    N --> S["I4 Resurrected this week"]
    R --> R1["Week-over-week retention rate"]
    A --> A1["New workspaces created"]
    A --> A2["Activation rate: second member edits within 7 days"]
    R1 --> D1["I3 Shared notes edited per workspace"]
```

| Input ID | Input metric | How it drives the north star | Owner team | Current *(Example)* | Target *(Example)* |
|---|---|---|---|---|---|
| I1 | [Metric] | [Mechanism] | [Team] | [Value] | [Value] |
| I1 *(Example)* | Newly activated workspaces per week | Adds workspaces to WCW for the first time | Growth | 480 | 650 |
| I2 *(Example)* | Week-over-week WCW retention | Keeps last week's collaborating workspaces | Core | 88% | 90% |
| I3 *(Example)* | Shared notes edited per collaborating workspace per week | Deeper use predicts retention (diagnostic for I2) | Core | 6.4 | 7.5 |
| I4 *(Example)* | Resurrected workspaces per week (collaborating again after at least one inactive week) | Returns lapsed workspaces | Lifecycle | 68 | 90 |

Worked decomposition *(Example)*, week to 2026-09-27: the previous week had 4,150 collaborating workspaces. At 88%
retention, 3,652 of them were retained (4,150 x 0.88 = 3,652). Adding 480 newly activated and 68 resurrected
workspaces gives 3,652 + 480 + 68 = 4,200, which matches the north star value in section 2. When the north star
moves, check which of the three components changed before celebrating or reacting.

## 5. Guardrail metrics

<!-- Guidance: Guardrails protect customers and the business while teams push the north star. Set a limit for each and say what happens when it is breached. Pitfall: guardrails that nobody watches. Put them on the same dashboard as the north star. -->

| ID | Guardrail | Limit | Why it matters | Action if breached |
|---|---|---|---|---|
| G1 | [Metric] | [Threshold] | [Risk] | [Response] |
| G1 *(Example)* | Sync failures per 1,000 edits | Not above 0.5 (current 0.4) | Collaboration value collapses if edits are lost | Freeze feature releases touching sync until back under limit |
| G2 *(Example)* | Invitation emails marked as spam per 1,000 sent | Not above 1.0 | Pushing invitations can harm trust and deliverability | Pause invitation experiments |
| G3 *(Example)* | Support tickets per 1,000 weekly active members | Not above 12 | Growth must not come from confusing flows | Review the change that moved it |
| G4 *(Example)* | Share of members who turn off notifications in week 1 | Not above 15% | Engagement pushed by notifications is not value | Review notification changes |

## 6. Targets and review cadence

<!-- Guidance: Targets come from the strategy horizon. Review the north star weekly for movement and the definition yearly for fitness. Record any definition change, because it breaks the time series. -->

| Review | Frequency | Participants | Output |
|---|---|---|---|
| Metric review | [Weekly] | [Product and analytics leads] | [Notes on movement by input] |
| Strategy check | [Quarterly] | [Leadership] | [Targets confirmed or changed] |
| Definition review | [Yearly] | [Head of product, analytics lead] | [Definition kept or changed, with reason] |

Definition change log:

| Date | Change | Reason | Effect on history |
|---|---|---|---|
| YYYY-MM-DD | [Change] | [Reason] | [Back-filled / series break noted] |

## 7. Common pitfalls

<!-- Guidance: Read these before approving the metric. -->

- Choosing a vanity metric (sign-ups, page views) that grows without value delivered.
- Choosing revenue or profit, which teams cannot move directly and which lags value.
- Having several north stars, which means none of them guides trade-offs.
- Setting input metrics that do not add up to the north star, so movement cannot be explained.
- Ignoring guardrails until customers complain.
- Treating correlation in the data as proof that an input causes the north star; test it with experiments
  (product/ab-test-plan).

## Related templates and references

- data/metric-definition for the precise definition of each metric
- data/dashboard-specification for the north star dashboard
- product/product-vision-strategy, business/okr, business/kpi-scorecard, product/ab-test-plan
- Amplitude, *North Star Playbook* (John Cutler and co-authors), available from Amplitude:
  https://amplitude.com/books/north-star

## Standard and licence note

Based on common product analytics practice. The North Star Framework is described in Amplitude's *North Star
Playbook*, which is cited by name only; no text, checklist wording or figures are copied, and all wording here and
the Tallow Notes example are original. Template licence: MIT.