As a startup entrepreneur or just as an indy developer, time and usually money are scarce resources. Complete focus is what’s needed to get things shipped. One strategy is building the minimum viable product(MVP). With SheHacks coming up again I decided to refresh my thoughts on what an MVP really is and how to design one.
What’s the MVP anyway?
According to lean startup a MVP is anything that leads to learning. Ideally that learning is achieved with the least amount of effort possible. This means that you don’t actually need to build anything. If you can learn something about your users with a landing page and some Google ads - that is a MVP.
Each MVP is an experiment that removes a layer of risk by confirming or disproving an assumption you’ve made about the world. This kind of MVP is great when you’ve got a new idea - you should be ruthless and try to kill that idea with every devious experiment you can think of.
Sticking to the MVP when you start dev is difficult, suddenly you have a ‘product’ and that product has needs dammit! So how do you keep your focus and find your next MVP? It’s time to think lean and agile and iterate!
Step one in an MVP cycle is to brainstorm what to do next. You’re sure to have a long backlog somewhere but don’t automatically choose the next thing on the list. Pivoting on a live product gets harder the more your product grows, but the ability to pivot is a startup’s biggest advantage so make sure you use it.
During brainstorming you should ask:
- What’s possible today that wasn’t yesterday?
- What problems could we solve better?
- What do our users want?
- What do our users need?
And don’t forget the big question - what features will help us meet our goals?
The next step is to prioritise your backlog. Do this by weighing up the estimated valued of each feature against it’s comparative complexity. The highest value for the lowest effort is always the goal of an MVP. There are exceptions but you should have a good justification for pursing something with lower value to effort.
Yes this is still a step, even when you’re in dev. Every feature should be validated before dev starts. Apply the creativity you used to validate your concept to each feature. This could include:
- Landing pages
- User interviews
- Sites like usabilityhub.com
Time to build things! Use agile methodologies to keep everyone focused on the business value of each feature and why it’s needed. Also check out specification by example, this helps everyone stay informed, leads to better software architecture and avoids unnecessary gold plating.
5 Measure & Analyse
Treating a live product with real users as an experiment takes a bit of adjusting. An MVP is still an experiment and so you need to measure your results. Use smart analytics like mixpanel to validate the assumptions you’ve made. This way if your feature is a flop you will still have learned something.