There are basically two reasons, one of them has to do with mindset and the other one has to do with the discovery process.

The one that has to do with mindset is clear when we hear phrases like “Why do you want to do a discovery? I’m the business person so I’m the person that understands the most about our business problems/needs and how to solve them. You just have to implement what I say”.

Sometimes this aversion is rooted in the “business demands => technology implements” mindset that I mentioned earlier. This was how things were made in the past, without any need for discovery, because “business people are the ones interacting with customers so they always know what is best for the customers”.

However, most frequently this aversion to the discovery process is motivated by the business person’s past experiences where the discovery process was too long. The business person needs the solution to his problems implemented as quickly as possible, so she can benefit from the results that this demand may generate. The business person can’t afford lengthy discovery processes.

It’s very difficult, but not impossible to change this mindset. It requires patience and repetition:

• Ask why: by asking why the business person is demanding the implementation of a certain feature, we have the opportunity to show this person a very simple discovery tactic that helps both the product manager and the business person to find other solutions hypotheses to the problem. We change to a discovery mode without using the word discovery. After a few times applying this tactic, we can mention to the person that understanding the why of a certain demand, generating solution hypotheses, and testing these solution hypotheses is the process of discovery and it’s based on the product manager and the product development team needs to find the easiest and quick to implement the solution.

• Learn about the business: sometimes the business person believes that she knows more about the business than the product manager. This normally happens when a new product manager joins a company and still doesn’t know much about its business. To solve this perception from the business person, the product manager needs to find ways to learn about the business as quickly as possible. Talk to business people, talk to customers, read about the business, attend short-term courses about the business, and go to conferences about the business topic. Product managers need to understand the business in order to discuss business issues with the business person.

• Shorten the discovery process: sometimes discoveries take quite long. A few weeks, one month, more than one month. Meanwhile, the business person has a problem that needs a solution as quickly as possible so she can benefit from the expected outcome that the solution of the problem may generate. This happens especially when the discovery process is focused only on the problem discovery. If the product manager is able to cycle fast between problem discovery and solution discovery, the business person may see the product development team working sooner rather than later on a solution hypothesis for the problem and may have her expectations for a solution calmed down.

MVD – Minimal Viable Discovery

Unfortunately, this third reason, the lengthy discovery process, happens quite often and this is our fault, especially when we aim to understand everything about a problem prior to testing solutions.

As I mentioned earlier, the discovery process has two sides, problem discovery, and solution discovery. We don’t need to know everything about a problem prior to testing, i.e., discovering solutions. The solution discovery is a powerful tool for us to understand more about the problem. For this reason, we need to cycle as quickly as possible between problem discovery and solution discovery. The faster we do so, the faster we understand the problem and the faster we discover a solution for the problem.

Also, if we do a complete problem discovery to understand everything about the problem, we may end up with so many sub-problems that will make the solution discovery process also very lengthy and the delivery will take a lot of time to be completed.

The product development community talks a lot about MVP, the minimal viable product, but we cannot forget this is not only about fast delivery of a minimal product, but also a lean discovery process. It’s time to adopt an MVD – Minimal Viable Discovery mindset, i.e., what’s the minimal problem discovery we need to make in order to test the minimal solution hypotheses and deliver the one that works and actually solves the problem?

A good example to illustrate this is the Lopes’ broker app. Lopes is the biggest real estate company in Brazil, where I’m leading the digital transformation efforts. When I joined the company the team was working on an “MVP” of this app. I put in quotes because it was under development for 5 months and there were still 2 to 3 months to go. When I dig a bit deeper into the process and why it was taking so long, I’ve learned a few things:

• The discovery process took anywhere between 7 to 10 months!
• The discovery process was focused only on the problem discovery.
• The discovery process was internal, i.e., demand gathering from business areas and benchmarking with other broker apps available in the market.
• The “MVP” was scoped as having 58 requirements/features and there were already 90 requirements/features scoped for future releases.
• The main pain point was based on a hypothesis that, if the broker received the lead, i.e., a potential customer interested in a property, the faster she received this lead and interacted with the customer, the greater the chances of closing a deal.
• Then, the team analyzed the broker journey and realized that when a lead arrives, the broker needs to search Lopes potential customers database to check if the potential customer is already in our database and if it is not, register the user data in our database.
• And then, from this broker journey analysis they realized that, if the broker was able to send a few other property options to the potential customer, it would potentially increase the chances of closing a deal.
• This created the scope to be implemented that took 7 to 10 months of discovery plus 7 to 8 months of delivery to build the app “MVP”.

