Suppose you’re a Product Owner in an Agile delivery team, ready to get working on your product. In order to do that, you’ll need to give your development team a goal and a list of things to work on. If you use SCRUM as the framework, you’d call that list of things to work on a Product Backlog. From the SCRUM guide:
Okay, so you need to start with a backlog, prioritize as you see fit and then build the highest priority items first. SCRUM – and Agile development in general – is both incremental and iterative (see here or here for a good explanation of those terms). Let’s illustrate this with an example. When a customer orders a car – and we use SCRUM to implement it – we might iterate on the chassis and incrementally build the car, like this:
However, as a Product Owner (the role you take as a Product Manager), you’re left with a few questions:
In this blog post, we’ll try to gradually answer those questions.
Let’s start with the second question on our list: how can I be sure that it solves a need of the end user? Henrik Kniberg correctly points out:
We start with the same context – the customer ordered a car. But this time we don’t just build a car. Instead we focus on the underlying need the customer wants fulfilled. Turns out that his underlying need is “I need to get from A to B faster”, and a car is just one possible solution to that.
Compared to our previous example of a customer ordering a car, it would now look like this:
Said plainly, this means that you first need to unravel the real problem and adapt as you see fit. The unraveling of the problem is iterative in nature: as long as you don’t get confirmation that you’re solving a real need, you need to change and adapt. You present the end user with a best guess of what a solution might look like. As long the user is not satisfied, you have to dig deeper and come up with alternatives. Ultimately, you hit the sweet spot and get confirmation that you understood the problem. This confirmation can be based on real usage data, qualitative insights or a combination of both.
SCRUM doesn’t indicate how you should implement Henrik’s idea. My understanding is that there is a preference for developing software and focusing the sprint on ending with an increment. This means working software is used as an artefact during the iteration towards defining the problem. The drawback, however, is that the team needs to re-work already implemented increments, as they need to adapt to new insights. I checked the software development wastes and identified the potential ones:
These are still concerns to be addressed which can be solved by a proper product discovery step.
Let’s first revisit the questions a Product Owner might be left with and indicate which ones we’ve solved:
In order to eliminate the potential wastes with Henrik’s example, you need to split the iterative part (finding out what the user needs) and the building of the software (crafting a solution for the problem). Finding out what the user needs implies a so-called discovery step.
Marty Cagan, the “most influential person in the product space”, agrees:
In Henrik’s example, the team is working to simultaneously determine the right product to build, and at the same time to build that product. And they have one main tool at their disposal to do that: the engineers. So what you see is a progressively developed product, with an important emphasis on getting something we can test on real users at each iteration.
Henrik is emphasizing that they are building to learn, but they are doing this with the only tool they think they have: engineers writing code. If you read carefully, Henrik does mention that the engineers don’t actually need to be building products – they could be building prototypes, but with most teams I meet, this point is lost on them because they don’t understand that there are many forms of prototypes, most of which are not meant to be created by engineers.
That’s right: writing software might be a good solution to find out what the user wants, but more often than not, it is the most expensive way to get there.
With a discovery step, you can focus on the objectives of a product: is it valuable, usable, feasible and viable? This step is mostly iterative. The end result is a clear definition of the problem and hence a possible solution to that problem; one that has a high probability of solving a user’s need. Because you took a discovery step, this means you can describe the real problem to the engineering team. You can also describe the problem in more detail and also describe what kind of properties you expect from the end solution, e.g. a fitness function which places the solution in context. The development teams then figures out how to build that solution. This is the delivery step and it is mostly incremental.
With the product discovery and delivery steps, there are two tracks the team must consider: a product discovery track and a delivery track.
Let’s revisit the Product Owner’s questions a third time and indicate which ones we’ve solved:
Discovery work focuses on fast learning and validation. But how do you chain that together with delivery work? When a project starts, you might do discovery first and then – somewhat later – let the engineering team start.
That looks a lot like Waterfall! But it doesn’t have to be like this. Jeff Patton, a veteran Product Manager and writer of the book User Story Mapping, says it is all happening at once (Dual Track). Instead of a waterfall, we get a loop. A discovery learning loop looks a bit like this:
It starts by describing
Product discovery loops chain together like this:
Discovery work uses irregular cycle lengths. It’s ‘lean’ in the sense that we’re trying to make the discovery cycle as short as possible. Ideas in discovery mutate and very often get abandoned, which is the best move forward into more deliberate development cycles.
In order to eliminate potential risks, you need to be aware of both the discovery and delivery steps. The discovery step focuses on the objectives of a product: value, usability, feasibility and viability and is mostly iterative. The delivery step focuses on how to build a product and is mostly incremental. While the steps are separate, the tracks happen at the same time, which we call Dual Track.
Jeff Patton’s article on Dual Track also mentions a few important points.
The two tracks are done in parallel:
The tracks don’t stop as soon as you’ve discovered one problem to fix. The next problem is already looking around the corner. In our example with the customer ordering a car (“I need to get from A to B faster”), we might also think the user needs shelter, which can range from a simple hut to a castle.
A final remark: this blog post started with SCRUM as the delivery framework, but the methodology doesn’t really matter: it could be Kanban, Crystal XP and even Waterfall as long as the team is able to keep pace in the two tracks. But of course, since the discovery part focuses on learning fast, an Agile methodology suits better.
Let’s revisit the Product Owner’s questions one last time and indicate which ones are solved now.