A prototype needs a question
“Build a prototype” sounds like a concrete next step, but it can mean anything from a rough physical assembly to an almost complete product. Without a specific question, teams often spend time polishing the visible parts while the important uncertainty remains untouched.
Before deciding what to build, write down the decision the prototype should inform. Examples might include whether a mounting approach survives representative handling, whether acceptable messages can be delivered in the target environment or whether a user can interpret an exception quickly enough.
A prototype earns its value by reducing uncertainty, not by accumulating features.
Find the expensive assumption
List the assumptions that would materially change the project if they proved wrong. Consider:
- physical fit, protection, power and mounting;
- sensor behaviour and measurement quality;
- communications coverage, latency and offline retention;
- device identity and data association;
- integration with an existing service;
- user understanding and operational workload; and
- manufacturing, deployment or support constraints.
The most important item is not always the most technically novel. A simple handling process can invalidate a sophisticated design if the intended users cannot follow it reliably in context.
Choose the right kind of prototype
Physical prototype
Use representative size, mounting, power and exposure to learn about the physical environment. The software may be minimal if the uncertainty is mechanical or operational.
Connectivity and data prototype
Exercise the information path from a device through communications and into storage. Include delayed, duplicated or missing messages if those states matter to the operation.
Workflow prototype
A simple interface or even a structured walkthrough can test whether users understand the status, terminology and action expected of them. It does not need a complete backend when the question concerns comprehension.
End-to-end slice
Build one thin but representative journey across every layer when the greatest risk sits at the interfaces. Keep the scope narrow enough that failures remain diagnosable.
Make the conditions representative
A bench test can remove the very conditions that create uncertainty. Where safe and practical, introduce representative distance, movement, signal quality, handling, user attention and time pressure.
This does not mean treating an early prototype as production equipment. The prototype still needs explicit boundaries, supervision and a clear statement of what its results can demonstrate, and what they cannot demonstrate.
Define evidence before running the test
Agree what will be observed and what result would change the decision. Capture measurements, user observations, failure modes and unexpected behaviour. Avoid reducing the outcome to a general impression that the prototype “worked”.
A useful result may be negative. Discovering that an approach is unsuitable before a larger build is one of the best outcomes a prototype can produce.
Stop when the question has been answered
Prototype code and hardware naturally attract improvements. Once the evidence is sufficient, pause and decide what follows. The next step may be another targeted experiment, a change in architecture, a formal build phase or a decision not to proceed.
Keeping prototype scope tied to uncertainty protects both speed and clarity. It gives the team permission to learn before it commits.