There are a few points to highlight from the process above:

• The discovery process was too long, which created a huge list of problems to be solved.
• The solution discovery phase was not performed. The team went from problem discovery directly to delivery, without any opportunity to test some solution hypotheses.
• The huge list of problems to be solved impacted directly the delivery process making it very long too.
• If the solution discovery was used as soon as the main problem was discovered, the hypothesis that the faster she received this lead and interacted with the customer, the greater the chances of closing a deal, probably the team would be able to devise a simpler solution, that probably would take days, not months to be implemented.

Regarding this last point, after a few discussions, we thought about an app with only a push notification for each lead and the broker could continue the tasks as she already did them. And it could be even simpler to test the solution hypotheses by not to even building an app, but by sending an SMS or a WhatsApp message to the broker. An A/B test could be made to compare the closing rates of the brokers who received SMS notifications versus the closing rates of brokers that didn’t receive them.

We actually ended up implementing the SMS notification, it took us 10 days to implement, and right after that, we were able to test the hypothesis that the faster a broker received a lead and interacted with the customer, the greater the chances of closing a deal.

The best discovery method is called delivery

I already mentioned that one of the reasons to deliver early and often is that the moment of truth for your product is when a product is in front of its users, being used in the context where it is supposed to be used. It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

So the best way to discover if a solution hypothesis works is actually implementing it and presenting it to potential users that may have the problem that you discovered during the problem discovery.

For many solution hypotheses, we don’t need to build a complete product to test. Today there are many low-code and no-code tools that allow us to build simple solutions. And some of these tools exist for quite a while, like presentations and forms. At Gympass we tested some solution hypotheses that we had to solve the problem we discovered of bringing new options to people that didn’t want to go to the gym but wanted to pursue a healthier lifestyle.

The solution hypothesis was to partner with wellness apps and provide this app to our users for a monthly subscription fee. This new idea had two main hypotheses that we needed to test:

• Application providers willingness to partner. Application providers, like gyms, are used to the recurring monthly revenue model. Would they accept to be paid per day of use?
• Our user base willingness to pay. Is our user base interested in paying a monthly fee to access the applications?

To test our first hypothesis, we built a deck with the value proposition that we planned to deliver to the partners and talked to some potential partners. We presented the opportunity to 8 potential partners, of whom 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app, and ZenApp a meditation app.

Okay, our first hypothesis was validated with just a simple slide deck. No product was built. Now we needed to validate the second hypothesis, the willingness to subscribe. Is our user willing to pay to access these applications through Gympass?

To test our second hypothesis, we built a simple form, where we described the product and asked for the user’s name, email, and company. After the user provided this information, he was directed to a Paypal subscription page, where he had to provide his credit card details to subscribe to the service. The user would receive an email with the activation link for each application. There was no real product, no logged-in area, just a form to test interest and an email with links to the applications.

https://youtu.be/U8SH5Aeay0A

So use the no-code or low-code tools options available to build your solution hypothesis to make it easier and faster to go through the solution discovery. As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

Summing up

• Business people dislike discoveries because of 3 main reasons. (1) They believe they know more about the business, the clients, and what they need. (2) They may have had past experiences where the discovery took too long. (3) They are used to a “business demands => technology implements” model.
• Changing this mindset requires patience and repetition. Three things a product manager should do continuously to help change this mindset. (1) Ask why the person is asking to implement the demanded feature. (2) Learn about the business. (3) Shorten the discovery process.
• In order to shorten the discovery process, we should think in terms of an MVD mindset, i.e., minimal viable discovery, where we discover enough about the problem in order to generate and test the solution hypothesis as fast as possible.
• The best discovery method is called delivery. The moment of truth of any solution hypothesis is when we are able to present it to the potential user in her own context where she faces the problem we want to solve. Today we have many low-code and no-code solutions that help us build our solution hypothesis to make it easier and faster to go through the solution discovery.
• As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.