A Good Discovery Can End with "Don't Build This"

Stop a proposed build when the evidence supports a simpler change or the benefit fails the agreed test. Discovery should leave you with a clear next step.

An idea can be exciting and still be the wrong thing to build now. I record a decision the team can act on, including a clear reason to revisit it.

When should discovery lead to a decision against building?

It depends on what the evidence rules out. Choose a simpler change when it addresses the need adequately. Pause when a specific dependency remains unresolved. Stop the current proposal when its benefit or feasibility fails the agreed test. Build when the remaining uncertainty can be managed within a clear scope.

I put those options on the table before research starts. If building is already assumed, every finding can become another feature. We need room for the evidence to change the direction.

What would make stopping a useful result?

Take a hypothetical business that wants an AI estimating assistant. The idea sounds straightforward: generate the text faster and send estimates sooner. First, I check what holds up an estimate.

Suppose the walkthrough shows pricing information arriving late. The team tries clearer intake and gives someone responsibility for unresolved questions. That lets them test the delay they actually found.

If that change addresses the delay, I reassess the writing assistant. We have another way to improve turnaround. Record the comparison before deciding whether development still earns its place.

This is a hypothetical decision path. It illustrates the comparison I am proposing; it supplies neither a client result nor a measured saving.

I want the record to explain why the direction changed. The business still has an outcome to improve. It can keep working on estimate turnaround through the simpler approach.

What does the failure evidence actually tell you?

As of October 2026, CB Insights identifies running out of capital in 70% of 385 failures with coded reasons.

The cohort consists of VC-backed shutdowns. Reasons overlap, and the analysis draws on public accounts after the businesses failed. It is a selected retrospective sample.

That number cannot predict your company's future or calculate discovery's return. I take it as a reason to discuss the economics alongside whether people want the product.

For the decision in front of us, I compare the expected benefit with delivery and continuing operation. I also check who will maintain the information the product depends on.

How do you distinguish stopping from needing more research?

I write down the unanswered question first. What answer would change our direction? If either answer leads to the same choice, I look for a better use of the next session.

If an important assumption remains testable, I choose a small experiment. Before running it, I record what result would justify continuing and what would lead us to stop.

For the hypothetical estimating assistant, compare total completion effort with a template. It should include the work needed to check the estimate and resolve missing information.

If suitable inputs are missing, I check whether we can obtain them. Give that dependency an owner. A pause needs something specific to resolve, with a reason to expect progress.

What are the trade-offs between the available decisions?

I use the following decision aid to make the choice and its trade-offs visible:

Decision	Reason to choose it	Trade-off to acknowledge
Build a bounded solution	Need and feasibility have support	Delivery and operating commitments begin
Improve the existing process	Simpler change meets the need	Some limitations may remain
Pause the proposal	A specific dependency can be resolved	The current problem continues meanwhile
Stop the proposal	Benefit or feasibility is inadequate	A future opportunity may require reassessment

Stopping has a cost too. We can abandon an opportunity too early. I record why the evidence is sufficient for this decision and what remains uncertain.

I keep the conclusion tied to the proposal. Stopping an estimating assistant tells us little about AI elsewhere in the business. The evidence supports a decision within a particular scope.

What can a feature withdrawal teach us?

As of October 2026, Apple's iOS 18.3 release notes retain a scoped example. They state that notification summaries for News & Entertainment apps were temporarily unavailable in that release.

That verifies a temporary withdrawal for a particular category. Its scope is limited to that category and release.

My inference is to give the pilot an exit path. I want operators to keep working if we withdraw a problematic part. That needs to be designed before people depend on it.

For an estimating assistant, that could mean returning to the existing process while checking a specific input category. Define who makes that decision and how operators continue working.

How do you make a decision against building concrete?

Put the reasoning in a short record:

1. State the original proposal and the user outcome it was meant to improve.
2. Summarise the evidence and its limits, with links to the supporting material.
3. Explain the alternatives considered and why the selected direction fits better.
4. Name the next owner and the condition that would reopen the proposal.

I also name what happens to the original problem. If it remains, someone needs to own the next step. The feature can stop while work on the need continues.

For a pause, the reopening condition might be access to suitable input records. For a stopped proposal, it might be evidence that the simpler approach fails to meet demand.

I tie reconsideration to a change in the evidence. A date alone gives us little reason to reopen the proposal. State what would make the decision different.

How does this fit a delivery process?

Discovery should inform whether we proceed to Requirements and what belongs in the PRD. If we continue, we agree the outcome and scope before Iterative development.

As of October 2026, Google's engineering guidance allows simpler approaches before machine learning. Choosing the appropriate amount of software belongs in the product decision.

Start Before the PRD for that sequence. Use Do You Need AI, or a Better Form? to compare concrete alternatives.

You can see the process and the available offers. If a build decision needs examination, book a call with the proposal and the evidence behind it.

I want discovery to change what we do when the evidence calls for it. Sometimes that means putting the build aside.

What else should you know about stopping a build?

Is discovery wasted if we stop the build?

Research is useful when it changes a decision. Record what the evidence supports and redirect effort toward the need that remains.

What is the difference between pausing and stopping?

Pause when a specific missing input could make the proposal viable. Stop the current proposal when evidence supports a different direction or the benefit is inadequate.

Can a successful prototype still lead to stopping?

Yes. A prototype can perform the task while failing the wider test of demand, operating effort, or acceptable consequences.

What should a decision to stop include?

Include the proposal, evidence, alternatives, and reason for the decision. Name the condition that would justify revisiting it and who owns that review.