Discovery Fails Before You Ever Talk to a Customer

Most leaders think bad discovery means not enough research. They picture a team that skipped the customer calls and guessed. That is rarely the problem. The teams that waste a quarter are often the ones doing plenty of research. They just aim it wrong. They rush to build, hear what they already believed, and run tests that prove nothing. When budgets are tight, those mistakes cost real money. Here is a way to think about the traps and steer around them.

The problem is jumping to build, not doing discovery

When a project goes sideways, people blame discovery itself. Too slow, too fluffy, not worth the time. That aim is off. As Tim Herbig puts it, the real trouble is "jumping on the Delivery of new ideas too quickly" before you have checked that the problem is real and the idea holds up without writing a line of code.

The pull to ship is strong. Your team wants to finally put something out there. That urge feels like progress, but it skips the cheapest step: validating an idea before you spend engineering hours on it. Small shipped increments do help you learn once you are past the big unknowns. Before that, the smart move is to stay out of the solution space and prove the problem exists first.

Discovery before delivery is a money decision

This is not about being thorough for its own sake. It is about not burning cash on things nobody uses. Prashant Mahajan cites Harvard research that 95% of products fail and 80% of features built are rarely or never used. That waste adds up to billions spent on work that delivers no value.

Discovery narrows you down to the features people use often and pay for, the ones that solve the bulk of a customer's problem. Everything else is a candidate to cut. In a downturn, customers get price sensitive and will not spend on things that do not clearly help them. Fixing the wrong bet after launch costs far more than catching it early. So treat discovery as risk reduction, not overhead. It is cheaper to learn than to rebuild.

Guard against hearing only what you already believe

Confirmation bias is the sneaky one. You go into research half-sure of the answer, and you find it, because you asked in a way that made it easy to find. The UserVoice team calls it the human habit of believing ideas that already fit our views, and it stalls real learning.

Build guardrails so your assumptions get checked. When research contradicts what you thought, treat that as the good stuff, not noise to explain away. Ask for the counterpoint before you decide. Get a teammate to poke holes. Watch how a downturn-focused piece frames it: observe customers in their real setting instead of pulling them into a lab, where it is too easy to ask leading questions and hear the answer you wanted. The point is to make it hard to fool yourself.

Test with a strategy, or do not test at all

Continuous discovery can turn into a treadmill. Talking to users every week feels virtuous, but Herbig warns it can lead to small-step thinking and chasing every new bit of insight instead of shipping what you already validated. His rule is worth stealing: if you do not have a pressing question to answer right now, or the capacity to act on a finding within about four weeks, running research puts your execution at risk.

Know your testing limits too. A conclusion built on one person is shaky. An A/B test with 100 people will not give you a real result. Do not chase quantitative tests when you lack the numbers, and do not keep validating past the point where building the thing is the fastest way to learn. To keep tests tied to strategy, an Impact Map forces you to connect a business goal to the actors, the behaviors you want to change, and only then the solutions worth testing.

The deep cut

The traps look like separate mistakes, but they share one root: doing discovery without a clear strategic fit. Herbig calls this "discovering without clear guidance," and says if you cannot explain how an effort fits your product's overall strategy, you are wasting your time. That is what ties it all together. Jumping to build, confirmation bias, and aimless testing all get worse when nobody set the goal first. Fix the fit, and the other traps mostly close on their own. When a new idea or actor shows up, hold it against your goal. If it does not move the goal, it does not get your quarter.

Three questions for your team

• Are we chasing too many ideas at once, and can each one point to the strategic goal it serves? If not, cut the ones that cannot.
• For each research effort on our calendar: do we have a pressing question, and the capacity to act on the answer in the next four weeks? If neither, cancel it.
• Where are we about to build something we have not validated without code, and what is the cheapest test we could run first?