“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“ – Manifesto for Agile Software Development
This is the very first principle from the Agile Manifesto, and we believe it is the most important. However, since this future-thinking Manifesto was written in 2001, we believe a paradox has developed around focusing on customer satisfaction, created by a foe from the past.
In this book, we will seek to answer this question, with a focus on concrete patterns and practices, taking context and complexity into account. We want to help bring us back to the future. We want to help you on your journey to becoming more outcome-driven with product creation.
What do we mean by outcome-driven?
To help clarify, let’s start with the definition of an outcome:
“A change in human behaviour that drives business results” – Josh Seiden
This is the definition we will apply throughout the rest of the book. We will explore what is changing in people’s behaviours, and how to measure that. Not only that, we will flip it on its head! How might we use data to act, to influence, and to inform what we do next to change people’s behaviour for the better.
When we think about creating products customers love which solve their most wicked problems, we often think about 2 streams of work:
First Stream: Discovering user needs, aligned with business goals;
Second Stream: Delivering against these needs.
However, there is one key piece which is frequently missed. A hidden Third Stream, which is key to delivering value to our user and to our business. Yet, we barely focus on this. Instead, we fall into the trap of continuously delivering, without validating and learning. Moreover, taking action on that. So, what is this Third Stream?
Have we actually, and measurably, solved the user’s problems whilst achieving the desired business goals?
We call this the Third Stream because this step happens after delivery, having its own feedback loops, measures of success and ways of working. This is where we continuously learn, after the product is in users’ hands. Every product development endeavour has these three streams, whether we are aware or not.
This book will guide you through connecting the three streams and share examples of why, what, how and when to discover, deliver and validate outcomes.
Principles for the three streams
“Efficiency, which is doing things right, is irrelevant until you work on the right things.” Peter Drucker
1. Value is not just for the user
When we’re developing products, we often talk about delivering value. However, the word “value” means different things to different people. Sometimes we also talk about delighting users – which is a worthy aim. However, if we gave away our product for free, we would probably have super happy users, but we probably wouldn’t last long in business! Therefore, when we are thinking about value, a useful lens to do this is to think in terms of outcomes – what user behaviours are we trying to help enable to solve their problems. Importantly, these outcomes should be linked to measurable business impact.
2. It’s not linear
From Lean Thinking, an important concept emerged – the idea of a Value Stream. This is a linear way of visualising our end to end delivery of user needs from the time the need is identified, to the time it solves a problem. This idea has been applied in recent years to product development.
There is one big problem with this, however: product development is not linear. If we draw out how great products are developed, we find lots of feedback loops, iteration and many options being discarded. It looks more like a ball of twine – it’s messy!
3. Development, not just delivery
In traditional project management, we ship a feature and move on, and if it was delivered on time and on budget it was a success. In product development, shipping is not enough – the product is alive. The services and features offered by it must continuously evolve.
When we think about developing products, often we think about development being equal to delivery. In fact, to develop any product, this includes learning and discovering our users’ needs and validating that we are building the right thing. This is an important distinction, as we need to take a holistic approach to development, and not to think of discovery and delivery as two unconnected things. So, instead of thinking of a (project) delivery team, consider referring to it as a (product) development team.
4. Shift right
In traditional product development, we might see something like this: a Product manager works with the team to undertake Discovery, prototypes get validated, and then the team delivers the feature. After the feature is shipped, rinse and repeat. This often leads to many challenges – for example, how do the team know that the intended outcomes have been met? How has the user’s behaviour changed? Has business impact been achieved? We often hear teams talk about “shifting left” – getting testers involved earlier, and getting the whole team involved in Product Discovery. This is great, but what we would also advocate for is “shifting right” – getting the whole Product team involved in measuring and learning after a feature has been shipped.
Approaches such as the DevOps movement have taught us that by shifting developers right in the flow of value delivery, they get a greater sense of ownership and understanding of what happens from a technical perspective after they ship code. We believe the same principle applies from a value perspective – shift out of the feature factory by shifting right.
This requires team members of all functions becoming comfortable in basic data interpretation. This does not mean everyone becomes a Data Scientist; instead, everyone on the team learns the basics of Product analytics from their resident Data Scientist or Product Manager, with little or no coding knowledge required. For example, how to read Product analytics dashboards and how to interpret data. This comes down to decision making, and it does not mean design-by-committee. Instead, for a decision-maker such as a Product Manager, having diverse perspectives informed by data ultimately leads to smarter next steps being taken after a feature has been shipped.
5. The real Definition of Done
Have you ever shipped a feature, thrown a big party to celebrate being on time and on budget, but then never checked if the feature was used?
The product is organic and alive, because it is the way the business offers services for the market. The business and the market aren’t static. So they are alive, just like the product.
Done is from the world of project thinking, when we deliver some new feature. But the product is still there, and the market needs are constantly changing. We can do product discovery and development through project management, however it won’t bring agility for our business.
When we speak about Definition of Done, we usually do so from a project perspective – “did our shipped code meet our scope & quality standards?” However, this “Done” really means “Shipped With Quality.” We need to take the idea of Done a step further – did we actually solve the user’s problem, whilst benefiting our business goals – and have we measured this? We are only properly Done once we have validated that this outcome has been achieved for the user and the business.
6. Act on validated learning
Have you ever collected metrics after shipping a feature, and then discovered a big problem – we have lots of data, but we’re not sure what actions to take?
It’s all about taking action. We shouldn’t just ship features to the market. We need metrics to continuously monitor the usage of the features. Not just that, we have to learn from it and take action. Every decision from discovery is just a hypothesis until being validated in the real world.
These actionable metrics feed into our continuous learning cycle and back into the other two streams. Importantly, the needs of our market and of our business will soon change again and we will need to continuously refine our metrics to validate future learnings and take actions. So, we close the of the Three-Stream learning loop.
There are three steps which make up The Third Stream:
- Measure: Approach based on metrics to be data-informed. Using the metrics that really matters to have actionable information and knowledge.
- Learn: Getting insights from data, learning from end users and the market through planned experiments and product results.
- Act: When needed, defining actions to adapt and evolve the services the product offers to meet user needs, aligned with business vision and strategy.
Summary
In this chapter, we introduced the Three-Stream learning loop. In this, we talked about discovery, delivery and validation as the 3 interconnected feedback loops when creating Products. We also looked at the Why behind this, with the 6 underlying principles, and the How, with the 3 steps.
In the following chapters, we will explore each principle more fully and talk about their antipatterns and patterns, as well as sharing concrete examples and ideas from our experience experimenting with this Three-Stream learning loop. It’s all about how we can have metrics for it, how we validate the metrics, and how we can take actions from it.
Consider these as potential ideas and options to try out for yourself and experiment with further.
Next Reading: Chapter 2: Measuring it
The Third Stream Book 