Being a freelancer, in the last couple of years I have switched frequently between companies and teams. After each change there has been a period of adaptation when I learned how the team worked, including their naming convention. Especially around Agile and Lean methodologies, in different places the same thing has different names; to make it more confusing the same name is used for different things as well.

Minimum Viable Product (MVP) is one of those terms for which I need to see a previous example in order to know what each team means. After learning what each team meant I frequently felt that they were under-using MVPs; and what is worse, some of their stakeholders were starting to see the term as a buzzword.

There is a common ingredient to all the types of MVP that I found useful: An MVP should help you validate your assumptions in order to steer your current strategy as soon as possible. Therefore I like to think of the MVP as a first milestone in the journey of experiments that will help you build what your customers want in a profitable and technically fit way. Off course the MVP is only the first step, after the MVP you should continue to build your product iteratively, validating your assumptions down the road.

Areas where an MVP can help

Business Validation

At a business level, MVPs can help you validate assumptions that are critical in order to ensure a good value proposition with the right market fit:

• Do your customers have the problem that you are aiming to solve?
• Would your customers solve that problem using your product?
• Would your customers pay your proposed price for your product?

Good news is that a Business Validation MVP can be built without spending much money in development, this is called the Wizard of OZ. The infamous example for this approach is the Zappos MVP, in their MVP their website simulated a fully functional eCommerce site, but behind the curtains all the order management and fulfilment was being done manually.

User Experience Validation

From a user experience perspective, you should also validate as soon as possible your initial assumptions, and MVPs can help you do it.

• Does your customer understand your product?
• Can customers easily complete the jobs that can be done with the product?
• Are your customers using the product in any unexpected way?

Usability tests can be done as well before writing a single line of code. Nowadays you can find lots of inexpensive mock up tools in both desktop and online formats.

Technical Validation

While you are designing and developing the product before launch, all kind of assumptions start stacking up one on another. As the volume of assumptions get bigger the risk of necessary rework increases exponentially. In house testing can never match actual users in production. By releasing your product soon and incrementally you will get the following benefits:

• You keep your product scalable from the beginning.
• The hardening of the product will be cheaper and more reliable (bug fixing).
• You make sure you can cope with the maintenance and operation of the product.

It´s important to find a balance between applying MVP and developing a perfect software. Some technical people tend to be too perfectionist, thus leading to a long time-to-market and potentially to delivering the wrong product. Technical validation can be achieved without having the complete Software Architecture in place: try to benefit from existing frameworks or techniques and build the foundations keeping in mind your non-functional requirements (performance, reliability, traceability, etc.).

Choosing the right architecture approach and the interfaces between your components are the most important technical parts to validate. Having them in place will enable you to replace pieces later with better developed software, without much impact. That’s one of the reasons why a microservices architecture is getting so popular these days: independently deployable parts that you can evolve or replace separately.

How MVPs can help different kinds of teams

Product/Feature Team

Product teams are responsible for a product or feature during all its life cycle, from its inception to its end of life. During this time the team has to create a product and improve it iteratively in order to fit its users´ needs. This kind of team is my personal favourite since the team builds a full understanding of the value that they are delivering and this knowledge is persisted with the team.

Product teams will have several chances to build an MVP, for either new products or new features for an existing product. In all these occasions the team can have all the benefits in all areas of validation: Business, UX and Technical.

Product Teams are especially powerful in business validation, since a fully empowered Product Team will have the chance to ask fundamental questions at the creation of a product or feature that will allow them to pivot or cancel initiatives before spending significant resources in building them.

Project team

Project teams are created for an specific project and their lifespan is as long as the project is. Projects are usually focused in performing a change in an existing product or building a product where requirements are agreed beforehand. Project teams are common in the B2B world, for example in Consulting Agencies and when building enterprise products.

From my point of view Project Teams can take benefits from MVPs in the Technical and UX plane. But from a Business Validation point of view, lots of variables are defined beforehand, therefore the opportunities for validation and steering are very limited.

Given that the scope of the project is usually decided beforehand, the team will rely on assumptions from an external agent (usually non-validated) to ensure that the project is delivering real value to its customers.

On the other hand if the project is approved beforehand, that means that if the team delivers on budget, the project is profitable. Problems usually arrive when the project team realizes that the value assumptions were not right or the budget was not realistic.

Component team

Component teams take care of one of the technical systems that compose a product. This usually happens in technically complex products, where a single team is not capable of mastering all the systems that compose the final product. In cases where component team are unavoidable, there should be an overarching product team that helps all the components understand the big picture and how their work impacts the end customer.

These teams can easily take benefits from an MVPs at a technical level, but not so easily in other areas. Only if the team is taking care of a component interfacing the customer, they will be able to validate User Experience assumptions; for example front-end components.

In the business area, a strong product team should coordinate all the component teams in order to sum up a Product wide MVP which delivers a consistent value for the end customer.

Final words

No matter the kind of team you are, Minimum Viable Product is a powerful tool that you should start using as soon as possible. Don’t let it be just another item in your manager’s buzzword checklist. If you scratch the surface, MVPs will optimize your learning curve and help you spend time in building profitable products that customers will love.