I don’t mean MVPs like James Harden or Nick Foles. While MVP does mean Most Valuable Player in sports lingo, the term I want to talk about stands for Minimum Viable Product.
In simple terms, an MVP is a product with just enough features to solve the problem and satisfy early customers, who can then provide critical feedback for your future iterations of the same product.
Starting with an MVP will make it much easier for you to test if your core value proposition is actually succeeding, and will ultimately cost a lot less in the long run than developing a bunch of features that your customers neither need nor want.
The more clearly you’ve defined the problem you’re trying to solve, the easier it will be to define your MVP. If you find that you need a laundry list of features just to address your problem, then you probably need to go back and narrow down your problem to something more specific.
To better understand how to define an MVP, let’s start with an idea and define the problem it is going to solve. As an example, I’m going to use an app idea from our VP of Partnerships, Don Tirea. The app would be for organizing pickup basketball games, which I’ll call PickupBall.
In this article about user stories and user roles, Don has already defined the core user roles of the application: game organizers and players. Now we need to take a step back and identify why this app is being made. What problem does it solve, or what efficiency does it create?
As someone who has played pickup basketball in the past, I’ve experienced firsthand the difficulties of connecting with your friends to get a game going. No matter how you go about it — sometimes you call everyone on the squad, sometimes you start the infamous group message, other times you show up and hope for the best — it can be hard to start a game. Let’s go through these common scenarios and the problems they present — in other words, the problem our hypothetical app aims to solve.
Calling — This is a lengthy process that requires the user to have everyone’s phone numbers, remember who they called, and remember the response of each person. What if five people say a 1:00pm game is fine, but you call the next three and they can’t make it there until 3:00pm? Do you reschedule? Do you call everyone back?
Group Message — Let’s face it, no one likes group messages. They are impersonal, lead to off-topic micro conversations, and if you weren’t at your phone for the heart of it, you are left with fifty notifications which are a pain to cycle through.
Just Showing up — This might be the most efficient route of them all, but it still presents challenges. When playing with local players you start to see a pattern. Everyone will go to the court at 4:00pm and play until the last ray of sunshine drops behind the skyline. No one had to call anyone else, everyone just showed up and played. Although this does work for a while, what happens when you go one day at the usual time and you are the only one there? Communication didn’t happen and expectations were crushed.
What all of these approaches have in common is that they fall short of giving you the communication tools you need to organize a pickup game quickly and easily. So, the core problem that addresses all of these scenarios can be defined as this:
Your problem should be short and to the point. If you have a list of problems, it’s going to be difficult to build an effective MVP, as you’ll essentially have to build several at once.
You should also clearly define your target market. In our case, we’re looking strictly at casual amateur basketball players. Pro players or players aspiring to go pro could have an entirely different set of concerns and priorities.
To solve our problem, some key features would be managing contacts and creating time-sensitive and location-based events. This allows for the right people to know the right information at the right time. So, all we need for our MVP is a way for users to import their contacts, create games at specific times and places, and invite their contacts to that event. That’s it.
You might be saying, “Come on, this is too simple. We need to think outside the box and add features the players would like. Maybe we can have players create several games in a time period and assign the pickup players to those games, or maybe we can add scorekeeping so we know who the best players are. Come to think of it, if this would work for basketball, how about football, or baseball, or soccer?”
When you start going down that road with your app, you need stop, pause, and think.
Go back to the problem you are trying to solve: as a casual amateur athlete, there is no quick and easy way to organize basketball games with your friends. Stick to that and come up with a solution that’s tailored to that problem and that problem alone. Yes, creating custom games would be cool; yes, keeping track of wins and losses could be awesome; and most certainly adding more sports to the mix could reach a larger audience, but that all needs to wait until we get product validation.
It is better to know that your MVP actually solves the problem you set out to solve for your user base before you start adding on features than to rush ahead and create a product that your users do not like. After all, our problem might not be something that enough people are really experiencing to justify a new app. That’s part of the benefit of creating an MVP; we can find out that our app doesn’t have product/market fit without investing too much into the project.
It’s okay to think about what your app could be, and how it could evolve to make your app even more appealing. You actually should be thinking about this stuff, but keep them on the back burner while you’re getting started. Write them all on a whiteboard or create a backlog using Trello or monday.com. These are good ideas that could make your app better; they just don’t belong in the first iteration of your MVP. You want to retain your focus on your original goal so that you can put out the best MVP that you possibly can, and see if people are interested in your product. Once you have done that, you can then add features based on your ideas and the feedback you’ve gotten to make the best app that you can create.
To recap: Identify the problem. Solve the problem. Collect feedback about your solution. Iterate on the solution. Polish the solution. And eventually add to the solution with validated and desired feature sets from the same user base that provided feedback.
