The image was generated by AI – hereby labelled accordingly :)

"Just one more week of research and we'll be ready to decide." And the one week becomes three months and no actual decisions are made.

Sounds familiar?

This pattern is the silent killer of product discovery, and it might be happening right under your nose.

One of the most common complaints about product discovery I hear from product leaders is that their product teams let it drag on endlessly, disconnected from decisions.

The hard truth: If your discovery activities don't help you make a decision by a specific date, you're not doing discovery. You're doing research theatre.

Let me break down the crucial difference and show you how to fix it.

1. Discovery vs. research: A different lense.

"The essence of product discovery is to be able to very quickly and inexpensively determine whether a given product idea is worth building" - Marty Cagan.

In his different writings, Marty Cagan emphasises that the goal of product discovery is to decrease business risk, and the output of product discovery is knowledge, insights, learning. Based on which decisions can be made.

Similarly, Teresa Torres keeps arguing that not in every case we are searching for the absolute truth but especially for not high risk unknowns we are looking for good enough insights to make decisions.

I personally have started to make this difference between Research and Product Discovery, based on my own experience from the classic product management world vs. tech product management world, working with researchers, Lean Startup, and my learnings built up over the time while building products at different tech companies:

↳ Research is for finding the truth.

↳ Product Discovery is for making informed decisions and reducing business risk.

Both are necessary and they have their place! But when teams confuse these purposes, discovery becomes an academic exercise that never leads to decisions.

I often use the terms "dirty research" for product discovery and "deep research" for thorough investigation. With this wording I want to express that with product discovery we use methods from research but we know that we don't apply them perfectly correct - therefore "dirty". Because our goal is not to understand the full truth but to make decisions to get to a solution that we believe has potential and want to test "in the wild" to get "real market feedback fast". And because we know it's dirty, we know that the results are biased, and therefore it's one piece of information in a see of data that should help make a decision.

When we have no idea about the world we operate in, no idea about our target group or the problem space, no idea about market dynamics, or other foundations truths, then we need to do proper "deep research" because then the goal is to understand the truth.

This simple distinction helps teams quickly decide whether they need to make a decision or truly understand the complete truth.

Just last month, I worked with a team that had spent two months on "discovery" but couldn't tell me what decision they were trying to make. They had mountains of fascinating data, but no clarity on how it would shape their product.

2. Three ways to break out of the discovery time trap

If your discovery work is taking too long, here are three immediate actions:

A. Refocus on the decision

Ask your team: "What decision do we need to make by when?"

Then work backward:

• What specific learning will enable that decision?

• What's the fastest way to gain that learning?

• What can we do within our time frame?

This simple reframing can transform months of discovery into weeks.

B. Tighten your learning questions

Vague questions lead to endless exploration. Instead of "What do users think about our onboarding?" try "Which specific onboarding step causes most users to drop off?"

The more specific your question, the faster you'll get actionable answers.

C. Revisit your experimentation methods

Often teams default to time-consuming methods when faster alternatives exist:

• Instead of a six-week user study, could a two-day rapid testing session answer your key question?

• Instead of building a working prototype*, could a simple paper prototype test the concept?

• Instead of waiting for perfect data, could a small sample give you directional clarity?

*Now with AI you could argue that building a working prototype doesn't take so much time anymore. For one, in many companies out there AI is still not a thing due to various different reasons. For them, building a working prototype still takes quite a lot of time. For two, even with AI, I facepalm those moments when I see a team argue about unnecessary details in this prototype that don't test the concept but simply bloat the solution they want to present. And yes that takes time which you could reduce. And three, testing a working prototype and testing a paper prototype have two different goals and consequences. Use them as two different experiment types that you pick depending on what you are trying to learn.

3. Two real-world examples that take just 1-2 weeks

Example 1: Prioritising outcomes from an Impact Map

Imagine you've created an Impact Map with multiple potential outcomes. Instead of endless debate about which to prioritise:

1. Extract the leaf-outcomes from your Impact Map

2. Create a simple survey asking about satisfaction and importance

3. Send it to 15-20 people who represent your target actor

4. Plot the results on an opportunity scoring matrix

5. Make your decision based on clear data

Total time: 1-2 weeks, not months.

Example 2: Testing if your product creates value

Want to know if people will actually value (and pay for) your solution?

1. Create a simple explainer or a fact sheet with screen prototypes (2-3 days)

2. Recruit 12 people from your target group (3-4 days)

3. Conduct problem interviews and show the video (5 days)

4. Ask if they want immediate access

5. If yes, mention the price and ask them to pay now

6. When they reach for their wallet, tell them it's not built yet but offer to add them to a waitlist

If they're willing to pay on the spot, you've validated the value proposition in a bit more than two weeks.

I've personally run this exact experiment multiple times. It works.

4. The discovery speed shift

The key to fast, effective discovery is remembering that its purpose is decision-making, not perfect knowledge.

Ask yourself:

• "What's the minimum insight needed to make this decision with confidence?"

• "How quickly can we get that insight?"

• "What specific decision will this information inform?"

And if there is a timeline, then "What is realistic to test and how can we realistically test this with high-enough evidence strength until that date?"

When you approach discovery with this approach, what once took quarters can often be accomplished in weeks or even days.

Remember: In product discovery, the goal isn't to gather all possible information, but the right information within your timeframe to make decisions and reduce business risk.

What's your experience? Has your team ever been stuck in never-ending discovery? Which of these approaches could help you speed things up?

Get in touch and share your most interesting discovery time trap stories with me. Maybe the ones that made you most desperate 😉

-

This article was edited by Viktoria Jancurova.