You are about to spend three months building a feature nobody asked for. That is the exact problem product discovery marty cagan built his entire framework to prevent. Cagan, co-founder of Silicon Valley Product Group and author of INSPIRED, spent decades studying why strong engineering teams still ship products customers ignore. His answer: teams skip discovery and jump straight to delivery, betting real budget on unvalidated assumptions.
If you want a straight answer on what his framework actually says, here it is. Cagan argues that every product idea carries four risks: value, usability, feasibility, and business viability. Discovery exists to test those risks fast and cheap, before a single sprint gets planned, using techniques like customer interviews, prototypes, and concierge tests.
This article breaks down how the framework works in practice. You will get the reasoning behind empowered product teams, the specific discovery techniques Cagan recommends, and how the process connects to prioritization and roadmapping once an idea earns the green light. If you run a SaaS product and want fewer wasted builds, this is where you start.
Most failed features share the same origin story: someone had a good idea, stakeholders liked it, and the team built it without ever testing it against a real customer. Research cited by Harvard Business Review and repeated across the product management world puts the failure rate of new products somewhere between 40 and 90 percent, depending on the industry. Cagan's framework exists because that failure is almost always avoidable. Product discovery replaces guesswork with evidence, and it does that before engineering time gets spent, not after.
Cagan draws a sharp line between what he calls feature teams and empowered product teams. Feature teams take a roadmap handed down from executives and simply build what's on the list. They measure success by output: did we ship the feature on time? Empowered teams work differently. They get handed a problem to solve, not a feature to build, and they own the discovery work that figures out the right solution. Success for them means outcomes: did this actually move the metric leadership cares about?
A roadmap full of shipped features means nothing if none of them changed customer behavior.
This distinction matters because it changes who does discovery and when. In a feature-team model, discovery either doesn't happen or happens too late, usually as a rubber stamp on a decision that's already been made. In an empowered model, discovery happens continuously, before commitments get made public.
Cagan structures discovery around four questions that every product idea has to answer before it earns a place in the sprint. Skipping any one of them is how teams end up with features that work perfectly but that nobody wants, or that customers want but that the business can't support.
| Risk | The question it answers |
|---|---|
| Value | Will customers actually choose to use this? |
| Usability | Can they figure out how to use it? |
| Feasibility | Can engineering build it with the time, skills, and technology available? |
| Business viability | Does it work for the business, legally, financially, and strategically? |
Most teams are decent at feasibility since engineers naturally think in those terms. Value and viability get skipped far more often, because they require talking to customers and to stakeholders outside the product team, which takes more coordination than writing code.
Skipping discovery doesn't just waste money, it wears teams down. Engineers who spend a quarter building something that gets pulled two weeks after launch start to disengage from the roadmap entirely. Product managers who keep defending features that flop lose credibility with leadership. Running lightweight discovery first, even a handful of customer conversations or a clickable prototype, gives teams a defensible reason to say yes or no before resources get committed.
Teams that adopt this habit also get faster over time, not slower. Once discovery becomes routine rather than an occasional extra step, the cycle time between having an idea and knowing whether it's worth building shrinks from months to days. That speed is the actual competitive advantage Cagan is describing, not a specific technique or tool.
Cagan's process isn't a rigid stage-gate system, it's a loop that product teams run continuously, usually inside weekly cycles. Product discovery starts with framing a problem worth solving, not a feature worth building, and it ends with enough evidence to greenlight or kill the idea before engineering commits real time to it.
Before any prototype gets built, the team writes down the specific customer problem and the business outcome it should move. Cagan calls this opportunity framing, and skipping it is why so many discovery efforts drift into building whatever the loudest stakeholder suggested. A well-framed opportunity names the customer segment, the pain point, and the metric that should change if the solution works.
Cagan recommends product trios, meaning a product manager, a designer, and a tech lead, work together on discovery every week rather than handing it off in sequence. A typical week looks like this:
Discovery isn't a phase before the sprint, it's a parallel habit that never stops running.
This cadence keeps the loop short enough that a bad idea gets caught in days, not quarters. Teams that batch discovery into occasional big research projects lose that speed advantage entirely.
Many product managers still treat engineers as a resource to consult only once a solution is designed. Cagan argues that's backwards. Tech leads catch feasibility problems in the framing stage, sometimes suggesting a simpler technical approach that changes what's even worth testing with customers. Waiting until after design is finished means expensive rework or, worse, a design that gets built as-is even though it's technically wasteful.
Ownership of the loop also matters more than any single technique inside it. Product managers hold the responsibility for the outcome, but they don't run discovery alone. Designers bring the interaction expertise that catches usability problems before a line of code exists, and tech leads keep the team honest about what's actually buildable. Getting that trio functioning as a real unit, meeting weekly and making decisions together, is what separates teams that discover fast from teams that just talk about discovery in retros.
Cagan's framework only works if teams actually run the techniques, not just talk about them in planning meetings. Each technique targets a specific risk from the four listed earlier, and most discovery sprints combine two or three of them rather than relying on one. Product discovery marty cagan style is deliberately lightweight: the goal is a confident yes or no in days, not a polished research report in months.
Cagan is blunt about the biggest mistake teams make here: asking customers what they want instead of asking about their actual behavior. A question like "would you use a feature that does X" gets a polite yes almost every time, regardless of whether the person would ever open the app for it. Better interviews dig into a recent, specific incident: when was the last time this problem came up, what did you do about it, and what did that cost you? That pattern surfaces real value signals instead of flattery.
If a customer can't describe the last time they had the problem, the problem probably isn't as painful as the pitch assumes.
Once an opportunity looks promising, the trio builds a low-fidelity prototype, often nothing more than clickable Figma screens, and watches five to eight target users try to complete a task with it. This step catches usability risk cheaply, before a single line of production code exists. Cagan pushes teams to test with real users outside the building, not coworkers, since internal staff already understand the product's logic and won't struggle the way a new customer would.
Fake-door tests put a button or landing page in front of real traffic to measure demand before anything gets built behind it. Concierge tests go further, manually delivering the outcome to a handful of customers to see if they'll actually pay or commit time. Both techniques test value and business viability with far less investment than a full build.
| Technique | Risk it tests | Time typically needed |
|---|---|---|
| Customer interviews | Value | 2-4 days |
| Prototype testing | Usability | 3-5 days |
| Fake-door test | Value | 1 week (traffic dependent) |
| Concierge test | Value, viability | 1-2 weeks |
None of these replace shipping the real thing eventually. They exist to filter out the ideas that would have failed anyway, before a sprint gets committed to them.
Discovery and delivery are not two sequential phases, they run side by side in what Cagan calls dual-track agile. One track constantly tests new opportunities while the other track builds and ships whatever has already earned enough evidence. Confusing this with a waterfall handoff, where discovery finishes before delivery starts, is one of the most common ways teams misapply the framework. The two tracks share the same trio and the same backlog, they just move at different speeds.
Once a discovery cycle produces enough evidence to justify a build, the idea moves into the delivery backlog with a clear opportunity statement already attached. Engineers building it already understand the customer problem, because a tech lead sat in on the discovery work from day one. This is what keeps delivery fast: nobody is debating whether the feature matters once a sprint starts, that argument already happened during discovery.
Delivery should never be where a team argues about whether an idea is worth building, that decision belongs to discovery.
A public roadmap only stays credible if the items on it survived discovery first. Teams that publish a roadmap based on stakeholder requests, then discover mid-sprint that the feature doesn't test well, end up either building something they know is weak or breaking a public commitment. Running discovery ahead of the roadmap, not after it gets published, avoids that trap entirely. This is also where a tool matters. A feedback portal that captures requests and votes gives the discovery track raw signal about which problems are worth framing as opportunities, while a roadmap with clear customizable statuses like planned, in progress, and shipped keeps customers informed without promising outcomes that haven't been validated yet.
Sprint pressure is the fastest way to kill a discovery habit. When deadlines tighten, the trio's Friday review gets skipped first, and within a few weeks the team is back to a pure feature-factory model. Cagan's advice here is blunt: protect discovery time the same way you protect testing time, because a team that only delivers eventually runs out of validated ideas to deliver. Guarding even a few hours a week for discovery, even during a heavy release cycle, keeps the pipeline from running dry three months later.
Cagan's framework comes down to one habit: test the idea before you build it. Frame the opportunity, run a trio through weekly cycles, and pick a technique that matches the risk you're actually worried about. Customer interviews catch bad value bets, prototypes catch usability problems, and fake-door tests catch both before engineering spends a single sprint. None of this requires a research department. It requires discipline and a place to capture what customers are telling you.
That last part is where most teams stall. Feedback sits scattered across support tickets, sales calls, and Slack threads, so nobody can frame an opportunity with real evidence behind it. A centralized feedback portal fixes that by collecting requests, votes, and comments in one place your product trio can actually use. If you want discovery backed by real customer signal instead of guesswork, try Koala Feedback and start building what your users actually asked for.
Start today and have your feedback portal up and running in minutes.
