How to use one company-wide goal metric alongside team scorecards

Use one company-wide goal metric to point everyone at the same result, and give each team a scorecard for the work it controls, with a written link between the two. People call that company-wide number a north star metric. You need both, arranged in layers, because a single number cannot manage every trade-off in a business.

Say your leadership offsite ends with a triumphant slide that reads “Our north star is weekly active teams.” Heads nod. Two weeks later, Support is still measured on how fast tickets close, Sales on bookings, Product on how many features ship, and Finance on gross margin. Nobody is wrong, and nobody is aligned. The star is bright in the strategy deck and invisible in the Monday stand-up meetings. When someone asks “are we winning?”, five different scorecards answer five different games.

In a version of this story that happens often, Support hits every close-time target while weekly active teams stall. The north star and the team scorecard were improving different things, because nobody had written down how ticket quality feeds the number of teams that become active.

What a north star metric is for, and what it is not for

Product teams popularized the phrase north star metric. It means the one number that best captures the value customers get from the product, and that the company can grow in a sustainable way. Amplitude, a product analytics company, publishes a North Star Framework that was developed with practitioners including John Cutler. The framework treats the north star as the center of a small system with three parts: the metric, a clear statement of the value it represents, and a handful of input metrics that teams can actually move. The point is not poetry, but shared attention.

A good north star has these traits.

• It reflects value: it rises when customers succeed with the product, and not only when you spend more on ads.
• It is understandable: a smart person outside your field can explain it in one sentence.
• It is measurable: you can say exactly what one row of data represents, which filters apply, and where the data comes from, as the earlier post on metric spec sheets explained.
• It can be moved at company level: many teams can contribute, without one team “owning growth alone.”
• It is not pure vanity: raw signups with no usage, or page views with no outcome, rarely qualify.

A north star is also not a few things.

• It does not replace revenue, cash, or compliance when those are board-level realities.
• It is not a personal goal for every individual employee.
• It is not a single number you put on the wall so you never need a scorecard again.
• It is not a slogan you choose because a competitor tweeted it.

Think of the north star as the company’s shared answer to one question: “If customers keep getting more of the core value, which metric would climb?” Everything else in your metric system should either feed that climb, protect the business while you climb, or warn you when the climb is fake.

Rule of thumb: If two teams can hit their local targets while the north star stays flat for two quarters, your metric stack is decorative and does not point anywhere.

Team scorecards: local control, shared direction

A team scorecard is a short set of metrics that a team reviews on a fixed schedule to run its work. Support needs to know how healthy its queue is. Sales needs pipeline (the deals still in progress) and win rate, Platform needs reliability, and Finance needs working capital. Forcing every team to report only the company north star is lazy management dressed up as focus, because those teams still have jobs that must not break while product value grows.

Healthy scorecards have three kinds of metrics, each with its own purpose.

• Contribution metrics show how the team feeds the north star or its input metrics. An example is the activation rate for an onboarding team, meaning the share of new customers who reach their first real use.
• Safety metrics show what must not get worse while you chase the contribution. Examples are churn (customers who leave), defect rate, or how satisfied customers are with their open tickets.
• Work metrics are operational signals a team uses to manage how much work gets done, such as cycle time or how old the backlog is. Work metrics are tools, not strategy, so keep them off the company “are we winning?” slide unless they are truly strategic.

The connection between these layers is a story, not a coincidence of names. “We ship features” does not automatically mean “customers get value.” You need a chain like the one from the earlier post on metric design: an objective, a behavior, a measure, and a target. Product shipping speed can sit on a team scorecard as a work metric. It should only sit next to the north star if you can show how shipping changes the value metric for a defined group of customers.

Alignment is a tree, not a mirror

Bad alignment copies the same key number into every slide deck. Good alignment is a tree, with one crown metric, a few input branches, and team leaves that attach to a branch. Support’s first-response time can attach to an input like “teams successfully complete their first week,” if slow support is killing activation. Sales bookings attach to growth and cash, and they may be a peer of the product north star instead of a child of it. That is fine, because companies are not pure product organisms. They are product, go-to-market, and operations groups that share one profit-and-loss statement.

When leaders say “everything ladders up,” ask them to draw the ladder. If the drawing needs three asterisks and a prayer, you do not have a ladder. You have a slogan.

When one metric is too few

One number can focus a room, and it can also hide the fire in the next room. You need more than a north star in these situations.

