A prototype should answer a difficult question
A prototype is not a smaller product. It is an experiment, and it should be designed like one.
Prototypes often turn into polished demos of things everyone already agreed on. That feels productive, but it spends time on the easy parts and leaves the risky ones for later.
Name the question first
Before anything is designed, write down what you do not know. Will managers understand a shared calendar without training? Can the system calculate allowances fast enough for a large team? Will customers pay for this at all?
Build only what answers it
A clickable mock-up can answer a question about understanding. A rough script can answer a question about speed. A landing page can answer a question about demand. None of them needs to be production-ready, and none of them should be.
Decide what you will do with the answer
Agree in advance what a good and a bad result look like. If the answer would not change the plan, the prototype is not worth building.
“A prototype that cannot fail is a presentation, not an experiment.”
Done well, a prototype turns a risky assumption into a fact in days, before it becomes an expensive one in months.
Written by the OneSyntax team
