What Is A MVP - A Minimum Viable Product?
Today we take a cautious look into our wizard's kitchen. I would like to show how we approach new development projects. There are two different approaches for us.
We Simply Build The App
When the scope of a new app is very manageable, it's easy to assess the risk of development. The cost is low because, for example, only one developer is working on it for a short time (less than a month). In this case, we define a feature set, the app is built and out to the public with it. This was the case with Phone Memos, Meeting Cards and also with Herein.
The Feature Set Is Too Large For "Just Building It".
Sometimes, during initial discussions about a new app, you can immediately see that this scope will exceed the person-month limit. Or - as in Merlin Project – the product is of strategic importance. In this case, we are talking about a risk investment and here, of course, we proceed accordingly more cautiously.
In the first phase, we build mockups (pictures in Apple Keynote of how we imagine the app), which we use to mentally simulate the operation and processes in the future app. Every now and then, however, we reach our limits of imagination and need another technique: a prototype.
A prototype is for us a small program, which illustrates a certain technique, a workflow or just a concept. So we build many small apps. Since these test apps only live for a very short time, we try to get to the goal quickly. So we are not concerned with beauty or clean programming.
During this phase, it is mostly still my job to check the financials of the future app: What will it cost us to develop the app and what could we earn from it. Because as I always use to say: "The seventies are over. Unfortunately, we can't live on pure love."
Eventually we will (hopefully) have explored all aspects of the new app. There is then a set of slides that show the look and feel. And whenever necessary, new or critical techniques were tested in a prototype until we were happy with the result. In addition, there is a big breakdown of expected costs and hoped-for revenues. Then we sit down (remotely via Zoom, of course) and discuss our findings.
At this point, many new app ideas have already failed. Be it due to a poor basic idea, a technical hurdle that is too low, or even one that is too high. And also, if the believed user numbers are too low, an app is not developed. Of course, I realize that these assessments - even if they are made in a team - are very subjective and in no way have to match a future reality. But at some point, a decision simply has to be made.
Starting shot for the MVP
When our confidence in the new app - and motivation to build it - are at a high enough level, we start development.
But again, we need to be careful. After all, I don't want to jeopardize the future of the team with a miss. And that's where another risk management mechanism comes in: making a minimally viable product.
According to Wikipedia, the term MVP was first coined by Frank Robinson and popularized by Steve Blank and Eric Ries. The idea behind it is so intuitively clear sense: You build a new product, which is equipped only with the most important core functions. On the basis of this product, you can then test within the team, strategic partners and, if you like, representatives of possible customer groups, whether there is interest in this product and whether the estimated market for it is sufficiently large. Of course, you also test whether the app is easy to use with the assumptions you have made.
An iterative approach to development has been established at ProjectWizards for many years:
- we develop according to the created mockups
- we look at the result in a small group and decide if it works well.
- if we are not satisfied, we iterate in case of minor problems in the software, in case of fundamental problems we draw on the mockup.
Always according to the motto: The fastest and easiest way dictates the procedure.
Thus, peu à peu all the building blocks for the MVP are assembled. At a certain point, someone (usually me) starts playing with the new software.
Initial Testing During The MVP Development Phase
Even though it is very time-consuming and sometimes even very frustrating, the concepts and assumptions have to be tested again and again. That means working with sample data in the new app. Of course, it first crashes at every nook and cranny. But over time, things improve.
At some point, the question comes up how much time you should or must invest in an MVP. There is no rule or regulation for this. It takes time to answer the question for yourself whether the new program is viable in the wild.
Differentiation From The Minimum Marketable Product (MMP).
The minimum marketable (or saleable) product goes a significant step further - at least in my definition.
While the MVP is only built for internal use (incl. some key people) and I cannot make any money with it yet, the MMP goes a significant step further: This version can be sold.
Contrary to the conventions of the open source scene, a MMP for me needs at least:
- a version number 1.0
- a documentation
- a website
- a sales partner (App Store, Paddle etc.)
- and more
For this reason we do not use the name MMP, but version 1 or 1.0.
When Is The Transition From MVP To Version 1?
For us, this is a smooth transition. We set a date for the finalization of the MVP, which in turn is the start date for the development of the remaining functions of version 1.0.
As you can see from the graphic, it is planned as a sequential process. In reality, however, the boundaries are sometimes very blurred.
When Is An MVP Ready?
There is no real set date for this. If we decide that we're not happy with the quality or the feature set, then we keep working on the app. Even if it's just an internal version.