Mapping Input Metrics From the North Star to the Work

Mapping input metrics in the North Star Framework: name the inputs, then trace each one down through opportunities to the work that moves it.

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

Input metrics are the part of the North Star Framework that teams actually work on. Amplitude's North Star Playbook describes them as "a small set of influential, complementary factors" that you believe most directly affect the North Star Metric, and says they are as important to the framework as the metric itself. The North Star is an outcome that depends on the inputs, and teams influence the inputs with their day-to-day work.

This skill maps the whole chain below the North Star. The playbook's statement worksheet has four layers: the North Star, the inputs it is a function of, the opportunities that could influence each input, and the interventions that make tangible progress on those opportunities. Mapping all four is what connects a metric on a dashboard to a ticket in a sprint. A companion page on North Star input metrics mapping covers decomposing the metric and testing the input set in more depth; this page follows the map downward to the work.

The reason for the extra layers is practical. Amplitude's Ibrahim Bashir explains in the playbook that a good North Star is hard for a team to move directly, given the many inputs and the time results take, so teams are better served moving one component that ladders up to the larger metric. The same logic applies one level down: an input is still too broad for a sprint, so teams need opportunities and interventions underneath it.

Each link in the map is a causal belief. John Cutler writes in a post on cascades that the North Star Framework is not a cascade, because there is no hierarchical relationship between the metric and the inputs, only a presumed leading and lagging relationship and a positive causal one. That is why each layer of the map is written as a belief to test instead of a goal handed down.

Input metrics are a common idea outside the framework too. Lenny Rachitsky calls the North Star an output metric and describes the next step as breaking it into its component parts, the input metrics. Amazon's weekly business review uses the same split, with controllable input metrics that teams can act on directly and output metrics such as revenue that are discussed only in a reporting sense (Commoncog).

How It Works

Each layer has its own character. The playbook's worksheet describes inputs as more addressable than the North Star, "part of the formula," persistent, and lasting quarters or years. Opportunities are leverage points that inspire several options, last months or quarters, and are solution agnostic but directional. Interventions are more work-like and experiment-like, time bound, and expected to change. Keeping these differences clear stops a team from writing a feature as an input.

Inputs often follow a pattern. The workshop guide suggests breadth, depth, frequency and efficiency as a heuristic, and applies it to an ecommerce North Star of total monthly items received on time: breadth is customers placing orders, depth is items per order, frequency is orders per customer, and efficiency is the share of orders delivered on time (workshop guide). The pattern is a starting point. Some products need an input it does not cover.

Mind mapping builds the structure. The playbook's process is to put the North Star, or a candidate, on a whiteboard, note related concepts in clusters, then combine, prune and rename them until each cluster is a named input with a high-level definition. Only after that does each input get an exact metric. Naming comes before measuring at every layer.

Every input needs a name and a definition. The playbook applies the same rule to inputs as to the North Star, and warns against inputs that are too broad or lagging, which make impact hard to measure, or too specific and prescriptive, which leave no room for new solutions. Its example is that "satisfied customers" may be too broad and "positive reviews on social media" too narrow.

Non-feature work gets its own input. The playbook suggests a system health indicator input covering factors users may not see but that affect quality and the team's ability to work, such as system uptime, cycle times, testing and deployment processes, up-to-date tooling, and ramp-up time for new team members. It recommends visualizing non-feature work as opportunities on the roadmap and reframing technical debt as drag on value.

The map ends at the work. Each intervention should name the opportunity it serves, and each opportunity the input it should move. When an intervention cannot be traced upward, either the map is missing a piece or the work is not valuable, which is the same conclusion the playbook draws from its roadmap check.

Step-by-Step Guide

Step 1: Write the function in words

Start from the North Star statement and complete the sentence the worksheet uses for the second layer: the North Star "is a function of our ability to" do a few things. Write a handful of phrases in plain words, such as "match customers with the right projects." Check that each phrase describes customer behavior or a result for the customer; phrases about a team or a feature belong lower down. These phrases are your draft inputs.

