Rémi Guyot, who co-wrote the book Discovery Discipline with Tristan Charvillat, questions in this opinion piece the consequences of excessive and limitless discovery by some Product Managers and Product Designers, to the point of forgetting the essential phase of delivery.
I have recently observed a phenomenon that first surprised me, then amused me… and finally worried me! This phenomenon is the emergence of Product Managers and Product Designers elevating discovery to a pedestal, to the detriment of delivery.
By surveying peers to see if others were sharing my impression, I was not disappointed. According to Raphaël Bonstein, Chief Product & Technology Officer at Studapart, "the trend created around discovery diverts many Product Managers from delivery. No one wants to do delivery anymore, as if it were 'dirty'. This even blocked me in some recruitments. Telling candidates that they will be writing specs has become a taboo." Believing that delivery is minor or secondary is to ignore the very specificity of our field. Perhaps, by living in a bubble, we have forgotten that our work material, digital, is the very foundation of our way of working.
Have you ever wondered why the digital field is systematically associated with notions of iteration and speed? Why has the concept of agility emerged so strongly with IT development jobs and not in the field of architecture, for example? For a simple reason: digital allows for an extremely short loop between designing a product, distributing it to the target audience, and measuring its adoption. This ultra-fast loop allows us to correct possible pitfalls so quickly that it is preferable to launch something imperfect – and correct it later if needed – rather than trying to anticipate what will happen. This specificity, the speed of iteration, is the heart of our industry. Try to find another field that allows as many approximations in production. The automobile or film industries, for example, would be completely different if they had the opportunity to correct their products every two weeks based on real usage data – unfortunately, their respective materials do not allow for this.
In this context, we must ask ourselves: why do we need a discovery phase in the tech world? The answer becomes evident when studying extreme cases.
- Let's take a first example: imagine that you are allowed NO iterations. You can release a new feature, but you won't have the opportunity to make it evolve afterward. What would you do in this case? You would tend to opt for a long discovery phase to minimize the risk of making a mistake. This approach, called "waterfall" in tech jargon, works, but it’s terribly slow.
- Now, let's study the opposite example: imagine you have ALL the iterations in the world at an infinite speed. In this case, you could ignore any discovery phase and simply test each possible variation to identify the best one. However, the reality of your daily environment is probably somewhere between the two… You need to do some discovery. How much? Enough to eliminate the most obvious risks. Not too much, not too little – a bit like nitroglycerin.
Wanting to do discovery without caring about delivery is a bit like wanting to create new recipes without wanting to step into the kitchen.
Because, in reality, that is the role of a discovery phase: to de-risk the impact of the delivery phase. At the end of discovery, you don't get a certainty or proof but a conviction! And it is during the delivery phase that this conviction is confronted with reality. The results come in, some hypotheses explode in midair while others are confirmed. Learning begins, allowing for a new discovery phase to correct the course where necessary. But one may be tempted to delay this delivery sentence indefinitely. Renaud Vaillant, Chief Product Officer at Pyxo, calls this "over-discovery, which is the tendency to always dig deeper (into the problem and/or the solution) at the risk of never making a decision and not testing anything in production."
People who have been working as Product Managers/Designers for a short time tend to greatly overestimate their capacity (or that of their team) to have a strong impact on a given metric. Their excessive optimism comes from too few discovery-delivery loops. So, without delivery, there is no learning loop. Wanting to do discovery without caring about delivery is a bit like wanting to create new recipes without wanting to step into the kitchen.
So, when should we stop the discovery phase to switch to delivery? The answer lies in an equation: when the time spent reducing the risk multiplied by your risk tolerance is greater than the time it would take to deliver the iteration.
In other words:
- The lower the risk, the less discovery you need to do
- The higher your risk tolerance, the less discovery you need to do
- The faster your delivery speed, the less discovery you need to do
Why do we see more and more people falling into the excess of discovery? Several causes can be assumed: a belief in all-powerful data, a Cartesian mind hoping for a perfect answer, a habit taken with a known protocol, discomfort with having to defend an opinion, a hierarchy which doesn't accept failure, etc.
Faced with the cost of the slowness caused by this pitfall of over-discovery, some organizations have found simple solutions to overcome the temptation to want to validate everything. An interesting approach is the one adopted at Strapi, whose Product team adopted the method described in Discovery Discipline before the book was published. According to their Chief Product Officer, Aurélien Georget, to avoid spending more time than necessary in discovery, you need to define in advance the type of initiative you are dealing with:
- "An L initiative means we are in the dark, so we do a thorough discovery, we take out the flashlights and explore.
- An M initiative, we do some discovery (about 50% of the effort compared to an L initiative).
- An S initiative, we go fast, very little discovery, it's a known and recognized problem, we scratch the surface, no need to reinvent the wheel."
They even created a mini-matrix with a few questions to choose if it's an S, M, or L initiative.
We see clearly that the notion of risk-taking is at the heart of the balance to be found. Because that is how the discovery phase should be approached, not as a religious procession where one must follow an immutable ritual from which one never deviates.
Beyond the loss of time, excessive rigidity in the discovery phase – "I absolutely need three months full-time to interview six people in each of the segments I am exploring" – leads to a loss of credibility with our key interlocutors. They do not understand this dogmatism where so-called good practices seem to take precedence over common sense. By wanting to do too much, we end up ruining the reputation of this phase. Too much discovery kills discovery.
There are dozens of risks that we might want to mitigate: not having the expected business impact, not meeting a user need, poorly addressing that need, seeing the right solution ignored or misunderstood, etc. These risks are not linked. You can be right on one point and completely wrong on another. Mitigating each of these risks is not done by always applying the same protocol. That is why the FOCUSED method, described in Discovery Discipline, reduces the discovery work to what is strictly necessary.
In addition to the initiative size notion used at Strapi, one can also speed up the discovery phase by targeting the specific points that deserve to be explored. The deliverables act as a diagnosis (where are the greatest risks?), while the recommended activities help to reduce the identified risks. When the deliverable is clear to all team members, it means the risk of error is low and it is not necessary to spend more time on it.
Let’s be clear: discovery phases deserve to have a precise and repeatable process. If the FOCUSED method has resonated with the community, I am delighted. However, it was never a question of ranking discovery as something superior to delivery. I hope we will collectively continue to grow on this topic, to develop our practices without falling into blind fanaticism
