What is a MVP or Minimum Viable Product?

process methodology software

When it comes to building software, whether you’re building it yourself or hiring a custom software services company to help you out, an increasingly important topic to understand is the Minimum Viable Product or MVP for short.

Before we dive into it, first you should know that MVP has a few names. In fact the first time I came across it, I was actually introduced to it as MMP or Minimal Marketable Product. I read about it in an amazing book called Agile Product Management with Scrum.

Whatever it’s called, MVP embodies a very important philosophy when it comes to software development and can actually be applied to other fields.

In this article, we’ll dissect MVP and explain how it’s one of the best things you can do when starting a new product, a new feature, or new anything :)


Let’s start with some background on software development. Back in the day, software used to be developed in what was called a Waterfall model which was most likely adopted from other engineering disciplines. From a high level, it would look like this:

  • Domain Analysis
  • Requirements Gathering
  • Design
  • Implementation
  • Testing
  • Delivery

If you were building a software product, you might spend a month or so analyzing your domain - in other words, understanding the world that your users inhabit and the lives they live. Then you’d move onto requirements gathering where you would meticulously define every aspect of your application and list out every feature that your users wanted or would want. You would spend a good amount of effort fleshing out these requirements and getting every detail right. Next up would be design. Based on requirements, you would start to layout the user interface and the software architecture to build your application. After your team approved all that, you would move onto coding the application, testing it and finally delivering it to your users.

From start to finish, you would probably be spending anywhere between 6 months and a few years before you actually presented your users with a usable product.

If you happen to get all the steps right leading up to the release, you’d be a genius. However, the reality is it’s incredibly hard and rare to get every step right without getting proper, genuine feedback. This is the problem with Waterfall.

You may ask your potential users for feedback along the way, you may show them wireframes, you may show them mockups, but until you put an actual usable piece of software in their hands, at no fault of their own, they won’t give you genuine feedback.

How many times has someone looked at a proof of concept and said “Wow, that’s great - let’s move forward!”. Then, when the real product is put in their hands, they figure out all these issues with it.

Therein lies the problem.

It’s hard for anybody to truly evaluate a product based on documentation, meetings, discussions, wireframes, or designs.

With Waterfall, what you’re left with is months, if not years of assumptions and predictions about how someone will feel about a product rather than genuine, reactive feedback.

It’s the genuine, reactive feedback that you want so that you know you are building a product or set of features that users will genuinely want and need. You want to get that as soon as possible and avoid long stints of assumptions and predictions that cost you both time and money.

The big advantage of software

As mentioned, Waterfall was adopted by the software industry most likely because it’s what other disciplines used. However, there is a big advantage that software has over things like civil or mechanical engineering.

Let’s use bridge building as an example. If you’re building a bridge, you should properly do a lot of upfront work, analysis, calculations, and small tests before you put your first user on it. When you open up a bridge for use - you get very little chance for error and it costs a lot of time and effort to redo anything.

This is not the case for most software.

For most software products, companies are given the chance to easily update and continually improve their product. With modern technologies like the internet, it’s incredibly easy for a software company to improve their software by deploying updates over time.

Basically, software companies are given many chances and opportunities to change their product based on user feedback.

This distinct advantage combined with the importance of genuine, reactive feedback gave rise to iterative development.

Iterative Development

Iterative development is a very simple concept. Rather than taking a product from start to finish and then leaving it alone, you build the product, get feedback for your users, and do it all over again.

However, a company does not have infinite resources, so something has to give. What changes is the amount of effort and time spent in each iteration.

In Waterfall, you might spend 2 years doing domain analysis, requirements gathering, design, and implementation before you push out a product to your users.

With iterative development, you do some version of that but on a way smaller scale. You do some basic research, some basic design, and push out the product in a matter of a few weeks if not less. If you can’t sacrifice the level at which you do those activities, then you reduce the scope of what you’re implementing.

Either way, the idea is you do smaller chunks of development and repeat. There are many philosophies and processes that help you execute small iterations of development like Scrum, Extreme Programming, and Agile Methodologies.

