A Minimum Viable Product or MVP is an application that hasn’t reached its full potential but it lets you test core product ideas. It’s not polished by a long shot; it’s not finished and can be buggy. But it’s still delivering the most important functionalities to the user and acts as a testing ground for future app options. The road to a successful launch is tricky. Here’s the checklist for a successful MVP.
What is an MVP and why you need MLP instead?
Yeeeah… one thing. We so much expect MVP to be unpolished and buggy that we kind of excepted the notion is a way to go with this thing. It’s not. That’s why we highly recommend creating in your organization a mindset of an MLP which stands for the Minimum Loveable Product. More on that in the linked article. Here we just want to point out that MLP is still an MVP but with a twist. Instead of trying to test something, you can release a smaller version of the product that people immediately love for its design and functionalities from the get-go. Not because it’s merely there and serves the purpose.
Read on that later, right now let’s move to the simple question: why it’s worth creating an MLP?
- You can quickly deliver value to your audience. Sure, in case of MLP it’s always good to wait a little longer than MVP, but it’s still worth it. People interested in solving their problems could easily get rid of it by using your app and become early adopters.
- You can beat the competition. Side-effect of that is that chances for using a similar product drop significantly. Why test something else if what you need is already there?
- MLP is a sandbox for testing. Not sure if a given functionality is worth the time of your software augmentation team? Do you think their time is too valuable to develop something half-baked and not precise enough in theory? Test it while you safely can. Don’t burn money, make it a part of your application. Sure, MLP is more about delivery already functional features but doing experiments on leaving tissue didn’t kill anybody. Oh well, you get the idea anyways.
- MLP is perfect for early pivots. Sure, MLP delivers even more quality on the market than MVP but it’s still not bulletproof. People might not except the direction you’re moving towards in 100%. That’s why it’s better to test something before you decide on investing all your money.
A 7-step checklist for a successful MVP
With this checklist for MVP launch, you will be able to save the time and money. Don’t burn the budget on something that doesn’t work or requires a lot of time; even for MVP standards. Use these good practices!
The checklist of what is required for a successful MVP can be summarize into three categories:
The goal, defined as the one major problem you wish to solve for your intended customers
A user flow process showing the process and steps your customer will take while using the product
A prioritized feature list representing the minimal functionality required to solve your customer’s problem
The goal
- Define your criteria behind an MVP success. This is where it all begins. What exactly do you want to introduce to your audience? How many users do you want to attract in first quarter? What level of user churn are you willing to except up to the end of the year? What number of active users do you want to have? What sort of feedback is the most valuable to you? These are questions you absolutely need to ask yourself… or define yours. It’s your product after all!
- Decide what problem you solve. This weighs on everything – from product’s architecture, through technology pick, ending with marketing messaging. Why do you want people to use your product? Even if their problem can be solved, what else? A single-purpose product is rarely seen as perfect these days.
- Make a list of long-term goals for future feature releases. It’s a mouthful but it boils down to a simple question: what else? What do you want to add? Will it improve already existing list of functionalities? Will it dramatically change how the product can be perceived by the audience?
A user flow process
- Don’t overthink it – keep the experience simple. Think of an MVP as a solution for opening a beer. Does anyone need the tool to make coffee? Bring home kids from school? Have multiple features that nobody uses? No – it needs to open a beer, period. Sure, you can still open it with a Swiss Army knife but that’s a multitool. The point is – people need to know what’s what and how to use it. Don’t complicate UX/UI for them. It’s there to work, not win a Nobel prize.
- Decide what features are essential, what are must-haves and what can you leave for the future. Map user journeys and user flow. Think about who wants and needs when. Do you need a certain functionality now or can it wait for the future build? Prepare a list of features and try to stick to it in the future. This is different from not-pivoting. Pivots you do when you absolutely need to. Sticking with your list means working towards market success. It’s also called having a plan.
- Always keep user’s perspective as a lighthouse. You’re not developing a product for yourself. You are not even doing it to make money. That’s a side product. You are solving a problem for someone out there. Meaning that your knowledge, skill, and experience are valid and important, but only to a point. Customer’s perspective is even more important. Is the product easy to use? Can I easily get to key functionalities in no time? How much time does it take me to understand the product at all? Make yourself comfortable around these questions, you will see them quite a lot.
A prioritized feature list
Identify core features. There are many frameworks you can use to make it happen. Some of the most popular are:
- The MoSCoW method, splitting features into must have, should have, could have, and won’t have
- Story mapping, where you have a series of categories that represent each stage of the user’s journey on a horizontal axis, and vertically under each of these, place the features in order of priority
- Confidence, when you estimate how confident are you about the positive impact of the feature (100%, 80%, 50%, etc.)
- ABCDE method. Through this method, you can control and prioritize your tasks. You must list all the personal and professional tasks you must follow up on. With that, you must assign each one to the following categories:
A stand for “Very important tasks”: it’s imperative that you take care of these, or you’ll suffer consequences;
B stand for “Less important tasks”: you need to take care of these tasks but not in an urgent manner;
C stand for “Nice tasks to do”: these are tasks that should give you pleasure to do;
D stands for “Tasks to delegate”: these tasks can be passed to someone else, so you don’t get overwhelmed;
E stand for “Tasks you can eliminate”: these tasks should make part of your list, and you can eliminate them.
Regardless what method will you choose, the goal is to decide on a prioritized list of features required to release the early version of the product. Anything not marked as the priority from the user’s perspective can be moved for a future app’s version.
Is there a difference when building for web and mobile products?
There’s one thing that is obvious for everybody – the technology. The tech stack defines how well and how quick can you make your product.
You need to remember though, that using a web MLP while developing a mobile app won’t get you anywhere. User base might even be the same, but the range of habits and needs are different. Simple translation of the code won’t cut it.
If you want to build simultaneously for both worlds, use a technology that facilitates multi-platform development. React Native, for example.
Summary
One of the most important reasons behind startups falling out of the market is no market need. These reasons is constant among various reports, no matter the industry. That’s why it’s so vital to have the right team behind you. Especially for mobile app development, where competition is fierce.
A successful MVP or MLP as we like to call it, originates from understanding the user. Start there and go for it!
