ACA Blog

ACA Blog


December 2018
M T W T F S S
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Categories


How iterative Product Discovery helps you solve the right problem

Jonas Van PouckeJonas Van Poucke

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:

The Product Backlog is an ordered list of everything that is known to be needed in the product.The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

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:

When a customer orders a car - and we use SCRUM to implement it - we might iterate on the chassis and incrementally build the car

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.

Focus on the customer’s underlying need

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:

You need to focus on the underlying need the customer wants fulfilled.

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.

There is a preference for developing software and focusing the sprint on ending with an increment. 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:

There are still concerns to be addressed which can be solved by a proper product discovery step.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:

Discover your user’s need

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 (product discovery), and at the same time to build that product.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.

Product discovery track versus delivery track

With the product discovery and delivery steps, there are two tracks the team must consider: a product discovery track and a delivery track.

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:

Dual Track: product discovery and delivery happen simultaneously

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.

When a project starts, you might do discovery first and then - somewhat later - let the engineering team start.

It becomes like this:

Product design and development sprints

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:

This is what a product discovery learning loop looks like

It starts by describing

Product discovery loops chain together like this:

This is how product discovery loops chain together

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.

Takeaway for resume tipsTakeaway

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.

Left-over questions

Let’s revisit the Product Owner’s questions one last time and indicate which ones are solved now.

We’ve recently launched a Product Management training in which we teach you how to answer the other questions. Check out one of our trainings or contact me directly to get detailed insights or if you want to find out more on what we have to offer.

Leave a Reply

avatar
  Subscribe  
Notify of