Skip to main content
日本語
Netsujo日本語

Exit Criteria to Decide Before Starting a PoC

Tomohiro Iida · Published June 5, 2026 · Updated July 11, 2026

What companies unable to reach a production decision after a PoC have in common is not having decided, before starting, on four things: the hypothesis being tested, the KPI being measured, the condition for stopping, and the threshold for moving to production. Simply putting those four into words up front turns a PoC from "just get something running" into "a place to gather the data a real investment decision needs." Design happens before you start, or you end up repeating PoCs with no way to decide anything.

This case focuses specifically on designing PoC exit criteria. For the broader PoC process and cost, see our related article, the PoC guide.

The company's situation (anonymized)

A startup launching a new Web3-related business consulted us about finding a partner to run a PoC. Their technical hypothesis was clear, and the target use case was reasonably well defined. An investment decision needed to be made within a few months, and they wanted the PoC itself completed within about a month.

As we talked it through, we noticed the stated verification goal was only "confirm the technology works" — with no definition of what would be judged once it did work.

For Web3 PoCs, judgment needs to cover not only whether the smart contract and wallet integration work as expected, but also fees, processing speed, UX, regulatory considerations, operational load, security, and integration with existing operations. "It worked technically" is only part of what makes a PoC a success.

Four issues we mapped out in the 30-minute session

Issue 1 — put the hypothesis into one sentence

Whether you can state what you are testing in one sentence — something like "using blockchain can cut identity-verification costs by 50%" — is the starting point. What matters is not leaving "what are we trying to prove" vague.

A theme that tends not to work well is something like "test the potential of a new Web3 business." The scope is too broad — there is no way to tell what result would count as success.

A better example looks like this:

If the answer to "why are we running this PoC" is "we're testing it because we don't know what will happen" — that is not yet the PoC stage. What is needed at that point is not development, but hypothesis definition.

Issue 2 — narrow the KPIs to one to three

A PoC plan listing ten KPIs almost always ends in an unclear decision. More numbers look thorough, but adding numbers you will not actually use for the decision does not speed up decision-making.

Narrow it to the minimum one to three numbers actually needed to test the hypothesis. For a Web3 PoC, example KPIs include:

Not everything needs to be a quantitative KPI, though. Legal, security, and operational issues can be hard to quantify. In that case, separate them out as "checklist items that must be satisfied before production."

For example, "does the design avoid being classified as a crypto-asset," "is the responsibility for private-key custody clear," and "is there a recovery procedure in case of an outage" are go/no-go checklist items rather than KPIs. Separating what you measure numerically from what you require as a condition makes the decision easier to organize.

Issue 3 — write exit conditions as a number plus a deadline

An exit criterion does not work if it is "we'll think about it if the results are worse than expected."

Set a number and a deadline together — something like "do not move to production if per-transaction cost exceeds $0.50," "move to the next phase only if the test environment is running within four weeks," or "redesign the wallet flow if registration completion is below 50%."

Ideally, exit criteria are documented before the PoC starts, and agreed by leadership, the business owner, and the development lead at kickoff. Leaving this vague tends to produce ongoing arguments near the end of the PoC, or after it, along the lines of "it worked technically," "but commercializing it looks hard," or "let's test a bit more."

What is particularly risky is loosening the exit criteria casually after the PoC has started. Of course, a change in external conditions or a discovered flaw in an assumption can genuinely call for revisiting the criteria. But even then, the reason for the change, who approved it, and the date of the next decision should be documented.

Set the criteria before you start. If you change them, record why. Without that discipline, extensions become a way to justify sunk cost rather than a genuine reassessment.

Issue 4 — production-decision conditions and a "90-day plan after Go"

Alongside exit conditions, decide the conditions for moving to production too. This is to avoid stalling out on "so, what happens next?" once the PoC ends.

For example:

Drafting the 90-day plan for right after a Go decision, at the same time you design the PoC, prevents stalling afterward. That 90-day plan should include securing budget, building the team, selecting vendors, legal review, security review, the target users for the beta, and the release-decision date.

A PoC is not something you write a report about when it is over. It exists to feed into the next investment decision. Without deciding what happens after a Go, even a good result will not turn into production.

Three common misconceptions

