Implementing Product Discovery in a business can cause several challenges, mainly due to the range of possibilities that can be explored. At this point, it is very common to have the question: where to start?

In this article, I bring my answer to this question. I explain the paths that I believe are more efficient and bring more results according to my experience within the Product area and project leadership.

Product Discovery

Why make Product Discovery?

The main goal of Product Discovery is to reduce risks. In the book "Inspired" by Marty Cagan, a reference in the Product area, 4 main types of risks that need to be mitigated in the Discovery stage are mentioned. They are:

• Value risk, which evaluates if the solution has value and will be purchased by the end user;

• Usability risk, referring to how easy the solution is to use;

• Execution risk, which evaluates the technical capacity of the team to implement the solution;

• Viability risk, which evaluates if the solution is aligned with the business moment.

Any business that has part of its operation working digitally needs to be attentive to mitigating these risks so that the final implementation does not cost more than expected.

It is known that most problems found in software exist due to failures in the Specification and Design stages (that is, during Discovery).

Although it may seem that "skipping" Discovery phases can bring efficiency and agility in implementation, over time the costs for bug correction become much higher.

Therefore, the Discovery stage is the moment to stress the problem and the final solution to the maximum, so that future changes are avoided.

 

What is Product Discovery?

Basically, it is creating solutions from user problems and needs. In practice, the Discovery process works in two different "spaces": the Problem and the Solution.

Everything starts by understanding your problem through a lot of research and investigation. This is the time to empathize with the user, conduct interviews and map out the pain points and needs of your target audience.

It is worth noting that the ideal for conducting an effective Discovery is to dedicate 50% to 60% of the time in the "Problem Space" - conducting research and alignments. This is because this is how we can understand in depth the real problems and opportunities of the business to create the correct solutions.

Building successful digital products requires two things: building the right product and building the product the right way. Discovery exists to solve the first of these.

3 key concepts for implementing Discovery

1. Deliver a high-standard Design

Design is about solving problems, not about implementing solutions. As already mentioned above, one of the main points for the good conduct of the Discovery Process is to empathize with the user and clearly understand what their real problems are (not yours or other people in the business).

Emphasizing the importance of design, a study on user interaction with websites and apps showed that the user takes fractions of seconds to decide whether or not to engage with the website or app they are accessing, and that more than 50% of people leave the site in less than 3 seconds. In addition:

• 94% of the impressions we have of sites are related to design;

• 75% of people judge the credibility of sites based on their aesthetics;

• 88% of users are less likely to return to the site after having a worse experience.

Build your Design Toolbox

As previously mentioned, there are two stages in Product Discovery:

To deliver a high-standard design, it is essential to ensure the quality of the process, ensuring that the ideal frameworks, tools, and concepts are applied for each stage.

There are frameworks that assist in both problem and solution identification, such as Design Thinking, Design Sprint, and Lean Inception. They are usually conducted in a workshop model and require more dedicated time.

However, in addition to the above, there are also other tools, methods, and concepts that can be applied separately and more quickly. Here is a brief list:

2. The solution must be built by many hands

Product Discovery requires active participation from the entire team. It requires alignment, good decision-making, and a problem-solving mindset.

Of course, there are people and functions responsible for leading the process, such as PMs and Designers. The point is that they should not be the only ones!

It is quite common for engineering and business teams to be involved only in very specific parts of the process, not understanding the whole of what is being built. This is a mistake made by many teams.

We must remember that the final product is the intersection of business direction, technology possibilities, and user needs.

To ensure this, it is important that PMs and Designers lead the process iteratively. But how to do this?

1. Give Discovery updates in Dailys This gives Discovery the attention it deserves and takes no more than 5 minutes per day. This way, the whole team is kept up to date with the progress and still allows everyone to contribute to the final solution.

2. Conduct weekly Discovery meetings These meetings should include at least one member of the Tech team and one member of the Business team. The main goals are to get everyone on the same page, answer questions, and make decisions together!

3. Test the solution with your users

Once again, it's time to involve users in the process. It's not enough to understand their problems: it's also essential to test the success of the solution and mitigate usability risk.

Daniel Kahneman, author of the book "Thinking, Fast and Slow," is well known for his work on behavioral finance and cognitive biases. According to him, biases are ways and paths that our brain creates to improve decision-making, aiming for effort savings and response agility.

What can we learn from this? What may seem obvious to those involved in the entire Discovery process may not be so obvious to those who weren't (the users!). It is quite common to conduct a usability test and discover that people generally have a very different perception of the action behind a button, for example.

Constant testing ensures that we are focusing the Discovery process on User Research, not personal opinions. As we have seen, this reduces risks by:

• Removing personal biases from created solutions;

• Finding problems before implementation, moments when they are less costly.

There are various types of tests and research that can be applied to validate the solution that has been created. It is possible to conduct quantitative and qualitative research, A/B, and Focus groups, among others.

However, the idea here is to delve into the details of the tests that provide direct feedback on the quality of the interface and solution we are creating, such as usability tests (moderated or unmoderated).

These tests are performed with prototypes that represent the interface in a realistic way, and allow us to understand how users behave toward our product. They provide us with very relevant insights about usability and how we can improve information architecture, text, error messages, and navigation flows.

Jacob Nielsen, in one of his studies, created the rule of 5. This rule states that testing with 5 users ensures that 80% of the problems will be found.

The table below shows the percentage of errors found according to the number of participants in usability tests.

Conclusion

Of course, the Product Discovery universe has numerous other areas and techniques to be explored, such as the use of data to guide decision-making.

However, I see that the implementation of this process will involve a lot of trial and error to generate real learning. Therefore, I see that we should start with the basics, which is the backbone of Discovery: a focus on solving user problems in alignment with the business.

After that, there are many (and very valuable!) possibilities for evolution to bring more quality and professionalism to the Discovery process.