Many of our clients approach us after a design sprint and ask us to help them figure out how their MVP should look like. In this article, we will share with you how we help them figure out a roadmap and a priority plan for their MVP. We assume you already have a good idea of what kind of solution you are going to offer and who are your users. If you don’t, you should probably do a design sprint first.
Going forward from a concept, even a very concrete one, into an MVP plan requires careful analysis of the implication of your concept. It requires technical and functional analysis. Your MVP plan should be a timed list of activities that you have to run, and the most important thing is to come up with a set of priorities because you will probably have to be agile on your MVP. Most MVPs tend to change as time unfolds, and that’s OK because you are in the business of innovations, and changes are part of that game.
Before we drill down on hows and whats, let’s examine the term MVP.
What is MVP ?
MVP stands for Minimal Viable Product. A minimum viable product is a version of your product with just enough features to satisfy early customers and provide feedback for future product development. It should answer the question: “Is my idea worth doing?” While you can validate quite a lot with just a well-designed prototype, still, before your product actually hits the real market, there is a lot of unknowns to be answered.
The MVP should be designed to answer at least the major questions you have, and it should include a set of features that will help us understand where and how we should move forward. So for us to design and plan an MVP, we need to consider two main questions:
- What makes our product viable?
- What is the minimal set of features we need to develop to make this viable product?
So how do we address this?
-
Core Value Proposition
To answer the question: “what makes our product viable?” we need to agree on the core value proposition of the product. We must agree on the problem we are solving and our main target audience. The people that feel this problem and would be willing to pay for a solution. As focused as we can get on that, as narrow as we can be, the easier our task will be.
So you have to consider that the MVP is not our final product. It’s a tool aimed to make us understand our solution and its relationship with the market. You should think about it as a starting point for your market experiments. So, like in a lab, you want to have as little clutter as possible, and if you are very focused on a small number of users, it would be much easier and cheaper to reach these users. Once you understand your value proposition, growth will be much easier. The core value proposition has to be written and agreed on.
-
Understand the Timeline & Budget in Your MVP
Usually, the budget is a bit easier because you know how much money you have. But as you hire a team, time becomes money, and things become complex. However you prioritize, you must set a target timeline. There are many considerations around the timeline. It can be the cost of the team, a market opportunity, or an investor directive. In any case, it should be clear and feasible as we will need to plan our MVP around the time and resources.
A common mistake is to forget about the go-to-market budget and only look at the cost of development. You should allocate a budget for rolling your MVP and supporting it. In many cases, these activities are more expensive than you expect, and it usually takes more time than you think to get your answers for your MVP.
Also, you should think about the cost of maintenance and iterations, as you will most likely make a lot of mistakes in your MVP. You will need to iterate both your technology and your design.
Once you identified and agreed on your value proposition, you need to outline the features you would include in your MVP. A good way to think about these is to outline the user journey in your product. Think about the 2 or 3 major use cases a user will have to do in your product to solve their problem. For example, in a vacation booking app, you would have to enable a filtered search, information about the hotel, and a booking process. You will probably need to have a signup flow too. If your core value, your differentiator in that app, is the ability to communicate online with the hotel, then this also must be included.
Draw each use case and use your team to write features and development tasks required for each step. Use post-it for each task. This should include everything that comes into your teams’ mind. Don’t think about cost or complexity. Think about the use case and how to make it serve the value proposition. Next, group the items based on dependency. For example, you can’t search without a search engine and a content database of searchable items. Do not cluster things that are not absolutely dependent on each other.
-
Identify the Must-Have Features
These are the basic stuff you have to enable. The must-have features are things that we can’t compromise. Things that are central to our product’s experience, and we are not willing to compromise on their execution quality. For example, think about google search. Speed is one of the core values of the search engine. It was a major differentiator, and even the first versions had to be fast.
Give each team member 3-5 dots and ask them to vote on the top 3-5 tasks that are “must-have”s. Finally, make the decider select the must-haves and move them under a list titled “must-have.”
-
Identify the Should-Have Features
These features must be included in the MVP. The functionality is essential to the user journey, like the “Must-haves.” But the quality of the execution can be compromised at this point. For example, you may have to have a payment gate on your launch, but you can decide against fancy payment integration and go for only PayPal simple card button.
Take all of the items that got votes but were not selected for must-haves and group them into a list titled “should-have.”
-
Think About the Could-Haves
Some of the features are not necessarily in must-have but are worthwhile having. We need to think about them as sometimes we get opportunities to add them either in the MVP itself or in the coming versions. It’s a good idea to estimate each item’s cost implication and identify “low hanging fruits” you may want to apply.
Draw a grid with two axes: impact and effort. The top-left items will become the first items in your “could-have” list, and the top-right items will be at the end of that list.
-
Won’t Haves
After skewing through all of the features and user flows, prioritizing, and deciding, you must have a list of things you will not be doing. If you don’t have these, it’s probably a sign that you’re not prioritizing well. MVPs require tough decisions, and not having a list of rejected ideas is an alarming sound that may indicate that you do not have a good enough idea about your core value proposition or your target audience.
If you went through all the steps, the only thing you need to do is to grab the low-impact items from your prioritization grid and place them in the “Won’t have” list. Make sure everybody in the organization is well aware that we are not going to do these even if time and resources enable us to do so. If we can, we will push our launch earlier.
Conclusion
MVPs can become tricky. They require strong alignment and strong leadership. Tough decisions are made, and you are bound to make some mistakes. Remember, it is more important to get started than to be right.
One last tip: A good way to get a good MVP plan is by starting with a design sprint. If you have a real-looking prototype validated with real users, your discussions and decisions are much easier to make.