Discovery should help teams decide — not just learn

Discovery is not about collecting endless insights. It’s about reducing uncertainty so teams can make better product decisions with confidence.

Summary:

• Most discovery work fails because teams try to answer everything instead of focusing on the few decisions that actually matter.
• Good discovery is lightweight, collaborative, and tightly connected to business goals, risk, and delivery.
• The goal of discovery is not “more knowledge.” The goal is better decisions.

Discovery is not about collecting more information. It’s about narrowing uncertainty into a few clear, high-impact decisions

How I approach discovery in product teams

Discovery has a branding problem.

For a lot of stakeholders, the word immediately triggers the same mental image: months of workshops, giant FigJam boards, endless interviews, and a team disappearing into “research mode” while delivery slows to a crawl.

Honestly, I understand where that comes from. A lot of discovery work does end up looking like that from the outside. Sometimes from the inside too 😅

The problem is that teams often confuse discovery with information collection. More interviews. More surveys. More synthesis. More dashboards. Meanwhile nobody can clearly explain what decision the team is actually trying to make.

That’s usually where discovery starts breaking down.

Because discovery itself is not the goal. Better decisions are.

For me, discovery is much more practical than people often make it sound. Most of the time, it’s about looking at the information the team already has, identifying the few critical gaps that still create uncertainty, and gathering just enough evidence to move forward responsibly.

Not building a feature for three users with a one million user base.

Not spending six weeks validating something nobody will care about after launch.

And definitely not running discovery for the sake of feeling “user-centric.”

The goal is to reduce uncertainty enough that the team can make smarter product decisions with confidence. That’s it.

Most teams already have more information than they think

One of the most common mistakes I see is teams restarting discovery from zero every single time.

In reality, most product teams are already sitting on a huge amount of useful information:

• support tickets
• sales calls
• analytics
• retention patterns
• feature adoption data
• customer complaints
• internal stakeholder knowledge
• previous research
• session recordings
• roadmap history

The issue is rarely a complete lack of information.

The real problem is usually that nobody has aligned on which questions matter most right now.

That changes how I approach discovery completely. I treat it primarily as a prioritisation exercise, not a research exercise.

The first thing I try to understand is: What are the biggest unknowns currently blocking good decisions?

Once that becomes clear, discovery gets much simpler.

Good discovery starts with questions, not methods

A lot of teams start discovery by jumping straight into methods.

“We should run interviews.”

“We need a survey.”

“Let’s schedule usability testing.”

Maybe. But before any of that, I want clarity on what we’re actually trying to learn and why it matters now.

That second part matters a lot more than people think.

Some questions are urgent because they directly impact prioritisation, revenue, retention, or delivery risk. Others are simply interesting. Discovery becomes messy when teams treat both categories equally.

For example, this sounds reasonable on the surface:

• How can we improve onboarding?

But it’s too broad to create focus. Questions like these are much more useful:

• Why are activated users dropping after day three?
• Which onboarding step correlates most with retention?
• Are we failing to explain the core value proposition?
• Is this actually an onboarding problem at all?

Better questions naturally narrow the scope of discovery. They also make it easier to decide what kind of evidence is actually needed.

Otherwise discovery can quietly become infinite. There is always another interview to run, another insight to collect, another workshop to schedule.

At some point, the team needs enough clarity to make a decision and move forward.

Good discovery helps teams reach that point faster.

I usually structure discovery around risk and uncertainty

This is probably the simplest mental model I use. Discovery exists to reduce uncertainty around product decisions.

Usually the biggest uncertainties fall into a few categories:

• Do users actually have this problem?
• Is the problem important enough to prioritise?
• Does solving it create meaningful business value?
• Are we targeting the right audience?
• Is the proposed solution technically and operationally viable?
• Are we solving the root issue or just a symptom?
• Is this worth the team effort compared to other opportunities?

Once discovery is framed this way, prioritisation becomes much easier because not every question deserves the same amount of effort.

Some unknowns are relatively harmless.

Others determine whether the project should exist at all.

That distinction matters a lot.

I’ve seen teams spend weeks polishing low-risk details while completely avoiding the uncomfortable high-risk questions sitting underneath the project. Usually because those questions are harder to answer.

Things like:

• What if users don’t actually care about this?
• What if the audience is too small?
• What if retention is failing for a completely different reason?
• What if this feature request only matters to one loud stakeholder?

Those are often the questions discovery should focus on first.

My typical discovery flow

Not every project follows the exact same structure, but this is roughly how I tend to approach discovery work.

1. Align on the problem space

Usually this starts with conversations:

• PM alignment
• stakeholder interviews
• reviewing existing metrics
• support and sales insights
• previous research
• product usage data

At this stage I’m mostly trying to understand:

• what people believe is happening
• where assumptions exist
• where opinions conflict
• what business pressure sits behind the request
• how success is currently being framed

This part is useful because teams often realise very quickly that different stakeholders are solving for completely different things.

Sometimes the loudest request turns out to affect a tiny percentage of users. Sometimes the issue everyone calls a UX problem is actually pricing, positioning, onboarding, or expectation mismatch.

Those are very useful things to learn early.

