North star metrics

North Star Metrics

Before starting

Confirm (ask or infer) before running:

• Product stage — pre-PMF / post-PMF / scaling? (NSM design differs significantly)
• Growth motion — PLG / SLG / MLG / CLG? (determines which value delivery moment to measure)
• Current metrics — what are the team currently tracking? Is there disagreement about which matters?
• Product category — what type of value does the product deliver, at what frequency?
• ICP — who is the core user? (NSM must measure value to them, not to the business)
• Existing NSM — if one exists, what prompted the review? (pivot, declining metric, new motion?)

---

Contract

This skill guarantees:

• No revenue metric is accepted as an NSM without explicit justification of why it reflects user value
• Every NSM is tested against all four selection criteria before approval
• Input metric tree has 3–5 inputs maximum — more is a sign the NSM is wrong
• Guardrail metrics are defined before any experiment targeting the NSM begins
• NSM revision protocol is specified — the team knows when to revisit the NSM

---

Role: Metric Architect. The NSM is not a KPI. It is not a revenue target. It is the compass for every experiment, every product decision, and every growth investment. Getting it wrong means optimizing confidently in the wrong direction. Your job is to select the right metric, build the tree underneath it, and prevent the team from using vanity metrics or revenue metrics as proxies for product value.

---

Inputs

Required before proceeding:

• Product description and the core value it delivers to users
• Growth motion (PLG / SLG / MLG)
• Product category (see Step 2 for reference categories)
• Current metrics being tracked (even if they are the wrong ones)

---

The core principle

THE NSM RULE:

The North Star Metric measures the value the product delivers to users —
not the value the business extracts from users.

WRONG: Revenue, MRR, ARR, bookings, contract value
       → These measure extraction. When they go up while NSM goes down,
         you are harvesting a product that is losing product-market fit.
         You will not see the cliff until you have walked off it.

WRONG: Vanity metrics — registered users, page views, downloads, DAU without context
       → These measure presence, not value. A user who signs up and never
         gets value inflates these. They are disconnected from retention.

RIGHT: A metric that, when it goes up, the users are genuinely better off —
       AND the business is likely growing sustainably.

The test: "If this metric goes up but users are not getting more value,
is that still a win?" If yes, it is the wrong metric.

---

Step 1 — Four-criteria NSM validation

Apply to every candidate NSM. All four criteria must pass.

CRITERION 1: Embodies value delivered to users
  Test: "When this metric increases, are users genuinely getting more value?"
  IF yes → pass
  IF "it depends" or "not necessarily" → this is a proxy, not the NSM

CRITERION 2: Predictive of long-term retention and revenue
  Test: "Do users who move this metric in week 1 have significantly higher
         30-day / 90-day retention than those who don't?"
  IF yes → pass (confirm with cohort analysis if data exists)
  IF not tested → flag: run a cohort analysis before finalizing
  IF no → this metric correlates with activity, not value

CRITERION 3: Measurable in your current analytics setup
  Test: "Can you query this metric today, by cohort, by segment, by date?"
  IF yes → pass
  IF no → either fix the instrumentation first OR select a proxy NSM that is
  measurable while you build toward the ideal one; document the gap explicitly

CRITERION 4: Influenceable by the team in the next 90 days
  Test: "Is at least one team (product, growth, marketing) able to move this
         metric with experiments in the next quarter?"
  IF yes → pass
  IF no → this is a lagging indicator; it belongs in the output metric layer,
  not as the NSM; find the leading indicator upstream of it

If a candidate fails any criterion: record why, keep it as a reference metric, and continue searching.

---

Step 2 — NSM by product category

The right NSM is almost always category-specific. Use this reference to calibrate, then customize.

PRODUCT CATEGORY → NSM REFERENCE

Communication / collaboration tools:
  NSM candidate: "Messages sent per user per week" / "Active projects with ≥3 collaborators"
  Why: value is in communication happening, not accounts created

Developer tools / infra / databases:
  NSM candidate: "Queries / API calls / deployments per active account per week"
  Why: usage IS value; a developer who ran 0 queries got 0 value
  Alternative: "Time to first successful query" as an activation NSM

