The Fallacy of Prototypes

Jun 7th, 2022

A great way to explore solutions to a problem is to prototype. For software developers, this usually means developing software. This can help validate hypotheses and steer concepts that are still percolating.

Often, the product development lifecycle results in iterations to a successful prototype, and you might even end up with something that does everything it's supposed to do. Congratulations!

Very commonly, there is a strong urge from stakeholders to take the successful prototype into production, with ongoing feature development focused on refining the existing work. However, the decisions made in standing up a quick-and-dirty proof of concept may not align with the decisions one would make when beginning a new product that is meant for real users.

The fallacy is: there will be time (and resources) available to clean up the prototype. Cleaning up the prototype is often the lowest item on the list of priorities.

Solving the problem

Set expectations low.

• Make the prototype ugly. Focus 100% of your efforts on proving the concept with the least effort and time required. Here, "ugly" means a lack of quality-of-life features, but it also means visuals. Avoid bringing something that looks finished to your stakeholders.
• Avoid using any of the "real" tools. A paper prototype might provide all the answers you need, with none of the expectations that the paper can be put in front of users. Consider creating a workflow of cobbled-together, off-the-shelf components that is viable enough to prove your concept but too annoying for proper use.