MVP stands for (in this article) Minimum Viable Product. It’s not an Agile concept. It’s not even a software-specific concept, though it’s certainly easier to do with software, since upgrading software is usually easier than upgrading hardware. The concept is simple: Instead of building every feature under the sun into your product then releasing it, build the least you think people will buy and release that, following up with more feature-rich versions. There are several good reasons to do this.
First and foremost, is the heart of lean and Agile: The earlier you get your product into the hands of customers, the sooner you get feedback you can adapt to. If you put an extra month or two implementing 5 features into release 1, you may very well find the customers were interested in only 1 of them, or even demanding a feature that you hadn’t even thought of. the worst case scenario is you release your product and find nobody wants it. Releasing earlier would have saved you from investing in a non-starter.
Even if your research team was spot on 8 months ago when your product was designed and the roadmap laid out, markets change. You may end up releasing a product that was absolutely perfect… for 8 months ago. Markets change, cultures change, competition changes… even laws change quickly these days. One concept that comes out of the lean movement is delaying making decisions until the last responsible moment when you have the most up-to-date information possible. Most design decisions on a product somehow limit your options for other decisions, or lock you into a particular implementation that won’t support use cases you discover later. Not everyone agrees that this is a sound strategy, so decide for yourself where you want to draw the line, and when the last responsible moment is for your decisions. Making decisions too late may lead to finding out too late there are no good solutions.
Another reason for doing this is to avoid premature optimization, where you spend too much time focusing on something that turns out not to be as important as you originally thought, or will be forced to change later anyway, wasting the efforts to perfect the original design. Getting 10 less-than-perfect features out the door, getting feedback on them, and focusing on the winning ones will often be a better strategy than getting 5 perfected features of unknown value to the user released.
Software and hardware typically undergo much more rigorous testing (especially integration and performance testing) just before a release. The longer you go without releasing the product, the longer you go without that rigorous testing, and the less sure you can be of how far away it is from being truly releasable. Early and frequent releases means that integration and performance testing is happening more often. The less that has changed since the last release, the fewer culprits there will be when you find problems, so they can be addressed quicker and more easily.
A practical justification for releasing an MVP as early as possible is you can’t make money off of something you’re not selling yet. Smaller companies can only fund development for so long without any income from it. Releasing early means you have funds to drive future development.
Some real-world personal case studies:
- I worked for one company whose main product was basically a powerful rules engine that could be adapted for many different applications. Sales were good, but implementing what the customer needed in our tool could take 9 months or more, and we didn’t get to recognize the income until the customer was satisfied. They got the idea to come up with “starter templates” for a few different industries so it just needed customization to the customer’s needs instead of starting from scratch each time. Great idea. So they started this process by hiring a marketing research company to find out what 10 markets they should create these starter templates for. The process took 8 months, and over $600,000. At the end of the 8 months, all of the research done in the beginning was no longer valid because the market had changed so drastically in that 8 months. Had they started with 2 or 3 obvious industries, they could have reaped the immediate benefits of the shortened cycle for those companies, and then chose the next few industries based on the current state.
- I worked for another company that was old and fading fast. I was working on The Product That Would Save The Company. Without giving details, it was a thing of beauty. Very high quality, but pretty expensive, including high costs of operation. But boy was it worth it if you wanted that quality. The project went on way too long because they decided they needed to add more features, and because they felt they needed to invent their own wheels in certain areas that didn’t really lead to any advantages. Just about two months before we were to release the product, the main competitor releasedh a much lower quality product, but also much lower initial and ongoing supplies costs. Then they started giving them away to key customers just to get the name out there and to reap the profits of the supplies those customers would need. We almost immediately disbanded the whole project to build The Product That Would Save The Company, because we knew we could not compete. The competition was first to market with a mostly passable product.
- In addition to being on the Board of Agile New England, I’ve also been the [co-]Product Owner of our annual Agile Games conference for the past 4 years (and involved with the conference for a few more years). A few years ago, the planning of the conference was started late due to some personnel issues. We were struggling with how to price the conference, how to estimate attendance, and how to build confidence in the event among the Board members. We often have pricing tiered based on how far off the conference is, but we decided to take a risk: We put “Early Bird” ticket prices even lower, and we started selling them before we even had the programming established and published. We sent out a message to past attendees and others we know saying “You know us, and you know what Agile Games is like. You know the quality of the presenters we get, and how organized we are. Buy your tickets now at an even steeper price discount, and trust us to wow you.” It was a huge success. Those early ticket sales gave us money to deal with hotels and airlines, and the confidence of the Board. We put together a great conference, and at the end, heard people say “Let us know when we can buy tickets for next year!” A lesson to be learned from this is to make sure your customers understand this is an MVP release and what things you have in mind for it in the future.
- Among my many interests outside of $DAYJOB, is working on a few Arduino projects, the current one being a lighting controller called LightBright. I had envisioned tons of features and interfaces to the controller. I even had a few people interested in looking at it. It was hard to map out when I would finish it. Then one day I decided to take my own advice, and release the MVP, which just needed another 2 weeks of work. The MVP implemented just on/off channels using relays, and 1 method of controlling them. The next release will probably be analog channels that can dim (I already have all the hardware for all of these features, including a spectrum analyzer and a bluetooth module). After that will probably be sequencing, then the blutetooth control. I don’t know yet, because I will base that decision on the feedback that I get.
I will give one word of caution on MVP; the V (Viable) is just as important as the M (Minimum). If the features you implemented in your MVP don’t work, or if the user interface is unclear or awkward, you may not get a second chance.