The Famous Product Discovery

Anyone who has had contact with product development teams must have already come across the term discovery. It is very common for people who are new to product development to think that product discovery is a process to understand customer needs, but this understanding is incorrect. The correct definition is:

Product discovery is a set of tools for help us mitigate product development risks.

First, we need to understand that product discovery has a very clear objective, which is the mitigation of risks in product development. Why? Because product development requires a significant investment. Typically, the product development team constitutes a considerable portion of the total costs of the company, so we need to ensure that we are investing the team’s time in developing things that will help the company achieve its goals while solving a problem or meeting a customer need.

What types of risks are we talking about? If we search for types of business risks on Google, we will find many types of risks. Some even talk about 10 types of risks. Marty Cagan (2017), a recognized authority in product management, discusses four types of risks:

1. Value risk: whether customers will buy it or users will choose to use it;
2. Usability risk: whether users can figure out how to use it;
3. Feasibility risk: whether our engineers can build what we need with the time, skills, and technology we have;
4. Business viability risk: whether this solution also works for various aspects of our business.

While I understand the need to categorize types of risks in product development, the type of risk is not as crucial as the priority of the risk, meaning knowing which risk has the highest potential to be a significant obstacle to the product’s success. Remember: we want to develop a product that helps the owning company achieve its objectives while solving a problem or meeting a need of its customers. That’s what it means to succeed with the product.

Therefore, we need to identify and prioritize the risks. After prioritizing the risks, we use product discovery as the set of tools that help us mitigate these risks.

Problem discovery and solution discovery

Another important aspect that is often unclear is the fact that product discovery has two sides: product discovery problem and finding the solution.

Problem discovery

This is when we seek to understand the problem (or need) through problem discovery and solution discovery with our client. We explore how this problem is connected to our company’s strategic business objectives, the motivation our client has for wanting this problem solved, when, where, how, and why this problem occurs, if there are existing solutions for this problem, and what our client thinks about these solutions. The problem is the focus, and this task is primarily led by the product manager and the product designer.

In 2011, I had the idea of creating a calorie-tracking app that not only provided information on the number of calories in each food but also assessed the quality of calories using a simple color-coded system of red, yellow, and green. In this system, red calories, like sweets and cakes, should be avoided, yellow calories, like rice and meat, can be consumed moderately, and green calories, like lettuce and spinach, can be consumed without restrictions.

The first thing I decided to test was whether there was demand for such an app. Therefore, before creating the app, I decided to build a landing page for the app and then run a Google AdWords campaign to drive some traffic to this page. The page explained the product I planned to build and how much it would cost. I tell the complete story of this app in my book “Guide to Startups: How Startups and Established Companies Can Create Profitable Digital Products.” This is a typical risk mitigation approach in problem discovery: I was trying to mitigate the risk of knowing whether it was a problem worth pursuing the solution.

Solution discovery

When we begin to understand the problem to be solved, we need to discover possible solutions for that problem. This is when we generate and test ideas and solution hypotheses in the simplest way possible with prototypes, proofs of concept, and other similar low-code or no-code techniques. Low-code or no-code tools allow the implementation of functionality with little or no programming, such as a form, for example. This helps everyone in the product development team better understand how to maximize the value to be delivered during product development, minimizing risk and time in the development process. For this reason, during solution discovery, the entire product development team (product manager, product designer, and engineers) should equally engage.

A very interesting example of solution discovery comes from the history of the McDonald’s restaurant. Richard and Maurice McDonald, known as the McDonald Brothers, were American entrepreneurs who founded the fast-food company McDonald’s. Their story was depicted in the movie “The Founder” (2016), and there’s a very interesting scene where the McDonald brothers explain how they discovered the best kitchen layout to streamline order processing. They went to a tennis court, drew the layout they had in mind with chalk on the ground, and tested operating in that layout. They observed areas for improvement, made adjustments to the layout, and tested until they arrived at the kitchen layout that was implemented in the first McDonald’s restaurant. Check out below an image that illustrates this solution discovery:

You can see this scene from the movie The Founder at YouTube

The most common reason for a product to fail

Behind many product failures, we can find a common behavior: going straight from problem discovery to solution development with little or no solution discovery. When talking to my clients about product discovery, they often describe situations like these:

“We conducted in-depth user research and identified problem X, which users want to solve to the point where they will pay for a good solution. So, we decided to create solution Y. However, now that we’ve delivered solution Y, we’re seeing very low adoption…”

This happened because they skipped solution discovery, going from problem discovery straight to delivering the solution. Let me repeat this because it’s crucial:

