In many organisations, product discovery is treated like a phase. It's the 'research part' that happens before the 'building part' begins. Once a project is defined and handed off to engineering, discovery is considered done. This is project-based discovery, and it's a risky way to build products. It assumes you can know everything you need to know upfront.

Continuous discovery flips this idea on its head. It’s not a phase, but an ongoing, weekly habit. Instead of front-loading all the research, product teams are in constant contact with their customers. They conduct small research activities, run quick experiments, and analyse data every week. This creates a steady stream of insights that informs what to build next. It treats building a product not as a linear race, but as a continuous loop of learning and adapting.

This shift is powered by what Marty Cagan calls an 'Empowered Product Team'. This isn't just a group of people who build features someone else defined. It’s a trio, typically a product manager, a product designer, and a tech lead, who are given a problem to solve, not a feature to build. They are empowered to figure out the best solution together, and continuous discovery is their primary tool for doing so.

The entire purpose of discovery is to systematically de-risk ideas before committing to the expensive process of building and launching them. Every new product idea carries four major risks that the empowered team must address. Think of these as the four legs of a table; if any one of them is weak, the whole thing will collapse.

Project-based discovery often focuses too much on feasibility, asking "Can we build it?" without equally asking "Should we build it?" Continuous discovery forces the team to confront all four risks simultaneously and repeatedly throughout the development process. For example, a team might use customer interviews to tackle value risk, prototype testing for usability risk, a technical spike for feasibility risk, and a business model canvas for viability risk, all in the same week.

To stay organised and focused amidst constant learning, teams need a way to visualise their thinking. This is where an Opportunity Solution Tree comes in. Created by product discovery coach Teresa Torres, this simple diagram connects a desired business outcome to the user problems, or opportunities, that might drive it. Then, it maps potential solutions to those opportunities.

It keeps the team focused on the outcome they're trying to achieve, not just on shipping features. It also helps manage the discovery process by clearly showing which opportunities have been validated and which solutions are being tested. The structure is simple: a clear outcome at the top, branching down into customer opportunities, which in turn branch into specific solutions you can build and experiment with.

A common challenge is knowing when to stay in discovery mode versus when to shift to delivery. This isn't a binary choice, but a spectrum. The decision hinges on one key factor: uncertainty.

If uncertainty is high, you invest more in discovery. This happens when you're exploring a new market, tackling a completely new customer problem, or using unproven technology. Your Four Big Risks are largely unaddressed. Here, the goal is learning, and you'll run many small experiments like interviews, surveys, and building simple prototypes.

If uncertainty is low, you can move more confidently toward delivery. This is common when you're iterating on an existing feature, serving a well-understood customer base, or using familiar technology. The risks are known and mostly mitigated. The goal here is execution, and you'll focus on writing production-ready code, testing, and shipping a high-quality solution.

The key is to continuously assess your level of uncertainty across the four risks. A product trio might decide to spend 80% of their time on discovery for one initiative and only 20% for another, more straightforward one.

This constant calibration is the essence of modern product management. It's about making smart, evidence-based bets on what to build, ensuring that by the time you commit to delivery, you're reasonably confident you're building the right thing.