Step 2: Cluster and name the inputs

Run a mind-mapping session with the North Star in the middle. Let the group add concepts freely, then merge related ones, remove extras and rename each cluster. Test the result against breadth, depth, frequency and efficiency from the workshop guide to see whether a dimension is missing. Give each input a short name and a one-line description.

Step 3: Define each input metric

For each named input, write the exact measure: the event or state, the population, the threshold and the time window. Check the scope against the playbook's warning about inputs that are too broad or too narrow. Confirm that the inputs have some independence, so a change in one is not immediately felt in the others. Record where a measure is a proxy and what it stands in for.

Step 4: Add a system health input

Decide whether the product needs an input for non-feature factors. If reliability, delivery speed or tooling limits what teams can do, define a composite health input from a few measures, such as uptime and cycle time, following the playbook's suggestion. This gives infrastructure and debt work a place on the map. Keep it to one input so it does not crowd out customer-facing ones.

Step 5: Map opportunities under each input

For each input, list the leverage points that could move it, written as problems or openings rather than solutions. The playbook's example for a do-it-yourself app lists opportunities such as "expand project selection" and "connect like-minded DIY-ers." Aim for a few per input that each inspire several possible solutions. Note what you would measure to see each opportunity progressing.

Step 6: Attach current and candidate interventions

Place today's roadmap items and experiments under the opportunities they serve. Add new ideas where an opportunity has none. Items that fit nowhere go on a separate list for discussion, since they may reveal a missing input or work with no clear value. Give each intervention the measure it should move in the short term.

Step 7: Review the map on a rhythm

Revisit the map when bets finish and when the roadmap changes. Interventions will change often, opportunities less often, and inputs rarely, which matches the time horizons the playbook gives each layer. Update definitions when you learn a measure was misleading. Retire inputs that stop showing any link to the North Star, and record why.

Best Practices

• Name before you measure. Clusters with clear names produce better metrics than formulas chosen first, and the playbook follows this order at every layer.
• Keep inputs about customers. The worksheet describes inputs as "not work related," so an input like "features shipped" belongs further down the map, if anywhere.
• Look for independence. The playbook's input template asks you to state that movements in one input are not immediately felt in the others; overlapping inputs double-count the same lever.
• Write opportunities as problems. A solution-agnostic opportunity lets teams try several interventions, which is what makes the bottom of the map a set of bets.
• Give non-feature work a visible home. A system health input stops platform and debt work from looking like a distraction from the North Star.
• Treat the map as a set of hypotheses. As Cutler's post on cascades explains, the links are causal beliefs, so review them against data instead of defending them.

Common Mistakes

• Stopping at the inputs: A North Star with four inputs and nothing underneath still leaves teams guessing what to build. Map opportunities and interventions so the link reaches the sprint.
• Writing features as inputs: "Launch the mobile app" is an intervention. Inputs describe persistent customer behavior that lasts quarters or years.
• Inputs that are really the North Star again: If an input moves exactly with the North Star and nothing else, it adds no lever. Break it down further or replace it.
• Treating the map as a cascade of targets: Handing each team an input as a quota invites gaming. Present each link as a belief and ask teams how their work could move it.
• Leaving non-feature work off the map: When reliability and tooling work has no input, it is either ignored or done quietly, and both hurt the North Star over time.

References

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

Related Skills

• Identifying Your North Star Metric: Words Before Numbers
• Using the North Star Framework for Roadmap Prioritization
• Building North Star Metric Dashboards That Trace the Work

Sources

• Amplitude: The North Star Playbook
• Amplitude: How-to Guide, Running Your North Star Workshop
• John Cutler: Beware of the Cascade
• Lenny Rachitsky: Choosing Your North Star Metric
• Commoncog: The Amazon Weekly Business Review

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