Minimum Viable Product

Lets first start at the confusion the term minimum viable product causes, from a practical and a theoretical standpoint.

The job of a minimum viable product is to do an acceptable job of solving a problem with the least amount of effort. A successful MVP is a product that just barely does enough (value) that customers may use instead of alternatives (growth).

That is, when you only look at the function as a product or service.

Theoretically though, a minimum viable product is a prototype on which a company runs experiments on with the purpose of learning from potential customers. The idea is to figure out if the prototype solves problems satisfactory enough that customers will pay to use the product or service. The focus herein is to investigate and test what features a customer would pay for to solve a problem.

Needless to say, developing something a customer wants will create a competency. While building something customers would not pay for is a waste of resources.

The term can get confusing because of the tangible and intangible properties it has when describing it. This causes the term being used in any stage a product goes through. Whether it is designing, creating, testing features or launching for paying customers, it all goes back to one term. Minimum viable product.

If you would like to read more upon the different stages, have a look at Scott Ambler’s article whom does a good job of defining the different stages. Eric Ries blog is also a good option, he is regarded as one of the instigators of the MVP movement.

In concept developing an actual product or service as an MVP is in many ways similar to a prototype. While the philosophy behind MVP – testing and learning – is in many ways similar to a pilot experiment.

In both instances a product or service is tested to become the great product creators envision.

A pilot experiment (when in context of a product or service) is used by larger companies to test whether a product falls in the taste of consumers and their target demographic. The scope of the test is limited but is a close approximation of the target market.

A company that does a pilot does not seek revenue nor profit from the experiment, as it is part of their R&D stage. Companies that have something to lose, will prefer a prudent approach to test products than launching in a non-controllable environment.

Think of it this way. Imagine the Coca-Cola company wanted to test a new refreshment. Would they mix a bunch of random ingredients, add some sugar, launch and see what happens? Or would they take a more deliberate approach testing the products in a laboratory? Unsurprisingly, the answer is a pilot in a controllable environment.

A minimum viable product is generally used by startups, but not limited to it. Founders, creators or investors will want to validate a product in a real market environment with as little resources as possible. The assumption with this approach is that a start-up will be able to test the product in real life and adapt the product with the feedback generated. The product is developed together with users, customers or early-adopters to make something remarkable.

In that case an MVP is like planting an unknown seed. Everybody waters it and overtime it becomes a plant (product) that people find useful.

Wait, that sounds similar? In some ways it certainly does, one could even argue that both words can be interchanged. At the end of the day a prototype is tested with the purpose to gain information. However, there are some differences.

One can view a pilot experiment as a very planned approach to testing a nearly finished prototype. This means that the prototype has been developed thoroughly. Naturally it takes longer to get to that phase. Therefore, people working on the project can be vested to its success, which means going back to the drawing board to fix issues will not lead to a completely different product.

Lastly, a pilot is generally developed in secrecy – but not always. Prospect customers will have little to no knowledge which brand actually developed the prototype.

Though a minimum viable product functions the same way, that is testing a prototype or even idea, the transition to showcase a prototype is drastically lower. A prototype in this scenario can be something tangible or even a sketch. The idea behind this is to learn from customers what features would better solve problems and if customers would pay for those features.

The result is that the product or service developed are considered fluid. The product can always adapt and reiterate.

The holy-grail with MVPs is to come up with winning features while not vesting energy into features nobody wants. Moreover, multiple prototypes can be tested at the same time.

Lastly, a prototype or MVP can be used to instigate sales on crowdfunding sites and therefore secure capital, validation and continuation. Not necessarily to sell the product as is, but by the content that can be created just using a prototype.

Start-ups or people involved in new projects go through a similar uncertainty pattern when validating a product or service. Skepticism, blind spots, overconfidence or something else. Whatever it is, failure is not waiting indefinitely in the horizon.

Development efficiency puts many uncertainties away and failure at a safe distance. One of the best ways to develop a product, is to develop it co-jointly with people whom will actually use it. Customers.

Working on a product together with prospect customers can quickly validate hypotheses. Simultaneously, it allows a team to learn and change ideas when necessary. Ultimately, this leads to product pivoting until the core product and its features become what customers wants.

If we return to the analogy in the introduction about phones. The core function of a phone is communication over a distance. Calling a person that is not in the same room. That would be its critical feature.

From thereon more features have been developed over time, some of them we wanted and others we do not use. Now imagine that the technology used on phones was never released, that instead an inventor wanted to launch a smartphone as we know them today. Without any reference point, just a lucid idea. Would that even be possible? Probably not, but some products do go through similar development taking decades to create.

