The Cult of Excessive Discovery: Are You Really Not Sure of Anything?

Year in, year out, things change and new Product books are relased, but there are themes that always seem to accompany our community. The main example of this is the consecrated process of discovery process with customers.

This topic usually occupies a big space in the courses and webinars in our category. Thats because everyone always wants to know what is the right way to talk to users, how to talk to them and what is the perfect formula for not biasing an interview (as it such thing exists).

All of these are extremely praiseworthy and highly developed attitudes in the famous manuals of good practices of the Product rockstars . But what seems to be missing (as in a lot of ready-made product formula) is the famous “why” you need this discovery.

If we know something, we dont need to find out!

We look for the “why’s” in so many areas around us as product professionals, why not do that with our processes too?

Discovery is good and, obviously, the more we do, the more insight into our users we have, but the only reason (maybe not the only one, but the main one) is that we can have more inputs to make decisions.

And that’s it. Just it.

Discovery is nothing more than another artifact that we have in our daily work so that we can tell if our Product goes on the path A or B, at the time X or Y and the way Z or H.

Of course it is a Lord Artifact, but it is “only” one more tool.

So, if you already have enough inputs to make a decision, why insist on making a discovery again?

Someone may have conclusions about it

Obviously you, as a product owner or manager, need to draw your own conclusion about a decision you are going to make, but is it necessary to hear from users something that perhaps someone else in your company has already concluded?

In an environment that we believe to be lean, doing discovery rework seems crazy, but it is what happens if you “only believe in what you see with your own eyes” and do not trust the vision of other people on your team to make decisions.

Isn’t cheaper just code?

Sometimes the time it takes to structure a survey, talk to users, meet these people, catalog the findings and align everything with the team is much bigger than a developer would spend to simply put it on screen and you analyze the results later.

Obvisoly this choice is not always the wisest, especially if the impact of your decision is very large and then it is “very expensive” (technologically speaking) to change that back. But if it is not the case, it might be worth!

Tools and tips to make decisions

It is already kind of established in our area that anything other than luck, opinion and guesswork is already the best way to make decisions, but it is worth remembering that you will not always be 100% sure that what you are doing will work.

And often, stopping to make a discovery can be so expensive in terms of staff time that you may need to determine paths to choose with the inputs you have on hand.

When that happens, stopping to make a discovery can delay your roadmap and “lock up” your backlog at a time that, strategically speaking, may be bad for the company.

Some ways I suggest to make a decision in these situations are:

• Talk to professionals who have been in the company for a longer time and maybe have a smart view about the results of your choise
• Search if any other Product professional has already experienced that and check what he has to suggest
• Understand the “price” of your decision and how much it is reversible if you happen to go the wrong way.

Make no mistake: discovery is good and I endorse it!

But, as good Product professionals that we try to be daily, we should not fail to question our own processes and always make a cost-effective relationship between the choices of the work we have and how much effective result it will bring us.

Whats you think about these ideias? Did you like it? Do you agree with me? Do you think it’s cool, but think differently? Add me on LinkedIn and let’s exchange more thoughts;)