Productivity / workflow tools:
  NSM candidate: "Tasks completed" / "Workflows automated per user"
  Why: value is in work getting done, not time in the app

Marketplace / platform:
  NSM candidate: "Transactions / matches completed" / "GMV" (only if users are sellers/buyers)
  Why: value requires a transaction — supply and demand must meet

Content / media:
  NSM candidate: "Content units consumed per session" / "Sessions per week per user"
  Why: value is consumption; registration without consumption = no value

Developer community / OSS:
  NSM candidate: "Actively contributed members" / "Answered questions per week"
  Why: value is in the community helping itself; lurkers provide no value signal

B2B SaaS (complex workflow):
  NSM candidate: "Accounts that completed their first [core workflow] within 14 days"
  Why: completion of the core workflow is the FVM; before that, the product has not delivered

AI / ML tools:
  NSM candidate: "Successful predictions / outputs used by the user" (not generated)
  Why: an AI that generates output the user ignores has not delivered value;
  measure used/acted-on outputs, not raw generation volume

WARNING: these are starting points. Validate with cohort analysis in your own data
before treating any of these as confirmed NSMs.

---

Step 3 — Input metric tree design

The NSM is the output. Input metrics are the levers the team pulls to move it.

INPUT METRIC TREE STRUCTURE

NSM: [Single metric]
  ↑
  ├── Input 1: [Acquisition lever] — "What brings new users to the FVM moment?"
  ├── Input 2: [Activation lever] — "What % of new users reach NSM-relevant behavior?"
  ├── Input 3: [Engagement lever] — "What keeps NSM-relevant users coming back?"
  ├── Input 4: [Retention lever] — "What prevents users who reached NSM from churning?"
  └── Input 5: [Expansion lever] — "What causes NSM to grow within existing accounts?" [if applicable]

RULES:
  Rule 1: 3–5 input metrics maximum. More inputs = the NSM is wrong (too composite)
  Rule 2: Each input must be independently measurable
  Rule 3: Each input must have an obvious owner (team or person)
  Rule 4: Moving any input should move the NSM — if the relationship is unclear, the input is wrong
  Rule 5: No input should be a revenue metric — inputs are behavioral, not financial

QUALITY CHECK — for each input, ask:
  "If this input goes up 20%, will the NSM likely go up within the same quarter?"
  IF yes for most inputs → tree is valid
  IF often no → the inputs are lagging or disconnected; redesign

Example tree (B2B developer tool, PLG motion):

NSM: "% of weekly active accounts that ran ≥5 queries this week"
  ├── Input 1: Signup → query activation rate (% who ran first query within 24h)
  ├── Input 2: Time to first query (median hours from signup to first query)
  ├── Input 3: D7 query recurrence rate (% who ran queries in week 1 who returned in week 2)
  └── Input 4: Multi-user adoption rate (% of accounts with ≥2 active users)

---

Step 4 — Guardrail metric system

Guardrail metrics are the constraints the team cannot violate while chasing the NSM.

GUARDRAIL PRINCIPLE:

The NSM creates optimization pressure. Without guardrails, that pressure
causes teams to move the NSM in ways that harm the product, the user,
or the business.

Classic failure modes guardrails prevent:
  - Improving activation rate by making free cancellation harder to find
  - Growing "active users" by sending more notification spam
  - Increasing queries-per-user by making the product confusing (users run more queries to get the same result)
  - Accelerating trial conversion by removing features that let users evaluate properly

GUARDRAIL CATEGORIES:

Category 1 — User experience floors
  Example: "Time to first meaningful response must remain < 3 seconds (p95)"
  Example: "Support ticket volume must not increase >20% vs prior 4-week average"
  Example: "Error rate on core workflow must remain < 0.5%"

Category 2 — Retention floors
  Example: "D30 retention must not decline more than 3pp below the 8-week rolling average"
  Example: "Churn rate in months 1–3 must not increase"

Category 3 — Business health floors
  Example: "CAC payback period must remain < 18 months"
  Example: "Gross margin must not decline below [X%]"

Category 4 — Trust and safety floors (if applicable)
  Example: "Privacy incident count = 0"
  Example: "Data export functionality must remain fully functional"

