Minimum viable product vs. minimum product
A while back someone told me how product managers often abuse the concept of an MVP. They cut the scope to the point that the product is no longer a minimum viable product, but simply a minimum product. I will use a simple product model to demonstrate that in reality is that there is no such thing as an MVP, and that the winning strategy is shipping early and often.
Viability is relative
The first problem is that no set of features makes a product generally viable. Every user or potential customer in the target audience requires a different level of complexity from the product to consider it viable. Take for example a calendar. Some people will find a product viable if it simply lists dates . This is the extent of functionality of most desk calendars, and they’ve sold millions of copies around the world. Others will require a bit more, for example showing the current date. This is pretty much the extent of the Windows calendar, which is installed on hundreds of millions of devices. Yet others will require events, recurring scheduling, inviting friends, reminders, and so on.
Imagine you can sort the possible features of your product on a line in some sort of a “natural” order of delivery, that is one that maximizes the appeal of your product to customers along the way. Every new feature will make your product viable for more users. If you were to graph this, it would most likely follow something close to a normal distribution
You can then add up all the people for whom the product is viable given a set of features, and a create a cumulative distribution. This will show what share of your target audience finds the product viable given your product has all the features up to the last one delivered.
The model above shows that there is no generally viable product. If you want to ship a minimum “viable” product, the best you can do is pick a threshold and say “I want to ship a product that is viable for at least 15% of my target audience”. I will refer to this as the “viability threshold”, which means the share of my target audience the product needs to be viable for before I release it to users.
Apart from being completely arbitrary, such “viability threshold” produces lost value for the business and customers. Let’s measure value simply as the number of users using the product over time, and let’s assume this is proportional to the share of target audience that finds the product viable. As you build out the product, a higher share of the target audience finds the product viable, but more users only use the product when you actually ship the new features.
The diagram below shows how the “viability threshold” produces lost value, because no product is shipped until the threshold is met.
In this example, the first product, or the MVP, is not shipped until feature 4 is completed, even though features 1–3 make the product viable for a share of the target audience.
Furthermore, if you look at the diagram closer, you will notice there is still more lost value that can be found between the individual feature releases.
You could think that is a loss you cannot avoid, but the scope of a feature is somewhat arbitrary, and very often features can be broken down to even smaller chunks.
Value maximizing strategy
Imagine that you break down each feature even further, and ship product to users from the very beginning. The diagram below shows how the total value, defined by the number of customers using the product over time, is significantly higher, compared to the previous strategy.
Using this simple model you can show that the winning strategy in product development is:
- Shipping early: Ship first product as soon as possible. Don’t guess whether a product is viable, let users decide for themselves
- Shipping often: Slice product features into the smallest deliverable chunks possible and ship them immediately.
Obviously, in the real world, the “natural order” of features and the distribution of users’ individual viability thresholds are not known. However, this is yet another reason why shipping early and often produces better results. Feedback from real users provides data to steer the ordering of features, and user traction provides data on viability distribution, which can then inform marketing activity.
This model above rests on the following assumptions:
- Future use is not impacted by early versions: If a product is not viable for a user, the model assumes they will simply not use it until it reaches their individual viability threshold. While some will argue that in such as case you will lose the user forever, that seems to be very unlikely for vast majority of products. If that was the case, the viability of the first release would define your total addressable market which seems like a stretched argument.
- Zero cost of product releases: This winning strategy results in a high number of releases. If there is a significant cost to a release, such as for physical products, this breaks down. Fortunately, for most software products the cost of a release is minimal.