MVP, or minimum viable product, is one of many acronyms tossed around without a shared understanding. In this article, I’ll break down the concept of an MVP, what an MVP could look like, and how the MVP is a useful tool for software product development.

This article will also give you an understanding of what WE at RokkinCat mean when we talk about building an MVP with our clients. The most important part of understanding an MVP is that your entire team is on the same page about what you’re working toward. Failure to be on the same page can lead to misaligned expectations, accumulating unnecessary technical debt, or neglecting to collect feedback from users soon enough.

What is an MVP?

While there isn’t a rigid definition I can give you, I do want to illustrate a few things about MVPs:

• MVP: Minimum Viable Product OR Minimum Viable Prototype
• An MVP is a concept (we’ll learn more below)
• To choose to build an MVP is to employ an agile strategy
• Executing an MVP should bring you closer to producing your big vision (Ex: full-featured product)

Put simply, a Minimum Viable Product (MVP) is the smallest slice of your [big vision for your] product that can deliver value to a set of users. By focusing development efforts on an MVP, you’ll decrease the time it takes to get your product to market and start generating revenue to fund the rest of your product’s vision.

Examples of MVPs

Seeing examples of MVPs compared to the entire product visions is what helped me shape my understanding, so we’ll start there.

Below, I’ll briefly explain the big vision and motivation and problems, then I’ll hypothesize some MVP ideas.

Example 1: Online Movie Rental in 2005

Big Vision: We want to make movies more accessible to families and eliminate DVD waste by providing movies online through web and mobile apps. Context:

• It’s 2005 – Netflix doesn’t exist yet, and we can’t rent movies on demand with services like Google Play or Amazon Prime.
• We know BlockBuster & Family Video rent out movies successfully in person, but we don’t know if users are comfortable renting movies online.
• We only have $5000 saved up of our own personal money, but we’d like to get investment from an Angel Investor or Venture Capital fund to create the big vision product.

MVP Ideas:

• MVP: Buy/license the use of 1 hit movie from the last month, and rent it out using a website on a pay/play basis.
• MVP: Buy 1000s of movies on DVD, a mail label maker + envelopes, and rent them out across the nation using a web app.
• MVP: Buy the top 25 movies from the last 3 months on DVD, and rent them out within your city using a web app.
• MVP: Buy the top 25 movies of all time, and rent them out within your city using an online form that submits to your email.
• MVP: Buy 5 top-rated & recently-released movies on DVD, and rent them out using a physical sign up list in the break room.

Example 2: Inventory Tracking

Big Vision: Tracking items within our warehouse on paper is time-consuming and error-prone. We want to create an application for our warehouse employees to use on mobile devices that will enable us to track the location and state of the items in our warehouse.

MVP Ideas:

• MVP: Share a Google Sheet with employees that has dropdowns for the item’s location and status, keyed by an item’s unique identifier.
  • Problem: Assumes account-level access to Google across company, spreadsheets are also bulky to navigate on mobile
• MVP: Create a Google Form to log item movement and current state (Item Identifier, moving from X to Y, include whether item is damaged or not), can check spreadsheet on a computer to find an item’s latest location.
  • Problem: Still have to interact with a bulky spreadsheet
• MVP: Create a mobile-friendly website to track an item’s movement from one location to another, and allow users to search for an item’s current location & status by item identifier.
• MVP: Create a mobile-friendly website to track an item’s movement from one location to another, and allow users to view and filter a history table of all item movements.

In this invenotry example, it appears necessary to create an MVP that is more technically complex than an online form. That’s okay! The point of an MVP is that it should fit YOUR situation, your potential users, your value proposition. If checking a spreadsheet makes it easier to search, but more difficult to enter data correctly, then it’s not solving the problem and delivering value. The challenge now is trimming back features to what’s most important right away.

While the latter two examples seem very similar, actually creating each of those requires a different work load. We’ll need answers to several questions:

MVP with Search	MVP with History
* How large of a data set do we expect? How many items will exist at once time?	* How large of a data set do we expect? How many transactions will be logged in a day? A year?
* If large, will a simple search work, or will we need to buy a service to improve the speed?	* How long will we need to keep this data around? Forever? Can we store older data somewhere cheaper, or does it need to be quickly accessible?
* Do we need to track only the item’s current location & status, or will we eventually want history too?	* Should we choose something that’s faster/easier/cheaper now, but have to plan to migrate to a more robust solution eventually?
* Do individual users need accounts, or can they share one login for now (is it important to know who moved what? Can we trust our users to enter their name alongside each movement log?)?

