Name the uncertainty
A prototype should answer a specific question: can users complete the workflow, can the integration supply the required data, or does the technical approach meet a measured constraint? Write down what is unknown and why it blocks a decision.
Choose the smallest credible experiment
Use a clickable prototype for interaction questions and a technical spike for implementation questions. A convincing interface does not prove reliability, and a working algorithm does not prove usability. Match the experiment to the uncertainty rather than building a miniature full product.
Set evidence and stop criteria
Agree which observations would support continuing, changing direction or stopping. Document sample limitations and assumptions. Use representative test cases where permission allows, and label synthetic data clearly. Avoid turning a demonstration into a performance claim.
Decide what can reach production
Review which prototype code can be retained and which parts need replacement. Production work may still require access controls, tests, monitoring, deployment and support. Capture findings and unresolved risks so the next investment decision rests on evidence.
Bring this to your project brief.
- A testable question and its business impact
- Representative inputs and evidence criteria
- A decision owner and production-readiness gaps
Use general descriptions or anonymized examples. Do not put credentials, personal records or confidential documents into the brief.
Prepare your project brief