Build the smallest thing that can answer the important question.
AI makes it inexpensive to demonstrate a possibility. That can be a gift or a trap. The right prototype answers a specific product or architecture question, rather than merely looking like a finished application.
What single uncertainty should this prototype resolve?
Choose the artifact that can answer that question: a low-fidelity interaction, a technical spike or an evaluation harness. Commit further only when the evidence warrants it.
Every prototype should have a decision at the end.
- Assumption
People need help at this exact step
Test the unknownObserve the current task and test a narrow interaction with representative users
Make the decisionProceed only if the job and proposed change matter
- Assumption
The difficult inputs can be handled
Test the unknownRun a technical slice against messy examples and explicit negative cases
Make the decisionBound the capability or stop if quality cannot meet the requirement
- Assumption
The capability can be operated
Test the unknownExercise identity, integration, latency and usage-cost assumptions
Make the decisionDefine the production scope and remaining risks before a build
A well-designed validation can recommend not building.
Use the least expensive method that resolves the real unknown. Do not commission sophisticated engineering and polished interfaces merely to make the prototype feel complete.
Ask what changed because of the prototype.
- The hypothesis and acceptance case written before testing
- Observed evidence, limitations and unproven assumptions
- A decision to proceed, narrow, change direction or stop
The complete product discovery argument
For CPO, CTO, Head of Product
The situation behind the request
A product leader has a concept for an assistant that reviews complicated customer submissions. Sales sees opportunity; engineering sees uncertain data quality, latency and integration risk. A polished interface will not resolve those unknowns.
Where the obvious solution falls short
Teams often confuse a demo with validated demand, technical feasibility or a business case. Prototypes can also hide the cost of API usage, support, permissions and messy input.
How we would approach the work
We define a hypothesis, user, acceptance case and one hard unknown. Then create an interactive product slice, technical spike or evaluation harness designed to test that unknown with realistic or synthetic inputs.
What the engagement may include
- Product opportunity and user workflow brief.
- Interaction prototype with uncertainty, correction and review states.
- Technical feasibility slice and option comparison.
- Evidence summary, decision criteria and production roadmap.
The choices worth making explicitly
Use low-fidelity interface work before sophisticated engineering when usability is the main unknown. Use a narrow technical spike when model or integration feasibility is unknown. Do not build both for show.
What we would test before calling it ready
Test actual tasks with representative users where permitted, validate input/output quality, estimate latency and cost, and identify unproven assumptions. Never equate positive reactions with purchase intent without evidence.
A sensible first step
Name the one question a prototype must answer. A well-designed validation can tell the team not to build the feature, which may be the most valuable outcome.