The term “pretotype” was coined by Alberto Savoia, former Engineering Director at Google. Ass he explains on his website, the main advantage of building a pretotype is to accelerate learning by building a quick and cheap version of your product. This kind of experiment validates whether “if we build it, they will use it” applies to your product idea.
It’s easy to confuse pretotypes, prototypes and MVP. Let’s explore the ways in which these terms differ, using a restaurant that offers a delivery service as an example.
A pretotype is a stripped-down version of a product, used to merely validate interest. For your restaurant with delivery service, a pretotype could be a simple website that tracks how many visitors come to your page, giving you an idea as to whether or not people would be interested in ordering food from you.
A prototype is also a stripped-down version of a product — but one that contains more detail than a pretotype. Once you learn that people are interested in your product, you create a prototype to test if what you’re building meets customer expectations, and to work with engineers to see if a product like yours can actually be built and will work as expected. Back to the restaurant: A prototype would involve adding a menu to your basic website and measuring which items people view more often. It might also involve creating a few recipes and offering people the prepared food for free, in exchange for giving you feedback.
MVP is also a stripped-down of a product — but not only does it contain more detail than a pretotype and prototype, it provides enough value that people will actually pay you to use it. Note that an MVP doesn’t have to be the final version of your product. It just needs to be usable. For a delivery restaurant, your MVP might involve delivering food to paying customers. However, you might use a third party to help you save time and resources on cooking and delivery.
Why Pretotyping Is Important
In his book Pretotype It, Alberto Savoia describes a pretotype that the team at IBM built for a text-to-speech machine. This was back in the day where people typed slowly and speech recognition was unheard of; there was no Alexa or Siri yet. The machine was meant to be revolutionary. It was supposed to allow people to dictate words into a microphone and see their words magically appear on the screen. Imagine what the world would’ve looked like if they built that a few decades ago!
Instead of immediately sharing their idea with an engineering team, the folks at IBM decided to test whether or not companies who were interested in the product would actually buy it as they promised they would. They told their customers that they’d built a prototype that was ready for use. What they installed was a dummy computer box (at the time, computers were much larger, much slower and much more expensive), and the whole speech-to-text conversion was done by a professional typist sitting in the next room. The goal was to see if this machine would be used and how it would be used without sacrificing possibly years of development and burning a huge budget.
Things didn’t go as expected. Most of those people who said they would buy the machine decided not to after using it for several hours. There was nothing wrong with the functionality itself — as they dictated, the text appeared on the screen with zero mistakes, and it was fantastic! But there were other problems that no one had thought about before actually using the machine. People’s throats became sore after some time, and the whole process was very noisy, thus requiring a separate room for a proper work environment and confidentiality.
Thanks to this experiment, IBM didn’t risk a ton of time and resources on this idea. But they still continued to research it on a smaller scale. It was decades before reliable speech recognition became available on any computer or smartphone, and it still has very limited applications for the same reasons IBM discovered in their experiment.
The lesson? Through building a pretotype, you can start learning about your product and customers at the earliest possible stage of the game. Test your product now, instead of waiting for months to build a prototype or even an MVP. Start with something rough and simple instead of letting your inner perfectionist drive your business. Data and observations, not the voices in your head, should inform what your product looks, how it works and whether you move forward with it.
Originally posted on Medium