What is Product Discovery & Product Delivery?

Main Takeaways

Reading Time: 3 minutes Product Discovery and Delivery are crucial in Product Development. In Product Discovery, we identify additional opportunities. In Product Delivery, we test continuously together with the customer our implementation.

Product Discovery

In the Product Discovery Phase, we identify additional opportunities for either implementing (product modifications) or applying our potential solutions (new markets, new customer/user segments). – By differentiating all these options we ensure to build the right product.

This leads us to a predominant challenge and conclusion.

"Before we can deliver Value, we first need to discover Value."

— (Appelo 2022)

"Product discovery is discovery of opportunities."

— (Cagan 2006, Torres 2021)

In this context the following terms are relevant.

Product-Solution Fit: The evidence that a product, or a service, solves a customer’s problem. When customers/users care about certain jobs, pains, and gains we have evidence that a product, or a service, solves a customer’s problem. product-Solution-Fit is a validation of our solution. We test it with prototypes and minimal viable products, MVPs. And if we have no Solution-Fit we iterate or pivot our development.
Product-Market Fit: This term comes from Steve Blank's customer Development Model (Blank 2013). We have a Market-Fit when customers/users are buying our products just as fast as we can build them, or when Usage increases faster than we can scale production. In contrast, we have no product-Market-Fit when customers/users don't fully understand what Value our product or service actually provides (Andresen 2007). The product fits the market, so we can create a sustainable business from it. product-Market-Fit is a growth and scale-up indicator.

Product Delivery

In the Product Delivery Phase, we test continuously together with the customer/user (peer groups) our implementation. Actually, we test several implementation proposals till the customer/user accepts one finally. – This ensures we build the product right (Torres 2021).

Be careful, what we deliver are our decisions what might be valuable.

"We often deliver wrong decisions — causing us to build a faulty product."

— (Carleson 2021)

If we have no feedback loop with the customer, this fault is detected when we show the product to the customer resp. in the market introduction only. We basically will never know what Value something will deliver until it is used by the customer. Therefore we should prototype our solution(s) early and often, and learn early and often (keyword: minimal viable product, MVP).
And we should make decisions at the last responsible moment. That is while we still have some options, but before we run out of options. We should create prototypes with loose internal couplings. When making decisions, we should hold and move smaller sets of decisions to correct mistakes sooner.

Any (Agile) product Development initiative is highly doomed to fail when it starts to solve a problem by taking the first solution coming to mind as the final one, and/or by building a product with a lot of features thinking the most the better.

Essentially, if this happens, we live in a pseudo-agile bubble. Instead:

we should discover as many aspects of the potential problem by staying as long as possible in the Problem Space. Then we decide what you have to solve.
we should discover as many alternatives of potential solutions by staying as long as possible in the Solution Space.
we should defer the decision of which option might be the final one as long as possible. Then we decide how you want to solve it.

In another post, I argued why Scrum a framework for both is: product discovery AND delivery.

Product Delivery Anti-Patterns

Unfortunately, you can do a lot wrong and suddenly, we are in product delivery anti-patterns (Tarnowski 2023).

Product Death Cycle — the failure mode where a team making a B2B, or B2C product focuses on customer/user feedback over product vision.
Product Build Trap — organizations measure their success by outputs rather than outcomes.
Feature Hell — adding feature by feature stress the architecture. Technical debt builds up and the need for refactoring increases. With every change, the development and release time get longer and longer.
Experience Rot — existing users won't use the new features and will stick to the old known essential ones instead. And the new users first need to figure out which basic essential features they need and where to find them.
Scope Creep, Feature Creep — changing given and/or adding new requirements (i.e. features).