Goals & Success Metrics

A goal is the outcome you’re trying to move. A metric is the number that tells you whether you moved it. Get these two right and the whole team pulls in one direction. Get them wrong and everyone works hard on things that don’t matter, or worse, games a number while the product gets worse.

Doing this well takes honesty about what you’re actually trying to achieve and skepticism about whether your number really measures it. This doc gives you both.

Second of three. Its input is an input metric from the North Star; its output is a goal a team owns. How to write the metric itself well is Setting Good Metrics.

Start With the Goal, Not the Metric#

What’s expected: Before you pick any number, you can say in one sentence what outcome you’re trying to create and why it matters to the business and the user.

A goal is a direction: “more shoppers complete a purchase in our store.” A metric is the measurement: “completed orders per week.” People rush to the metric because a number feels concrete. But a metric with no goal behind it measures motion, not progress. Always name the goal first, then find the number that tracks it.

Three rules for a good goal:

• It’s rooted in what the product is actually for. The Storefront’s goal is about orders happening, not about time-on-page. If your goal could belong to any product, it’s too generic to guide anything.
• The team can directly affect it. “Grow online retail” is not a goal your store controls, too many other things move it. “Lift the share of full carts that become paid orders” is something your work can actually push. Pick goals you can move.
• It resists gaming. Ask, before you commit: how would a lazy or cynical version of this team hit this number without helping anyone? If there’s an easy answer, the goal is weak. More on this below.

Types of Goals: Growth, Engagement, Revenue#

Most product goals fall into one of a few buckets. Knowing which bucket you’re in keeps the team honest about what it’s chasing. A common shorthand is GERM, four kinds of outcome a product can pursue:

Pick the one that fits the product’s stage. A brand-new store’s goal is Growth: get first-time shoppers to discover it and make a first purchase (activation, a new user reaching their first real win with the product). An established store like the Storefront, with steady traffic but flat orders, is really chasing conversion and Retention: turn the visitors it already has into buyers, and buyers into repeat buyers. The bucket tells you which metrics are even worth considering.

From Goal to Metric#

What’s expected: You can get from an abstract goal to a specific, trackable number by way of the actions users actually take.

The bridge from a goal to a metric is user actions. You can’t measure “buying is effortless” directly. But you can list the concrete things a user does on the way to that outcome, then measure the ones that matter.

1. List the actions. Walk the journey and write down what users actually do: view a product, add to cart, start checkout, enter payment, place the order. Listing them keeps you honest, you can only measure actions that actually happen.
2. Pick the actions that reflect the goal. Not all actions matter equally. For an orders goal, “placed an order” matters far more than “viewed a page.” Choose the two or three actions that, if they went up, would mean the goal is genuinely being met.
3. Turn the action into a metric. “Placed an order” becomes “completed orders per week,” and the step before it becomes “checkout completion rate.” Now they’re numbers you can watch.

The same three moves work on any product. For a subscription app chasing retention: the actions are open, use a core feature, renew; the action that reflects the goal is “renewed”; the metric is “renewals per active subscriber per month.” Goal, to action, to number, every time.

A few distinctions that make a metric sharper, each with a plain example:

• Direct vs. proxy. A direct metric measures the thing itself (“completed orders”). A proxy stands in for something you can’t measure directly (“checkouts started,” used as a proxy for orders before payment confirms). Prefer direct; use proxies knowingly, and remember they can drift from the real thing.
• Magnitude vs. ratio. A magnitude is a raw count (“6,000 carts this week”). A ratio puts it in context (“80% of shoppers who reach checkout complete it”). Raw counts flatter you; ratios tell the truth. A rising cart count with a falling completion rate is a store getting worse while the headline number goes up.
• Per-user, per-time. “Orders” is ambiguous. “Completed orders per week” is comparable across weeks; “orders per session” (the conversion rate) is comparable across traffic levels. Almost every good metric is normalized this way.

Gaming: The Trap#

What’s expected: For every metric you propose, you’ve asked how it could be inflated without helping a user, and you’ve rejected it if the answer is easy.

This is the most important skill in the doc, and the one that separates a metric that guides a team from one that quietly rots it.

There are two ways a metric fails this. One is vanity, a number that only ever rises and tells you nothing you would act on; Setting Good Metrics covers how to spot and rewrite those.

The other is gaming, and it is worse, because a gameable metric actively steers the team toward bad behaviour rather than merely failing to steer it. The test is one question, asked of every metric before you commit:

How would a cynical version of this team hit this number without helping a single user?

• Measure “time on page” and the team makes screens confusing so people stay longer.
• Measure “add to cart” and the team nudges shoppers into carting things they never intend to buy.
• Measure “sessions” and the team celebrates a traffic spike while orders stay flat.

If the question has an easy answer, the metric is dangerous. The fix is usually to pair it or normalize it: measure completed orders per session (the conversion rate), not raw sessions; measure paid orders, not carts created. A good metric is one a cynic can’t hit without actually doing the job.

Guardrails: The Metric That Must Not Move#

What’s expected: Alongside the metric you’re trying to push up, you’ve named the ones that must not get worse while you do it.

Optimizing one number in isolation usually breaks another. Push checkout completion up by stripping out the review-and-confirm step, and you might raise wrong-address orders and returns. A guardrail metric is a number you watch to make sure your win isn’t secretly a loss somewhere else. State it up front: “we’re driving checkout completion up, and the return rate must not rise.” Guardrails are how you keep a local win from becoming a global loss. You will also see them called counterbalance metrics; same idea, and the useful move is to pick the pair at the same moment you pick the metric, not after a report looks wrong.

Common pairs:

When a Metric Moves the Wrong Way#

What’s expected: When a number drops, you can diagnose it methodically instead of guessing.

Numbers move and you won’t always know why. Don’t guess. Split the possibilities and work through them:

• Is it us or the world? Internal (we shipped a change, something broke, an experiment is running) vs. external (a competitor launched, it’s a seasonal dip, the market shifted).
• Where exactly? Slice by time (sudden drop or slow slide?), by region, by platform or device, by user segment. A metric that only dropped on mobile, only last Tuesday, is a very different problem from one drifting down everywhere for a month.
• Real or measurement? Sometimes the product is fine and the tracking broke. Rule that out before you act.

The discipline is the same as debugging with data: the number is a starting point for a question, never the answer by itself.

The Standard#

A world-class product person can be handed any product and, within an afternoon, propose a goal rooted in what the product is for, a metric that tracks it, a guardrail that protects it, and a clear answer to “how could this be gamed.” If you can do that, you can steer a team. If you can only produce a number because a number was asked for, you can’t.

Next: Constraints & Cost