MVP Development Explained

Our clients often put a slightly different meaning in the term MVP, so we decided to write a short explanation.

A minimum viable product (MVP) is a lighter version of the final product with the primary purpose of building earlier traction and receiving faster feedback for guiding further development. It’s a fully functional product with just enough core features to solve the early adopter’s main problems. MVPs are cheaper and take less time than developing a complete solution from the start.

What Is a Minimum Viable Product

MVP is a complete and polished product, just with some tradeoffs to increase the development speed.

Keeping only the most essential features is extremely important as it’s the main contributor to both time and cost of the development. The feature set should be just enough to solve the main problems of your target audience.

Unless the design is your competitive advantage, you should seriously consider some compromises on it. The UX is still critical, as the MVP must be convenient and easy to use from the start. However, polishing the look is not that important at the early stage, and you better plan it for future phases.

You can’t compromise on quality here. MVP is not an internal prototype but a fully developed product that will go onto the market. Errors and bugs aren’t acceptable, just like in a final product.

Thinking of scale is a big mistake on this stage. A single server is more than enough for most web applications to handle thousands of initial users. Plan for the best, and make it easy to implement, but don’t do it just yet to save time and reduce the complexity. In case your product goes viral, you can quickly implement a few hacks to earn time for making it right. That’s what we call “good problems.”

Why MVP Is Necessary

Starting with an MVP is essential to avoid common pitfalls startups make during the early stages.

According to EU startups, the most common reasons why startups fail are:

1. No demand for your product
2. Lack of skills required for the business
3. Cash burn
4. Failure to get feedback on an early stage
5. The market is not yet ready for the product
6. Weak team with poor leadership
7. No real interest in the product and it’s market
8. Inability to raise capital
9. Poor marketing or sales
10. Ignoring your customer needs and wants

Testing the water by launching the MVP onto the market first is an ideal solution for avoiding all of those reasons.

You can quickly test the demand by analyzing your MVP’s performance and how fast it’s getting traction. Usage patterns, engagement, and conversion rates would be enough to see the whole picture. If the demand is too low, that might mean the market is not ready for the product, the problems are not that critical, or the existing solutions are better.

MVP is usually much cheaper than the full product. You can develop it on a budget that would help to avoid cash burn. Because it includes only the core features, you definitely won’t be wasting money on the unnecessary ones.

Your minimum viable product is not much different from the full-blown solution. It would hopefully have real users, and you can use any methods you like to get feedback from them. That would help you better understand the customer’s needs and wants.

Just like with all products, creating a successful MVP required more than a good idea and programming. Your team would have to work on sales and marketing to get great results. It’s an ideal time to put them to the test and evaluate your skills, leadership, and interest in the product.

“Traction Is What Investors Are Looking for When You Present Your Plan,” according to entrepreneur.com. It’s not just traction on paper, which is not more than an assumption, but a proven and measured one. A working MVP with a high growth rate would be an enormous bonus when raising capital for your startup.

What Is the Purpose of Building an MVP

MVP is necessary for many reasons. However, it has only one primary purpose - to launch the product onto the market as soon as possible.

The data it provides you is golden. You will know what features users are begging for, instead of guessing. They will tell you of other related problems they have that you’ve might never know otherwise.

You can start the slow marketing process much faster, and it would have more time to add-up and provide a steady flow of new customers. It’s also much easier to get sales and presales when you have something to show that they might be using the next day.

If everything goes well, the product solves problems people are willing to pay for, and your marketing and sales did a great job, you’ll have a cash flow early on. It’s truly an unforgettable feeling to get that first sale of your brand new product. Heck, if the problem was critical, and the solution is perfect, the MVP might even go viral. People would recommend it over and over again.

And even if it’s an internal product to solve a specific problem in your company, wouldn’t you benefit from having a solution sooner? It would undoubtedly have a positive ROI.

Agile MVP Development

You should always start with a problem worth solving. The product that doesn’t solve a pain, need, or want would never take off. The users might give it a try but would never pay unless it’s what they were looking for from the start.

To keep a consistent picture of the product in your head, we suggest following Eric Ries’s advice from “The Lean Startup” book and create a Lean Canvas. You can always use it as a reference to test if new features are critical for an MVP. Writing a full business plan is often a waste of time, and no one will read it anyway.

