What Should an MVP Actually Include?

Gantzer > Uncategorized  > What Should an MVP Actually Include?

What Should an MVP Actually Include?

If you’ve never built an application or software program before, you may find that it is difficult to decide what your minimum viable product (MVP) actually needs to be. It can be particularly difficult to boil the idea down to its nuts and bolts because ever since your lightbulb moment, you’ve been mentally growing how this product will work in your mind — cool features, awesome UX, etc.

 

But getting your MVP right is essential. It means making some sacrifices in the short term to increase your chances of long term success. I work with dozens of tech founders and one of the hardest negotiations we have is what we can strip out vs what we absolutely have to keep in the MVP.

 

We’re going to cover a few major issues in this post — why the MVP matters, how decide what to keep, and when it’s time to build it out.

 

Why the MVP Matters

 

Software development has come a long way in the last ten years. It’s better, more affordable, and faster. But let’s not kid ourselves — good development is not cheap. The temptation to rush into full development without first testing an MVP is the cause of countless wasted development dollars.

 

Iteration #1 of your platform will be an invaluable test of your idea. You’ll learn a lot — whether your navigation makes sense, if your value proposition is clearly explained to users, whether or not users need to be educated on specific functions, etc. These lessons will inform future iterations of the platform.

 

Early in my career I worked on a project where the client insisted on developing an MVP with tools that would automatically sync different social media accounts, save search history, include dual factor authentication, etc, etc. These features, while cool and likely something that should have been included at some point in the development, were entirely premature and clouded our ability to glean insights into core issues — like navigation, user sign up, etc. By over-complicating the MVP, we missed essential learning opportunities and the project ran out of money.

 

What to Keep

 

That said, you want to keep certain functions in the MVP. Which ones? To answer that, you need to have a crystal clear idea of what the value add of your technology is going to be.

 

For example, if you are building an app that finds great coffee shops near you and offers discounts, reviews, loyalty programs, and free swag — you need to step back and ask yourself what the primary reason is a user will download and open your app. If it is just to find the best local coffee shop, then your MVP could realistically just be a search and review function. All the bells and whistles can come later.

 

But knowing that, you also know you have to keep the review function. If you think users want to find the best local shop, then they want more than a map, they also want reviews. Filter your feature set this way — start with your core value add and stick to that.

 

Okay, Let’s Build it Out

 

So you’ve built out a lean MVP and given this beta platform to a handful of users. How do you know when it’s time to start layering on more features?

 

Of course, certain outside factors may come into play — do you have the funding, what is your target launch date, etc. But you will know you have accomplished everything you need to from the MVP phase when you have learned the following:

 

-Attention: You know what grabs and holds your users’ attention in the app or software program. This is crucial because it will dictate how you develop feature sets around the stickiest parts of your platform. Going back to the coffee app example, if users are spending most of their time on review pages instead of searching on the map, you’ll know you need to make seamless navigation tools on the review pages and make sure new features are accessible from there.

 

-Bottlenecks: Every MVP I have ever worked on has surfaced at least a few bottlenecks. These are places where users get stuck. It isn’t clear to them what to do next or how to find what they are looking for. When you have identified the obvious bottlenecks, it’s okay to start building on top of the MVP.

 

-Feedback: Hopefully your beta users have a channel to send you direct feedback on their experience. Get as much of this as you can, collate it by sentiment, key issue, user type, etc. Based on that information, you will be able to solve your users’ biggest problems, enhance their favorite features, and maybe even discover a whole new direction for the platform entirely.

 

-Time: You’re excited, you’re ready to get your product in the hands of your customers, and you can clearly see a clear path to scale. Don’t sacrifice the quality of your MVP for the sake of getting to market. One of the biggest MVP mistakes we see is rushing the development and caring more about being first to market rather than having the best possible MVP. Don’t get caught up in the rush, don’t put unnecessary pressure on your engineering team, and pay attention to every detail of your MVP to make the best first impression possible.

 

We have only just scratched the surface of how to approach and maximize the effectiveness of an MVP. If you’d like more information, please contact me directly, I answer all emails personally.

Leave a Comment.

Comment
Name
Email