Continue
Continue to a scoped build decision
When the right participants complete the critical workflow or make a meaningful commitment, the result survives honest objections, and the narrow delivery/cost constraints are understood.
Before a build commitment
What to validate before investing in development
Before you invest in development, validate the decision—not just the feature list. A build is easier to justify when you can point to a specific customer problem, a defined buyer, a behaviour that shows real commitment, and a feasible way to deliver the promised outcome. If the most important uncertainty is still “would anyone choose this over doing nothing or using an existing alternative?”, more development will not answer it reliably.
Start by writing down the commitment you are considering: the budget, time, people, integrations or irreversible choices it would require. Then identify the one assumption which, if wrong, would make that commitment premature. Your first test should reduce that uncertainty with real behaviour, not applause.
Evidence boundary
Separate what you know from what you hope
| Known | Assumed | Still unknown |
|---|---|---|
| The customer group, the situation in which the problem occurs, and any current workaround you can verify. | The proposed product is a better option than the workaround. | Whether the right buyer will commit time, access, money, or a comparable scarce resource for the proposed outcome. |
| Constraints that are already factual: budget, delivery capacity, data access, regulation or technical dependencies. | A feature list will be enough to change behaviour. | Whether the narrowest valuable workflow can be delivered reliably at a cost and effort the business can sustain. |
The important distinction is not whether an assumption feels reasonable. It is whether someone outside the team has behaved in a way that would be costly, inconvenient, or difficult to fake if the problem did not matter.
Decisive unknown
The decisive unknown: will the buyer make a meaningful commitment?
Interest is useful for learning language and objections. It is not the same as evidence that a buyer will choose the outcome. Before development, look for a commitment proportionate to the decision: a scheduled working session with the right decision-maker, access to a real workflow, a paid pilot, a deposit where appropriate, or a narrowly defined manual trial. The right signal depends on the risk and context. A person’s safety, privacy, legal obligations, or financial exposure can make a lightweight test inappropriate; stop and obtain the right professional guidance instead.
Illustrative scenario — not a customer case or outcome claim
A manual workflow before a portal
A solo operator is considering a custom portal for client onboarding. They know that clients often send information late, and they assume an automated portal will remove the delay. The decisive unknown is whether clients will complete a clearer, bounded intake without repeated human follow-up.
Before commissioning the portal, the operator runs a two-week manual version with three new clients. Each receives the same short intake, a clear deadline, and one reminder. The test records completion rate, time to delivery-ready, missing-information rate, and the number of follow-ups. It does not prove that a portal will sell, integrate safely, or reduce long-term costs. It only tests whether the narrow workflow deserves a deeper build decision.
Smallest useful test
Run the smallest useful test
- Name one risky claim. Example: “The right buyer will complete this workflow without individual chasing.”
- Choose real participants. Use people who resemble the intended buyer or user, not only friends who want to be supportive.
- Simulate the outcome with the least irreversible effort. A manual concierge delivery, constrained pre-order, prototype review, or observed workflow may be enough. Do not collect sensitive data or make a promise you cannot safely fulfil.
- Set the evidence rule before the test. Define what behaviour counts, the maximum time/cash you will spend, and the condition that means stop or revise.
- Record what happened, including friction. Keep facts, participant comments and your interpretation separate.
Revise
Revise the offer or test
When the problem is real but the buyer, wording, workflow, price, channel, or delivery method is wrong or incomplete. Change one material assumption at a time.
Stop
Stop or defer the build
When the test cannot safely access the necessary data, the right buyer will not make the defined commitment, a viable alternative already solves the problem sufficiently, or the delivery economics cannot work inside the agreed limit.
Evidence limits
What this evidence can and cannot tell you
A small test can show whether a particular risk is worth reducing next. It cannot prove a market is large, guarantee revenue, establish legal compliance, predict product-market fit, or justify unlimited development. Treat a positive signal as permission to make the next bounded commitment—not proof that every later commitment is safe.
If you have one defined commercial opportunity and need the known, assumed and unknown evidence separated before you commit more time or money, explore the existing Kairos decision products. If the commercial decision needs its own scope or evidence plan, use the company site’s custom decision fit review. Legal, tax, employment, financial and other regulated questions still require the appropriate qualified professional.