Having the opportunity to design & build 6 MVPs in 30 days really taught me a lot about what features you should launch with.
Over the last few years the concept of launching an MVP (Minimum Viable Product) has exploded in popularity and is now a common practice for both startups and established tech companies. But as is the case with most concepts that reach buzz-worthy status, there’s a lot of confusion. There are die-hard advocates, staunch skeptics, and a ton of people that just toss around the term without really knowing what it means.
So let’s back up for a second to get on the same page. The overall idea of an MVP is that you should build the smallest amount of your product that people get value out of and then you add additional features to it. MVP-advocates argue that building the smallest amount first allows you to find out what additional stuff people actually want so that you don’t waste your time building a bunch of features that no one uses. However, the MVP-skeptics argue that in reality, MVPs just end up being a bunch of crappy products that don’t have enough features to be useful or loveable. This debate has led people on both sides to come up with even more fun acronyms like the Minimum Valuable Product, Minimum Loveable Product, or my personal favorite the RAT (identify your Riskiest Assumption and Test it).
I’m here to say that this debate is kinda pointless. The concept of an MVP is not new. In fact, it’s been around for well… forever. The idea of an MVP is really just the concept of evolution. Things start small and then evolve over time. For example schools, grocery stores, and cities all started as small MVPs compared to what they’ve evolved into today. So the point of whether or not we should make an initial smaller version of our product first and then add to it over time should not be up for debate. Of course, you want to make your product better after you launch it! Instead, we should be spending our time trying to figure out the most difficult part of this whole concept:
What features should be part of our initial version and which ones should wait?
There are three things that make this question so challenging. 1) We don’t know what features our customers will really love until they start using the product. 2) Humans are naturally impatient and want everything immediately. Gimme all of the features! and 3) We don’t get a lot of practice at this. Even experienced entrepreneurs and app designers aren’t rolling out MVPs every day. Instead, they’re mainly focused on improving what they already have.
As an experienced UX designer, this last point was true for me up until about a month ago. However, over the last 30 days, I went on an incredible journey. My co-founder and I were able to completely design & build the MVP for 6 different apps ranging in scale from small startups apps to an internal app for a large enterprise. And over the course of this fast-paced MVP-fest we came up with a framework for deciding which features were in and which features were out. (Side note: I'm the co-founder of Adalo, a startup that lets you quickly build apps without code.)
In order to help explain our framework, I’m going to use one of the apps we worked on called Tavolo. Tavolo is basically DoorDash meets OpenTable. Their mission is to ‘minimize the undesirable side of dining’ by allowing people to reserve a table, order, and pay for their food all ahead of time. (Kudos to them. It’s an amazing idea.)
Step 1: Create The Story For Your App.
Start by writing down the main problem or problems that your app is going to solve and then list out all of the steps that a person would need to take on their journey to overcoming those problems. For example Tavolo’s story:
[The Main Problem Their App Solves]
Eliminate the hassles surrounding reserving a table and paying for your food.
[A person experiencing Tavolo would]
Open the App → Pick a Restaurant → Make a Reservation → Invite Their Friends → Pick Out Their Food Items → Pay for It → Head to the Restaurant → Check-In → Enjoy Their Food!
[Additionally, the Restaurant would need to]
Get Notified of the New Reservation & Order → Check the Party In → Send the Order to the Kitchen→ Give the Party Their Food → Mark the Order as Complete
Step 2: List Out the Helpful Information at Every Step
After writing down the journey as a series of decision points, your next task is to figure out every piece of information that would help someone take the next step on their journey. For example one of the first decisions on Tavolo is which restaurant should the person go to. And at this decision point there’s a ton of information that would be helpful like: Name, Location, Price, Menu Items, Reviews, Whether Their Friends Had Been There, etc.
Step 3: Create a List of All Possible Features
At the end of steps 1 and 2, you should have a long document (or a bunch of sticky notes) with a set of decision points and all of the corresponding information that people would need to make those decisions easier. This document will serve as the perfect inspiration for you to create a list of all of the possible features for your app. Just turn those actions and information into specific features.
Step 4: Mark the Mission Critical Features
Now that you’ve got a full set of features (or as complete as possible without getting your app in the hands of your audience) start by marking the ones that are mission critical. Is this feature 100% necessary for completing a step along the journey? For example, in order to pick a restaurant I have to know the name & location of the restaurant, and I have to have a way to select that restaurant. Everything else, like search and ratings, while helpful, is technically not necessary here.
Step 5: Enhance Your App with the Easy Win Features
After you’ve decided which features are 100% necessary, your product should be at the point where someone using it could at least accomplish the main tasks that your app set out to achieve (albeit probably in a very subpar way). Now the fun part. You’ve got to decide on all of the features that make that experience easier for your users. These features will directly relate to the helpful information from step 2 that people need to make those decisions.
In order to decide on the tricky ones, ask yourself the following questions:
- Is this feature easy to implement?
- Will people really use it that often?
- Does it benefit to your early adopters or is it only useful when there’s a lot of users?
If they’re any red flags to any of these questions then move that feature to a future version. For example with Tavolo:
[Features That Didn’t Make the Cut]
- Notifying users of nearby restaurants (geolocation is hard to build)
- Analytics dashboard for the restaurants (useful, but not for early adopters since there won’t be that much user-generated data yet)
Ignition sequence start ... 6, 5, 4, 3, 2, 1, 0 ... All engines running. Liftoff! We have a liftoff
It’s Go Time!
Once you’ve completed step 5, you should have a great sense of what features your MVP should have and which ones should wait for the future. You’ll also have a clear list of what features you can add to easily take your app from minimum viable to minimum lovable. Just how many of these easy wins you can get to before launch depends on your budget, your timeline, and how important ease of use is to you and your team.
But the point is not to get caught up in whether to call your product an MVP or an MLP. The point is that you’ve now got a great list of prioritized features that should serve as a blueprint for the future. You’re not just doing features because you think they’re cool. You’re creating the best first version of your product that will attract the most amount of early adopters, create a sense of momentum, and ultimately give you the best chance for success.
.png)
