North Star Metric Cross-Functional Alignment That Sticks

North Star metric cross-functional alignment that lasts: a sponsor, onboarding, approval habits and shared language, without a cascade of targets.

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

North Star metric cross-functional alignment rarely fails in the workshop. It fails in the months after, when the metric competes with every team's existing targets and the workshop output fades into a slide. This skill is about the systems that keep the North Star Framework in use: who sponsors it, how new people learn it, how decisions get checked against it, and how to avoid turning it into a cascade of targets.

Amplitude's North Star Playbook is direct about this. Ted Clark says in it that "your North Star is not a proclamation you nail to the wall and magically everyone starts to follow," and that you need systems in place to drive it forward. The playbook lists what teams that stuck with the framework had: a sponsor with both influence and authority, leadership buy-in, communication and change management processes, an onboarding process that brings the framework into existing ways of working, and approval processes.

The playbook's case for the framework starts with language. A product manager in its introduction found her company speaking three languages, the customer's, the product's and the business's, with nothing tying them together. North Star framework alignment means building a shared vocabulary across those groups, so that product and engineering, sales and finance can discuss one decision in the same terms. The playbook counts it as a sign of success when non-product team members start using words like "inputs" or "our North Star."

A shared metric does not mean cascading metrics across teams. John Cutler writes in Beware of the Cascade that the North Star Framework is not a cascade: there is no hierarchical, top-down "here's the strategy, what projects will you do" relationship between the metric and its inputs. Teams choose how to move inputs, and time-based goals map the work to those inputs. Treating the framework as a target cascade brings back the politics it was meant to reduce.

This page focuses on making alignment last across an organization. For the day-to-day practice of giving each function an input it owns and a place in the review rhythm, see the companion guide to aligning teams around a North Star.

How It Works

Sponsorship comes first. The playbook asks for a sponsor with both influence and authority. In practice the sponsor opens the workshop, uses the North Star in leadership reviews, and backs teams that decline work because it does not connect to an input. Without that backing, the first conflict with an existing target decides the matter against the framework.

The metric has to show up where decisions are made. Amplitude's own practice, described in the playbook, is to report the North Star weekly within product and leadership teams and share progress quarterly at company All Hands alongside pipeline and revenue. Customer success managers also report it in quarterly business reviews. The playbook also recommends socializing the North Star repeatedly in formal and informal forums, and encouraging colleagues to share it too.

Onboarding and approvals make it routine. New hires learn the North Star, its inputs and the reasoning behind them in their first weeks. Approval processes, such as a project kickoff template or an investment review, ask which input the work targets. The question Ted Clark describes in the playbook, "Is that going to advance the North Star or one of its inputs?", becomes a standard line in those documents.

One North Star across products matters for alignment. Workshop participants often insist they need more than one, and the playbook treats that as a trap except for distinct lines of business with different customers. Its example is a bank with dozens of consumer products that customers may see as a single product: a trustworthy partner in their quest for financial independence. Clark warns that teams with different North Stars end up with the same in-fighting and resource battles as before.

Current dysfunction is not a reason to wait. The playbook describes the moment in workshops when teams realize how many problems their company has and decide "it'll never work here." It offers two strategies: start where you are, using the framework's language and chipping away at assumptions, and start small, building a North Star for a product scope you can actually influence. Getting product and engineering to share one North Star for a single product area can be a better start than a company-wide rollout.

Structure can follow later. The playbook says there is no reason to overhaul the org chart at the start, and suggests considering team design only once the North Star has produced a few months or quarters of learning.

Step-by-Step Guide

Step 1: Secure a sponsor and a scope

Find a leader with influence and authority who will use the North Star in their own reviews and defend decisions made with it. Agree the scope with them: one product area, one business line, or the company. If the company is not ready, start small with a scope your group can influence, as the playbook suggests. Write the sponsor's commitments down.

Step 2: Translate the North Star into each function's language

For each function, write a short explanation of the North Star and the inputs in its own terms. For engineering, cover which systems, experiments and health measures affect which inputs. For sales and customer success, cover which customer behaviors signal value and renewal. Test each explanation on someone from that function and revise until they can repeat it.

Step 3: Put it into existing forums

Add the North Star and inputs to meetings people already attend: leadership reviews, team reviews, company all-hands and customer business reviews. Follow Amplitude's pattern of weekly reporting in product and leadership teams and quarterly company updates. Keep it brief and consistent. Avoid creating a new meeting whose only purpose is the North Star.

Step 4: Build it into onboarding

Add a short module to onboarding that covers the North Star statement, the metric, the inputs, the beliefs behind them, and how work gets linked to inputs. Include a worked example from your own product. Ask new team members to trace their first project to an input. Update the module when the model changes.

Step 5: Add the input question to approvals

Change the templates people already use to start or fund work so they ask which input the work targets and what effect is expected. Accept supporting work, such as compliance, with a stated reason. Do not turn the question into a quota for each team. The aim, in Cutler's framing in Beware of the Cascade, is to map the work to inputs rather than hand down targets.

Step 6: Resolve requests for multiple North Stars

When a team asks for its own North Star, ask the playbook's question: are there real boundaries in users, their needs, and the strategy to meet them? If products are really packages or add-ons for the same customers, offer an input instead. If there is a genuinely separate business with separate customers, support a separate framework for it. Record the decision and the reasoning.

Step 7: Check cross-functional alignment signals

Every quarter, check the playbook's signals: can team members explain how their work connects to the North Star, do non-product colleagues use its language, is the metric mentioned in large company meetings, and is it easier to say "no" with evidence? Survey a few people from each function if needed. Pick the weakest signal and assign one action to improve it.

Best Practices

• Get the sponsor to use the metric in their own decisions. People follow what leaders ask about in reviews more than what they announce.
• Repeat the North Star in many forums. The playbook recommends socializing it repeatedly, formally and informally, and encouraging colleagues to share it.
• Translate before you broadcast. A single company-wide explanation rarely lands with every function; tailored versions do.
• Keep the input question in approval templates short. One line on the targeted input and expected effect is enough to change conversations.
• Start small when the organization resists. The playbook's "start small" strategy builds evidence in one area that others can see.
• Leave the org chart alone at first. Wait until the framework has produced learning before redesigning teams around inputs.

Common Mistakes

• Treating the North Star as a cascade: Assigning each team a slice of the North Star as a target invites gaming and in-fighting. Frame inputs as causal beliefs and let teams choose how to move them.
• Relying on a launch announcement: A single all-hands presentation fades within weeks. Build the metric into recurring forums, onboarding and approvals.
• Allowing a North Star per team: Separate North Stars for teams serving the same customers bring back the resource battles the playbook describes. Offer inputs instead.
• No sponsor with authority: Without a leader who backs decisions made with the framework, existing targets win every conflict.
• Waiting for the organization to be ready: Current dysfunction is normal. Start where you are, or start small in one product area, and let results make the case.

References

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

Related Skills

• Running a North Star Framework Workshop
• Using the North Star Framework for Roadmap Prioritization
• Iterating the North Star Metric and Its Inputs

Sources

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