When you’re looking to build a new piece of software one of common phrases you’ll hear is the MVP, or minimum viable product. For many budding startups an MVP is the first step to success, and can make or break a company. But what exactly is an MVP, and how do you go about building one for your software startup? Today, we’ll look at the steps on how to build and MVP for your next project, and how it can help make your project a success.
What Is an MVP?
The key idea of an MVP is it allows a quick feedback loop. Most will refer to it as a build, measure, learn process, and the key is to repeat that process quickly and frequently. This allows you to quickly get your ideas in front of an audience, learn about their usage of it, and the iterate changes to match user exceptions.
The MVP is just that, the minimum product you can put out to users to get feedback about it. The key is to think about the single major problem your product solves and focus on delivering that and adding to it later.
Many project builders get bogged down in the all the features they need to add, which inevitably increases the time to market. The problem with this, is it’s hard to know whether the market actually wants your product, or if there isn’t a large enough need to support it. An MVP is meant to be released quickly, validate against real market data, and allow founders to either continue further or pivot to a new idea if the market isn’t receptive of the initial product. In essence, you’re looking to either succeed or fail fast.
Nail Down Your Problem
First and foremost, you need to have a clear problem statement on what your software does and how it helps your market. You need to be able to answer the question “Why are we building this?”.
The key idea is to keep your problem statement narrow and easy to understand. Many will suggest targeting a specific niche to start and expanding from there. The more constrained at this point the easier it’s going to be to validate your ideas.
You’ll also want to clearly state who is having the problem you’re looking to solve. Once again, depending on your product, it might be best to niche down here and focus on small subset of your dream audience. Your application might target small business owners, but maybe for the first test you solely focus small coffee shop owners. This is important for later also as it will help when you start looking towards marketing.
Setup Success Criteria
You also want to make sure you setup what constitutes success for your MVP so you have something to measure against. This is the goal you have for this initial phase of the project, and generally determines whether the software has a further life that you’ll continue to work on.
What your goals are depends heavily on your market, and what you individually define as success of your project. Be realistic here, as whether you achieve your goal is going to be a good indicator of the future viability of your product. You want your goals here to be a bit lofty to push you and your team, but still be something that seems doable.
Some sample goals you might have are:
- Get X number of feedback from users
- Achieve X amount of users/subscribers
- Hit a total revenue goal of $X
- Have a total monthly recurring revenue of $X
Do Your User Homework
Homework isn’t just for school anymore! Every successful MVP has some legwork you need to put in to determine its viability. There’s nothing worse than building something only to realize too late nobody wants or needs it. Put in the work upfront and save yourself the wasted hours.
The most important thing you can do here is get initial pre-build feedback from potential users. You should already have an idea of who your target market is based on your problem statement above, so using that start to explore whether they’ll actually use your software or not.
The best way to do this is to get out and start talking to the group of people who you envision will use your application. Call them, email them, talk to them in person, whatever it takes to get them to discuss your idea. You want to get a feel for if they’d be interested in your project, and if they want to be notified when you release the first version.
I’m a big fan of using Reddit for my initial research. Reddit is basically a huge forum that has sub-forums for pretty much any topic you can think of. This allows you to easily find people who you’re looking to target with very little effort. Reddit is usually pretty strict on overtly marketing, but for initial research the users there are usually willing to help out, especially if what you’re building will benefit them.
If no one seems interested it might be a sign you’re on the wrong track. Maybe it doesn’t solve a real problem, or maybe it tries to go about it in the wrong way. Whatever it is, all the feedback you get at this stage is important as it might save you from building something that has no market or help you to focus on an existing problem in a more intuitive way.
Seriously, don’t skip this step. You should have at least a handful of interested parties before you start building or you might just be wasting your time. Guessing whether a problem exists is never a smart use of your time.
Analyze Competitors
This goes hand in hand with the above customer research, but I feel deserves it’s own section. You want to spend some time looking at competitors and analyzing what they do right/wrong.
The idea is that you should have something that differentiates yourself from a competitor, some sort of competitive advantage. Maybe your competitors are too general while you focus on a specific niche and build your product just for them. Maybe you have a killer feature that they don’t.
Whatever it is, you need to be able to answer why a user should use you over them. It doesn’t have to be anything crazy, especially at this stage, but you need to differentiate yourself in some way in order to compete against someone who is likely bigger and has a larger budget than you.
In the rare case that you don’t have any competitors spend some extra time doing your user research. Competition is a good sign that there is a market for a product and not having it might be good or bad. On one hand you might have discovered an untapped market and can dominate it early. On the other-hand, it might just be an unviable market that can’t support any competitors. Figure out which before you invest time building a product.
Outline Your User Flow
Once you’ve validated your idea and determined there is a market for for it it’s time to outline the user flow. This is important as a poor user experience is a very good way to frustrate and drive users away.
When mapping the flow, keep in mind the end goal of your application and creating the shortest path to that goal for your users. You want them to experience the benefits of your application as soon as possible and with as little friction as possible.
There are multiple schools of thought on planning applications and software projects, and what works for some is likely a pain for others. One way we like is an agile, user-stories based approach. Focus on action points at each step for your users and work to satisfy these actions.
This is just one way to go about it, use what works best for you and your team. There are a lot of good guides to planning and brainstorming, but that’s a bit out of scope here. Keep in mind, for an MVP this should be the core user flow for the main problem you’ve identified. While it might be nice to have a bunch of extra features, focus just on the flow that solves that one problem. You can always build on it later if it’s successful.
List and Prioritize Features
Once you’re flow is setup it’s time to actually start looking at the individual features. At this stage it’s okay to just throw out ideas and keep a log of them. I always suggest getting somewhere you can just start jotting down ideas, and keep a log of everything you want to build, even if it’s only nice to have features that definitely won’t make the MVP.
As this is an MVP though, not all those features are or should make it into your initial release. Go back to your flow you create and identify the features that line up with that. If a feature doesn’t, put it on a backlog and come back to it later. Be ruthless in cutting features, the longer you’re in development the longer it will be before you starting brining in customers and revenue.
One you’ve pruned your list you should have only the features which accomplish the singular goal you’ve identified. This is the feature set for your MVP. This is all you need to do to get the initial product out the door and begin getting user feedback. Once that’s done, you can come back to your backlog, and start seeing which features you need next. If you’re lucky, your initial users will have suggestions (or complaints) and that can help guide future development.
Launch, Learn, and Build
All that’s left now is to build and launch your application. Take those initial contacts you talked to in the research phase and let them know about the launch and see if they’re interested in providing feedback. Start aggressively marketing and do whatever it takes to start getting users. If you correctly identified your audience earlier you should have also identified likely places they like to hang out.
Hopefully, your feedback is positive and you steady inch closer to your goals. Once you’ve determined to continue on with the project you enter the measure and learn cycle. Really pay attention to what your users are saying, and quickly iterate new features for them based on feedback.
On the flip-side, maybe your application didn’t pan out. It happens, even with good pre-build research sometimes the interest isn’t there, or the application isn’t what your users had in mind. Don’t look at this as a failure, but an opportunity to learn and improve. In some cases, you might be able to salvage the work by tweaking the application to handle the problem in a different way or pivot to a new problem entirely. In either case, the whole idea of the MVP is that if it doesn’t quite work out you’re invested minimal time into building it.
Other Considerations
While that’s the key flow to building a basic there are a handful of other questions many startups have.
What Tech Should I Use
The practical advice is to use what you know. If you’re a PHP developer for example, don’t let someone tell you that you have to use Java or your project will fail. In truth, almost any language is going to be good enough for an MVP, and any problems a language might have won’t likely be relevant until your user base is in the millions.
So many times developers will get in their head that they need to use a specific piece of technology in order to properly build an application. In most cases, this is not true, and using what you know to get something out the door quickly is usually more important. Only in very specific cases will your choice of tech matter for the MVP.
There’s also a series of no-code solutions as well that will let you build something quickly without coding. While building your own email service might be cool, using something like Mailchimp or Aweber to begin with is usually a better choice. Focus on building your core product, and then if that’s successful you can always come back and build out some of auxiliary features. Don’t re-invent the wheel, and don’t be afraid to leverage an existing solution.
Do I need a cofounder?
It depends. There’s been many applications launched by an individual that have been successful and a number that have had one or more co-founders that have helped it along. There’s pros and cons to each path, and you need to honestly evaluate them.
One of the more common setups is the tech + marketing founders. One builds the product while the other markets it. If you have the skillet to do both, and the time, then going in solo is perfectly fine. If you don’t, then finding a co-founder isn’t bad either. It really depends on you and your individual circumstances. Don’t let this stop you from taking action though. You can always bring on a tech or marketing guy after the fact. For example, just because you don’t know how to code doesn’t mean you can’t start doing market research.
What about design?
Design is important, but don’t spend too much time on it. As long as the service is intuitive and looks presentable you’ll be in a good spot. Unless your product is specifically targeting designers the majority of your users won’t care too much about a bit of roughness here and there.
That’s not to say throw something up that looks like crap, but don’t agonize over every single pixel. For a quick start, there’s a ton of starter templates and UI designs that are free or cheap to use. They might not be unique, but they’ll look good enough to get you started. You can always come back and work on them or hire a designer later on. Systems like Material Design are good places to start to get a decent looking design without investing a lot of time.
What about (insert x here)
Don’t let yourself get distracted. There are a million little things that will crop up that will only serve to slow you down. Focus on getting the product out the door, then come back and work through your backlog of features, marketing, and other ideas.
My MVP is too Minimal
That’s kind of the point, but it’s an easy trap to fall into. There’s so many other applications out there with a list of features a mile long it can be a bit intimidating. Don’t let this stop you though! If you’re done your research and have a good list of users interested in your product you’re in a good spot.
Remember, the key is to build the absolute minimum product you can get away with to determine whether you want to invest more time in building it. Don’t let adding shiny features distract you from launching. The sooner you launch the sooner you can get feedback which is the lifeblood of any successful software project.
Above all else, remember that your goal with an MVP is to get the minimum product out the door and into your users hands. The sooner you have real users testing your product and giving feedback the sooner you’ll know whether continued development is worth your time.