Ein sehr kurzes Buch von Joshua Seiden, jedoch mit sehr wichtigen Gedanken. Damit wird vielleicht auch verständlicher, warum der Vergleich Haftung/Sicherheit mit Auto und Software hinkt und untauglich ist. Das sind zwei völlig unterschiedliche Welten! Ähnliche Probleme erwarten uns im Bereich der Künstlichen Intelligenz und den vorhandenen Regulierungsüberlegungen. Wohl ein falsches Werkzeug wenngleich immer „sowohl-als-auch“ gilt. Zum anderen finden sich hier einige Erklärungen, warum immer mehr Menschen unzufrieden sind: Weil es immer seltener um eine spürbare Wertschöpfung und Mehrwert, aber dafür mehr und mehr um Zahlen und Kontrolle geht. Hier ein paar Auszüge daraus:
1. What Are Outcomes?
An outcome is a change in human behavior that drives business results. Outcomes have nothing to do with making stuff — though 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.
We thought we were doing it right. But we were focused on the wrong thing: we were focused on what we were making — our output— which 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 It’s common to get caught in this kind of confusion — mistaking “making stuff” for making progress, and mistaking shipping features for being done. It’s a legacy of a time when we mostly made physical goods, and making stuff well was the primary challenge.
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 this — when is customer service done, for example?)
The problem with this approach is that features can be finished and delivered and “work perfectly” but still not deliver any value.
What you want is to manage with outcomes: ask teams to create a specific customer behavior that drives business results. That allows them to find the right solution, and keeps them focused on delivering value.
Our highest priority is to satisfy the customer through early and continuous delivery of value.
2. Using Outcomes
The design guru Jared Spool asserts that there are only five things executives care about: increasing revenues, decreasing costs, increasing new business and market share, increasing revenue from existing customers, and increasing shareholder value.
An outcome is “a change in human behavior that drives business results.”
To find the right outcomes to work on, we start with a simple question: “what are the customer behaviors that drive business results?”
Because outcomes are things people do, they’re both observable and measurable.
You just need to remember two things: first, that an outcome is a human behavior that drives business results, and second, to figure them out, we just need to understand what our customers are doing that drives the results that we care about.
MVP, or Minimum Viable Product.
What are the customer and user behaviors that drive business results? What’s powerful about this question is that it changes the focus of your planning — instead of focusing on what you intend to make, you’re setting your focus on the people you’re trying to serve.
Behind this question lie a set of related and incredibly important questions: What are our customers trying to do? How do they do that today? How can we make it easier for them to do that? How can we get people to do more of these behaviors? What’s powerful about this question is that it orients your planning process away from features and towards behavior change. This question opens up our solution space to a much broader range of possibilities.
How do we know we’re right?
Tracking Progress with Outcomes
When teams are re- writing internal systems, for example, they often report progress in terms of how many system features they’ve completed. It would be better to instead measure progress in terms of new organizational behaviors created by their work. For example, what is the ratio of users of the new system vs the old system? How many of those users are able to use a new business process as a result of the initiative? Are the new business processes unlocked by this initiative ones that in turn generate positive outcomes?
Technologists sometimes push back — they will make the claim that they can’t cut users over from one system to another until the new system is complete. But this is where the power of outcomes shows up: no digital system is ever really complete, and conversely, even very small slices of a new digital system can start generating value before the rest of the system is ready.
What new behaviors did your work create that are creating value for the business?
The whole point of OKR (Objectives and Key Results) is to help you think critically about what you’re working on, not simply find a new way to talk about it.
So how do you write better OKRs? One way is to think of Key Results as outcomes.
Use the magic questions to define outcomes: what are the human behaviors that drive business results? How can we get people to do more of these things? How will we know we’re right?
Use outcomes (not features) to plan initiatives. Ask “what new behaviors will this initiative create that will deliver business value? How can we deliver that value sooner?”
3. Outcomes-Based Planning
Before we start though, it’s worth spending a moment to talk about the complexity and uncertainty that we all have to confront when we work with systems of outcomes.
Roadmaps fail when they present a picture of the future that is at odds with what we know about the future. If we were setting out to cross an uncharted desert — one that we cannot see from the air, and that was of unknown size — it would be crazy to predict that we could cross it in a few hours. How far are we traveling? What terrain will we encounter? What sources of food and water exist? You get the idea — you’d be reckless to make a prediction.
So promising your organization a plan that’s filled with certainty is similar to promising an arrival date for crossing the desert.
Instead of building plans around the outputs that you’ll make, it often makes more sense to plan around themes of work, problems to solve, or outcomes to deliver. The less certain you are that your outputs (ie. the features you want to deliver) will deliver the results you seek, the more it makes sense to plan in terms of outcomes, and to build your roadmaps around sets of outcomes.
What behaviors at each step predict success and satisfaction? And what behaviors at each step predict failure and dissatisfaction?
Planning with outputs limits teams’ agility and problem-solving flexibility. Increase teams’ capabilities here by planning around outcomes Create outcomes-based roadmaps that list questions, themes, and outcomes instead of features. One way to find outcomes is to create Customer Journey Maps. These maps help visualize how systems work in
Terms of customer (and employee) behavior, and so can help you find important outcomes in the system.
4. Organizing for Outcomes
Frankly, it wasn’t going to get done anyway. We didn’t lose anything except the false hope that it would get done.
For years, the feature- based way of planning work had made it hard to prioritize work. This is a basic problem of output-based planning. How can you figure out what features are important if you aren’t sure which features will deliver value?
It’s hard for everyone to shift their thinking from the concrete world of features to the abstract world of outcomes.
In the next meeting, I asked them to talk about what they were worried about. It was night and day. They started telling their stories about their business.
You have to be open to failing and learning and be open to talking about it.”
5. Outcomes for Transformation
Outcomes-based thinking is, in fact, the key to transformation.
This is an important lesson for transformation leaders. When you are trying transform an organization, you are trying to change the way the organization works — in other words, you’re trying to get your co-workers to change their behavior. Understanding your co-workers’ points of view, their motivations, and the behavior change you seek to create is the foundation of any transformation effort. Expressing the change you seek in terms of outcomes allows you to build change programs that very specifically target the behaviors you want to promote.
Changing behavior inside an organization is a hard problem, and not one that is easily solved by planning on paper. Instead, it benefits from an action-oriented approach. You try something, see if it works, and if it does, you invest in the approach.
Frame organizational change initiatives in terms of outcomes. What are the new behaviors you want to create in the organization? What will people be doing differently when your change program is successful?
Reading List
Impact Mapping A technique for identifying important outcomes. Note that Impact Mapping uses the terms I’ve used in this book in a different way. What I call an “impact,” impact mapping calls a “goal.” What I call an “outcome,” impact mapping calls an “impact.” Once you’re past the different language sets, the Impact Mapping method is very compatible with the ideas in this book. www.impactmapping.org
