Selects and validates the North Star Metric (NSM), builds the input metric tree beneath it, defines guardrail metrics that cannot be sacrificed, and designs the review cadence. The NSM is the single metric that most accurately captures the value the product delivers to users — not the value the business extracts from users. Prevents the most common failure mode: optimizing for revenue metrics that move up while the product quietly loses product-market fit.
Selects and validates the North Star Metric (NSM), builds the input metric tree beneath it, defines guardrail metrics that cannot be sacrificed, and designs the review cadence. The NSM is the single metric that most accurately captures the value the product delivers to users — not the value the business extracts from users. Prevents the most common failure mode: optimizing for revenue metrics that move up while the product quietly loses product-market fit.
triggers
["/north-star-metrics","/nsm","user is defining success metrics for a product or growth motion","experiments are running without a clear NSM to orient against","the team is arguing about which metric to optimize","NSM is out of date after a product pivot or market shift"]
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
