02 / Note
Product Validation
How I Validate AI Products Before Expanding Them
A practical note on testing a bounded workflow before adding more features, claims, or operating complexity.
Before expanding an AI product, I first ask whether the current workflow can be used, inspected, and verified with a clear boundary.
The useful loop is deliberately small: build the smallest version that can answer one real question, put it in front of real users, observe actual use and willingness to pay, then expand only when the evidence supports the next step. The loop is a decision discipline, not a promise that every experiment will become a product.
Start with one useful question
An MVP is easier to validate when its job is explicit. The first version should make one workflow possible and make its limits visible. That means defining what goes in, what comes out, what remains a human decision, and which result would justify another iteration.
The boundary is not an excuse to hide unfinished work. It is a way to make a useful test reviewable. A small workflow with clear failure states is more informative than a large surface that cannot show which part created value.
The validation loop
- Build the smallest useful version. Keep the workflow narrow enough to inspect from input to output.
- Put it in front of real users. Observe where people understand the workflow, where they hesitate, and what they actually use.
- Record the evidence. Separate observed use, willingness to pay, and implementation assumptions. Do not turn an assumption into a result.
- Choose the next decision. Expand, revise, pause, or remove the workflow based on the evidence available.
MVP discipline is not low quality
| MVP discipline | Low-quality shortcut |
|---|---|
| One bounded workflow | A feature list with no clear job |
| Explicit limitations | Missing behaviour described as flexibility |
| Tests and reviewable output | A demo that cannot be checked again |
| A decision after observation | Expansion because the roadmap looks empty |
The distinction matters. Validation does not mean asking users to accept careless work. It means making the smallest version honest enough that the next decision can be made from something real.
Limitation — This principle does not provide conversion data by itself. It only defines how to collect and interpret evidence before expanding scope.
A practical decision record
question: Can this bounded workflow be used and reviewed? observed_use: Record what people actually did. missing_evidence: Record what remains unknown. next_decision: Expand, revise, pause, or remove.
The actionable takeaway is simple: write down the question before adding the feature. If the current version cannot produce a reviewable answer, more scope will usually make the decision harder, not clearer.
Continue from here