01 / UNDERSTAND
What is a North Star Metric?
A North Star Metric is a product measure intended to represent the value people receive from using an offer. A supporting model connects it to inputs the team can influence. It is a hypothesis about value, not proof that every counted action helped someone.
A useful candidate reflects the product’s strategy and has a plausible connection to sustainable outcomes. The choice depends on the service. More visits, messages or sessions can mean greater use, but can also indicate confusion or repeated failure.
Why use North Star Metric?
Teams can optimise separate local metrics without improving the overall service. A shared value measure helps connect those activities to an outcome and makes tradeoffs easier to discuss. It is most useful when the counting rules and their limitations remain visible. Selecting an attractive number without investigating what it represents only replaces several disconnected metrics with one influential proxy.
When to use it
USE IT WHEN
Several teams contribute to a shared product value proposition.
Local activity measures are pulling work in different directions.
The organisation can investigate whether the candidate tracks delivered value.
When to choose another method
Use OKRs for a time bounded objective with specific targets.
Use HEART Framework to connect experience goals with signals and metrics.
Use User Interviews when the underlying value proposition is still assumed.
What you’ll need
Describe who receives value, what changes for them and how the organisation sustains delivery. Map the event or outcome that might represent this change. Work with analysts and operational colleagues on counting rules, identity, time windows and data quality. Bring evidence of actual use and unresolved need. Decide which harms or exclusions the candidate could conceal.
What a useful value metric needs
Keep the elements that help answer your question and support a decision.
What people can meaningfully achieve.
The person, account or outcome being counted.
An observable event plausibly linked to that achievement.
Factors the team believes can influence delivered value.
Quality, access and operational consequences to preserve.
Evidence that would support or challenge the metric.
02 / PUT IT INTO PRACTICE
How to choose and test a North Star Metric
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Describe the value
Start with the person’s outcome rather than a product activity.
A completed repair matters more than repeated visits to its status page.
02
Propose candidates
Compare a few observable measures and their counterexamples.
Bookings, attended visits and resolved repair episodes represent different boundaries.
03
Define counting
Specify identity, time window, repeated events and qualification rules.
Count a resolved episode once rather than every contractor visit.
04
Connect inputs
Identify factors plausibly influenced by the teams involved.
Coverage, attendance and effective completion may affect the outcome.
05
Add guardrails
Check quality, exclusion and costs hidden by the main measure.
Monitor reopened repairs and requests denied access.
06
Validate the connection
Compare the candidate with qualitative evidence and longer term outcomes.
A closed ticket may not mean a resident’s problem is resolved.
07
Use and revisit
Review the model when the strategy, population or measurement changes.
Keep a quality gate visible rather than silently changing the metric definition.
Example: measuring value in a repair service
Fictional scenario: a repair service considers “resolved repair episodes per month” as a candidate North Star. It proposes counting a repair episode only after operational completion and an agreed quality check. Multiple visits within one episode count once. The candidate is not presented as validated.
Input measures include requests the service can responsibly accept, attended visits and effective completion. Guardrails include reopened episodes, denied access and disproportionate contractor workload. Each has its own definition rather than being silently folded into the main count.
The diagram links inputs to the candidate and places guardrails below. A rise in closed tickets would not establish delivered value. The team first checks whether its completion records match residents’ accounts and whether harder cases disappear before entry.
03 / BELOW THE SURFACE
Below the surface: more activity can mean a worse service
In an episodic service, people may benefit from needing it less often.
VALUE
Could this count rise because the service failed?
Distinguish activity from benefit.
BOUNDARY
When is one episode genuinely complete?
Make qualification and repeats explicit.
VALIDATION
Whose account could challenge the event record?
Check the candidate against lived experience.
A repair product could increase sessions by making status information unreliable. It could increase completed appointments through repeat visits that failed to resolve the original issue. Those counts describe activity generated by the service, not necessarily value received.
Ask whether the event is a healthy occurrence or a symptom of unresolved need. Count an outcome without rewarding its repeated failure. A quality gate and an episode boundary can make the candidate more meaningful, but they also introduce judgement and a delay before it can be counted.
This is an editorial interpretation check, not a claim that one metric captures every service outcome. Preserve the qualification rules and assess missing cases separately. If the organisation cannot verify resolution responsibly, use the candidate as a question to investigate rather than label a convenient event as its North Star.
North Star Metric companion worksheet
The original companion connects value, candidate metric, inputs and counting rules. Page two records counterexamples, validation evidence and guardrails. It supports choosing a candidate rather than providing a universal product metric.
Practical tips
Write a counterexample for each candidate.
Define repeated events and completion boundaries.
Validate value beyond the tracking system.
Common mistakes
Selecting activity because it is easy to count.
Treating a proposed metric as already validated.
Changing qualification rules without recording the change.
What you’ll get
A candidate metric and a transparent model of what it represents. Validate its connection to delivered value, then use inputs and guardrails to interpret change without hiding the people outside the count.