2. Define and prioritise discovery questions

This is where discovery either becomes focused or turns into chaos.

I try to identify:

• highest-risk assumptions
• biggest knowledge gaps
• decisions blocked by uncertainty
• areas with the largest potential impact

Strong discovery questions create direction. Weak ones create endless exploration.

This step also helps the team avoid over-researching low-impact areas just because they are easier or more comfortable to investigate.

3. Split responsibilities across the product trio

I strongly prefer discovery being collaborative instead of becoming “the designer’s research phase.”

In practice, responsibilities often split naturally:

• Designers focus more on user behaviour, workflows, usability, and synthesis
• PMs focus more on business context, prioritisation, and stakeholder alignment
• Engineers or EMs help validate technical feasibility, implementation concerns, and data requests

The exact split matters less than shared ownership.

The strongest discovery work usually happens when product, design, and engineering build understanding together instead of throwing findings over the wall between functions.

4. Reset often and check if you’re still on track

This part is rarely linear.

Teams collect signals, patterns emerge, assumptions change, and new questions appear. Discovery work naturally shifts as the team learns more, which is why I try to pause regularly and reassess where things actually stand.

Usually the conversation becomes:

• What do we know now?
• What changed?
• What still feels unclear?
• Are we still solving the right problem?
• Do we already have enough confidence to move forward?

Those resets matter because discovery can quietly drift into endless exploration mode without anyone noticing. Teams keep collecting information, but the level of clarity never really improves.

The goal is not to keep discovery alive as long as possible.

The goal is to reduce uncertainty enough to make a good decision and move forward responsibly.

Sometimes that takes a week. Sometimes longer. But if a discovery effort keeps expanding without creating more clarity, that’s usually a sign the team lost focus somewhere along the way.

5. Turn insights into decisions

This is where many discovery efforts quietly fail.

Teams gather useful insights, create synthesis boards, share findings, and then never fully translate any of it into concrete product decisions.

A good discovery outcome is not a giant documentation archive.

It’s clarity.

For example:

• We should not build this feature.
• This audience segment is too small.
• The retention problem starts earlier than expected.
• The onboarding issue is actually a pricing issue.
• This request matters internally more than it matters to customers.
• This problem is real, but lower priority than other opportunities.

Sometimes the most valuable discovery outcome is saying no early. That saves teams an incredible amount of wasted effort.

Discovery should stay connected to delivery

Another mistake I see often is teams treating discovery and delivery as completely separate phases.

Discovery ends. Delivery begins.

Real product work rarely behaves that neatly. New questions appear during implementation constantly:

• technical limitations
• edge cases
• adoption concerns
• usability gaps
• stakeholder feedback
• unexpected user behaviour

Good teams continue learning while building and shipping. Not in a chaotic way, just in a practical one.

Discovery should support delivery, not delay it indefinitely.

That’s an important distinction because sometimes teams unintentionally use discovery as a form of risk avoidance. More research starts feeling safer than making a decision.

But execution matters too. At some point, the team needs to move.

Balancing qualitative and quantitative insights

This topic gets overcomplicated constantly.

You do not need perfect data coverage from every angle before making decisions. Most product decisions happen with incomplete information anyway.

What matters more is building enough directional confidence.

Quantitative insights help identify:

• patterns
• scale
• drop-offs
• trends
• behavioural signals

Qualitative insights help explain:

• motivations
• confusion
• expectations
• emotional friction
• context behind behaviour

You eventually need both perspectives, but not always at the same depth.

Sometimes a handful of strong user conversations combined with analytics is enough to move forward confidently. Sometimes it isn’t.

Rigid process matters less here than good judgement.

One of the hardest parts of discovery is communication

Especially when stakeholders disagree.

And they will.

Discovery often surfaces uncomfortable realities:

• the requested feature is not valuable enough
• another opportunity has bigger impact
• the audience is smaller than expected
• users behave differently than stakeholders assumed
• revenue impact is unclear
• the original request solves the wrong problem

This is where communication becomes part of discovery itself.

I’ve found it helpful to keep stakeholders involved early, share learnings continuously, explain trade-offs clearly, and connect findings back to business goals whenever possible.

People usually handle disagreement much better when they understand why prioritisation decisions are being made.

Silence creates resistance. Visibility creates trust.

The best discovery work often feels surprisingly lightweight

That doesn’t mean shallow.

It means focused.

Some of the most effective discovery work I’ve seen involved:

• a few stakeholder conversations
• reviewing analytics
• validating one critical assumption
• a handful of user interviews
• aligning the trio
• making a decision quickly

That’s it.

No giant process. No discovery theatre. No six-week workshop calendar. Just enough clarity to move responsibly. Honestly, that’s usually the goal.

Closing

I think product teams sometimes romanticise discovery a little too much.

Discovery is not magic. It’s not a creative ritual. It’s not endless curiosity for the sake of curiosity.

It’s a practical process for reducing uncertainty.

The best discovery work helps teams:

• focus faster
• prioritise better
• avoid expensive mistakes
• build the right things
• understand trade-offs clearly

And most importantly, make decisions with more confidence. That’s the part that actually matters.