The move from measuring output to outcomes was the right one. But we stopped one level too soon.
Within the last decade, product teams got religion about outcomes. Stop counting features shipped, the thinking went, and start counting what those features produced. Teams got focused on retention, NPS, revenue per account, the metrics that actually move when a business is doing well. Teams that used to report "we launched fourteen things this quarter" started reporting "we moved activation by six points," and that was, without question, progress. A team that can't tell you what its work produced can't tell you whether the work was worth doing.
But look closely at that list: retention, NPS, revenue per account, activation. Every one of them is a business outcome. They tell you how your company is doing. They don't tell you what happened in your customer's life. A hair salon's booking software can post excellent retention numbers for years while doing nothing in particular to help the practice fill its afternoon schedule, and the dashboard will look fine the entire time. Retention is downstream of value delivered to the customer, sometimes by a year or more. By the time it moves, you're reading a rear-view mirror.
Chapter six of Product at a Distance spends most of its pages closing a different gap: a level underneath the outcomes conversation that almost nobody has built. The outcomes your product created for the person using it, measured directly. Not inferred months later from what your business did as a result.
Value capture and value creation aren't the same spectrum
Start with a distinction that sounds obvious once you say it but often gets ignored in practice. Every metric your BI tool can generate sits somewhere on a spectrum between two poles.
Value capture metrics measure value that has already accrued. ARR, churn, MAU, NPS, conversion rate: these are trailing indicators. They tell a product team how things went last month, and they're essential for understanding whether the business is healthy. What they aren't is directly actionable in the moment. A product manager staring at a churn number knows something is wrong. The number itself gives almost no clue about what to build next.
Value creation metrics measure the value being generated right now, forward-looking, tied directly to something the product team can influence this sprint. This is where customer benefit metrics, or CBMs, live, and it's the layer most companies never build. Their dashboards are full of value capture. They have almost nothing that tells them, in real time, whether this week's build effort will actually help the person who has to use the product.
Neither kind of metric is wrong. A company that ignores value capture metrics doesn't know if it's solvent. A company that only has value capture metrics doesn't know why. Of the two gaps, the missing value creation layer, the CBM layer, is the bigger opportunity (gap) on most product teams' dashboards right now.
What a customer benefit metric actually is
I first heard the term from Scott Cook, Intuit's founder, who was relentless about getting business units to adopt it. It stuck with me enough that when I ran product at Demandforce, Intuit's front-office suite for small businesses, we restructured how the whole team prioritized around it.
A customer benefit is the improvement in a customer's life, in what matters most to them, from using your product. A customer benefit metric measures the size of that improvement. That's the whole definition, and it's harder to apply than it sounds, because almost every metric you already track fails the test.
Take a typical e-commerce dashboard: daily active users, net margin, conversion rate, NPS, customer retention. Run each one through the filter and watch how few survive. DAU tells you people showed up, not that anything good happened once they did. Net margin is a real benefit, just not to the shopper. NPS asks people to rate a relationship, which tells you almost nothing about what to fix. Conversely, an ecommerce metric that qualifies as a CBM is dollars saved per order relative to competitors, because that's a benefit the customer actually experiences and can name for themselves. (Unless this is a luxury good site, in which case dollars saved is generally not a customer benefit.)
This is the discipline the exercise demands. Not benefits to your company, your investors, or your own sense of product craft. Benefits to the customer, defined in terms they'd recognize, measured in a way that moves before the trailing indicators do.
Finding your CBMs
The best way to find your CBMs is a workshop, not a solo exercise at someone's desk. Getting product, sales, and marketing in the same room draws the brainstorming from more than one team's view of the customer, and it builds the shared conviction you'll need later, when a CBM says to cut something a stakeholder is attached to. A memo can propose a metric. A workshop gets the room to arrive at it together, which is the only way it survives contact with the next roadmap review.
Start by establishing your value propositions: at most, 2-3 value props per product line. If they already exist - great, bring them into the CBM workshop. If they don't, work with marketing to establish them prior to the workshop (it's way too much to attempt both in the same session.) Once the value props are locked, the workshop itself runs in four stages.
First, get the room to genuinely internalize the difference between a CBM and every other kind of metric they've used before. This part is worth some time investment; the instinct to reach for a familiar business metric is strong and persistent, and it takes deliberate effort to override.
Second, brainstorm the specific benefit statements tied to each value proposition, then force a synthesis down to the two or three that actually matter.
Third, and this is the hard part, figure out how to measure each benefit. Some are obvious: a delivery promise becomes "percent of orders that arrive by the promised date." Others take real work, especially anything involving a service's judgment rather than its speed.
Fourth, take your existing roadmap and test every strategic theme against the CBMs you just defined. Which themes clearly serve a customer benefit? Which ones don't map to anything at all?
That last step is uncomfortable by design. You will likely find many roadmap themes with no CBM attached, and that's just evidence that the exercise is working as intended. Some of those themes will still get built, because there are legitimate reasons beyond direct customer benefit to build things. But now you know exactly how much of your roadmap capacity you're spending on them, instead of assuming everything on the roadmap is customer-driven when a fair amount of it plainly isn't.
If you want to run this with a distributed team, Product at a Distance includes a Miro-based workshop template built for exactly this: benefit statements on one side, a facilitation flow that gets a remote group to the same synthesis an in-person room would reach. It's one of the free tools at productleap.co/book/tools, alongside the other templates from the book.
Putting CBMs to work
Once you have CBMs, the temptation is to treat them as one more thing the product team tracks. Resist! CBMs are meant to run through three parts of the company that rarely share a vocabulary.
Inside product development, they become the standing question behind every prioritization call. Not "does this feature look good," but "which CBM will this move, and by how much." During the sales process, they replace vague value claims with something closer to proof. Instead of telling a prospective SMB customer that your software will help their business, you point to a specific number, new appointments booked per month, percent of overdue patients recontacted, and let them run the math against their own operation. And with existing customers, CBMs give you a way to make the case for deeper engagement in concrete terms, rather than an account manager's hunch about who's ready for an upsell conversation.
What ties all three together is that a shared set of CBMs is what lets a distributed team make good decisions without a chain of approvals. If everyone on a remote team agrees on what customer benefit they're accountable for and how it's measured, they can make roadmap and backlog calls independently and still end up rowing in the same direction. The payoff goes beyond a more customer-oriented metric on a dashboard; it creates a different way of running the company.
Seeing it all on one page
When I work with clients, I always ask to see their product strategy. Sometimes I don't get much in response. More often, I get too much: insights from a research project over here, a strategy deck over there, a couple different roadmap artifacts. None of it truly fitting together.
So one day I challenged myself: could I come up with a single page, or even more constrained: a single slide - that would concisely encapsulate a company's product strategy?
I locked myself in a room with a large whiteboard and came up with what I call the "Product-on-a-Page" view. It's the single artifact that reconciles your value propositions, the customer benefits underneath them, the metrics you're using to measure those benefits, and the roadmap themes that are supposed to be delivering them. Below is that view for an SMB front-office platform, the kind of software that helps a dental office, auto shop, or medical practice manage marketing and appointments. You can find more examples in chapter eight of my book
Notice the bottom row. There's a roadmap theme, rebuilding the admin settings panel, that doesn't map to any CBM at all. That's the honest output of the exercise: a legitimate piece of work, clearly not customer-facing, called out and capped rather than smuggled onto the roadmap next to the items that actually move the benefits customers came for.
CBMs are a specific type of outcome that most teams never measure. Overarching outcomes tell you whether the business did well. CBMs tell you whether the customer's life got better, in a way you can point to this week, well before the lagging outcomes catch up. Fix the CBM and the business outcomes tend to follow. Chase the business outcomes directly, and most of what you're doing is watching the past.