Business vs. Product Outcomes

Before we sort a single number, let's get two words straight, because most teams use them interchangeably and that's exactly where the trouble starts.

A KPI, a Key Performance Indicator, is a measurable value that shows you how effective you are at achieving a business objective, and a metric tracks the status of a specific business process. The whole distinction sits right there. Revenue growth against this year's objective is a KPI, and the number of features your team shipped last month is a metric. KPIs tell you whether you're hitting the objective, and metrics tell you how the machinery is running.

Mix the two up and you get a team reporting busy machinery as if it were a winning business. Without the distinction you're guessing at what's working, and worse than that, you're guessing at what's not. A team that's guessing will always reach for the number that makes the quarter look best, which is how a team ends up celebrating a record month of features shipped while sales stay flat.

The three piles

I put every number that claims to tell you you're winning into one of three piles.

Business outcomes. The money. Revenue, margin, customer churn (the customers who leave), and the cost to acquire a customer. These are the numbers the company keeps score in, and they're the ones that decide whether the mission stays funded.

Product outcomes. The change in customer behavior you believe drives the money. Activation is the share of new users who reach the product's first real moment of value, adoption is how many of them make it part of their routine, and retention is how many of them are still using it months later. You can move these directly, and you can only move the business numbers through them.

Vanity. The counts that go up and feel like winning while proving nothing at all. Eric Ries called out the classic list years ago in his Lean Startup work, and it runs hits, page views, followers, likes, and downloads.

The business-versus-product-outcome split isn't my invention. Josh Seiden and Melissa Perri have each built whole books on it, and what follows is the version I run.

Notice what's missing from the piles, which is the metrics. Velocity, cycle time, all the numbers that tell you how fast the machinery is turning. Those are a fourth kind of number with an honest job to do, diagnosing your process, and they get the next page all to themselves. They just never get to claim you're winning.

You've already watched a team confuse the piles. The app from Part 01, the one with two million downloads and twenty sales, is all three piles sitting inside a single story. Downloads were the vanity pile, sales were the business outcome, and the product outcome nobody was watching was whether a download ever turned into a buyer. The whole failure sat in the one pile nobody was watching.

So the job on this page is simple to say and hard to actually do. For every number you measure, know which pile it's in, and never report one pile as if it were another.

A number means nothing until you know if it's good

One of the biggest tech companies I've worked for drills a lot of things into your brain, and one of them has stuck with me ever since. One number doesn't tell you the full story. You don't just need to know the NUMBER, you need to know whether the number is GOOD.

Ex: "It costs us $60 to acquire a customer." That number is awful for a $1 product and it's fantastic for a car purchase, and nothing about the $60 by itself tells you which of those two situations you're in.

"We grew 30% year over year!" Good news, right up until you learn that your closest competitor, working off a bigger base than yours, grew 40% over the same stretch.

"We cut costs by 20%!" It took 15 people six months of work to get there, and the objective that year was growth rather than cost.

"We only grew revenue 2%." Every other line of business lost 30% or more, so your 2% might quietly be the best story in the whole building.

Same numbers, opposite verdicts, and the context is doing all of the work. So share the number, but remember that one number on its own is rarely enough. You have to benchmark it against the market, against your competitors, against your own baseline, and against the objective the number was supposed to serve in the first place.

That last benchmark is the one that bites. Cutting costs by 20% is a real achievement and the wrong one if the objective was growth. A great number pointed at the wrong objective isn't a KPI at all. It's a distraction with a chart.

A KPI you won't act on is a vanity metric in disguise

There's a quieter failure than celebrating the wrong number, and I've lived through it twice.

One of the teams I built a few years back grew to about 20 strong in our region, and about a year after I left, its turnover rate, the share of its people who left, sat steady at 40%. At another company, the product team I was on ran a turnover rate of 41%. For reference, turnover above 5 to 8 percent in most corporate settings is already considered high.

Both companies measured their turnover. Neither one of them did anything about it.

