Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

Tyranny of Outcomes

19 Aug 2023

"Outcomes over outputs."

So often we talk about measuring work by the impact it creates, not whether we did it. A goal of "ship Foo in Q3" isn’t nearly as good as "35 new users are using Foo" or "retention increased 12% after releasing Foo."

This extreme focus on outcomes can have an undesired effect on product teams. The team might stop doing anything that doesn’t directly drive a business metric. They can start choosing only metrics that they know how to move - which tend to be the easy, well-understood problems. For teams with quarterly goals, it can lead to focusing on short-term metrics that can move in a few weeks.

It is tempting to use output goals as a solution for these problems. "Establish a baseline for retention" or "learn why users aren’t adopting new features."

But a better way is to re-frame these outputs as an outcome. An outcome is simply a behavior change in a person. "Increase retention by 12%" is a behavior change in your customer - more of them stick around.

This is a great way to handle goals when you don’t really know yet what the business outcome looks like. It can help teams address long-term, ill-defined problems.

If you want to "learn why users aren’t adopting new features," think about why you don’t already know this. Why is it hard for you to get this answer? Is it because you don’t have product analytics? Then your outcome could be "answer two new questions about product usage each week." If it’s because you’re not talking weekly with customers, then perhaps your goal could be "product teams have spoken to 20 customers." Those are outcomes. They are measuring a behavior change in your team. Before, the world looked one way, but after you made changes, it looks a different way.

If your goal is "ship the new feature in time for the September marketing event" then ask yourself why shipping itself is the goal. Perhaps you’ve had trouble hitting deadlines before and you want to fix that with iterations and continuous delivery. The behavior you want to change is all about how you ship, so frame your goal that way. This might turn into "Demonstrate continuous delivery by shipping 6 releases this quarter that each improve the new feature needed for the September marketing event."

Recently Written

Too Big To Fail (Apr 9): When a company piles resources on a new product idea, it doesn't have room to fail. That keeps it from succeeding.
Go small (Apr 4): The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.
Start with a Belief (Apr 1): You can't use data to build products unless you start with a hypothesis.
Mastery doesn’t come from perfect planning (Dec 21): In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27): Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13): Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17): You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13): A description of how I use OKRs to guide a team, written so I can send to future teams.