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:
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:
There are a few points to highlight from the process above:
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.
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:
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.
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.
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:
You can also acquire the books individually, by clicking on their titles above.
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.