I haven’t written for some time. The reason is that I am working with a client in a more hands-on way, which I call interim CPO, to accelerate some important product themes for the organization such as product culture, product vision and strategy, feature teams vs. product teams. This type of work is quite intense from a time point of view, it requires a lot of conversations so that I can understand the different aspects of the company, its mode of operation, and the business so that I can make a diagnosis and, based on that diagnosis, draw 4 hands an action plane. That’s why I haven’t been able to write as often as I would like. On the other hand, in this work a topic emerged that I believe is of interest to several companies and several product development teams, the need for discovery, which will be the topic of this article.

I have sometimes encountered people from the product development team (product managers, designers, and engineers) wanting to do discovery to understand the problem well before building a solution, while people from other areas, with a lot of experience in the product topic, believe that there are basic things that don’t need discovery, they just need to be implemented. From this debate comes the question: can there be situations in which product discovery is not necessary?

Short answer: Yes, there may be situations where product discovery isn’t necessary.

Before understanding what these situations are, we must remember that discovery is not a process, but rather a toolbox for risk mitigation. What type of risks? The main risk is the risk of building a product, or a feature, that will “float”, that is, it will be a failure. Building a product is expensive, normally the product development team is one of the most expensive in the company, and we also have the costs of infrastructure and product development tools, which are also not cheap.

Why might a product or feature be a failure?

• Will the client want it? (value risk for the customer)
• Will it bring a return to the company? (business viability risk)
• Can we build it? (development risk)
• Will the customer know how to use it? (usability risk)

We need to answer the above questions as best we can to avoid building a product or feature that will fail, which wastes time, money, and work.

However, discovery may not be necessary if we have a situation where:

• we do not have any of the risks described above, or;
• there is one (or some) of the above risks duly identified, but the cost (financial, time) to mitigate this risk is greater than the cost of making the product or functionality.

I will give some examples to help make these situations tangible.

Building well-known features

When a feature is well known, it means that someone has already made the discovery, found a good solution, and the market is already used to that solution. In a case like this, discovery may not be necessary. Imagine you are working on building an eCommerce. There are already many ecommerces on the market. Most people have already purchased from an ecommerce store, and have had good and bad experiences. Consequently, most people know which eCommerce works well to serve as a benchmark for the eCommerce you build. It’s the famous “we don’t need to reinvent the wheel”.

On the other hand, you may be creating an eCommerce for a new market niche that is not served or is poorly served by existing solutions. In a case like this, discovery will come in handy. But you won’t need to discover everything, you can discover existing solutions. What’s good about them? And what doesn’t work or could be improved to be more suitable for this specific niche you are serving? And, to quickly deliver value to both the customer and the company that owns the product, my recommendation is to implement the best existing solution and, based on that solution, do discovery to better serve your niche.

Construction of functionalities required for regulatory reasons

If you are building in a regulated market, you will have to implement some functionality to comply with these regulations. For example, if you are building a product in the financial market, it is important to comply with the regulations of BACEN, the Central Bank of Brazil. If you are working on a product in the medical field, you will certainly find some regulations that must be observed, and that will imply and build certain functionalities into your product.

One of the products we developed at Locaweb was called PABX Virtual, a PABX system that ran in the cloud using VoIP (Voice over IP) technology, which was new at the time (2006). It turns out that the telephone market is very regulated. In Brazil, we have Anatel, the National Telecommunications Agency, a regulatory agency that supervises companies that offer telecommunications services in the country. Locaweb’s Virtual PABX is in the telecommunications market and, consequently, must follow certain definitions dictated by Anatel. For example, every month we had to send reports in a certain format to Anatel, meaning no discovery was necessary. What needed to be done was already pre-determined by the telecommunications market regulatory agency.

Construction of urgent features

For some reason, you are in a situation where a solution must be implemented urgently. For example, a crisis like COVID-19, or the infrastructure where your product is located was hacked. These are situations that require immediate action.

When the pandemic hit, we were gearing up at Gympass to launch Gympass Wellness, a marketplace for physical activity, nutrition, and meditation apps, in pilot mode for 5 companies in Brazil and 5 companies in the USA, which represented 0.5% of our total customer base at the time. The idea was to test whether there was interest in this offer, that is, to do a discovery with an MVP to validate whether there was interest. As soon as the pandemic arrived and the lockdown was ordered by the authorities, we decided to include Gympass Wellness in the main Gympass offering as a way of providing an alternative for our customers who had their employees stuck at home. It ended up being a very important retention tool for Gympass and, due to the pandemic, we ended up canceling the discovery mode we were in and started offering the product to the entire customer base. There was simply no time for discovery.

Discovery is a tool

We tend to think that this topic has only two answers, we should “do discovery” or “we shouldn’t do discovery”. However, there are different levels of discovery depending on the different risks and the different levels of risk we have. As a result, the answer to the question “Should we do discovery?” It’s not simply yes or no. You may be working on a feature that has very little risk involved and you can do discovery to resolve that specific risk, and you may have a discovery that lasts a few days or even a few hours.

Importantly, remember that discovery is a tool, and like any tool, there are situations in which it may not be the most appropriate tool. To be able to understand which tool is most appropriate, we first need to understand the principles, which are the guide to behaviors we use in everyday situations. I’ve been talking a lot lately about the 4 essential principles of a product culture:

• Fast and frequent deliveries: you cannot innovate and create new products by delivering code in production monthly or quarterly.
• Focus on the problem: understand the problem well and then think about possible solutions. Test different hypotheses to see which solves the best and fastest.
• Delivering results: what a product development team has to deliver are results. Product, app, feature, and algorithm are not the objective, they are means to deliver results.
• Ecosystem mindset: it’s customer focus, only with a boost. Every company has more than one customer, and it is necessary to understand these different types of customers and their relationships.

By understanding the principles well, we can evaluate which tool can best help us practice these principles.

Finally, if you are not sure whether or not you need to do discovery, my recommendation is to act cautiously, list and prioritize the risks, and understand whether it is possible to quickly mitigate these risks, keeping in mind that our number 1 priority is to generate results as quickly as possible. Result for the company that owns the product, and for the customers for whom the product will solve a problem or meet a need.

Summing up

• Discovery is a risk mitigation tool. Therefore, there may be situations where product discovery is not necessary. If we have a situation in which (1) we have no risk, or (2) there is some (or some) duly identified risk, but the cost (financial, time) of mitigating that risk is greater than the cost of making the product or functionality.
• Some examples of situations that may not require discovery are (1) building well-known features, (2) building features required for regulatory reasons, and (3) building urgent features.

In-company Product Management Continuing Education Program

My newest product is the In-company Product Management Continuing Education Program, to help you and your team increase your knowledge about product management concepts, principles, and tools and, consequently, increase the success rate of your digital product endeavors.

This product is made up of 3 elements:

• Kick-off talk for the entire company, entitled Lessons Learned from a Digital Transformation, where I present practical examples of how product culture can enhance a company’s digitalization journey.
• Monthly training sessions on product management and digital transformation topics, to help company people learn about concepts, principles, and tools that help create successful digital products. There is a standard sequence, which can be revised to suit the company’s needs. All product and design people, technology leaders, and leaders from other company areas must participate in this training. For more details about the content, access this document.
• Mentoring, individual or group sessions, where we work on topics seen in training or other relevant topics.

Sessions can be in-person or remote! Check out what people are saying about my services.

Does it make sense for your company? Let’s talk! Feel free to contact me through email or WhatsApp, or schedule an appointment on my calendar.

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.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

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 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.