It’s easy to confuse between a prototype and an MVP. Both are aimed at validation, but the target audiences and approach to development are quite different. As a digital products company we frequently come across startups who confuse between the two.
Know what you’re building
Are you building an MVP or a prototype? The purpose of a prototype is to demonstrate your idea to win over important stakeholders – like investors who will fund you to build the MVP. A prototype is rarely market ready. An MVP on the other hand is a bare bones version of your product that’s ‘just enough’ to get actual users to actually use it, and give you feedback. It also needs to have just enough functionality to test your overall business model.
For example if you’re looking to develop an Uber clone for hailing taxis, a simple mobile app that allows users to hail a taxi by tapping a button won’t do. The app would also need an interface for taxi drivers to sign up, a backend for admins to check on rides when disputes come up etc. Launching without these features would mean testing (or validating) only part of the business model or worse having a product that lacks viability in the market.
Do you really need to ‘build’ a prototype?
Some ideas can be prototyped without writing a single line of code. Dropbox famously launched with just an explainer video. Published on Hacker News this 3 minute video gave early adopters a hint of the actual experience; enough according to founder Drew Houston for many smart people “to give feedback as if we were putting the product in their hand”.
Setting up landing pages is another great way to validate consumer interest in a product without developing complex software. Buffer went a step further and actually set up a landing page with pricing and packages to gauge potential users willingness to pay. Upon clicking on this section, a pop up would appear saying “hello, looks like you’ve caught us before we are ready. Enter you email and we will get back to you…”
Transitioning from prototype to MVP
Building a prototype is quick and dirty. If you’re a developer this might mean a few Red Bulls and late nights to hack something together, that will help you to research and validate your idea. If you’re not technical you may hire a freelancer to burn the midnight oil. Either way you will end up with a product that demonstrates your idea to friends and mentors, helps you to gather feedback and if you’re lucky win you some funding to build a MVP.
The MVP is meant for a wider audience. It may be minimal but it also needs to be viable. A SaaS app that takes forever to load or a mobile app that crashes regularly, aren’t viable in today’s market. The MVP also needs to see you through your first set of users. You may build a throw-away MVP, but this often costs more – in terms of time, money and lost opportunities. Rebuilding your core application, while also trying to scale it is no easy task.
Switching gears
All this means that the MVP requires a completely different approach to development altogether; one that follows industry coding standards to develop a product with satisfactory performance and extensibility to add new features on-the-go. Testing is needed to ensure that the end product works reliably and meets basic usability standards.
Once you launch your MVP to the market you will find that quick changes are necessary. If you’re working with a freelancer at this point, a single part-time developer’s bandwidth is unlikely to suffice. That is, if you’re lucky enough that your freelancer hasn’t delivered an improvised solution that takes the ‘viability’ out of the MVP. Don’t believe this happens often? Stay tuned for a follow up post, where we will explain the material differences between an agency and a freelancer with the costs of each option.
Why does this matter? Nothing kills a good idea faster than a bad MVP.