Discovery Is About Killing Risk, Not Filling Slides

Your team runs discovery. They interview users, run workshops, build decks. Then the deck lands in a meeting and someone says, "We know that's a problem, but we can't do anything about it." The work was real. The impact was zero. This happens because discovery gets framed as producing insight, when the job is shrinking risk. Change the frame and the whole thing gets sharper. Here is how to run discovery so it moves decisions instead of filling slides.

Name the four bets you are actually making

Every product decision is a bet on four things: that people want it (value), that they can use it (usability), that you can build it (feasibility), and that it works for the business (viability). Marty Cagan named these, and Dave Masom's framing is the useful part: product management is a game of risk, and discovery is how you de-risk before you build.

This gives your team a shared vocabulary. Instead of arguing about whether to "do more research," you ask which bet scares you most. A LogRocket breakdown adds the stakes: nine of ten startups fail, often because they never found a real problem people would pay for. That is value risk, and no amount of polish fixes it later.

Most teams over-index on feasibility because engineers are in the room and code feels concrete. Value and viability get waved through. Name all four out loud so the scary ones do not hide.

Point discovery at the bet you are least sure about

Once you name the four risks, you do not chase all of them. You find the one that would sink the product and aim there first. A probability-impact read helps: how likely is this to go wrong, and how bad if it does. Konstantin's rundown of risk types lays out a plain matrix, put likelihood on one axis, impact on the other, and work the top-right corner first.

The payoff is speed. If value is your biggest risk, you do not need a six-week research plan. You need to test buying intent with a prototype and a few real users this week. If feasibility is the risk, you pull in your tech lead and ask what could break before you spec the feature.

Discovery that targets the riskiest bet stays small on purpose. You are buying down uncertainty, not touring the problem space.

Stop shipping insights nobody asked for

A lot of discovery dies because it is too front-heavy and idealistic. Designers get the green light to define the problem, then run big workshops while stakeholders wait for something to demo. By the time findings land, a parallel team already shipped the quick win. Martin Sandström calls this getting stuck in discovery with insights no one asked for, and his fix is blunt: understand why you are on the project and what people expect before you plan a single interview.

His smaller-loop approach is the practical version. Find the smallest substantial insight that would change the solution, run a quick experiment, learn just enough, then correct course. Corporate projects move like oil tankers. They respond to gentle, tactical input, not a grand reveal at the end.

So before your team scopes discovery, answer one question: which decision will this change? If nobody can name it, you are about to produce a report nobody reads.

Package findings so a busy leader can act in ten minutes

Good insight dies in bad packaging. Henry Latham, writing on fluffy discovery, argues the root problem is not weak research, it is research that never gets translated into a decision. Three moves fix that.

First, know your internal audience. A CFO wants finance impact, a product lead wants opportunities other teams are missing. Customize the takeaway, do not read the same deck to everyone. Second, quantify the qualitative. "Struggling to find motivation came up in seven of ten interviews, rated four out of five for pain" beats a stack of transcripts. Third, lead with business value, not just user value. Pair the user problem with a dollar figure: what they spend today, what you could capture.

This is not spin. It is respect for the reader's time, and it is what makes stakeholders trust the next thing your team brings them.

The deep cut

The easy miss is treating de-risking and packaging as two jobs. They are one. When you frame discovery as shrinking a named risk, the packaging writes itself, because you already know which decision you are informing and who owns it. The team that starts with "which bet are we least sure about, and who needs to act on the answer" never produces a report nobody asked for. They cannot, because the audience and the decision were the reason the work existed. Start every discovery with the risk and the receiver, and the fluffy deck problem quietly disappears.

Three questions for your team

• Of the four bets, value, usability, feasibility, and viability, which one worries us most on this project, and what is the fastest experiment that would shrink it?
• Why are we on this project, what decision will our discovery change, and who in the org needs to act on the answer?
• For our last discovery readout, did we quantify the findings and tie them to a dollar figure the business cares about, or did we hand over raw insights and hope?