In previous blog posts we’ve written about minimum viable product, making sure your product actually fills a need (solves a problem) and how to identify your customer.
The time has come to talk a little bit about prototypes. The message of this blog post is, in short, don’t do it!
Disclaimer: we’re talking about software here. There may be other cases where prototyping is not only doable, but necessary.
Why not, you ask? For two reasons, both tied in with the concept of Minimum Viable Product. First, time is a-wasting and you don’t want to wait any more than necessary to take your innovation to market. Second, with the way technology is progressing, you can add, change or remove parts of your system without taking it offline for one second. Modular development, good stuff when it’s done right!
If you’re working with an MVP, you want to start by finding out what the core of your idea is. What’s the functionality you absolutely must have? What is the minimum that will be enough to attract the early adopters and at the same time provide you with relevant data? For this a prototype is not enough, but once you find that sweet spot – you have the first iteration of a live product. An MVP.
With an MVP you can start accumulating behavioral data. People don’t always use software the way we expect them to, so we need to find out just how they will surprise us.
The best way to build your MVP and then develop it further is to have really short delivery cycles. Achieving that is fairly uncomplicated if you develop modularly, piece by piece.
A prototype is something entirely different. With a prototype you build an example or a model of a more or less finished product. This gives little or no room for the user-centric development that comes with working with an MVP. It doesn’t provide the opportunity to collect data on user behavior at an early stage and let that guide the planning of features and functions. A prototype is not production ready, which means it’s not really possible to start selling the product and let that finance the next development cycle or an expansion of the company.
To sum it all upp:
- Start with an idea, an innovation
- Code an actual product, but no more functionality than necessary
- Collect data, analyze it and prioritize and plan further development from that
We may end up with a product that is perfectly in line with the original idea, but looks entirely different than was expected and is changing with every cycle of updates. We may also have development cycles of mere days or weeks, keeping the customers happy with ever increasing functionality.
And we will have done it by diving in head first, not by prototyping.