That's the part that should bother you, because neither team was flying blind. The number was right there, every single quarter, telling them they were losing nearly half of their people. And turnover isn't a soft HR number that lives off in a corner somewhere. People walking out the door is money walking out the door, which makes it a business outcome, and it's one of the most valuable KPIs that most companies track and then do absolutely nothing with. If yours is growing, stop making excuses and go do something about it.

A number only becomes a KPI when a decision is attached to it. You ran this test once already, back in Part 03, when you checked whether your hypothesis metrics would actually drive a decision, and the same test applies to your whole dashboard. If the honest answer is "we just look at it," then it doesn't matter how serious the number looks on the slide. You've built yourself a vanity metric with extra steps.

Outcomes, not activities

The piece of feedback I remember most from my whole career came from a Chief Technology Officer who was reviewing my yearly plan.

That plan was full of activities. Partnering with other teams, all of it real work. His reaction was that this is what he expected me to be doing anyway, and what he wanted was something different. What are the outcomes we're going to get over the next year from the activities you're doing?

He was right, and it stung. Partnering with other teams isn't an achievement, it's the job description. The achievement is what the partnership produces, the revenue retained, the churn avoided, the thing shipped that customers actually use.

It is a lot easier to deliver output than it is to deliver outcomes, and that's the entire reason plans fill up with activities. Activities are guaranteed because you control them, and outcomes are not guaranteed because the customer and the market both get a vote. Which is exactly why outcomes are the only thing worth putting your name against.

So run the CTO's test on your own plan. For every line that names an activity, ask what outcome that activity is supposed to buy, and if you can't answer that, you haven't written a plan. You've written a to-do list.

Picking yours: baseline, target, decision

Which numbers make your list? Start with the business objective the number serves and the stage you're at, because a startup's list and an enterprise's list are not going to be the same list. Then comes the question almost everyone skips, which is whether you need to measure product, process, or people. Maybe all three. Product is the piles you just sorted, process is the next page, and people is where the skipping tends to happen, because most businesses only ever track the financial numbers, and the financials only give you a small portion of the story.

That's why I group KPIs into four buckets. Financial (margin, revenue growth), customer (retention, lifetime value, meaning what a customer is worth to you over the whole relationship), marketing and sales (acquisition cost, conversion, meaning how many prospects become buyers), and employee (turnover, time to hire). The buckets are answering a different question than the piles are. The piles tell you what kind of number you're holding, and the buckets tell you which part of the business that number is watching. One number can sit in both at once, and retention is the easy example, because it's a product outcome by its pile that lives in the customer bucket by the part of the business it watches. You don't need every bucket on every dashboard, but you do need to know which buckets you're blind in.

Then I want every KPI you keep to carry three attachments.

A baseline. Where the number is today. If you don't have one, then building it is your first project, and you saw in Part 03 how long that can take.

A target. Where the number needs to be, benchmarked against the market and against your competitors rather than pulled out of the air.

A decision. What you're going to do differently when the number moves, or when it stubbornly doesn't.

This shape works just about anywhere you point it, even somewhere as unglamorous as recruiting. When I hired, my baseline was nine business days from first contact to offer, because that's where my process actually sat. My target was to hold it there or better, and the market is what set that bar for me, because great candidates have competing offers sitting in front of them. And the decision came pre-attached, because the moment that number slips, you either speed the process up or you lose the hire.

The same shape sits inside my epic template, which is the write-up that frames a large chunk of product work. There's a primary metric, the thing that improves when the work succeeds, and its baseline and its target both get written down before the work ever starts.

One more habit, and this one comes straight out of my own communication template. When you report up, tie the work to a north-star KPI, the one number that the whole effort exists to move, instead of to a pile of raw counts. And remember the lesson from Part 01, that part of picking the number is knowing which number your audience actually values.

OKRs sit on top of KPIs

