Using the North Star Framework for Roadmap Prioritization

A North Star framework roadmap: score bets by input influence and likelihood, prioritize by expected value, and review every finished bet.

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

The North Star Framework is not a prioritization framework, and Amplitude's North Star Playbook says so directly. It does give prioritization a shared reference and a short list of rules. This skill uses them to prioritize a product roadmap and build a North Star framework roadmap with three parts: a two-factor scoring model, a force-ranked list of bets, and a review step that feeds results back into the scores.

The core rule is in the playbook's prioritization tips: when prioritizing, consider both the influence of the input on the North Star and the likelihood that the opportunity drives the input. That gives a product roadmap scoring model with two questions for every item. How much does the input it targets matter to the North Star? And how likely is this work to move that input? The rest of the tips shape how you use the scores, which turns the North Star into a working roadmap prioritization framework.

The playbook prefers a series of small bets over one big bet, prioritizing by expected value or influence over the amount of work completed, and paying attention to forecasted value and "experimentation friendliness" rather than obsessing over duration estimates. It also warns against big batches of work with infrequent chances to learn and pivot, and encourages multiple experiments or bets against a single high-value opportunity.

John Cutler, co-author of the playbook, describes a roadmap format that fits. In his post on continuous roadmapping he uses a North Star Metric and inputs to ground the roadmap in strategy and keeps a board of bets where only the item up next and the item in progress need detail. The rest stay as high-level options until they come close. That keeps the ranking cheap to change when results come in.

This page focuses on the scoring and ranking. A companion page on connecting the North Star metric roadmap covers mapping items to inputs, one-pagers for big bets and the levels of bets in more depth.

How It Works

Each item gets two scores. Input influence reflects how strongly the targeted input drives the North Star, based on your input map and any historical data. Likelihood reflects how confident you are that this piece of work will move the input, based on evidence such as research, past bets and prototypes. Multiply or combine them into an expected value, then rank. The playbook names these two factors; the scale you use for them is your choice.

Effort enters differently from most scoring models. The playbook says teams often obsess about duration estimates, and that forecasted value and how friendly the work is to experimentation matter more in most product-led situations. In practice, that means preferring items that can be split into small bets with early signals, and treating a large, indivisible item as riskier regardless of its size estimate.

The roadmap becomes a portfolio. The playbook suggests thinking of the roadmap as a portfolio of bets, where a large project is a bet made of smaller, related ones. Check the ranked list against the input map: if all the top items target one input, the portfolio may be neglecting a lagging one. Include a few bets on the system health input so non-feature work competes in the same list.

Goals attach to bets. The playbook's tips for OKRs suggest framing them as the impact that bets at the opportunity level will have on one or more inputs, and warn against teams packing a quarter with deliverables instead of focusing on an outcome. Cutler makes the same point in his post on cascades: time-based goals map the work to the inputs.

Review closes the loop. The playbook's roadmap tips include following up on completed items to see whether they had the expected impact, and it suggests replacing "to do, doing, done" with "to try, trying, review." Each review updates the likelihood scores for similar work. Over a few cycles, the scoring model reflects what actually moves your inputs instead of what the team hoped would.

Step-by-Step Guide

Step 1: Rate the inputs

List the inputs from your map and rate how strongly each one drives the North Star, using historical data where you have it and the team's judgment where you do not. Note which inputs are lagging this cycle. Write down the reasoning behind each rating. These ratings are the influence half of every item's score.

Step 2: Tie every candidate to one input

For each backlog item and roadmap candidate, name the one input it is mainly meant to move and the opportunity it addresses. Items that cannot be tied to any input go to a separate list for discussion, as the playbook's roadmap check suggests. Tie reliability and debt work to the system health input if you use one. Reject items whose only justification is a stakeholder request.

Step 3: Score likelihood with evidence

For each item, rate how likely it is to move its input. Base the rating on evidence: research, prior bets on the same opportunity, prototypes or analogies. Write one sentence on what the rating rests on. Where evidence is thin, rate low and consider a smaller bet that would raise confidence.

Step 4: Split large items into smaller bets

Break big items into bets that each produce a readable signal on the input, following the playbook's preference for a series of small bets. Where a high-value opportunity is uncertain, put several bets against it instead of one. Re-score the smaller pieces. Flag anything that cannot be split as a large batch that needs a strong case.

Step 5: Rank and balance the portfolio

Combine influence and likelihood into an expected value for each bet and force-rank the list. Check the top of the list against the input map for balance, and against capacity. Following Cutler's continuous roadmapping board, detail only the next item and the one in progress, and keep the rest as options.

Step 6: Set goals on the bets

For the bets you commit to, write the expected effect on the targeted input and the date you will check it. If you use OKRs, frame key results as that effect on inputs. Avoid goals that count deliverables. Share the ranked list with the reasoning so stakeholders can see why their request sits where it does.

Step 7: Review finished bets and re-score

When a bet finishes, compare the input's movement with the expectation and move the bet to "review" instead of "done." Record whether it won, lost or was inconclusive, and why. Adjust likelihood ratings for similar work and, if an input did not respond as expected, revisit its influence rating. Start each planning cycle with these reviews.

Best Practices

• Write the reasoning next to every score. A number without a sentence cannot be challenged or learned from.
• Prefer bets that can be split. The playbook's preference for small bets and fast feedback over large batches reduces the cost of being wrong.
• Keep likelihood honest. Rate new ideas low until evidence arrives; enthusiasm is not evidence.
• Balance the portfolio across inputs. A ranking that ignores a lagging input can optimize one lever while the North Star stalls.
• Let non-feature work compete. Scoring health work against the same model makes its trade-offs explicit instead of leaving it to side deals.
• Keep most of the roadmap light. Detailed plans far down the list are wasted when reviews change the ranking, as Cutler's roadmapping post argues.

Common Mistakes

• Scoring only effort and reach: Models that ignore the link to an input rank busy work highly. Always ask which input the item moves and how sure you are.
• Treating the North Star as the goal for each item: Individual items rarely move the North Star visibly. Set expectations on inputs, where effects can be seen.
• Locking the ranking for a year: A ranked list that never changes ignores what reviews teach. Re-rank at least every planning cycle.
• Skipping the review step: Without reviews, likelihood scores never improve and the model stays a guess. Move finished work to a review column before anyone calls it done.
• Using the score to end debate: The score summarizes beliefs. When someone disagrees, examine the belief behind the number rather than pointing at the total.

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
• North Star Metric Cross-Functional Alignment That Sticks

Sources

• Amplitude: The North Star Playbook
• John Cutler: Continuous Roadmapping
• John Cutler: Beware of the Cascade

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