“Our goal is not to create a deliverable, it’s to change something in the world — to create an outcome” – Jeff Gothelf
We’ve heard the battle cries – outputs over outcomes. It sounds like common sense, and nobody really disagrees this is the way to go. However, in spite of the best intent, product development teams are still reporting being stuck in feature factories. They agree with the principle of being outcome-driven, but when the rubber meets the road, the struggle begins.
We move onto the next feature, not checking what happened once it was actually live in the real world. Or having mountains of data, and unsure how to tell a story with it. Or setting the best outcome-centric Key Results, and then leaving them as zombies.
Let’s go back in time: the three waves
We observe that there have been three waves in the evolution towards modern product development methods. If we go back in time to pre-1995, traditional Waterfall development was how we created products. Then came Scrum, XP and other first generation Agile approaches, to help us work as teams, deliver incrementally and iteratively, and become more user-focused. We think of this as the first wave.
In the 2000’s, approaches such as Design Thinking, Lean Startup, Design Sprints and modern Product Discovery methods were introduced, to help us understand what our customer’s problems and needs were. Moreover, these helped us take a more Lean, customer-centric approach than more traditional upfront planning. We think of this as the second wave.
We believe we are entering a third wave, where product people want to break free of feature factories, think about what happens after shipping and become more outcome-driven. The DevOps movement has already helped product developers shift-right from a technical perspective. We believe the time is now to shift-right from a business and product perspective too.
This book will provide practical ideas to help Product teams move towards more outcome-driven approaches to product development.
The time paradox
Let’s start by going back to a time when Agile, Design Thinking, Lean Startup and Modern Product Management approaches did not exist.
David and Dionatan were children of the 1980s, and there’s no better way to think of time travel than the Back to the Future movie. Our protagonists Doc Brown, Marty McFly and Jennifer Parker had just triumphantly returned to 1985 after their trip to the future in the DeLorean. Young Jennifer returned home, only to be greeted by old Jennifer. Shocked, Jennifer faints. In spite of everything in this universe looking like it should, a time paradox had been created by our antagonist, Biff Tannon, bringing the Sports Almanac back from the future and changing the past. They had returned to an alternate 1985.
We believe we are right in the middle of a time paradox right now. All of the more customer-centric approaches we mentioned above have been fantastic steps forward. Despite us undertaking Lean product discovery, Agile product delivery, something is still amiss. Digital transformations are failing more often than not. Attrition rates are higher than ever in software development companies. Moreover, business outcomes are being missed on a regular basis, causing the lifespan of companies to be shorter than ever before. What has happened?
Going back to the future
The old version of success from the past has been confronted with these new approaches, and quite simply, they cannot coexist. What does this definition of success still look like in many organisations: 1) Did we ship it on time? 2) Did we ship on budget? 3) Did we ship our planned scope? The revenge of the old project management iron triangle. The bottom line is these measures of success are ill-suited for modern product creation, where we are working in the Complex domain, as described in Dave Snowden’s Cynefin Framework. In this domain, discovering the right problems and right solutions is emergent. A probe-sense-respond approach is called for here, rather than the best practice approach the aforementioned measures of success attempt to apply. Operationally and conceptually we have moved forward, but one key question still remains largely only answered:
“What happens after we ship a feature?”
Who is this book for?
This book is for people involved in creating products, primarily:
- Product Managers & Owners;
- Product Leaders;
- Product/UX Designers;
- Product/UX Researchers;
- Product Developers;
- Agile Coaches & Scrum Masters.
This is not intended to be an introduction to Agile, Lean, Design Thinking or Product Management, and there are a huge amount of books we recommend on those topics, which we will reference at the end of this book. By contrast, this is a book of concrete examples, patterns and practices we would like to offer you as options to experiment with. We include a little piece of theory for each, but our intent is to make this book a reference guide, to help get you started on your journey.
How can I read this book?
This book contains three parts, segmented by the 3 steps we call out in The Third Stream – Measure, Learn & Act. Each part contains antipatterns associated with that step, some light theoretical context, and details of concrete patterns you can try out with your own Product teams. The examples and names we call out are not real names, but created loosely based on our own experiences over a combined 40+ years of working as part of, and through coaching, Product teams, Product Managers & Product leaders.
Next Reading: Chapter 1: The Third Stream
The Third Stream Book 