If the answer cannot change the decision, I probably do not need to ask the question.

I have started judging Discovery differently. I used to associate thoroughness, at least partly, with how much had been covered: how many discovery questions I had prepared, how many angles had been explored, how complete the requirements gathering looked. More recently, I have been asking a different question first: how much of this do I actually need to ask another person?

A surprising amount of information already exists somewhere. It may be in a document, a workflow, a previous decision, a dataset, an example, a system people already use, or simply in an observable result. If I can recover that evidence myself, asking someone to reconstruct it for me is not deeper Discovery. It is often just moving analytical work from me onto the client, owner or user.

That has led me to a simple test for many questions: what uncertainty is this intended to resolve, and what could become different because of the answer? The answer might change scope, feasibility, risk, whether the work is ready to price, which option still makes sense, or what the next bounded step should be. It might expose a contradiction or invalidate an assumption. But if I cannot explain what the answer could change, I am becoming much less convinced that the question deserves to be asked.

This does not mean that fewer questions automatically produce better Product Discovery or customer Discovery. In practice, asking fewer questions can require more work. I may need to read what already exists, compare sources, inspect current behaviour, separate facts from assumptions, identify the real unknowns and decide which of them matter before I ever open a conversation. The visible questionnaire gets shorter because more of the Discovery happened before the questionnaire existed.

AI has made this distinction more important for me. Generating a comprehensive-looking list of discovery questions is now almost trivial. Give a model a product idea or a client brief and it can produce fifty polished questions across users, workflows, integrations, risks, data, constraints and success criteria in seconds. That can be useful as a coverage check, but the length and polish of the list are no longer evidence that the Discovery itself is good.

The harder work is deciding which questions matter enough to interrupt someone with. A question about the current process may be unnecessary if the process is already documented and can be observed directly. A question about a requirement may be premature if the underlying problem is still unclear. On the other hand, a short question about a trade-off, an exception, a priority or a decision that is not captured anywhere may change the entire direction of the work.

There is an important limit to this idea. I cannot know every useful question in advance, and exploratory conversation still matters. Sometimes a question is valuable precisely because it reveals an unknown I had not modeled yet. The standard is not that I should know the answer before asking; it is that I should usually be able to explain why I am asking and what uncertainty the answer might reduce.

That changes the role of a questionnaire for me. It is no longer a checklist that proves I have been thorough. It is the remainder after I have used the evidence already available and narrowed the problem as far as I reasonably can. Each remaining question should earn the interruption it creates.

It also changes what I expect Discovery to produce. A good Discovery process does not have to end with an implementation plan. It may conclude that more evidence is needed, that the scope is not yet ready to price, that the current idea is not justified, that AI is unnecessary, or that the next step should be validation rather than building anything. Those are legitimate outcomes if the evidence points there.

I still ask plenty of questions. The difference is that I no longer count the questions themselves as evidence of quality. If an answer cannot change a decision, materially reduce an uncertainty or alter what happens next, I probably do not need to ask the question.