Output vs Outcome: How to Tell Which One Is on Your Roadmap

One of the product managers I coach works at a small software company, and in March he brought me a question that sounded like a prioritization problem. His team builds new features to get the next client onboarded, and one they had already shipped was not easy to use. He knew it needed another pass. But the roadmap kept moving on to the next new feature for the next client. He could not figure out how to argue for going back to rework something the team had built six months ago.

That is the output vs outcome problem sitting inside one roadmap. An output is the thing your team ships, and an outcome is what changes for your customer, and then for your company, because you shipped it. On a roadmap built from outputs, his feature was finished the day it shipped, and there is no place on the page to say it has not worked yet.

"Outcomes over output" is a cliché phrase by now (I say so in my own class), and you have probably nodded at it in a meeting. Nodding does not help much. You still have to figure out which of the two is sitting on your roadmap. Most product managers I work with stop at the feature and a count of how many people used it.

Output vs outcome on a roadmap and in a status update

I told him that his question is usually a symptom of having a feature-based roadmap instead of an outcome-based roadmap. If you define success as completing something and moving on, your roadmap works like Tetris. A finished row disappears from the board the moment you complete it, and your accomplishments disappear with it. It also gets hard to go back for a second version of anything, because the measure of success was shipping, and you already shipped.

So a simple way to tell an output from an outcome is to ask what would make the item done. An output is done when it ships, on time and to spec, and shipping is what the team celebrates. An outcome is done when a number you named in advance has moved. So you ship, you check whether it worked, and you keep iterating until the problem is solved. There is one question you can only ask about an outcome. Have we done enough? If you are shipping features and moving on to the next one, you never get to ask it.

A status update works the same way. "We released the feature on schedule and under budget" reports an output. The outcome version says what the release was supposed to change, what the measurement shows so far, and what you will try next if the number has not moved.

Be careful with the words that sound like outcomes, though. Adoption tells you that people tried something, but not whether they got anything out of it (I wrote about why in Adoption Should Never Be Your North Star Metric). "Easy to use" and "intuitive" describe the design of a solution, and they say nothing about the size of the problem. Intuitive is not a metric. Even customer satisfaction is an influencer that leads to a business outcome and not the outcome itself, because the idea is that satisfied customers spend more money with us. Until you can say by how much, you are reporting a hope.

Asking "so what" until you reach the money

Near the end of the call I gave him one more idea, and it is the one action in this letter that turns an output into an outcome. Every time you think about a user-level feature or task, add a "so what?" to it. Then ask it again. "So what?" is the question that takes you up the ladder. He had taken my course, so he knew which ladder I meant.

The item he wanted on the roadmap was to make that feature easier to use. So what if it is difficult to use? What does that create? He had an answer right away (he is one of the rare product managers who talks to customers all the time). Clients adopt it more slowly, he said, and that means his company gets paid less. I asked what the problem is if they never fully adopt it. Then the product is not sticky, and they drop it.

In less than two minutes, "make it easier to use" had become a statement about which clients his company keeps. Those clients bought because of a promise the company made to the market. If the product is too difficult to use, the company is not living up to that promise, and that leads to churn. Now the item reads like a question an owner can answer. Do we want to keep these clients and earn their referrals? Then we need to improve this experience, and here is why.

The answers went past two places where people usually stop. The first is "our clients will be happier," which is only the customer's side. A roadmap that stops there cannot make a business case. That is how teams end up prioritizing by vote counts in an idea portal, where customers want it and nobody can say what the company gets. The second is a number that is only ours, like usage or support cost, which leaves you with nothing to promise the customer. Our way of growing our business is by helping our customers grow theirs, so the answers have to say what the customer gets and then run all the way to what we get paid.

That is the product metrics ladder (one of my product strategy frameworks) that I walk through in Are You a PM or a Feature Factory Worker?, and "so what?" is how you climb it.

Ask yourself and your team first. DO NOT hand the question to the stakeholder as a form to fill out before their idea is allowed on your backlog. That puts the burden of discovery back on the person who asked. From their standpoint, you just put up a blocker and gave them homework.

Sometimes the answers do not climb. Say the item is a redesign that helps a user find something twenty seconds faster. If those twenty seconds are sending buyers to a competitor, the impact is huge. If the user loses twenty seconds and still buys, then the problem is not worth solving right now. You can tell the person who asked "not yet," and your reason is about the customer.

The roadmap line, rewritten as an outcome

Once you have the answers, the line on the roadmap changes. I told him to put the objective and the measurement of success on the roadmap, and to let the feature ideas fall underneath it. You keep working through the ideas until you hit the metric. If you hit it earlier than you expected, great, you move on to the next objective, and if you don't, you keep iterating. He said it back to me more plainly than I had said it to him: "We shouldn't move on from the problem until we solved it." He was right.

I ran a roadmap this way on a regulatory research product for pharma and life sciences companies. Their compliance teams wanted to understand new regulations around the world without paying expensive consultants to interpret them. That was the outcome they wanted, with or without our product. So every feature we built had a goal metric tied to customer value, like the percent of their questions that got a satisfactory answer and how fast they got it. None were adoption or engagement. I measured how much the product helped the customer because I was going to relate that back to my own business later.

What to do this week

Pick the top item on your roadmap, or the last status update you sent, and ask what would make it done. If the answer is that it ships, you are looking at an output. Then ask "so what?" and write each answer underneath the one before it. Keep going until one answer says what your customer gets and the next one says how your company gets paid for it.

You will probably stall on the second or third answer the first time you try this. That is where you find out you never knew why the item was on the roadmap. That's ok. Take your best guess to the person who asked for the item, say what you think it is for, and ask, "Do I have that right?" Then put the objective and its measurement on the roadmap, above the feature.

A roadmap of outputs clears itself like a Tetris board, so by your year-end review there is nothing left to point to, but the numbers on an outcome roadmap stay where you put them. Those numbers are how you answer the question I ask in the first session of my course: is the company better off because of you, and can you prove it?

-Brennan

Want a coach to climb the ladder with you on YOUR roadmap? Join the next cohort of The Influential PM.