Prototypes are not your products

Every great thing was once a great prototype.

You have to scrape a website for the app you are building, so you quickly write a quick script to get the job done. Or, if you are an engineer in a small team, you hack together some building blocks and prove your point and move back to the ‘main’ task.

But do you really just go back to working on the ‘main’ task? You rather spend hours achieve some perfection as if your prototype was your product. In the end, you call it a day, or just get so confused that you have no clue what you’re supposed to be working on.

The best advice I have gotten on building a prototype- be it a greenhouse, or a script gluing few discrete scripts together- is to build your prototype as if you’ve to throw it away.

A good prototype has only one purpose. And the purpose is to prove a hypothesis. If your prototype (or even your startup) is a machine learning algorithm to find potential health issues from a medical imaging report, then you shouldn’t worry too much about how ‘beautiful’ your script to downloading images looks like, etc. Because, at the end, you and your prototype will be judged for the key purpose the prototype itself was built for.

A good prototype, whether for software sub-package, or a nutrient delivery system for plants, should have these characteristics-

  1. The existence of the prototype can be summarized in one life.
  2. It is ugly. (If it’s too pretty, kudos! But most likely, you confused your prototype with the product and instead focussed on irrelevant things.)

When you don’t confuse your prototype as your product, here are the benefits you get:

  1. You validate one, and only one idea. Successful prototype will bolster your confidence in the eventual product that you will ship or get paid for.
  2. You get more realistic. When you’re expected to give a one line description of why you’re building this prototype, whether by your boss or yourself, you can’t fool anyone!
  3. Your product gets shipped faster. Good prototypes prove one thing, and that they do pretty well. If you’re building an innovative solution, snapping together confidently proven hypothesis is easier and faster than a muddy swamp of shiny unproven ideas and claims.

So, go on, and figure out what your prototype is for, and sacrifice it to learn lessons for your final product.