Answering these questions and choosing which features to implement comes down to 1) what is highest priority to your users? and 2) what risks are you willing and able to afford in order to gain revenue?

MVP & Agile

The term MVP is popular in the software & startup communities because of its alignment with the agile methodology. Agile is a set of guidelines for building software that is, as it describes: agile! Otherwise described as nimble, quick, adaptable.

Agile’s guidelines prioritize:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Prior to Agile, products were built using the “Waterfall” method, which looked like a team coming up with one big solution to a problem, documenting every possible detail, making a plan for how it would be developed, then building it. This process could mean waiting 6 months – 2 years to output working software. This plan didn’t include collecting user feedback until after the entire product was built, at which point user feedback could reveal something fundamentally wrong, and well … you get the idea.

Hence, the Agile manifesto was written. Certain specific frameworks like SCRUM + Kanban were born of Agile, but the manifesto stands to serve as a guide for building products in general. These processes plan for iteration – meaning they intend a product to be developed, put in front of customers for feedback, and then have that feedback incorporated moving forward. In order to continuously iterate on a product, however, one must first deliver an initial version of that product. But what is included in an “inital version”? How do you decide what makes the cut?

How to choose an MVP

An MVP should bring you closer to producing your big vision

With that in mind, consider asking yourself: “What is stopping me from building the whole thing right now?” Be completely honest with yourself.

• Do you have the money? The time? Maybe your MVP is something that will enable you to seek investment funding, so that you can quit your job and work on the product.
• Do you know if your target market will pay for the value you’re providing? Maybe your MVP is providing something cheap to produce for a small group of beta testers, then charging for that.
• Do you need a user base? Can you provide some of your value manually until you’ve grown your user base or revenue? (Ex: Google Form instead of building an app, manually delivering DVDs instead of printing labels & buying envelopes to mail them)

Your MVP will become your immediate focus – this is what you should be prioritizing since it’s what is driving you toward your big vision.

Questions to ask yourself as you hone in on your MVP:

• Can we make it any smaller? Cheaper? Easier to build?
• Can we initially offer it to fewer people?
• Does it still provide value?
• Would our customers use this?
• How quickly can we build and test this?
• How will we collect feedback? Can we incentivize feedback collection?

Ideas for pulling an MVP out of your big vision:

• Beachhead Market / First Customer(s)
  • Offer it to less people (limited launch)
  • This might mean the product is less technologically demanding while still providing value to the group you’ve enlisted as your first customers
  • Ex: create a riding app that supports 10 users instead of supporting 100 users right out of the gate.
• Limit Scope & Functionality
  • What is the tiniest amount of value you can offer?
  • Is having an account necessary?
  • Is it necessary to have this available cross-platform (web, Android, iOS) for first launch?

An MVP

• Is an avenue for testing assumptions about your customers
• Delivers value to your customer
• Is testable
• Brings you closer to producing your big vision

An MVP is NOT

• Your entire product vision
• Your entire product vision but just for a dozen people – that’s just getting customer feedback on your entire app
• Delivered to every potential customer all at once

MVPs Are Great! Here’s how we use them at RokkinCat

MVPs + iterative development enable your organization to pivot and be adaptable. By getting customer feedback early, one can avoid building a product that doesn’t actually provide value, or one could discover an entirely different value proposition along the way.

Defining an MVP also provides an opportunity for your team (and any accomplices) to get on the same page about what is most important for your product or your company.

At RokkinCat, we’ll often associate building the MVP with your first launch to customers. As described above, if your MVP is in fact testable and provides value, then we should be able to launch it to beta users and start delivering that value!

Once you’ve delivered your MVP to your customers, that doesn’t mean that it’s time to develop everything else all at once. We can use the principles of creating an MVP to guide our next course of action, and now you’ll have some user feedback to guide your decision making.

One pitfall we see time again is throwing the phrase MVP around without a consensus on what that means within the context of the product you’re building. It’s often that you end up with different interpretations of what an MVP of your product is, especially if you’re learning to use an iterative approach for the first time. THIS IS NOT A BAD THING! In fact, building consensus and fielding different opinions on what is most important to your product is extremely useful. The mistake would be to continuing to allow confusion in priority, as that often results in a burnt out development team and no stakeholders getting exactly what they want.

What if we just do waterfall anyway? We’re pretty sure we know what our users want

The risks of developing a product all at once are well-documented, and I’ll recap them here. You may very well be correct that you already know what your users want, you’ve done lots of customer discovery, and maybe you even have a user base committed to beta-testing your product once it goes live. This doesn’t change the fact it takes a long time to build a software product (during which user needs/constraints change), and that it is significantly more difficult to iterate after you’ve launched a big product.