Iterating the North Star Metric and Its Inputs

Iterating a North Star metric through regular product metric reviews: check confidence, refine inputs and definitions, and know when to revise.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A North Star model is a set of hypotheses, and hypotheses need checking. Iterating a North Star metric means reviewing the whole model on a rhythm: the metric's definition, the inputs, the links between them, and the beliefs underneath. Most reviews change something small, such as a threshold or an input. A few end with the conclusion that the North Star itself needs to change. This skill covers both, with most of the attention on the small, frequent iteration that keeps the North Star Framework useful.

Amplitude's North Star Playbook says teams that implement the framework successfully are never "done." It describes the real muscle as continuously checking whether the metric and inputs still represent current beliefs, product vision and product strategy, then refining accordingly. John Cutler adds in the playbook that a common misconception is expecting a perfect North Star after one workshop, and that getting it right can take weeks or months.

The playbook frames the review with Jabe Bloom's contrast between gap thinking and present thinking. Gap thinking fixes a future end state and tries to close the gap, and teams lose momentum when the end state never arrives. Present thinking asks where we are, what we need now, and how to improve the current way of working. Applied to the framework, it becomes a short list of questions a team can ask every few weeks.

A product metric review of this kind is different from switching the metric. Amplitude's North Star hub says to revisit the metric whenever there is a significant shift in product, market or strategy, and gives a rough cadence for changing it: every six to 12 months for early-stage startups and companies new to the framework (North Star hub), and every one to three years for more established organizations. The frequent review is what tells you whether one of those shifts has happened. A companion page on when to change your North Star Metric covers running the switch itself.

How It Works

The review asks the playbook's present-thinking questions (North Star Playbook). Can current efforts align more closely with the chosen inputs? What decisions do we need to make now, and is the framework supporting them? Can every team member trace current work to the North Star, and if not, what context is missing? Has confidence in the inputs and the North Star gone up or down in the last couple of weeks, and why? What have we learned recently about beliefs and value exchanges that needs tweaking?

Confidence is the main thing to track. For each link in the model, record whether evidence since the last review strengthened or weakened it. Evidence comes from finished bets, input movements, customer research and the relationship between the North Star and business results. A link whose confidence keeps falling is the first candidate for change.

Changes come in three sizes. Definition changes adjust a threshold, window or population without changing the concept; the playbook's own example, Amplitude's Weekly Learning Users, used a threshold of two other people that the playbook says was not magic. Input changes add, split, merge or retire an input when the map stops explaining movements. Metric changes replace the North Star, which is rare and needs the full process.

The playbook gives the main trigger for a metric change. Ted Clark says that a good North Star is a leading indicator of revenue, so if the North Star is flat, expect revenue to be flat, and if the North Star is not directionally indicating where revenue is going, it is time to revise it. Other triggers the playbook lists are a changed market, a different business stage, or realizing the metric is not something the team can control. Cutler warns that changing the North Star is often one of the hardest things for companies because "they get too attached to it."

Change is common in practice. Lenny Rachitsky found that about a quarter of the more than 40 growth-stage companies he surveyed had recently changed their North Star or were about to (Choosing Your North Star Metric). A review rhythm makes those changes deliberate.

The playbook also lists signals that the framework is working, and they make a useful checklist for each review: people can explain how their work connects to the North Star, collaboration improves, more people describe the strategy coherently, non-product colleagues use words like "inputs," and saying "no" gets easier and better supported by evidence.

Step-by-Step Guide

Step 1: Set the rhythm and the group

Schedule a short review every few weeks with the North Star owner, input owners and an analyst. Put a deeper review on the calendar for each planning cycle. Bring the original workshop notes, including the beliefs and value exchanges, so the group can see what the model was built on. Keep the group small and share notes widely.

Step 2: Ask the present-thinking questions

Open each review with the playbook's questions about alignment, decisions, traceability, confidence and recent learning, taken from the North Star Playbook. Ask each input owner to answer the confidence question for their input. Note where people cannot trace their work to the North Star. Keep answers short and specific.

Step 3: Update confidence on each link

For each link, from bets to inputs and from inputs to the North Star, record whether recent evidence strengthened or weakened it and why. Look at finished bets, input trends and any new research. Check the North Star against lagging business results over the longest window you have. Mark links whose confidence has fallen for several reviews in a row.

Step 4: Make small refinements

Fix definitions that proved ambiguous or misleading, and restate history where needed so trends stay comparable. Split inputs that hide two behaviors, merge inputs that always move together, and retire inputs that no work seems to move. Record each change with a date and a reason. Tell dashboard owners before the change goes live.

Step 5: Check the triggers for a bigger revision

Ask whether the North Star still points where revenue is going, as Ted Clark suggests in the playbook, and whether the market, business stage or strategy has shifted. Compare the elapsed time with the rough cadence on the North Star hub as a sanity check. If a trigger is met, schedule a revision with a workshop instead of changing the metric in the review. Write down the evidence either way.

Step 6: Review the framework's own health

Run through the playbook's signals that the framework is working. If people cannot connect their work to the North Star or the metric has disappeared from company meetings, the issue may be adoption rather than the model. Assign an action to whichever gap is largest. Revisit it at the next review.

Step 7: Publish the changes

Send a short summary after each review: what changed, why, and what stays the same. Update the dashboard annotations and the written definitions. For any change to an input or the North Star, explain what it means for current bets. Keep a change log so new team members can see how the model evolved.

Best Practices

• Review the whole model along with the number. A North Star can look healthy while an input link has quietly stopped working.
• Track confidence explicitly. A simple up, down or unchanged per link, with a reason, is enough to show trends across reviews.
• Prefer small changes. Adjusting a definition or an input keeps continuity; replacing the North Star resets alignment and should be rare.
• Tie revisions to evidence and triggers. The playbook's revenue signal is a clearer trigger than a general feeling that the metric is stale.
• Watch for attachment. Cutler's warning that companies get too attached to their North Star is a reason to invite an outside view to deeper reviews.
• Keep a change log. Dated reasons for each change protect trends and help new people understand the model.

Common Mistakes

• Reviewing only when something breaks: Without a rhythm, the model drifts until a crisis forces a hasty change. Put reviews on the calendar.
• Changing the North Star in a routine review: A metric change needs the full process, including the people who were not in the review. Use the review to decide whether to start that process.
• Silently editing definitions: An undocumented threshold change makes trends look like progress or decline. Date and annotate every change.
• Ignoring the link to business results: A North Star that keeps rising while revenue and retention do not is sending the trigger signal. Check the link at every deeper review.
• Treating adoption problems as model problems: If nobody uses the framework, changing the metric will not help. Check the playbook's signals before redesigning the model.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: North Star Framework

Related Skills

• Mapping Input Metrics From the North Star to the Work
• Building North Star Metric Dashboards That Trace the Work
• Running a North Star Framework Workshop

Sources

• Amplitude: The North Star Playbook
• Amplitude: North Star hub
• Lenny Rachitsky: Choosing Your North Star Metric

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.