• Trade-offs are real in most businesses. Growth competes with quality, speed with safety, and acquiring customers with keeping them. A single metric will tempt people to sacrifice whichever side goes unmeasured.
• Different time horizons both matter. Revenue arrives late, while activation shows up early, and both matter. The earlier post on leading and lagging measures covered that split. A north star that only moves slowly still needs early-warning inputs for weekly work.
• Risk is often lopsided across the business. Failures in reliability, privacy, and compliance can end the company while the product metric looks fine for a month.
• The business has several sources of value. Marketplaces, two-sided products, and multi-product portfolios often need more than one crown metric, plus a clear owner for each.
• Incentives can be high-stakes for people. The moment pay, promotion, or public ranking hangs on one number, the pressure to game it rises. A later post goes deep on that, and the design lesson here is to pair the star with safety metrics before you attach bonuses.

Many product organizations use one practical pattern: one north star, three to five input metrics, and a short list of safety metrics. The north star answers “are customers getting more core value?” The inputs answer “which lever is stuck?” The safety metrics answer “what are we not allowed to break?” That is still a small system, and it is not one lonely number pretending to be a strategy.

When too many metrics kill the signal

The opposite failure is familiar. There are forty tiles on the executive dashboard (a screen of charts and numbers that updates on its own) and twelve goals per team, and the weekly meeting becomes a tour of red and green dots. Too many metrics fail for three reasons.

1. Attention is finite

If everything is a priority metric, nothing is. People optimize whatever gets asked first in the meeting, and the rest becomes background anxiety. The dashboard advice from the earlier post on charts applies here: one primary question per view. A scorecard is a product for human attention, so treat it that way.

2. Ownership blurs

Metrics without owners become weather reports, where everyone comments and nobody commits. The spec sheet from the earlier post forces you to name an owner. If you cannot say who moves the number and who can change its definition, cut the metric from the active scorecard, or demote it to a diagnostic that you open only when something looks wrong.

3. Conflict hides in the pile

When Sales, Product, and Customer Success each bring eight metrics, the trade-offs never surface as explicit choices. They surface as quiet sabotage. Discounting ruins the economics of each sale, feature switches boost activation while destroying trust, and ticket deflection improves close time while enraging customers. A smaller shared stack makes these trade-offs something people can discuss.

How many is “too many”? There is no sacred number to aim for. A useful check is whether the team can recite the active scorecard from memory and say which decision each number informs. If they cannot, you are collecting metrics and not using them.

A simple stack: north star, inputs, team cards

Here is a mental model you can draw on a whiteboard. The diagram below is the visual version of the same idea.

Read the stack from top to bottom.

• North star: the shared customer-value outcome for the company or product line.
• Input metrics: a few levers that explain movement in the star. Depending on your model, these might be acquiring the right users, activation, engagement, retention, or expansion.
• Team scorecards: contribution metrics tied to the inputs, plus safety metrics and a couple of work metrics for local control.
• Diagnostics: deeper charts and segments that you open when an input moves, and not every week by default.

Diagnostics are where analysts shine, but they are not the same thing as the scorecard. If every cut of the data lives on the weekly slide, you will never finish the meeting. Keep diagnostics one click away, with clear definitions and quality checks from data quality for people who ship numbers.

Worked example: a fictional analytics product

Imagine a business-to-business product called Northwind Analytics Suite. Its customers are operations teams at mid-sized companies. The core value is that operations managers complete a weekly decision review inside the product with data they can trust. After a workshop, leadership picks a north star.

North star: weekly active decision workspaces, meaning workspaces where at least one manager completed a “decision review” in the last 7 days.

Why not weekly active users? A single user who logs in to download a spreadsheet file is not the same as a team that runs the routine the product was built for. Why not revenue alone? Revenue matters for the board, but it lags product value, and it can rise on multi-year contracts while product engagement dies.

Leadership then chooses three inputs.

• Activated workspaces: new workspaces that complete a first review within 14 days of being created.
• Review completion rate: the share of scheduled reviews that are completed on time.
• Trusted data share: the share of reviews where no critical data-quality warning fired, which ties product value to data quality honestly.

The safety metrics at company level are logo churn (the share of customer companies that leave), the number of severity-1 incidents (the most serious outages), and the sales discount rate, so that growth does not buy fake adoption.

Team scorecards then attach to these inputs without cloning the north star onto every desk.

Notice what is missing from the company “winning” slide: every team’s backlog size, every individual’s activity count, and vanity signups. Those can exist in tools, but they are not the shared scoreboard.

A sample weekly narrative might look like the plain-text status note below, which your product manager could paste into Slack.

NORTH STAR (trailing 7d)
weekly_active_decision_workspaces: 1,842  (WoW +2.1%)

INPUTS
activated_workspaces_14d: 96   (target 110)  <- miss
review_completion_rate: 0.74   (target 0.78)
trusted_data_share: 0.91       (target 0.90) <- ok