If an inventor would been forced to bring out parts of a smartphone instead of a working phone, be it by investors or an angry wife or husband, would the inventor find a product market fit?

Nevertheless, phones were developed in different stages, with working products. Features were added and some were removed. Ultimately, the idea of companies was to increase the value of a phone by adding features customers would pay for.

We do not only see the previous development in technology, but in pretty much every industry. In marketing and sales, it is known as value added benefit. It can be something different like how a milk bottle is opened (packaging) to how restaurants offer bread appetizers.

Features are important in many ways. Features can set a product apart from competing solutions. Features can make the difference for customer purchasing one product over the other. Yet customers will rarely want to pay for features that they do not want.

Ordering a cup of tea will yield what one would expect: a cup, hot water, teabag, sugar and maybe milk or a slice of lemon. Now imagine it came with an unwanted slice of red-velvet cake or that everything you expected was delivered except for hot water. On the first scenario you did not order cake but still must pay for it. In the second case, you expected hot water to be included but found out you have to pay “more” for that feature.

To certain extent the previous example applies to every single feature. Developing features that are unwanted cost the customer more and can be detrimental for the proposition a company is offering. On the other side, developing what is wanted is beneficial for both the customer and the business.

So how does one go about designing features? There are a few ways of figuring that out, but one of the answers lies in the philosophy of an MVP. Run experiments and gather data to find wanted features. In other words, talk to customers.

Now most of the testing needs to be done when there is a preconception of what needs to be solved. You simply cannot run an experiment if you do not have a product or service to run an experiment on.

There is no way around it. If a product or service in its co­­­­mpetency as stand-alone tangible or intangible object does not solve a problem or meets expectations, the company exploiting the object will go bust.

Now a problem can have multiple solutions, usually there is no single dedicated solution. However, all solutions will compete in a zero-sum game. That is one of the reasons why only one core product should be built. That being said, one can still build or sketch multiple MVPs to test hypotheses.

One may question what the difference is between a core feature and a core product. Arguing from a business development standpoint, a core product is a product that satisfies one need. A feature enhances the core product by adding value to it.

Once a core product or service has been chosen one can focus on its features. In some cases, a core product is just enough and nothing else needs to be developed. In others, it will require features to convey for example the idea of trust.

Whether an MVP has been deployed to investigate features or a team has been brainstorming for features, it can be rather difficult to select features when the only thing you have is a hypothetical scenario.

In some cases, you can validate features to future customers by explaining the features to them. In other cases, you can sketch it out or create a replicating scenario. However, that is never the same as showing how a customer interacts with a working feature.

Moreover, development can take time, and not always will a feature have the impact a team expects. On top of that, some features can only be developed if there is enough capital.

So how does one go about developing features? Prioritizing features can be a daunting task when there is not a clear path and there is a timing and capital constrain. Though, it always depends on the situation, the answer is to rank features.

Ranking features from zero to X can help prioritizing what needs to be worked on. In true MVP fashion it should not matter if it is a hit or miss in the first itineration, at the end of the day a company is learning by doing. A wrong feature on an MVP scenario will still yield more information and give a good sense of direction than being indefinitely stuck in the analysis scenario.

Taking the phone example. The experience a user is at least expecting is calling over a distance. That would rank as the most important feature. A phone that can only make phone calls.

The next step would be looking at what is important or easy to develop. Maybe adding multiple characters to buttons so messages can be sent.

The next step would be perhaps a camera, improved battery life, Bluetooth or something else.

The idea behind this exercise is to figure out, what is the minimum you can do to satisfy customer expectation and what is the very best that you could deliver if you had infinite resources. The baseline is to figure out what features generate the most value while keeping three principles in mind. Namely, impact, capital and implementation.

Impact is the effect the feature has on potential customers. What the most want. When a feature does not convey impact, it is best to leave it for future itineration’s or when the business is stable enough to look at it again.

One can also look at a strategical impact. For example, a proprietary feature. If you would like to read more about it check the seven questions article.

Capital is the amount of money needed to develop a feature. If the feature requires more capital than a business is comfortable spending it is best to leave it. Though it is important to question the up-side, in an MVP environment it would be best to avoid it unless it is a core feature.

Implementation is closely related to capital, as they both influence each other. Implementation is the amount of time it takes to execute a feature. Some features can take a long time to implement while others can be short. Something that is a quality of life improvement for customers and is easy to implement, will generally be the first features a company can work on.

Picking winning features is both beneficial for a business and customers. The framework laid out before should help selecting and prioritizing which features can become differentiators.

If you would like to know more about prioritizing check the Eisenhower Matrix.