Discovery is essential. I'm not arguing against it. But I've watched too many teams use discovery as a place to hide from the discomfort of making a decision.
The pattern looks like this. The team identifies a problem worth solving. Someone suggests doing discovery. Great, that's the right move. They run user interviews. They map journeys. They synthesise findings. All good so far. Then someone says "we need more data." They run a survey. They do competitor analysis. They build a service blueprint. They present back to stakeholders, who ask good questions, which triggers another round of research.
Eight weeks have passed and nothing has shipped.
The trap is that research always feels productive. You're learning things. You're being rigorous. Nobody gets criticised for being thorough. But at some point, the marginal value of the next interview or the next analysis drops below the cost of not building anything. The team knows enough to make a bet, they just don't want to, because making a bet means you can be wrong.
The fix is putting a timebox on discovery before it starts. Two weeks. Maybe three if the problem space is genuinely new. At the end of that window, you make a call with what you've got. Not a perfect call, a good enough call. Then you build something small, ship it, and learn from real usage instead of hypothetical scenarios.
The best product teams I've worked with are fast at this. They move from "we think this is true" to "let's find out" in days, not months. They treat discovery as fuel for decisions, not a substitute for them.
If your discovery phase is longer than your build phase, something has gone wrong. Ship the smallest version of the thing. The market will tell you more in a week than another month of research ever will.