The most common reason for product failure is to go straight from problem discovery to solution delivery.

Discovery is a set of tools to help us mitigate the risks of product development. Discovering a problem is easy. Finding a solution is difficult and requires product managers, designers, and engineers to think about possible solutions. Then, it’s necessary to evaluate the solutions to determine if at least one works, and if so, if more than one works, which one has the highest chance of success.

Sometimes, solution discovery confirms which product or feature we need to deliver, and that’s a success. However, there are times when solution discovery shows us that we won’t be able to find a solution with a chance of success, and that’s okay. It’s good because it will save us a lot of time and energy working on delivering a solution that will fail. We need to invest in solution discovery to avoid product failures.

Solution discovery can be a prototype, but it can also be other things, like a landing page where we attract traffic to understand if there is demand, as shown in the example of the calorie-tracking app. It can also be a spreadsheet where we assess the financial viability of a particular solution. As mentioned before, product discovery is a set of tools to help us mitigate the risks of product development, and there are many different types of tools for the various risks in the product development process.

Once, a client had a very interesting solution idea for a specific problem she discovered that most of her customers had. However, when she decided to run some numbers, she understood that the solution was not financially viable because the amount of money she would receive from customers would not be enough to cover all the costs of adjusting the product. And that was good because she managed to save all the time and money she would invest in building a solution that would become a failure.

A real-life example — a Locaweb product that never came to life

When I was at Locaweb around 2010, we discovered that some potential customers didn’t want to use existing website builders and were seeking web design professionals but lacked sufficient knowledge on how to manage the work with such professionals. As we had experience in website construction, we thought we could manage this relationship with web design professionals for the customer.

We were very excited about the opportunity and designed a solution. We were already having some discussions about how to develop this solution; however, before thinking about building the solution, we decided to create a prototype to present to some potential customers and learn from their reactions and feedback.

When we presented the prototype of the solution to potential customers, we received a cold shower. We wanted to be the intermediary, making it clear that we would do our best to help the customer have a good website, but we didn’t want to be responsible for any misconduct by the web design professionals. We wanted the system to self-regulate through a type of 1 to 5-star rating. When we built our prototype — a one-week effort — and presented it to potential customers, almost everyone wanted us to pay some penalty for non-delivery or delays if things didn’t go as expected.

We made changes to the prototype to present the product in alternative ways to make the roles and responsibilities of Locaweb and the web designers clearer, but without success. It was when we decided to cancel the development of the product. We were very glad we did that and learned how important it is to do solution discovery before putting energy and resources into delivering a complete product.

Solution discovery is a powerful yet simple and inexpensive way to increase the success rate of our product development efforts. However, many teams overlook it and go from problem discovery straight to solution delivery. If we had done that in this Locaweb example I just described, it would certainly have been a significant failure. It would have caused a lot of headaches for Locaweb, our product development team, and our customers.

Why do business people hate discovery?

It is common for business people in companies starting their digital transformation journey to become quite frustrated with product discovery. This frustration is often expressed in phrases like “Why do you want to do discovery? I am the business person, so I am the one who understands the most about our business problems and needs, and how to solve them. You just have to implement what I say.” This thinking stems from an old model of technology management where business people demand, and technology people implement. That’s how things were done in the past, without the need for discovery, because “business people interact with the customer, so they know what is best to solve their problems and meet their needs.”

In addition to this motivation, aversion to discovery can also be fueled by the experience of long discovery periods endured by business people. Business people need the solution to their problems implemented as quickly as possible to benefit from the results this demand can generate. Business people cannot afford prolonged discovery phases.

I have heard cases where the discovery process took a long time — several weeks, a month, more than a month. Meanwhile, the business person has a problem that needs a solution as soon as possible to benefit from the expected outcome the problem solution can generate. This occurs mainly when the discovery process focuses solely on discovering the problem. If the product manager can swiftly switch between problem discovery and solution discovery, the business person can see the product development team working on solution hypotheses for the problem earlier, potentially calming their expectations for a solution.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
• Chapter 1: The so-called digital transformation — Project and Product
• Chapter 2: Uncertainty and digital transformation
• Chapter 3: Types of company
• Chapter 4: Type of company vs digital maturity
• Chapter 5: Business models
• Chapter 6: Agile, digital and product culture
• Part 2: Principles
• Chapter 7: Deliver early and often — Measuring and managing the productivity — Case study: Dasa Group — Case study: Itaú Unibanco
• Chapter 8: Focus on the problem — The Famous Product Discovery

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing 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 books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products