GUARDRAILS
logo_churn_90d: 1.8% (watch)
sev1_incidents_7d: 0
avg_discount_rate: 12% (cap 15%)

STORY
Activation lag is concentrated in self-serve SMB.
CS-led first review still hits target.
Action: ship checklist empty-state; CS pilot for mid-tier.

That is a stack in use: a few numbers, clear ownership, a story, and a next action. A later post will turn this into a meeting that does not waste everyone’s time. For now, notice the design. The north star is not alone, and the team cards are not a junk drawer.

How to choose the right altitude

Managers often fight about altitude. Should the company watch weekly active users or net revenue retention, which measures how much revenue you keep from existing customers? Should a small team watch button clicks or activated accounts? Use these altitude questions to decide.

• Who can change it this quarter? If nobody in the room can move it, it is background context, not a team target.
• What decision changes if it moves 10%? If no decision changes, it is trivia.
• Does it still mean the same thing next quarter? Definitions that change every month are not north stars.
• Is it a stand-in or the thing itself? Stand-ins are fine if you label them. Unlabeled stand-ins become lies.

Analysts can help by refusing to “just add the metric” without a one-line statement of the decision it supports. That is the same discipline as problem framing in the foundations series: data without a decision is expensive decoration.

Common mistakes

• Treating the north star as a brand slogan. It has a pretty name, a fuzzy formula, and three warehouses that disagree. Fix the spec first.
• Copy-paste alignment across teams. Every team reports the same company metric and none of the levers, which feels aligned but changes nothing.
• A scorecard that is really a data lake screen. If the weekly card needs a scroll bar, you built a catalog, not a scorecard.
• Ignoring money and risk entirely. Product north stars can coexist with revenue and risk metrics. Pretending finance is optional is how “great product, dead company” stories get written.
• No safety metrics at all. One metric with a bonus attached and no “do not break” list is an invitation to the failure modes covered in the next post.
• Changing the star every single quarter. Inputs can evolve, but the crown metric should move rarely, and only with a written reason.
• Hiding data quality from the stack. If data quality is not on the stack when the product depends on trustworthy numbers, you are measuring theater. Tie data-quality promises into the inputs, the way Northwind did.

Quick recap

• A north star focuses shared attention on customer value, but it is not the only number a company needs.
• Team scorecards should contribute to the inputs, protect the safety metrics, and keep a few work metrics local.
• One metric is too few when trade-offs, risk, and time horizons matter, and too many metrics exhaust attention and hide conflict.
• Design a stack of crown, inputs, team cards, and diagnostics, then draw the tree and write a spec for what you keep.
• Alignment is earned when local wins move the shared star without burning the business down.

The next post in the series covers how people break metrics on purpose and by accident, and how to design for that reality.

How to practice this week

• Inventory: list every metric that appeared in your last two executive or team reviews, and count them honestly.
• Label: mark each one as a north star candidate, an input, a safety metric, a work metric, or a diagnostic. Most will turn out to be diagnostics or work metrics.
• Draft a stack: write one crown metric, three to five inputs, the safety metrics, and one team card for your own team. Use the spec sheet template from the earlier post for the crown and each input.
• Draw the tree: on a whiteboard, connect team metrics to inputs with arrows. Delete any metric that cannot earn an arrow or a clear “peer board metric” label.
• Pressure-test: ask, “How could we hit every local target while the north star stays flat?” Write down the loopholes, because those loopholes become safety metrics or definition fixes.
• Read next: the next post covers gaming and Goodhart’s law, since a clean stack with bad incentives still fails. For charting the stack without noise, revisit the data visualization series. For building the tables behind the inputs in code, the Python for analytics path still helps.

Series notes

This is Part 4 of Metrics that matter. Previous: the metric spec sheet. Next posts stay on portfolio design.

Sources

Research and further reading used for this article:

• Amplitude, About the North Star Framework
• Amplitude, North Star Playbook (resource hub)
• Amplitude, Every product needs a North Star metric
• Amplitude, Introducing the North Star Playbook
• Reforge, Don’t Let Your North Star Metric Deceive You
• Analytics Made Simple, Learn hub
• Analytics Made Simple, Analytics foundations
• Analytics Made Simple, Data quality for people who ship numbers
• Analytics Made Simple, Charts that make sense (data-viz)
• Analytics Made Simple, Python for analytics

Merch on Etsy

Open store →

Standard Deviation White Ceramic Mug View on Etsy → Mean Squared Error Shirt View on Etsy → Git Version Control Shirt View on Etsy → Naive Bayes T-Shirt View on Etsy →