I recently wrote a post about how continuous discovery is not product discovery — it's feature discovery. I see the term discovery being generalized and, like most concepts in product development, getting diluted to the point of being meaningless.
I wanted to elaborate on that point a bit, addressing how we as PMs are constantly processing input. Discovery represents a conscious effort to solicit this input from stakeholders. However, not all discovery is the same. I call this constant stream of input “product input”. Exactly as its name denotes, we get input from all kinds of stakeholders all the time. Smart PMs capture this stuff and put it in a funnel for refinement in priority order. Some stuff we can toss immediately; most stuff takes a bit more analysis. This is a hygiene function of PM.
If we think about actively seeking product input, we can do that in at least a couple of ways:
Product discovery has historically been seen as an effort to de-risk or reduce uncertainty related to a significant investment in product development. Canonically, we use it to make a decision to formally develop a new product (go from idea to a formal commitment to develop). In most organizations, taking a product to market involves a set of formalities that allocates sufficient resources and creates the transparency necessary to accompany its progress. Truth be told, proper product discovery is rarely done.
Feature discovery involves actively trying to understand markets, including our customers, and other factors to help shape the evolution of our product during Product Delivery. It is routine and, unfortunately, also under-served on most product teams. We could update the traditional product discovery/delivery diagram thusly:
Feature discovery via approaches like Continuous Discovery is getting a lot of press lately but referred to as just "discovery". This generalization can be misleading.
This table summarizes the differences between these two.
Product Discovery | Feature Discovery | |
Goal | Formal decision on significant product development investment, e.g., new product | Identify features to add to the product (end goal) |
Focus Entity | Product | Features |
Frequency | Exceptional, relatively infrequent | Routine, ongoing during product delivery phase |
Level of Effort/Intensity | High level of effort, intense | Effort depends, but less intense |
Risk Severity Mitigated | Very high, sometimes existential for vendor | Relative low (a failed feature tends to be less disruptive than a failed product) |
As usual, there's a bit of nuance that should be addressed:
There are gray areas between product discovery and product delivery. We can take a conservative approach and limit investment and disruption until we're sure we have product/market fit. However, a formal decision should be made before we take a product to market in a standard way.
I might consider my discovery problem-oriented, i.e., looking for market problems to solve. I would say we only do this so we can explore products and features we'd like to develop. If you like calling this dedicated effort "problem discovery", cool. It should still be followed by product discovery.
While looking for market problems to solve as part of feature discovery, we might uncover opportunities for new products. While this is a possibility, finding new products is not the primary motivation for doing feature discovery.
In conclusion, the distinction between product discovery and feature discovery is critical for product management success. While product discovery focuses on high-stakes decisions about new product investments, feature discovery is a continuous process embedded in product delivery, refining and evolving features based on market needs. Generalizing discovery under a single umbrella dilutes its meaning and overlooks the strategic differences between these two efforts. By being deliberate about how we define and approach discovery, we as PMs can better prioritize and manage input, making informed decisions that drive both innovation and incremental improvement.
Comments