Have you ever played a video game and felt like there was too much going on? That if the plot was just simpler, you’d enjoy it more?
The same can be said for building software: if you’ve got too many features, it can distract and overwhelm your users. To make them happy, you have to find the right balance of features and simplicity.
You can do this by ensuring your first version is a Minimum Viable Product, aka MVP. How do you do that, and what are things you should consider or avoid when laying out the groundwork?
Summary
- A Minimum Viable Product, or MVP, is the least-complex version of a product you can deliver and still offer enough value to users for them to engage and come back.
- When deciding what features should be in your MVP, you should compare value with complexity.
- Features that are more complex and less valuable should be avoided.
- Anything that’s highly valuable but not complex should be considered.
- Make sure that as your narrow down your feature list, you keep your main problem and users in mind.
- To have a successful MVP, you need to build based on evidence, focus on value rather than cost or speed, and track metrics from beginning to end.
Requirements vs Minimum Viable Product
While both are needed, requirements and the outline for your MVP are fairly different. Both are a list of features, but at different stages in the process. A requirements list is like your starting wish list. You brainstorm all the possible ideas you have about what should go into the app, and write them down. It’s basically every option you can take.
Your Minimum Viable Product, on the other hand, is the most streamlined minimum of what you can put out in a product while still being valuable enough to solve a problem. You should take your requirements list, and use evidence and discussion to assign priority. You’ll want to find the few pieces that account for your core functionalities, and start there. You’ll be better off with an MVP that contains the top 2 or 3 things of your app instead of a long list of features that may have significantly lesser value.
Things to Consider when Developing your MVP
So you’ve got your requirements list in hand, and an idea of the direction you want to go. What now?
The Moscow Method
As you begin to break down your requirements list, one method you could use is called the Moscow method, or MSCW. It’s an acronym that stands for Must, Should, Could, Won’t. All of your features will fall into one of those four categories. Your highest priorities will be under Must: features you must implement. These are things that are essential to your solution.
Features that you Should implement are next. These are aspects of your application that are important, and should be put in the first iteration, if possible. If not, leave them for later iterations. Speaking of later iterations, features that fall under Could can be added in iterations down the road, but are definitely not going in your MVP. Lastly, anything that’s getting nixed entirely is a feature that you Won’t implement.
By assigning priority to your features with the Moscow Method, you can start to really think about what’s necessary to your product’s success. Keep in mind what your users actually want, and what’s required for a product-win.
Value vs Complexity
But how do you decide what aspects are Musts and which are Wont’s? One option is to compare a feature’s business value to its complexity. Connect the dots between your feature ideas and your goals and metrics for success. Once you’ve done that, it’s easier to see which features are the most valuable to the business.
However, Just because something is valuable doesn’t mean it should be built. It’s also important to think about how difficult a feature may be to implement. Complexity can drastically increase cost and time to market. Generally speaking, most MVPs have at least one or two key features that are fairly complex, but it’s also important to limit complexity in your MVP where possible.
So how do you decide? It’s time to graph! At Slingshot, we like to create a chart with all of the ideas for features on the project. We then chart them based on their business value and complexity to implement. An example can be seen below:
Anything in the high value, low complexity sector is those Must features we’ve been discussing; if it means a lot to the business, and isn’t hard to execute, you should definitely do it. Next, take time to decide on anything that is high value but high complexity; you don’t want to do all of them, but some should be included. Same goes for low value and low complexity. Eliminate any low value, high complexity ideas, as they aren’t worth doing for the MVP.
Features vs Functionality
Another thing to keep in mind is what types of features you’ll be implementing. Of course you’ll want your functional features: those that are the core of what it is your app does. But you’ll also want to build a well-rounded solution. Even if your app is functional, a product that isn’t reliable, usable, or intune with users will fail.
Your product should be reliable; you’ll want to show your users that your app is one they can depend on. Building a fast and consistent platform will let users know that they can always count on your application to help them. Usability is what it sounds like: is your app easy to use? You can ensure this with testing at each stage to check with users on how comfortable they are with the interface.
Last but (probably) most important, your app should have an emotional aspect. You’re building this product for a specific audience, and if they don’t feel the product was built with them in mind, you’re dead in the water. It’s important to use design and the above-mentioned usability testing to make sure your app feels personable, approachable, and fun.
Keep the Problem in Mind
Lastly, the important thing to remember as you go through development is your initial problem. Before there were interview guides and wireframes, you and your company saw a problem that could be solved through software. As you move through each stage, continually ask yourself: “What are we trying to fix? Will this product help solve that?” Don’t lose sight of why you originally started; by keeping the original problem front-of-mind, you’ll be able to ensure your product solves the problem.
What Not to do When Building an MVP
Now that you know all the things you should be doing to develop your MVP, you should also think about what to avoid.
Assuming makes… well you know
Don’t assume that you already have the answer to your initial problem. Your problem may not even be a problem; you won’t know without speaking to your users. Interviews that ask about a user’s experience rather than their opinion on your application will help lead you in the right direction.
Speed is not the name of the game
We talked about what a Minimum Viable Product is, but not what it is… not. An MVP is NOT simply the earliest and/or smallest version of your product possible. You want to make sure that you’re delivering something of real value. If not, the users aren’t going to care about it.
Understand your Features
If you skip from your wish list to development, some features may get out the door that you don’t fully understand why they were dreamed up to begin with. If you struggle to tell why a feature is there, it’s probably a good indication it can be removed. If you can easily describe a feature’s reasoning and purpose, you can determine if it’s beneficial. Building unnecessary features increases time, cost, and complexity. If it’s not necessary for success, it shouldn’t be built.
Measure with Metrics
Adding to the above point about understanding, you also need to know how you’re going to measure success. If you don’t know the metrics you’re looking for, how will you determine if the software was a success? Look beyond the timeline and budget, and determine how you can measure outcomes that truly move the business forward.
Conclusion
We now know that our features need to be narrowed down on what Must and Should be included, and how valuable and complex they are. We also need our product to be well rounded with functionality and emotional connections, all while keeping the final goal in mind. We also know what not to do: don’t assume, rush, or forget to understand.