DESIGN RULES:
  - 2–4 guardrails maximum (more = guardrails themselves become management overhead)
  - Every guardrail has a specific number threshold, not a direction ("don't worsen")
  - Any experiment that would violate a guardrail is blocked before it ships

---

Step 5 — NSM by growth motion

MOTION-SPECIFIC NSM GUIDANCE

PLG:
  NSM focus: activation and habitual usage
  Leading indicator: "% of signups who reach FVM within 7 days"
  Output metric (not NSM): Free-to-paid conversion rate
  
  Why not conversion rate as NSM: conversion is affected by pricing, not just value.
  A product can improve conversion by raising urgency without improving value.
  FVM rate or habitual usage is the honest measure.

SLG:
  NSM focus: deal quality and expansion
  NSM candidate: "Accounts that complete technical evaluation and advance to procurement"
  OR: "Expansion ARR per cohort at 6-month mark"
  
  Caution: SLG NSMs are longer-cycle and harder to influence quickly.
  Add a leading NSM (e.g., "champion activation within 14 days of account creation")
  alongside the lagging one for faster feedback.

MLG:
  NSM is split across two tracks:
  - PLG track NSM: activation / usage depth (as above)
  - SLG track NSM: pipeline velocity or account expansion
  
  Report both separately. Blending them obscures the health of each motion.

CLG:
  NSM focus: value exchange within community
  NSM candidate: "Questions answered by non-staff within 4 hours per week"
  OR: "Active contributors who have posted ≥3 times in the last 30 days"
  
  Why not member count: member count measures interest, not community health.
  The community has delivered value only when a member gets a useful answer.

---

Step 6 — NSM revision protocol

The NSM should be stable — but not permanent. Define when to revisit before you need to.

NSM REVISION TRIGGERS (any one → mandatory review):

Trigger 1: Business model change
  New pricing model, new product tier, or new monetization mechanism
  → The relationship between value delivery and revenue has changed

Trigger 2: Significant product change
  Core workflow redesigned, new feature becomes the dominant use case,
  or primary ICP segment has shifted
  → The FVM definition may have changed

Trigger 3: NSM moving but business declining
  NSM goes up while revenue, retention, or NPS goes down
  → The NSM has decoupled from actual value; it is now a vanity metric in disguise

Trigger 4: NSM no longer influenceable
  The team has exhausted all practical ways to move the metric
  → The NSM is saturated or has become a lagging indicator; find the upstream driver

Trigger 5: Post-PMF validation
  Pre-PMF NSMs are often proxies; after PMF is confirmed, upgrade to a more
  precise measurement of value delivery

REVISION CADENCE:
  Default: NSM review every 6 months even without a trigger (30-minute check-in)
  Mandatory: immediately on any trigger above

REVISION PROTOCOL:
  Step 1: Document the current NSM, its rationale, and the trigger for revision
  Step 2: Apply the four-criteria test to the proposed new NSM
  Step 3: Run a parallel tracking period (4–8 weeks) where both old and new NSMs
          are tracked before the old one is retired
  Step 4: Communicate the change to all teams with the rationale — teams optimizing
          for the old NSM need to reorient experiments

---

Output format

## North Star Metric Design

**Product:** [Name]
**Growth motion:** [PLG / SLG / MLG / CLG]
**Product stage:** [Pre-PMF / Post-PMF / Scaling]

### NSM
Metric: [Single metric definition]
Measurement: [Exact query / event / formula used to calculate]
Current value: [Baseline if known]
Target direction: [Increase / Decrease]

### Four-criteria validation
Embodies user value: [Pass / Fail — rationale]
Predictive of retention: [Pass / Fail — evidence or flag for cohort analysis]
Measurable today: [Pass / Fail — instrumentation status]
Influenceable in 90 days: [Pass / Fail — which team owns it]

### Input metric tree
NSM: [Metric]
  ├── Input 1 [Acquisition]: [Metric] — Owner: [Team]
  ├── Input 2 [Activation]: [Metric] — Owner: [Team]
  ├── Input 3 [Engagement]: [Metric] — Owner: [Team]
  └── Input 4 [Retention]: [Metric] — Owner: [Team]

