Discovery has a stopping problem. Unlike a sprint, which ends on Friday, or a prototype, which is done when it's built, discovery is theoretically infinite. There's always one more customer you could interview. One more data cut you could run. One more stakeholder who hasn't weighed in yet. Teams that feel comfortable in discovery - and discovery is usually more comfortable than the anxiety of commitment - can stay there indefinitely.
But the other trap is real too. Teams under delivery pressure do two customer calls, call it discovery, and start building. They confuse activity with signal. The features ship, the customers don't use them, and the team wonders why their process didn't work.
There's no universal answer to how much discovery is enough, but there are reliable signals for both failure modes.
The signal that you've done too little
The clearest indicator that you've done too little discovery is that the team can't answer the question: what would change our minds? If you've already decided what you're building, and you're doing discovery to confirm it rather than to interrogate it, you're not discovering - you're documenting.
Another signal: the team's ideas aren't changing. If you can look at your ideation artifacts from three weeks ago and two weeks ago and last week, and the same three ideas are at the top every time, you haven't introduced enough new information. Discovery that doesn't change your thinking isn't discovery. It's preparation for a decision you've already made.
A third signal: there's one thing nobody wants to investigate. The uncomfortable question - the one that, if the answer came back a certain way, would require abandoning your current direction - is the one that always gets deferred. Teams that do too little discovery tend to have a sacred assumption at the center of their roadmap. They'll research everything around it but never the thing itself.
The signal that you've done too much
If you're doing interviews but there's no decision on the table that interview findings would change - stop. You're collecting data for its own sake, which is research, not product discovery.
A second symptom: the team keeps introducing new questions to answer before making a decision. "We should interview a few enterprise customers before we decide" was reasonable three weeks ago. Today it's avoidance. Each new question defers the moment of commitment, which is the moment of risk. Teams that are uncomfortable with risk will generate new research questions indefinitely.
A third symptom is more psychological: the team has lost confidence in their ability to make a decision with imperfect information. They're waiting for certainty that isn't coming. Every new data point gets weighed against all the uncertainty that remains, rather than against what they knew before they started. This is a process breakdown, not an information problem.
Discovery isn't about eliminating uncertainty
The framing that causes most of the trouble is this one: that the purpose of discovery is to reduce uncertainty until you're confident enough to act. This is wrong, and it's wrong in a way that leads directly to both failure modes.
Discovery can't eliminate uncertainty about whether customers will adopt something that doesn't exist yet. No amount of interviews resolves that. What discovery can do - and this is the correct framing - is reduce the cost of being wrong. It changes the question from "are we certain?" to "if this doesn't work, how quickly will we know, and how much will it have cost?"
Under this framing, the stopping criterion for discovery is: do we know enough to make a reversible bet at reasonable cost? Not: do we know enough to be certain?
This reframe changes the behavior. Instead of asking "what else do we need to know?" the team asks "what's the cheapest version of this we can put in front of customers to learn the thing we still don't know?" Discovery feeds delivery rather than replacing it.
The decision that ends discovery
Every discovery phase should be scoped to a decision. Not a vague one - not "figure out what to build" - but a specific one, like:
- "Should we build a synchronous or asynchronous collaboration model for our core editing flow?"
- "Which of these three onboarding paths would serve enterprise users better?"
When discovery is scoped to a decision, it has a natural endpoint: the moment when you have enough signal to make that specific call with reasonable confidence.
- The interviews stop when you've heard the same answer enough times that additional interviews would change your confidence by less than the time cost of running them.
- The voting session ends when the ranking has stabilized enough to distinguish the top options from the rest.
Teams that frame discovery as "figuring out what to build" will never be done, because there's no arrival condition. Teams that frame discovery as "answering this specific question so we can make this specific call" can tell when they're finished.
Signals that you've crossed the threshold
Here are the practical signs that you've done enough discovery on a given question:
- The team is having the same conversations they had last week. Not because they're stuck, but because the inputs aren't changing anymore. You've reached the saturation point on a particular question.
- You can articulate not just what you're building but why this over the alternatives. You've considered the alternatives seriously enough to explain why you rejected them. That requires actually generating alternatives, not just affirming your first instinct.
- You know what you'll learn from shipping that you can't learn from researching further. There's a question you can't answer without putting something real in front of customers. That's your signal to stop discovering and start building.
Go deeper
Running structured workshops to move from discovery toward decision is something Bandos was designed for. If your team has done the research and needs to converge on a direction, how Bandos runs discovery workshops walks through the facilitation model. And if you want a visual map of where your team's opportunities sit relative to each other before you commit to a direction, the opportunity solution tree tool gives you that structure.