Problem framing
A feasibility question is a decision in disguise.
Why “can we build it?” needs a constraint, a decision and a useful stopping point.
Start with the decision
“Is this feasible?” sounds like a technical question. On its own, it is usually too broad to investigate efficiently. A demonstration might be possible while a reliable product remains uneconomic. A system might work on representative inputs and still fail under the latency, data or operating constraints that matter. The first useful question is therefore: what decision will this investigation change?
Separate the uncertainties
Consider a proposed system that must extract structured evidence from unfamiliar documents. There are several distinct questions: whether the relevant evidence is present, whether a method can identify it, whether errors can be detected, and whether a person can review the output at an acceptable cost. A convincing example answers only a small part of that set. Separating the uncertainties makes it possible to choose an experiment for each, instead of building a polished demonstration that quietly avoids the difficult cases.
Define what would change your mind
Before an experiment, describe what evidence would justify proceeding, narrowing the scope or stopping. This does not require false precision. A provisional threshold, a set of unacceptable failure modes and a clear statement of what remains unknown can be enough. The important distinction is between evidence that makes an idea look promising and evidence that changes the decision.
Leave a usable answer
A useful feasibility result is rarely just yes or no. It explains what appears possible, under which assumptions, what has actually been tested and what must be investigated next. It should also identify which conclusion is most vulnerable to new information. That gives the team a basis for committing resources — or a defensible reason not to.