MVP or Minimum Viable Product

So now, you understand the reasoning behind iterative development. It’s a push to get genuine feedback as fast as you can so that you can iterate, and improve your product. So how does a Minimum Viable Product fit in?

An MVP is the product of your first iteration of development.

Remember, your goal is get user feedback as soon as possible. So an MVP is the smallest, simplest, most barebone version of your product you can come up with that will get you the feedback you need to proceed.

Let’s break that down a bit.

“Smallest, simplest, more barebone...”.

The idea here is that you want to reduce the time and effort as much as possible. The reality is until you get user feedback, everything you assume could be wrong. So spending more and more time in the assumptive phase can really hurt your success. You want to reduce that time so you can test your assumptions and ideas as fast as you can. So the philosophy here is how small can you make it.

“...that will get you the feedback you need...”.

This combats the idea of making things small. If your MVP is too small, too bare, it could be so unusable that you get no feedback at all. If there is zero attraction to even try out the feature or product then you’re going to get nothing back.

“...to proceed.”

This last thought is really your ultimately goal. An MVP is all about getting to the next step. If you execute an MVP correctly, you’ll have enough information to help you make big decisions to move forward.

Deciding on what makes up your MVP is really an art in trying to balance reduced time and effort and creating something that people will actually use.

Applying MVP at all levels

MVP was originally used when talking about releasing the first version of your product. Since then, however, its principles have been applied at all levels.

For example, let’s say you’re creating a new feature. Rather than building the best, highest gloss version of that feature - you might scope it down and release the MVP version of that feature to get feedback on where to go next.

It’s become so common at our company that we start to use it as a verb. “Let’s MVP that feature!”

Later in this article, we’ll see how MVP can be applied to more than just software development.

How do you go about defining your MVP?

There are definitely a lot of strategies when it comes to defining an MVP but it doesn’t have to be a complicated process. In fact, at BiteSite, when we talk to our clients about “MVP’ing” their product or a new feature, it’s a pretty simple conversation.

When it comes to most people and how they think about their product or a new feature, nine times out of ten, they are already thinking bigger than an MVP. It’s just the nature of what happens when you think about your next great idea and get excited about what it could be.

So the process is very simple: go through every aspect of your product or feature and ask yourself “Do we really need this right now?”

Play your own devil’s advocate and you’ll be surprised how much you can cut out.

In fact, you may even be noticing these days that brand new products are missing some features that you would have thought would be no brainers. That’s probably a company putting out an MVP and seeing what how the masses react. Remember the first iPhone and it missing copy and paste?

When you develop a product, you’ll most likely have an endless backlog of features. MVP’s help get your the feedback you need to prioritize what’s important now versus what can be delayed until a later date.

Don't make your MVP too minimal

Something that I’ve recently learned that I’m guilty of is the practice of making your MVP too minimal. This will usually stem from the developer side rather than the product management side.

When I started implementing the MVP philosophy to our products and features, I made the mistake of always cutting out the same things. One thing, for example, I cut out all the time was UI design. I would always just say, let’s just get the basic data entry working with a basic UI first and see how users respond to it. The problem was, if the interface was really bad, users wouldn’t use it at all.

Remember, the goal is to get feedback from users.

Part of the delicate dance of figuring out your MVP is figuring out what it is that users will care about and what they won’t care about. So make educated guesses and don’t strip out too much.

Defining your MVP doesn’t always mean cutting out functionality

A lot of times when we talk to clients about MVP, it’s not always about cutting functionality out for the user - but rather replacing it with a non-software solution.

For example, you may say “I want my users to be able to reset their own passwords.” A developer comes back to you and says, “Well. Right now, I can manually reset the password, but we’d have to build out an interface for the user to reset it themselves.”

Depending on the product, a good MVP solution to this might be to keep this feature out, and for now just have the developer reset the password manually and have a human being e-mail that user manually.

