FEATURE – A traditional output-based mindset is not appropriate in the digital world. In this piece, the author explains why digital product teams should be managed to outcomes, instead.

Words: Jeff Gothelf, designer, Agile practitioner and Lean UX advocate

With lean thinking continuing its rapid expansion across the world of technology, many companies start running into a conflict of process and medium as they attempt to practice these ideas. Upon developing a high-level understanding of lean, the managers of IT organizations seem to focus on the methodology's number one remit: increasing the quality of products and services while ensuring respect for people. Yet, all too often their attention quickly turns to a rather different problem: how to get more bug-free code out the door faster.

As Josh Seiden and I discuss in our new book Sense & Respond, there are several problems with this way of thinking. For one, it conflates "bug free" as the only measure of quality for the software being shipped. Second, building off of a traditional manufacturing mindset, managers assume that more code is somehow better for the customer and the company. In reality, both perspectives are flawed.

When a company manufactures a physical good it knows exactly what materials go into creating that product. It knows how much they cost. It knows what the product will look like when it rolls off the assembly line, and it can reasonably assume what customers will do with that product. In this world, where there is little unknown, getting "more stuff out the door" at higher rates and with fewer defects is a perfectly legitimate way of thinking. Software, however, calls for a different approach.

The quantity of software rarely determines its value to the customer or the business. Software, particularly when powered by a DevOps culture of continuous deployment, integration and automated testing, is continuous. In other words, it never ends. Every byte of code we produce has to be maintained in the future, allowing for significant creativity when it comes to writing it. Ultimately, software can take many shapes that stay stagnant for short periods of time. This increases the uncertainty and complexity of the software systems we build. Finally, there is the human factor: our customers continue to surprise us when it comes to how they use the digital products and services we create. Indeed, so many of the features we take for granted today were never originally planned. Instead, they emerged from the continuous use of these systems and adopted by the companies who made them. While this happens in physical manufacturing as well, the key difference is the pace at which this evolution takes place: as quickly as software can get into the hands of customers, companies can update and improve it. This is not possible with physical goods, because the buying cycles are longer – which leads to longer feedback loops.

This uncertainty makes managing digital product teams to specific outputs – feature sets delivered by a specific deadline – a fool's errand. Instead, digital product teams should to be managed to outcomes.

Outcomes are measures of customer behavior that affect our business. They are quantifiable and highly measurable using analytics tools. Customer behavior shows us whether or not we've found the optimal combination of code, copy and design to make our products successful. If such behaviors reflect a suboptimal workflow in our software system, we have the ability to adjust very quickly.

Measuring and managing teams to outcomes gets us out of trying to quantify and reward the production of features. Digital product teams are building complex, living systems that need to be constantly managed, optimized, pruned and refined. The number of features they ship is irrelevant. The impact their code has on customers is a far better indicator of customer value. This is the "sensing" part of the work. Did we put something in the world that customers love?

Because digital systems evolve continuously, like their physical product counterparts, digital teams need to stay close to the customer. They need continuous feedback on whether the code they're deploying is impacting customer behavior in a positive way or hurting their ability to complete the desired task. Teams can then use these measures – these outcomes – to determine how well their current work is proceeding and whether or not this is still the right path to pursue. In other words, managing to outcomes exposes waste quickly and helps team understand where and how to reduce it. Outcomes keep teams from building digital products and services their customers don't want. This is the "respond" part of the work. Once we've understood how our latest efforts affected customer behavior, we can make an educated guess about how to proceed.

In addition, managing teams to outcomes gives leaders a clear, objective prioritization process. Teams that have an outcome as their measure of success (e.g., increase retention for our service by 50%) can now use that success criteria as a filter for their work. When forced to choose between competing priorities or corporate political agendas, the team can ask, "How does this idea help us achieve our retention goal?" and "Does this idea stand a better chance of helping us achieve that goal than something else?"

Certainly, physical product manufacturers aspire to drive outcomes, like retention, as well. If you bought a Toyota from me five years ago, I very much want your next car to be a Toyota as well. That said, with buying cycles typically much longer than digital systems and the ability to update physical products limited to the pace at which we can adjust our assembly line flows, digital teams have a distinct advantage here.

They now also have an easier way to objectively say "No" or "Not now" to pet projects and distractions from their core mission. The continuous nature of software means that insight can start flowing very quickly – right after the first release – revealing whether or not the idea the team chose really does have the potential to change the customer behavior they hoped for. If it does, they continue down that path and optimize until the ROI of their efforts is no longer meaningful to the company. However, if their early results refute their original assumptions, the team can change course quickly, reducing wasted time and effort on features or optimizations that do not positively affect customer behavior.

Outcomes humanize our products. They tell us how well our vision for the customer experience aligns with the market. They also reveal the complexity and inherent unknowns in each initiative. This is particularly important in the digital world as the level of uncertainty in each product or service can be very high. We might not be able to optimize our digital projects for production, but we certainly can – and should – optimize them for continuous learning and improvement, based on how our customers react to every bit of code we put in their hands.

_{THE AUTHOR}