Principles for the three streams
“Efficiency, which is doing things right, is irrelevant until you work on the right things.” Peter Drucker
1. Value-driven = Business Value + User Value
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. Shifting the Developers Left
In traditional product development, we might see something like this: a Product Manager talks to a customer, hands off to a UX designer, they work together and hand off to a development team to ship. This often leads to many challenges – for example, silos are created, what gets built is not the right thing, and the people at the end of the development stream don’t know why they’re building what they’re building. Shifting the development team left gets them involved in product discovery activities.
Approaches such as Agile Testing and the DevOps movement have taught us that by shifting development members left in the flow, that we can increase problem-solving abilities of the whole team to deliver better outcomes. This means that Product Discovery work becomes as important as Delivery work for all team members. Bringing in the whole team’s perspectives leads to more diverse options on solving the user and business problems.
The secondary benefit is when the features are being developed later on, the developers understand and empathise with the needs of the users, and are aligned on the purpose of their work. As knowledge workers, having this sense of purpose increases intrinsic motivation to produce better solutions and outcomes, rather than just focusing on shipping more outputs.
5. Done is never done forever
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. Validated learning is useless without taking action from it
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 loop of the Three-Stream Loop.
The Third Stream Book 