OKRs, short for Objectives and Key Results, are how KPIs turn into direction. You set an objective for the quarter, and underneath it a handful of key results, each one a KPI you're committing to move. Take retention from 60 to 70 percent, or cut the cost to acquire a customer by 20%. At the end of the quarter you score the key results, learn from whatever moved, and then go set the next quarter's. The argument for why outcome commitments beat a feature roadmap is back in Part 03 if you want to go review it.

One rule here I treat as absolute. If you have OKRs, you must also have KPIs already in place, and in place means already measured, a number you track today with a baseline you trust, before it ever shows up as a key result. Commit to taking retention from 60 to 70 and you had better already know that it sits at 60 right now. If you don't have KPIs in use, you can't monitor the work you're doing, and the OKRs are going to be pointless. An objective without a measurable key result is a wish.

Two more rules I picked up from actually running them. First, you shouldn't hit 100% every single time, because if you're scoring 100% every quarter, you aren't challenging yourself nearly enough. Second, start small. The futurist Jim Carroll's line is "think big, start small, scale fast," and that's your adoption plan sitting right there. One quarter of OKRs, iterate on it the next quarter, then scale it.

And they don't have to wait around for company permission either. One company I worked at didn't use OKRs at all, so I set them up just for my own team and aimed them squarely at learning. Each quarter, everyone carried an objective around something they wanted to learn, with a half day every Friday to work toward it.

You might be thinking that this breaks the rule I just called absolute, because "learn something new" isn't a KPI on anyone's dashboard. Fair. Learning OKRs are a deliberate exception, and what survives is the part of the rule that actually matters, which is that every key result still has to be checkable, and a decision still hangs on whether it lands.

Say one of your front-end engineers wants to learn React, which is a coding framework. The key result isn't a course finished by the end of the quarter, because that's an activity, and you already know the test for those. The key result is what the course buys you, which is the new skill showing up in the product. If it doesn't show up there, then the decision is sitting right in front of you, and you change how the learning time gets spent. It's also the smallest possible start, which is exactly where Carroll's line (think big, start small, scale fast) tells you to begin.

"But we're not in business to make money"

The results page opened with the line that companies exist to make money, and one of the best pushbacks I've ever gotten on it came at me in public.

I was giving a talk, and a man in the audience, an engineer at a firm that's 100% employee-owned, quoted me what his company's founder had told him when he was fresh out of school. We are not in business to make money. We make money so we can stay in business.

It's a great line, and it's also not a rebuttal. Read it again, because the founder concedes the whole point in the second half of it. Staying in business is the thing that the money buys, and everything that firm exists for, the ownership culture included, dies the day the money stops. Tesla makes the same loop obvious. A mission about a cleaner environment, and not an inch of it moves without money.

So that's the lesson hiding inside the exchange. Your KPIs aren't the opposite of your purpose, they're how you know the purpose is still funded. The business outcomes tell you the company gets to keep existing, and the product outcomes tell you customers are getting the value the mission promised them. Drop either half of that and you're either a charity running out of money or a profitable company that forgot why anyone should care.

The man who pushed back is the proof. In that same conversation, he told me the KPI videos that came with my book had him rethinking whether he was using the right indicators in the right way. Here's a man who believes purpose is the whole reason his firm exists, working to get his measurement right. Measurement didn't shrink his purpose, it's what protects it.

Now sort your own dashboard

Pull up whatever your team reported last month, and sort every number on it into the three piles, business outcome, product outcome, and vanity. The process metrics, meaning anything that measures how the team works rather than what the customer or the business actually got, can sit off to the side for now, because they're the next page's problem.

For each number that's claiming to be a KPI, ask three things. Which business objective does it serve? Where are its baseline and its target? And what decision changes when it moves?

A number that fails the first one might still be a metric, a process number with an honest job, and the next page covers exactly what those are for. A number that fails the second one isn't dead, because building its baseline is your first project. A number that fails the third one is vanity, no matter how official it happens to look, so cut it from the report before it cuts your credibility.

Every KPI you keep should tell a story about the health of your product or your organization. If a number can't tell that story, then stop reporting it.