Now that you have the idea of the product you want to create, it’s time to think of the actual design. MVP’s design shouldn’t be gorgeous as impressing users is not your goal. Your primary goal is to show them that your product can conveniently solve their big problem.

User experience (UX) is still critical. The MVP must be easy to use, and users should get the idea of how to do that at the very beginning. Start with wireframing the main screens and flows. You can also do minimal user-testing by showing your interactive wireframes to the target audience and watching their reaction. If they actively click through it and seem to know what they are doing, you’re good to go.

For most projects, writing extensive user stories is a waste of time. If the design is done right, developers should clearly understand what each element does and have a general understanding of the product. You have to describe only specific features, like complex flows and formulas, to get everything done correctly. The developers will ask more detailed questions on particular features closer to their implementation if they aren’t sure.

Usually, the clients still pick too many features for their MVP. Their explanation might be that the competitors have that, it’s just cool, nice to have, or unique. Remember, those are not valid reasons for selecting MVP features. A good idea would be to ask yourself, “Does my product still solves the problem well if I remove this particular feature?“. If the answer is yes - put in into the backlist. Otherwise, that is a critical feature that should go to the MVP. The real MVP should be that minimalistic.

MVP Development Teams

We assemble small MVP development teams of one to three developers for a reason. This way, all of them are equally involved, more efficient, and always on the same page. You can read more about why small teams are often better in this excellent article by Doist.

Our approach reduces communication overhead as everyone knows the product, along with his role in it. The client doesn’t have a manager firewall in front of the team and can directly communicate and provide feedback to any team member. The developer has an opportunity to ask additional questions to clarify the task, align with the client, and implement it as expected.

Small teams also save precious time on management. In fact, they don’t require much supervision at all. We do use task tracking software to understand the whole picture and plan the work. Everyone has tasks assigned for the next sprint and implements them one by one. Time-constraining the MVP sprints doesn’t make much sense, so we use phases instead.

Code reviews depend on the project. Usually, we do them only for the critical parts or when freshly hired developers commit their first pieces of code. If the client insists, the MVP is the first step of a large project, or the project is mission-critical, we perform code reviews for all pull requests.

Web Application MVP Example

People learn by example, and to give you a better understanding of the process of creating a successful MVP, we have a semi-fictional one (based on a true story).

The client had an idea of building a data visualization web application. He had a strong vision of the final product from years of experience in the niche. Together with his designer, he had prepared beautiful designs for every page upfront.

We’ve analyzed the designs and ranked every feature by importance for a potential user and the effort it would take to implement. Together with the client, we planned hard and not-important features for the later stages. We’ve also identified new critical features this product should have from the start. Those are crucial for almost every b2c web product:

• Server-side rendering for SEO optimization and CDN caching. Google does a great job crawling client-side applications, although we still see those isomorphic ones usually achieve higher rankings.
• Responsive design from the start. Today, most consumers use their phones to browse the web more often than desktops. Designing a mobile-friendly experience for b2c products became extremely important.

The product was small, and the one-person team has proven to be ideal for it. In two months, the product got launched onto the market.

The client quickly got insights from Google Analytics on how people were using it and understood what part of it was the most important. By analyzing this product in Google Search Console and doing more SEO research, he found that people were looking for two more related pieces of information.

We have implemented both, and one of them turned out to be important too. The product is getting a lot of traffic on related keywords, and it shows strong engagement in Google Analytics.

Both were completely new features, and one of those we have postponed. Having an MVP on the market pushed the client into data analysis, which provided those insights. The chances of randomly brainstorming them were slim.

The client also incorporated insights from product usage into features he planned before. We haven’t implemented them yet, but in our opinion, the changes are fantastic and put those features on the next level of usefulness.

Conclusion

Most projects should start with an MVP development.

It’s a quick and cheap way to get feedback from real users that’s enormously helpful during the later stages of product development.

MVP is the best way to put your product and your team to the test and face reality. You would most likely have to pivot a little after getting more data about your users, their pains, needs, and wants.

The development speed is critical. The sooner you launch the product into the market and collect the first feedback, the better.

You can’t afford compromises on quality. Don’t think of it as a prototype. After all, it’s a minimal version of the final product.

At LeanyLabs, we have gained substantial expertise with MVP development and startups in general. We are always happy to share our knowledge, so if you need help or have additional questions, just reach out to us.