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?
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:
I will give some examples to help make these situations tangible.
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.
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.
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.
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:
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.
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:
Sessions can be in-person or remote! Check out what people are saying about my 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.
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.
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:
You can also acquire the books individually by clicking on their titles above.