How iterative Product Discovery helps you solve the right problem

• 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:

However, as a Product Owner (the role you take as a Product Manager), you’re left with a few questions:

• Where does the backlog come from?
• How can I be sure that it solves a need of the end user?
• How can I be sure that the development team will actually deliver my interpretation of the requirement?
• How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on?

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:

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:

• Estimation not possible due to poor analysis/information gathering (Partially Done Work).
• Technical complexity not analyzed properly (Partially Done Work), because it doesn’t make sense to do so during an iteration.
• Wrong choice of technology or solution (Defects), because the non-functional requirements are a moving target.
• Redesigning due to missed requirements (Defects).

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:

• Where does this backlog come from?
• How can I be sure that it solves a need of the end user? 
  • We start with an idea and iterate until we find a solution that fulfills a need. We keep doing this until we get a confirmation.
• How can I be sure that the development team will actually deliver my interpretation of the requirement?
• How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on?
  • This makes the problem bigger: the development team now needs to do (at least some) more rework to cover up all the changes.

Discover your user's needs

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.

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.

Let’s revisit the Product Owner’s questions a third time and indicate which ones we’ve solved:

• Where does this backlog come from?
• How can I be sure that it solves a need of the end user? 
  • We start with and idea and iterate until we found a solution that fulfills a need.
  • We should really spend more time with our end users to really understand their problem.
  • We should try to do this as fast as possible so that the engineering time doesn’t run out of work.
• How can I be sure that the development team will actually deliver my interpretation of the requirement?
  • In terms of problem description, I’m able to provide more detail and give more context.
• How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? 
  • The engineers really know it’s going to be a car before they can come up with a suitable architecture up to the task, and they may in fact choose to implement this architecture with a different delivery strategy than one designed to learn fast.
  • As the risks are tackled in discovery and the necessary delivery work becomes clear, that delivery work progresses much faster than it would otherwise.

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.

It becomes like this:

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

• what we believe is the problem we’re trying to solve and for whom,
• the solution to solve the problem,
• and how we’d measure its success.

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.

Takeaway

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.

• These two tracks are two types of work performed by the same team.
  
  • Discovery must check regularly with the team on feasibility, correct implementation and technical constraints that affect design decision.
  • Delivery uses insights from discovery during development.
• Discovery focuses on the riskiest assumptions first, i.e. user problems of which we have low confidence they solve a real user need (or the need is unknown).
• Delivery focuses on solutions for which we have high confidence that it solves a user’s problem.
  
  • The confidence might come from validated learning during discovery.
  • Or we start – e.g. in the beginning of a cycle – with backlog items for which we think no discovery is needed, such as technical work or features of which we already have high confidence they solve a user problem.

The two tracks are done in parallel:

• Discovery / Iteration: focus on the riskiest assumptions (problems of which we have the least knowledge of) and try to define them with the least effort possible.
• Delivery / Increment: focus on a well-defined solution (we have high confidence the end user needs it) and tackle the ones with highest value first.

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.

• Where does this backlog come from?
  • The backlog comes from assumptions which are validated during discovery.
  • However, there is a new question: how do we identify the list of assumptions to focus on? Where does the list of Opportunities come from?
• How can I be sure that it solves a need of the end user?
  • We start with an idea and iterate until we found a solution that fulfills a need.
  • I should really spend more time with my end users and really really understand their problem.
  • I should try to make this as fast as possible, so that the engineering time does not run out of work.
  • Do this in parallel, with the whole team.
• How can I be sure that the development team will actually deliver my interpretation of the requirement?
  • In terms of problem description, I can give more detail and give more context.
  • Involve (at least part) of your engineering team in discovery. This way, they get in touch with the real end user get a better understanding of the user’s real world.
• How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on?
  • The engineers really know it’s going to be a car before they can come up with a suitable architecture up to the task. They may in fact choose to implement this architecture with a different delivery strategy than one designed to learn fast.
  • The risks are tackled in discovery and the necessary delivery work becomes clear. The delivery work can now progress much faster than it would otherwise.