Building new features is not only time-consuming, but also very expensive. Especially if you only find out after implementation that the assumption you made about how it would work turned out to be a false one. The feature is not used or it even causes a drop in sales. This ‘Delivery focus’ is still very common in companies working agile. In this article, I explain how you can avoid this type of scenario in the future by designing your process differently.

© 2008-2022 Modyo SpA

Delivery focus

An example of a business strategy that we often see passing by is as follows:
A 5-year plan is written based on business performance, trends, competitive analysis and market research. Next, this 5-year plan is broken down into annual and quarterly plans and a look is taken at which features can be built to achieve the goals. This approach is very focused on the output (Delivery focus): create, build, deliver and meet sprint points as much as possible. We see that with this approach, decisions are still too often made based on gut feeling and opinions and not or hardly based on data and validations. This standard process of setting priorities for development teams looks like this:

© Dottie Schrok, Productboard, 2022

Product discovery phase

What if prior to the Delivery phase, where features are developed and delivered, there is a Product discovery phase? In this, (pre)validations are done and relevant insights are gathered, compiled and prioritized to feed the Delivery phase. Then the process would look like this:

© Dottie Schrok, Productboard, 2022

Product management = risk management

Such a Product Discovery phase is so important because it actually reduces your risk up front. There are 4 types of risk levels:

• Value risk: whether customers will buy the solution or choose to use it
• Usability risk: whether customers understand how to use the solution
• Feasibility risk: whether it is feasible for development to build
• Business risk: whether the solution fits within business strategies

From data and validation, we can mitigate the first two risks especially well in the Product Discovery phase.

Creating learning backlog

The Discovery phase is not about delivering features, but about delivering learnings. In fact, you create a learning backlog in this phase.

But how do you make sure that the product discovery phase actually starts feeding the delivery phase, so that decisions and strategies are made data-driven? This obviously requires a major change in culture and organization. You can read more about this in this article on organizational culture from my colleague Ruben. What I will mainly focus on in this article is laying the foundation for the product discovery phase: documenting all learnings in a structured way and creating a learning backlog. To do this, we will go through a number of steps:

Step 1: collect learnings
Organizations often know more than they think they do. There is a lot of knowledge available and it is important to bring it together. That way you can clearly see what information you already have and where additional research needs to be done. To bundle learnings, we at Online Dialogue use the 6V model. Using this model, we collect as much data as possible about the customer, the product, the organization and the market. The 6 Vs are:

Complete as many R's as possible and see where you are still missing information and want to do additional research. Describe the learnings from the various analyses, studies, etc. as succinctly as possible and turn them into short statements.

For example:
“User research (1) shows that visitors have difficulty filling in the zip code field in the form (2). This is because explanations are missing and people immediately get an error message (3).”
“A/B test 302 (1) shows that removing the information icon at shipping costs (2) causes a significant uplift in conversion of +2%. This is because distraction has been removed (3).”

(1):Data source
(2): Location problem/situation
(3): problem/situation description

Step 2: write out customer journey
Start by defining the different stages in the customer journey. Write these down from left to right. It can help to also immediately attach the different pages on your website and the different marketing channels to this. Here is an example

Step 3: writing out needs and preconditions
You then identify various needs and preconditions that you need to consider in your strategy. Consider:

• Customer needs: this one should always be in there. A tip is also to put this one at the top, so you practically force yourself to think about this first. What are customers' requirements and goals? Grab insights from interviews, previous A/B tests, data analysis and customer service, for example.
• Business needs: what are the needs of the business? What are the goals? It is helpful to include at least the mission, vision, KPI and metrics in this column.
• Third parties: are there third parties that influence the customer journey. Then it is important to take this into account in the strategy as well. For example, think about selling parties if you have a marketplace platform.
• Preconditions: for example, are there technical limitations, rules to consider from a legal standpoint or must-have features to realize the strategy? Put them in this column. Write down these needs and preconditions from top to bottom. This way you get a table like this:

Step 4: plotting learnings
Finally, plot the learnings and statements from step 1 in this table. in what stage of the customer journey is the learning located? Does it connect to any of the needs/edge conditions? This then looks like this:

... Just a quick note: we send out a newsletter every three weeks that includes the latest blogs, team updates and, of course, news about the offerings in our academy. Click here to subscribe.

Newsletter sign up

Conclusion

It is very important to add a discovery phase to your existing agile processes. Indeed, by doing so, you reduce the risk of spending money and resources on faulty assumptions. To do this, always start by collecting learnings about the target audience in order to build a learning backlog. Then you can prioritize all these collected learnings and move on to the validation phase.

Now that you have the know-how to get started with learning backlogs, you can already make follow-up steps in setting up and fine-tuning your discovery sprint. Still, it remains a difficult process with many snags. Would you like to know more about other (recognizable) challenges in developing discovery sprints? My colleague Desiree will publish a follow-up article about this soon. And on April 6 we will organize another Dialogue Thursday with the theme: Discovery sprints - discover the unknown. Sign up here> DiDo #41

Do you need more help with Product Discovery? We would love to help you with this! Sign up for our Product Discovery training.