Books for software engineers and managers

Outcomes Over Output

Why Customer Behavior is the Key Metric for Business  Success

by Joshua Seiden

Categories:
CTO,
Engineering Manager,
Product Manager,
Designer,
Startup Founder

Product roadmaps should centered around building as little as  possible

Product roadmaps often present as a time-based list of feature deliveries. We’ll build A by X, then B by Y, then C by Z, …, on and on we go.

More advanced companies call them solutions. You might even have a Solutions Roadmap. These companies at least orient around the problem, recognizing the difference between a feature and a solution.

Features are outputs, solutions have outcomes.

After understanding this difference, the next step is to embrace the goal of building as little as possible to solve the problem at hand. Intuitively, this makes sense. You’d obviously rather invest $1M solving a problem than $5M.

But we’re product managers, designers, and engineers. We produce. So intuition be damned, we’re going to ideate, design, and build some amazing stuff.

Once we realize the goal of building as little as possible, we can orient our planning process around building less. To my mind, this aligns well with the Build-Measure-Learn model presented in The Lean Startup.

Outcomes are behaviors, measurable and  observable

Engineering managers and product managers pride ourselves on delivery. Did the thing get built on time, on budget, on spec? That’s how we judge our own performance and also how our managers typically judge us.

Instead, we should be measuring ourselves against user and customer behavior changes. Email open rates, user interactions, account creations, and the like.

Orienting a team of producers around outcomes is difficult. Equally difficult is retraining yourself to be outcomes focused.

Present problems, not feature  requests

When feature requests come in from users, there isn’t much we can do about it. Users will be users.

But from internal staff (notably Support), I recommend shifting conversations about features to conversations about problems. I helped facilitate this change a few years ago within my organization and have seen these benefits:

Company-wide, we are orienting around solutions, not features. We can ask what the desired outcomes are, not just the desired outputs.

  1. Support doesn’t feel on the hook for solving the problem
  2. Designers and engineers don’t feel obliged to reject an idea that won’t work for various UX or technical reasons
  3. Product managers can think more conceptually and tie together previously unconnected ideas
Outcomes Over Output

How strongly do I recommend Outcomes Over Output?
8 / 10

You can read Outcomes Over Output in an hour or two. I read it waiting on my car’s oil change.

I particularly recommend this book for anyone (and their manager!) who feels stuck in a feature-building rat race.