Experimental R&D
Prototype the uncertainty, not the entire product.
The most useful prototype is the smallest experiment that can expose a consequential failure.
A prototype needs a question
A prototype can demonstrate a user experience, test an algorithm, reveal an integration constraint or expose a research problem. Those are different jobs. If its purpose is unclear, a team can spend weeks improving the parts that already work while the main uncertainty remains untouched.
Choose the uncomfortable input
Suppose a proposed method works on one carefully chosen example. The next step is not necessarily a larger interface or a more impressive demonstration. It may be a deliberately awkward input: missing information, a shifted distribution, a conflicting constraint or a case that defeats the method’s central assumption. Finding that boundary early is useful work, even if the prototype becomes less presentable.
Keep the shortcuts visible
Every prototype makes compromises. Some are harmless for the question being tested; others would invalidate the result. Document what is simulated, manually supplied or left out. Distinguish an engineering shortcut from an untested assumption. A manually curated input can be perfectly appropriate for an algorithm experiment, but cannot establish that a complete automated system will work.
Measure the change in understanding
The output is not only code. It is also a clearer account of what works, what fails, what the system depends on and which experiment should come next. Sometimes the most valuable prototype makes it obvious that the original approach should not be pursued. That is a successful investigation if it prevents a much larger commitment based on a mistaken assumption.