In the beginning when you’re dealing with your first set of users, this might be a great way to start. You may find out after you release it that for the first year - no one has requested to reset their password. On the flipside, you might find out in the first week that everybody wants to reset their password and as a result you prioritize this feature.

That’s what MVP is all about. Start off with a small scope and don’t implement feature until you have good evidence that it’s needed.

You don’t have to get it right

The idea of an MVP is very consistent with a lot different processes, philosophies, and methodologies. You’ll read this a lot:

“It’s not about getting it right. It’s about moving forward.”

That’s the crux of it all. If you’re having a lot of trouble figuring out if your MVP is too small, or too big, or if you’re making the right assumptions or not - don’t worry about it too much. MVP is all about picking a path, implementing it, and testing it with real users. You’re bound to get some stuff wrong. But knowing you’re wrong based on feedback is way better than assuming you’re right or wrong.

Yes, it’s good to have informed discussions, it’s good to have opinions, and it’s good to make educated assumptions - but don’t dwell on this too long. Just move forward and get the feedback.

The Sprint Book by Jake Knapp really solidifies this concept and even assigns a “moderator” to the process to keep this in check. In fact, that book and its process in general is an amazing embodiment of MVP.

It’s all about the Feedback

By now you’ve gathered that MVP is all about feedback. The one thing to keep in mind, though, is that feedback can come in many different forms and they all have their place. The following is just a short list of different types of feedback you can aim for when finally releasing your MVP:

  • Direct Contact
    • After you’ve deployed your MVP, you can directly contact your users and ask them what they liked and what they didn’t like. This obviously is only suited for smaller number of users, but can be very helpful for companies starting out. One thing to keep in mind is to analyze the feedback rather than just follow it. Just because one person says they didn’t like your sign-in screen doesn’t mean everyone hates it.
  • Surveys
    • You could proactively reach out to some users and send a survey. There is a whole art to designing surveys, but even simple surveys can get you some great information.
  • Data and Usage Analytics
    • Data analytics is a great way to get unfiltered, honest, reactive feedback. When you talk to customers in person, they may hold back their true sentiments. Data and usage analytics let their actions do the talking. Take a look at how many people are actually using your feature or product and how they are using it. Tools like Google Analytics, New Relic, Skylight, and Mixpanel can help you with this.

MVP is just a start

The last thing I’ll mention about MVP is to remember that it’s a philosophy on how to start implementing your product or feature.

When I say scale back your product idea or vision - that’s only to implement your MVP and get going. By no means do I mean throw out your big ideas or vision. Keep those in your back pocket and let your MVP inform you as to whether or not you’re on the right track.

How can you apply this

You’ve learned a lot about what an MVP is. So how can you start applying what you’ve learned. Well, it depends on what you’re working on.

Are you thinking of building a new piece of software?

If you are, chances are you’ve already had a big vision in place. Keep that vision in your back pocket and start to think about your MVP. Put all your ideas on the wall, and start crossing off the ones you really don’t need to get going.

Our favourite clients at BiteSite are the ones who have thought about their MVP. They come in with a big inspiring vision, and then shortly after say “...but as a start, here’s what I envision.”

Personally, I love when I can envision a product that I can build in a couple of days that will instantly bring value.

Are you an established company with an established product?

If so, chances are you are considering developing new features. You can apply the MVP principles to your features. Scale them down to a small enough level that you can quickly implement them, deliver them, and get some informative feedback.

MVP for everything

What’s interesting is as I go further and further into my professional career, I find the principles behind MVP can be applied to a whole lot. The idea of implementing small and quick deliverables and then getting feedback is finding its way into a lot.

Currently, I plan on applying it to our sales process and identifying target markets and in the past I’ve applied it to small changes in our company. We would try small versions of our changes and if they failed, we’d scrap them. If they succeeded, we’d iterate and build on them.

MVP is an incredibly powerful idea that was introduced to me through software, but I’m finding more and more that it can be applied to almost everything.

Casey Li
CEO & Founder, BiteSite