Building North Star Metric Dashboards That Trace the Work

Tracking a North Star metric on a dashboard shaped like the framework: business results, the metric, inputs, system health and bets on one page.

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

Most product management KPI dashboards are a grid of charts. A dashboard built for the North Star Framework has a shape instead: it follows the framework's tree from the work at one end to business results at the other. Tracking a North Star metric this way lets a viewer see why the number moved, which inputs moved it, and which bets were supposed to move those inputs.

The shape comes from the playbook. Amplitude's North Star Playbook draws the framework as the work, then inputs, then the North Star Metric, then medium- and long-term business results, with leading measures at one end and lagging ones at the other. Its Burger King figure lays out the same chain in columns: product initiatives, leading indicators, squad goals, the North Star of digital transactions per user, and revenue as the lagging indicator.

A dashboard in that order answers the questions the framework raises. Cutler says in the playbook that the North Star is meant to get people thinking about why it is going up or down. With inputs beside it and bets beneath them, that question has somewhere to go. Without them, a drop in the North Star starts a hunt through unrelated reports.

Amazon arrives at a similar layout from a different direction. Cedric Chin's account of the Amazon Weekly Business Review describes a deck that presents the business as an end-to-end process, with controllable input metrics that teams act on and output metrics such as revenue that are discussed only in a reporting sense. The framework dashboard adds two things Amazon's deck does not center: the bets currently in flight and a health input for non-feature work.

This skill covers the design of that page: which panels it needs, in what order, and how to keep it honest. A companion page on building a North Star Metric dashboard covers chart construction and the weekly review meeting in more depth.

How It Works

The dashboard has five zones, read from left to right or top to bottom. Business results come first or last, depending on reading direction, and show the lagging outcomes the North Star is expected to lead, such as revenue or retention. The North Star Metric sits next to them with its definition. Inputs follow, each with its own trend and definition. A system health panel covers non-feature factors. The bets zone lists the work in flight under the input it is meant to move.

Definitions live on the page. The playbook insists on a name and a definition for the metric and each input, and gives Amplitude's own former North Star as an example of a precise one: Weekly Learning Users, the count of active users who shared a learning that at least two other people consumed in the previous seven days (North Star Playbook). Printing the definition next to the chart stops teams from quietly measuring different things under the same name.

The health panel comes from the playbook's advice on non-feature work. It suggests a system health input and lists examples such as uptime, cycle times, testing and deployment processes, up-to-date tooling, and ramp-up time for new team members. It quotes Troy Magennis's six areas of health: value, consistency, quality, speed, quantity and sustainability. On the dashboard, this panel shows drag building up before it reaches customers.

The bets zone follows the playbook's review language. It suggests replacing "to do, doing, done" with "to try, trying, review," so work is reviewed for its effect instead of closed. Showing each bet with its target input and status makes it obvious when a lot of work is in flight against one input and none against another.

Leading and lagging need different time frames. Inputs and health can move within weeks; the North Star moves more slowly; business results lag further. Chin describes Amazon's standard chart showing the trailing six weeks next to the trailing year by month (Commoncog), which gives both views at once and suits a page where zones move at different speeds.

Step-by-Step Guide

Step 1: Draw the tree before any charts

Sketch the framework for your product on one page: business results, the North Star, its inputs, the health input, and the main opportunities under each input. Use the input map if you already have one. Decide the reading direction so the page flows from the work toward results. This sketch is the dashboard's layout.

Step 2: Write every definition

For the North Star and each input, write the name and a precise definition, including the unit, threshold and time window, in the style of the playbook's Weekly Learning Users example. Agree the query or event logic with analytics. Note where a measure is a proxy. These definitions go on the dashboard next to their charts.

Step 3: Build the metric and input panels

Chart the North Star with a short and a long view, for example the last several weeks next to the last year by month. Give each input the same treatment so they can be compared. Place inputs in the order of the tree. Add a line for any target or expected range, and mark it as an expectation.

Step 4: Add business results and the health panel

Add a small panel of the lagging business results the North Star should lead, such as retention or revenue, so viewers can see whether the link holds over time. Add the system health input with its component measures, following the playbook's suggestion. Keep both small; they are context for the tree.

Step 5: Show the bets under their inputs

List current bets under the input they target, each with its status in "to try, trying, review" terms and the measure it should move. Pull this from wherever the roadmap lives so it stays current. Highlight inputs with no active bets and bets with no input. Link each bet to its one-pager or ticket.

Step 6: Annotate changes and releases

Mark releases, experiments, definition changes and outside events on the charts. When an input moves, viewers should be able to see which bet landed nearby. When a definition changes, note the date so trends are not misread. Keep annotations short and dated.

Step 7: Use it in reviews and prune it

Walk through the page in the order of the tree at each review: bets, then inputs, then the North Star, then results. Follow Amazon's exception habit that Chin describes on Commoncog: owners explain unusual movements or say they are still investigating. Remove panels nobody uses. Add a panel only when it answers a question the tree raises.

Best Practices

• Keep it to one page. The value of the layout is seeing the whole chain at once, and a second tab breaks the chain.
• Order panels by the tree. Grouping by team hides how one team's input affects another's.
• Print definitions next to charts. The playbook's emphasis on a precise name and definition is easiest to honor where people actually look.
• Show expectations as expectations. A target line drawn from a hypothesis should be labelled as a belief so a miss prompts learning instead of blame.
• Keep lagging results visible. If the North Star rises and results do not follow over several months, the dashboard should make that obvious, since it is the signal the playbook gives for revising the North Star.
• Put non-feature health on the page. A health panel makes the case for platform and debt work in the same view as everything else.

Common Mistakes

• A grid of every metric anyone asked for: Adding charts without a place in the tree turns the page back into a generic KPI dashboard. Each panel should be a node in the framework or context for one.
• Showing the North Star alone: A single big number invites people to try to move it directly, which the playbook warns against. Always show the inputs with it.
• Leaving out the work: Without bets on the page, nobody can connect a movement in an input to what the team did. Pull the bet list in automatically.
• Hiding definition changes: A changed threshold without an annotation makes a trend look like progress or decline. Date every change on the chart.
• Treating the dashboard as the framework: A page does not create alignment by itself. Use it in reviews and planning, or it becomes decoration.

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
• Using the North Star Framework for Roadmap Prioritization
• Iterating the North Star Metric and Its Inputs

Sources

• Amplitude: The North Star Playbook
• 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.