The art of scoping an MVP
The concept of a Minimum Viable Product has been popularized to the point that the phrase is used without even thinking about it. Perhaps you even hear and use it so often that you have to pause for a moment to even remember what “MVP” stands for.
“Let’s just get this to MVP, and take care of the rest of this later,” says the engineer, tired of having the project drag on for sprint after sprint with no shippable product in sight.
“What is the MVP for this project?” asks the executive, who doesn’t understand a complicated feature proposed for their biggest piece of software.
“Which features are considered part of the MVP, and which will we do later?” the product manager wants to know, as she builds user stories for the backlog.
All 3 of these people are talking about the same concept, but it means different things to each of them. And that’s OK! The MVP must be defined precisely enough to be well understood by everybody on the team, even though it will impact them all differently.
Understanding the MVP concept
The idea of a minimum viable product was popularized by Eric Rees (of “The Lean Startup” fame) more than a decade ago. The core value of an MVP is to achieve a product that you can quickly get into the hands of your users for feedback. You want an actual working product, and you want to get it into their hands as early as possible. Starting with an MVP does two things: it helps you get to market fast, and it helps avoid building the wrong set of features.
So how do we define a project MVP that will be well-understood by everybody on the team? Let’s break out the two descriptive parts of the phrase: minimum, and viable. A product that isn’t viable hasn’t achieved MVP, and if you built more than the minimum then there is a risk that some of what you built will need to be redone.
Think this seems obvious? It is, but many projects struggle to actually get the scope of their MVP right,
The minimum product
Understanding the “minimum” you need to build is important. Why? Because everything you build before getting the product into the hands of your users will likely need to be completely re-written. No matter how much user research has gone into the planning of your software, there is no substitute for actual, real-world usage. When your software product hits the real world, you will almost always be surprised by what your users tell you about it.
Sometimes the surprise will prompt you to think, “That is genius, why didn’t I think of that?”. Sometimes you will fume, “But that is exactly what you said you wanted!”. And sometimes in the worst-case scenario, you find out that nobody wants your product and you must either pivot or abandon it.
The less you build before you get this feedback, the better. In the happy case where you can add/adapt something to help your users find more value in your product, wonderful! Getting feedback early helps make sure you know where to focus your next efforts.
If you find out that your understanding of the product needs was wrong, you can go back and retool without too much frustration and rework.
In that worst-case scenario where the best course of action is to start over or move on to an entirely different product? Well, the less time, money, and energy you spent on it the better.
A viable product
Imagine a friend asks you to test their app. “It’s like Uber, but for sending singing telegrams to somebody. Just enter the address, and a barbershop quartet will be there to serenade and entertain whoever you like”.
With your friend watching over your shoulder, you open their app and enter an address. Blank screen. Your friend jumps in excitedly, “OK, now imagine that here you will select from a list of different types of telegrams you want to send. Funny, romantic, patriotic, or even…”.
This app clearly is still in the research and planning stage, and nothing near what you could consider viable. If the app is supposed to send a singing telegram, it is difficult to provide any feedback to your friend if you can’t actually use it to order a singing telegram. To be “viable” not only does the software need to achieve some level of completeness and usability, but there needs to be a barbershop quartet somewhere waiting to dash somewhere at a tap of your finger!
If you expect to gather user feedback on your MVP, your users need to be able to use the product. If it is missing basic functionality or is so buggy that you can’t actually use it, feedback is going to be blank stares, comments like “this sucks!”, or other unhelpful responses.
Balancing minimal vs. viable
As you may have observed, there can be some tension between minimal and viable. If you define the MVP as being too minimal, feedback might not align with your eventual app. If you focus too much on a complete feature set, you may end up with functionality that needs rework later.
There are no hard and fast rules about how minimal your MVP should be, and there is no formula to let you know exactly which features need to be included.
There are some guidelines though that you can apply.
Factors influencing your MVP definition
Some points to consider as you decide what makes it into your MVP, and what doesn’t:
- If you are building a product that already has a market, then your competitors have already done your market research for you. Congratulations! Defining your MVP will focus on being attractive for as many users as possible.
- If you have one or more team members who deeply understand There are ways to start gauging product-market fit long before you ever start building, and if you don’t have a very good idea of what you are building, who it is for, the market size, etc. then you important no matter how well you think you know what needs to be built.
- Don’t confuse validating an idea with building a product. There are ways to start gauging product-market fit long before you start building. If you don’t have a good idea of what you are building, who it is for, the market size, etc. then you aren’t ready to think about MVP scope.
- Time and budget can sometimes be influencing factors. If you must have your product built for a certain event such as a holiday season, that may affect how much you can do. If you have a large budget, perhaps you can expand the team to get closer to the ideal balance of viable vs. minimal – otherwise, you will need to cut features.
- The risks associated with customers using your software will affect how you look at MVP. Building a new take on a to-do list? You will want to validate your idea very early on to see if it is as unique and compelling as you think it is. If you are building control software for a nuclear plant, well… maybe just skip the MVP step entirely.
Reid Hoffman is often quoted as saying “If you are not embarrassed by the first version of your product, you’ve launched too late.” All else being equal, your MVP should tilt towards being as minimal as possible, with as much excess functionality cut from the scope as possible.
The art of the MVP
Building just the right features for your MVP is much easier said than done, but spending some time to get it right is well worth the effort. Remember to make it as “minimal” as you can so that you can get feedback early in the process. At the same time, make sure it is “viable” as well so that the feedback can influence the actual product you are working toward.
Make sure that everyone on the team understands the scope of the product at this early stage, and why it was scoped the way it was. When team members question the scope of the project, take time to confirm, or address the concerns with the team.
Can the definition of the MVP change? Of course! New information and perspectives should always cause you to go back and revisit your plan. Remember to be agile in your scope, just as you are everywhere else in your project.
Now go out and build something great. Get feedback, iterate, and make it even better!
