Josh Seiden - Outcomes Over Output: Why customer behavior is the key metric for business success

In 2006, I was working on Wall Street for a brokerage that served the the largest institutional money managers in the world. Our system allowed their traders to buy and sell stocks on a massive scale; millions of shares of stock flowed through our system each day. Traders used our simple but powerful trading app to place their trades, and almost everything was perfect. There was one problem though: our business was built on a single type of trade. Although we were the best place in the world to make that kind of trade, we knew that if we were going to survive, we would need to diversify, to offer other trading styles to our customers.

Our founder and CEO, a visionary who had started two successful companies before starting this one, was confident he had the answer: replace our trading application with a new appone that would support other trading styles. This new app would diversify the services we offered to traders, and protect the future of our business.

So the product team got to work: we designed and started building an ambitious new trading app. When it was done, it would be unparalleled in terms of look, feel, and function. But two years later, we still hadnt shipped anything. Leadership shut the program down. Despite the fantastic technical and design talent working diligently, the program had been a failure.

What went wrong? We had just spent two years making stuff. And we picked the wrong stuff to make. Sure, the design tested well and the prototypes looked good, but rest assured, it was the wrong stuff. It was too hard to make, there was no customer demand for it, and we could have solved the problem by making other, simpler things.

All that stuff that looked-good-in-planning led us to work for more than two years without delivering anything. We delivered no new capabilities to our customers, and we delivered no value to our business. Said another way, our team generated no outcomes.

If youve picked up this book, youre interested in this notion of outcomes, so lets start by defining the word in our context: an outcome is a change in human behavior that drives business results. Outcomes have nothing to do with making stuffthough they sometimes are created by making the right stuff. Instead, outcomes are the changes in customer, user, employee behavior that lead to good things for your company, your organization, or whomever is the focus of your work.

Looking back on my team on Wall Street, its clear in retrospect that we could have managed the process and structured our project differently. We could have identified the outcomes that the business was seeking and found a much faster way to start delivering them. We could have done that by focusing on the outcomes that our customersthe traderswere seeking, and finding a way to deliver those sooner.

If this sounds to you like Im saying we should have been more agile, youre right. Thats what Im saying. But heres the funny thing: that team was an agile team. We had standups and stories and even an agile coach. We thought we were doing it right. But we were focused on the wrong thing: we were focused on what we were makingour outputwhich would be a big, beautiful app. We were building it piece by piece, and when it was ready, it would be beautiful, and then we would ship it to customers.

We should have been focused on something else: creating outcomes by changing customer behavior.

Getting to Done: The Problem with Features

Its common to get caught in this kind of confusionmistaking making stuff for making progress, and mistaking shipping features for being done. Its a legacy of a time when we mostly made physical goods, and making stuff well was the primary challenge.

In the old days of engineering, setting project goals wasnt that hard. If youre building a bridge, for example, you know youre done when the bridge is built and people are crossing it safely. If youre making cars, youre done when they roll off the assembly line. But when youre making software products, done is less obvious. When is Microsoft Word done? When is Google done? Or Facebook? In reality, software systems are never done. We just decide to stop working on them, or work on one part of them over another. (And it turns out that lots of our work is like thiswhen is customer service done, for example?)

Even if our new software-based products are never done, why does that matter? Why not just make an endless list of features and ask our teams to work on that listforever? In fact, a lot of contemporary project management turns out to work exactly this way. The problem with this approach is that features can be finished and delivered and work perfectly but stlll not deliver any value. Think about all those website pop ups that try to get you to subscribe to a companys mailing list. Do they work? Technically, they function as specified. But do they deliver value? Turns out that on the whole, they dontpeople simply get annoyed and just abandon the web site instead.

Our world is full of features like this that work as specified and yet deliver no valueor worse, create problems we never intended. If youve ever used a microwave oven youve experienced this problem: how many of those buttons do you use in real life?

So if features dont automatically create value, then it follows that we shouldnt use them as the center of our planning process. In fact, we want to use a planning process that makes it possible to make as little stuff as possible and still achieve the outcome we seek. How do we do that? That is the question this book answers: we can instead use the idea of outcomes. Outcomes, or the human behaviors that drive business results, are what happen when you deliver the right features.Ideally, they happen when youve delivered as few features as possible. To get started, lets spend a moment to define some of our terms.

Project Goals: Output, Outcome, Impact

Imagine that you work for a charitable organization and youve been asked to build a well in a small village that lacks modern plumbing. Youve been given funding by a foundation that wants to increase the standard of living in this village. They have observed that villagers spend a large amount of time every day walking to the river to carry water. The foundation believes that if the villagers had a well in the center of the village, they wouldnt have to carry water such long distances anymore, and they could use their time for other activitiesones that would allow them to improve their standard of living.