Misconception 1 — a PoC is technical validation, so the business side can join later
A production decision cannot be made by the technical side alone. Business owners, the development lead, legal, security, and operations each need their own go/no-go conditions. If the verification results are not produced in a form usable for a business decision, you end up at "it worked technically, but we don't know how to interpret it" once the PoC ends. The hypothesis, KPIs, and exit conditions need to be decided jointly by business and technical sides. This matters especially for Web3 PoCs — beyond technical feasibility, the hurdle of using a Web3 wallet, private-key custody, gas fees, regulatory response, user support, and integration with existing systems are what stand in the way of production. A PoC that leaves these out of scope from the start tends not to perform as expected.
Misconception 2 — if the PoC "worked," that is success
Many cases end up unable to go to production even though it worked technically, because of cost, operability, UX, regulation, security, or integration with existing operations. A smart contract simply running is only part of the success condition — whether users can operate it without confusion, whether transaction fees are acceptable, whether administrators can operate it, whether recovery is possible after a failure, and whether it clears legal review also need to be examined. So the success condition for a PoC is not "it works," but "the material needed for a production decision is in place." Even a No result carries real value if the reason is clear.
Misconception 3 — deciding exit criteria is a bad sign, since it assumes failure
Exit criteria are not "a failure scenario" — they are "a decision threshold." Defining the conditions for a Yes and a No as a pair is exactly what lets you move forward quickly regardless of the outcome. Without exit criteria, a gray-zone result leads to endless discussion — not constructive persistence, but delayed decision-making. The purpose of a PoC is not to keep hope alive; it is to decide, with a limited budget and timeframe, whether to invest further.

What happened after

For a company in this kind of consultation, documenting "one-sentence hypothesis," "two KPIs," "three exit conditions (number plus deadline)," "the production-decision threshold," and "a draft 90-day plan after Go" before starting the PoC noticeably sped up internal business decisions.

The PoC itself proceeded on the originally planned budget of JPY 800,000 over four weeks. One of the KPIs ended up hitting the exit criterion, so the decision was made not to commercialize the original concept as planned. On the other hand, a different use case surfaced during testing that looked more viable, and the decision for the next PoC was to pivot toward that narrower use case.

What mattered was that the No result was not treated as a "failure." Because exit criteria were set in advance, the next choice was made based on data rather than the emotions of the people involved.

Our consulting sessions focus on putting the process of "building a decision framework before you run anything" into words in 30 minutes.

Q&A

Can PoC exit criteria really be decided before starting?
Yes, they should be decided before starting. Deciding exit criteria only "once you've tried it" leaves the interpretation of the result open to disagreement among stakeholders, and makes an exit decision impossible. Document exit criteria in a quantitative, pre-agreed form: "if this KPI falls below X, we do not proceed," "if this technical constraint cannot be resolved, we exit," "if this legal or operational condition is not met, we do not commercialize." That said, it is not that the criteria can never change if external conditions or assumptions change. If you do change them, record the reason, who approved it, and the next decision deadline, and make clear the change is meant to sharpen the decision rather than extend the PoC's life.
What is a rough cost guide for a PoC?
At Netsujo, a Web3 PoC is a standard package priced at JPY 800,000 over four weeks, covering technology selection, a PoC design document, KPI design, and defining exit criteria. With a narrower scope it can start from JPY 500,000; with multi-chain comparison, smart-contract implementation, integration with existing systems, and legal or security review included, it can run JPY 2-5 million. Details are published as a range on our pricing page. When looking at PoC cost, it is safer not to judge on development cost alone. Check whether it includes a design document, KPIs, exit criteria, and go/no-go decision material usable for the business decision.
How should we think about cost recovery if the PoC "fails"?
We design the cost around the idea that a PoC is "an investment that pays off regardless of whether the conclusion is Yes, No, or Pivot." Even with a No result, if "why it was No," "which assumption broke down," and "what to try next" are clearly documented, that becomes material for the next investment decision. The biggest loss is not failing — it is repeating PoCs that cannot be judged, and burning budget and time without a decision. Setting exit criteria up front speeds up the decision once a No comes in, which minimizes the cost of exiting.
How to run a PoC
Five things in common among companies that stall out on a PoC
Three design decisions before using an NFT as a "certificate"

We help put "what to test" and "what threshold decides exit versus production" into words in a 30-minute consulting session.

Book a consulting session