Everyone knows that starting a new venture it’s a very resource-demanding activity. All types of resources: time, money, attention, etc. This is especially true in the modern world with internet startups, because every tech startup is a global business in some sense, and it’s different from a local street-corner flower shop. It’s also a very risky activity with a high chance of failure. And when there is a costly operation with high associated risks, but also a high reward - then lots of people putting their effort to optimize it, to reduce risks and make an opportunity more stable. 

One of such optimization techniques for a startup is prototyping. It became extremely popular with a rise of Lean Startup culture. The major idea of prototyping is to ultimately reduce costs of checking and validating a business idea or it’s part with substitution of an actual product with a prototype. So what is a prototype? According to Wikipedia, “a prototype is an early sample, model, or release of a product built to test a concept or process”. This is a little bit abstract, but the key things there is that prototype could be just anything, as long as it fits its single purpose - helping to test a concept. Could be a list of paper with a process visualized, a video, model of a product, a clickable page without actual code - that’s not important as long as it provides you essential insights regarding the concept you trying to test.

There are great books written about how prototyping help in startup development. The first comes to my mind will be Steve Blank’s “Startup Owner's Manual” and “Sprint” by Jake Knapp (recommended by Google Ventures). But if you don’t want to go too deep into this - the main idea is that if you have a chance to test and validate any assumptions with a prototype instead of the actual product - you should do it. And since 99% of the startups are actually limited in resources - you should put the minimum possible effort to your prototype and make it small, easy, cheap, “lightweight” and focused. The last one is important. Because broad prototype will not be quick and will blur the feedback you plan to get from it.

In my previous article, I describe major strategies for building an MVP, and some of you could see that the prototype goal heavily intersects with MVP goals. That’s true. They both are a source of customer feedback, but they are different. An interesting fact: every MVP is a prototype of the eventual product, but it’s very rare when a prototype is able to satisfy all MVP requirements. So there is an injective relationship between these terms. And normally to build an MVP require much more effort than building a prototype.

There is a pretty logical question: why do we need MVP at all then? Why not cover all products with simple, cheap prototypes, test everything, get feedback and just build a solid product? Several years ago I was asking myself the same questions and now I will share with you some interesting practical insights, which you probably can’t find in books.

I’m the founder of the startup-as-a-service company Centaurea and it’s pretty obvious that what we do is building startups. So for the last 5 years, it was something close to 60-70 different startups and business models we were involved pretty heavily. And 10+ fully built and launched by Centaurea. What we find over these years is this 2 key facts: 

• Сustomers feedback for the prototype and actual product (even for the MVP) often has a significant difference.
• People have totally different expectations from a free product and from a paid product, even if it’s cost $1.5 and what will be accepted OK in a free product, could be a point of pain even at the cheapest product.

Why is this happening? Think this rely somewhere upon behavioral psychology area and require some study. But I could guess that this happens because of these things:

1. Every prototype is a simplified model, sometimes dramatically simplified. And this simplification matters a lot because the devil is in the details.
2. In quantum physics, there is an Observer effect which shortly indicates that the observer makes an influence for the whole system just with the fact of observation. The similar story happens with a prototype. Every prototype is by default a controlled experiment on a simple model, and the user knows there is should be feedback from him. Because of this, his behavior could be very different from what he was able to demonstrate just laying on the couch at his own home, using the product.
3. There is a large gap in expectations between paid and free version, much larger than let’s say for a product between $5 and $50.

Does this mean prototype are useless and should not be used? Of course, it’s not. We just need to be a little skeptical about the feedback we get from a prototype and especially with feedback for a paid product with a free prototype and later retest main assumptions with an MVP. But knowing that limitations prototypes could be your very powerful tool for more rapid and less risky startup development.

So how the prototyping process should work? For me it’s like that:

1. Split your problem to multiple independent subproblems
2. Create a minimal, but sufficient prototype for a subproblem
3. Validate prototype and get feedback
4. Combine feedback from subproblems to initial problem solution

Thanks for reading, I hope this post brings you some Value. I will be happy to know your thoughts and discuss it in comments, as well as answer your questions. if you need some help with your MVP or startup we in Centaurea are ready to help.