How much product discovery is enough?

The topic of discovery is currently on everyone's lips in the field of product development. The times when discovery was often neglected are a thing of the past (yes, not everywhere). Today, we'll find out together why too much time is sometimes spent in the problem space and which rules of thumb really help you to better understand your customers.

What experts say about Product Discovery

Alberto Savoia

(inventor of pretotyping and former product manager at Google)

"You need to design and run a bare minimum of three to five experiments."

Teresa Torres

(Internationally recognized author, speaker and coach)

"If you're still wondering how much time you should spend in Discovery, the answer is: As much as you can every week."

The quotes reflect the areas from which the experts come. Alberto Saboia, for his part, comes from new product development. Teresa Torres, on the other hand, speaks more from the field of existing products, where there is often too little room for discovery in practice.

Both quotes don't quite capture what Thomas thinks about Discovery. According to him, you should spend as much time with Discovery until you understand the clients. You are ready when you understand the causal relationship between the desired interaction and the reason for it.

The problem: too much or too little discovery

For a long time, organizations did far too little discovery. In the worst case, this meant two years of development for the development team for something that didn't work in the end and then had to be laboriously rebuilt.

Sebastian is increasingly observing that a lot of discovery is currently being carried out due to the past. There is no measure or limit for too much discovery. As a result, some teams seem to be drifting towards over-discovery.

Both scenarios represent a waste: On the one hand, on the development resources side, as the team has developed something for nothing. On the other hand, on the side of UX resources. Both fail to achieve the goal of understanding customers as quickly as possible and then confronting them with a solution.

The solution: Switch quickly between problem space and solution space

An effective approach is to switch from the problem space to the solution space as quickly as possible and present the customer with a solution. To do this, Thomas conducts five to ten interviews with his customers. He then presents them with an initial visual sketch or prototype, which should show them roughly what the product will look like. This saves the entire team the above-mentioned waste.

Quick feedback from customers is important with this approach. They can use the presented sketch to comment directly on what works - and what doesn't.

If the solution doesn't work for the customer, you switch back to the problem space to better understand the problem. The faster this mechanism works, the faster you learn to understand your customers.

How do I get into the solution space faster?

Are you in a situation where you have been stuck in the problem space for a long time? Then Thomas has a concrete suggestion: build a small solution that reflects your current understanding of the problem.

"Building" can mean many things here:

• A landing page that offers a solution to the problem
• Emails to existing customers in which you offer an initial solution
• A presentation
• A small clickable prototype

If the customers then show real commitment and want to buy the solution: Great. If not: back to the problem area.

If you would like a concrete example of this, Thomas explains it to you in the video above from minute 7:38.

• You should move quickly from the problem space to the solution space - keyword: speed of learning.
• You should iterate this until you can predict how your customers will behave.
• You should also be able to explain why customers behave the way they do.

Does this guide help you to optimize discovery time in your team? We look forward to hearing about your experiences.

‍