This is part 2 of 3 part series about MVPs and PoCs
Part 1 - Difference between MVP and PoC
Part 2 - MVP from Software Engineering perspective - this article
Part 3 - How to run PoCs - Software Engineering perspective
What’s an MVP from Software Engineering Perspective
In my own words:
Minimum Viable Product is a minimal set of features developed in your application/website/device that is enough to verify the hypothesis about your product. Usually, you achieve this by developing only the features that are essential to your value proposition and that require minimum amount of work to deliver working product. An MVP can also be a new set of functionality developed for another department within your company.
Most common mistakes with running MVPs
There are two most common mistakes that I’ve seen in my career. Not releasing to your actual “production” environment and growing the scope too much.
First sin of running MVPs is not releasing it to production. What the “production” means to you might differ. E.g. for an Android App it will be Play Store, for internal corporate projects, such as backend service, it will be the environment where your service can communicate with other services that deal with real customer data. Don’t let Product Owner convince you that deploying to “test” will validate any assumption of your service. People don’t use your application the same way in production and test environments. Also the audiences for those two environments differ. For test environment, it’s usually Product Owners or Manual Testers. Running your MVP in a non-production environment might generate false results. Don’t do it.
Be wary of perfectionist Product Owners and obsessive bosses. They will often convince you to develop more than necessary for an MVP. Some people want their product to be prefect or are afraid of releasing not finished product. If an MVP takes you half a year to develop, it’s probably not an MVP (unless you are building a space rocket). I can only advise you to try to convince them or their superiors to reconsider what should the MVP entail. Point out cost of excessive development and lost time-to-market opportunity. You can also point to thousands of blog posts and researches emphasizing the value of releasing early, such as here or here.
This is only a technicality, but because people do not understand difference between MVP and PoC, often an MVP is called PoC and the PoC is called MVP. I hope the first part of this blog series will clarify this to you. You can find it here.
How to run Minimum Viable Product
This section is an overview on how to run an MVP. I won’t get into many details here, but I hope to give you some pointers that can help you with your day-to-day work.
Define hypothesis and decide what’s the core value of your product or functionality
You need to define a hypothesis that you would like to validate and then support it with metrics. An example of such hypothesis would be: “Pet owners would like to be reminded of the next vet visit through their phone”. Sometimes you are ok without a hypothesis, but you should always know what is the assumption that you want to test.
Then you need to define what’s the biggest value that you can deliver in the shortest time. I do not recommend a timeframe here, MVP development time might vary from a day to a few months, depending on the context. What you should define, though, is the scope. Challenge your scope and think if you can deliver any value in less time. Cut on fireworks and themes or CSS styles for your app. What you need is a usable product that people can use and want to use.
How to define what is essential and what is not to an MVP? Quick googling yields plenty of results: here or here
MVP goes hand-in-hand with agile product development and scrum. As such, an MVP would be nothing else but the first sprint. Of course sometimes the MVP might take longer than a single sprint to develop. I recommend you talking to your Scrum Master to extend the sprint to the MVP timeframe or stop working in sprints altogether until the MVP is finished. There is little to no value of working in sprints when you cannot deliver anything in two weeks.
Release the app to your audience!
Release it! And release it to production! Make sure that you can measure the impact of your MVP, whether it’s requests per second or users per month. Sometimes you need to embed that logic into the MVP itself.
Measure the results
Define when the MVP fulfills it’s role - whether it’s 100 users in the first week or 50 thousand images uploaded within a month. It’s helpful if those metrics are SMART. At least they should be realistic and time-bound.
Doesn’t work? Move on, rinse and repeat
If your MVP does not catch on, which might very well happen, you might need to change focus. It might happen that the metrics were not set-up properly. If you feel that’s the case - review the measurements. Very often, though, you have just proven that your assumption was wrong. Perhaps people don’t need another app that reminds them of vet visits and are happy with calendars? Or your department does not need the new functionality and the new backend service is unused? Ask your customers for feedback to confirm your assuptions. After that, there is nothing else left as to move on and try something else. Find another brillian idea and run with it!
Summary
The whole idea of MVP is to quickly validate if your app/service delivers value to your customers/department collagues/your management/whoeverThatIs. Therefore you should create some assuptions about your audience, select few core functionalities that they will benefit from the most, and develop it in the shortest time possible. Then you measure if the assumptions are really true. If yes, you’ve succesfully ran an MVP and can continue development using other techniques, such as scrum or kanban. If it turns out that the effort put into the development of an MVP does not pay off (the value delivered is lower than the money/time put into developing the MVP) then you should probably shut the experiment down and start again with something else. Remember that there are other success/failure factors to an MVP that I haven’t written here much about: marketing, pricing model, global economic crisis and many more. However, I wanted to focus on the technical part of the MVP and how to make it more succesfful from the developer standpoint.