### Guardrail metrics
1. [Metric] must not fall below / exceed [threshold] — Owner: [Team]
2. [Metric] must not fall below / exceed [threshold] — Owner: [Team]

### NSM revision triggers
Next scheduled review: [Date]
Mandatory revision triggers: [List the 2-3 most likely for this product]

---

Brain reads / writes

If a companion brain repo is connected:

Before starting:

• Read knowledge/icp-map.md — ICP defines who the value is delivered to; the NSM must measure value to the Core ICP, not the broadest possible user
• Read experiments/experiment-log.md — past experiments reveal which behaviors actually correlate with retention (proxy for NSM validation)

Brain write (after NSM is defined or revised):

• Write to decisions/: NSM definition, input metric tree, guardrails, revision triggers, and rationale; this becomes the reference document for all future experiment design

Brain not connected: document the NSM decision in a shared doc before running any experiments that reference it.

---

Anti-patterns

Anti-pattern	Why it fails	Fix
Revenue as NSM	Revenue measures extraction; can increase while product is losing users	Use a behavioral metric that predicts revenue; revenue goes in guardrails
DAU / MAU without qualification	Active users who got zero value inflate this metric; it doesn't predict retention	Define "active" as "performed the core value action" not "logged in"
Composite metric (e.g., engagement score)	No one can explain what moves it; experiments can't be designed against it	Pick one observable event as the NSM
Too many input metrics (>5)	Team can't hold 8 metrics in focus; experiments fragment across too many levers	Too many inputs signals the NSM itself is wrong; simplify the NSM first
No guardrails defined	Team optimizes the NSM via dark patterns or at the expense of retention	Guardrails are required before any experiment targeting the NSM
Never revising the NSM	Market, product, and business all change; an NSM from 3 years ago may be measuring the wrong thing	Schedule a 6-month review cadence; define mandatory revision triggers
Pre-PMF team picking a lagging NSM	A 90-day cohort retention NSM gives no feedback for 90 days	Pre-PMF: use a leading activation NSM with a short feedback cycle

---

Benchmarks (2025–2026)

Benchmark	Value	Notes
FVM rate (% of signups reaching FVM in 7 days) — target for post-PMF PLG	40–60%	Below 25%: activation is the primary growth constraint
D7 retention (high-frequency SaaS)	>25% is meaningful	Low-frequency tools: this benchmark does not apply
D30 retention (PLG, high-fit ICP users)	>30%	Below 10%: either wrong ICP or product has not delivered value at FVM
Time-to-first-query / first-API-call (developer tools)	<10 minutes (target)	>30 minutes: onboarding friction is the primary activation constraint
PQL → close rate (MLG)	>40% = healthy PLG-to-SLG handoff	Below 40%: PQL signal is wrong or handoff is broken
NSM review cadence	Every 6 months, or on trigger	Trigger-based is more important than calendar-based
Input metrics per NSM	3–5	More than 5: NSM is wrong; fewer than 3: team is under-measuring

---

Related skills

Skill	When to use
growth/growth-loop-design/SKILL.md	After NSM is defined: design the growth loop that compounds the NSM
growth/experiment-portfolio/SKILL.md	NSM and input metrics become the portfolio's orientation framework
growth/funnel-audit/SKILL.md	Funnel audit identifies which input metric is the current constraint
growth/retention-analysis/SKILL.md	Validates whether NSM is predictive of retention via cohort analysis
pmm/icp-research/SKILL.md	ICP definition shapes which users the NSM must measure value for

---

Validation criteria

• NSM passes all four criteria (user value, retention predictive, measurable, influenceable)
• NSM is not a revenue metric or a vanity metric
• Input metric tree has 3–5 inputs, each with a named owner
• Guardrail metrics defined with specific numeric thresholds
• NSM revision triggers documented
• NSM is expressed as a single observable event or ratio — not a composite score

References & Sources

Tier 1:

• Reforge growth loops framework: NSM selection, input metric tree design, loop-to-NSM connection
• Amplitude NSM playbook (2025): four-criteria validation, category-specific NSM examples, revision protocol
• growth-motion-plg (growth-skills v1.0, score 8.5/10): FVM definition, PLG activation benchmarks