Detailed Guide-How to Approach MVP in Software Development

Reflecting on his past struggles with team management and experiences of working with managers, Sérgio Schüler, Product Manager at OLX group in Berlin, Germany, planned to build Teamometer—a software application to help organizations manage their teams more effectively. Before he began the product development process, he decided to cut his teeth with MVP to get initial validation from the market. MVP in software development is an experiment to find out whether the key hypotheses about the product are valid or not before getting into lengthy and complex parts of software product development. To do that, he launched a simple website with a “try it free” button to test the market response for Teamometer. Although he received a good response in the beginning, including from a large Indian manufacturer, he couldn’t convert it into customers. What went wrong, according to him, was that he misjudged this response as demand, whereas what it actually was companies “Interested to explore”—they were looking for a similar solution, but not the same product; that when they shared their unique requirements, he entered in the “sales mode” and pitched variations, instead of taking it as a call for “invalidating” the product. Misjudging the response is one of the common mistakes that many product managers make with MVP in software development. This happens when you have not fixed the value proposition of the product. It is typically indicated in a workable but not a saleable concept, wherein users are interested but are not willing to pay for. Workability in software development is related to prototypes. A concept that works is not your MVP. A concept that could be sold is what you are trying to build here.

When you build a prototype, you ask—Does it work? The goal is to test the concept from design and technical standpoints. When you build an MVP, you ask—Can it be sold? The goal is to test the concept from sales and business standpoints. The test of saleability does not always need a prototype. And that’s because saleability depends on the value proposition the product offers to its users. The problem that the product solves. For example, Dropbox solved the file synchronization problem that many users were suffering in silence. Although, when it comes to validating the problem, these “silent sufferers” became a greater challenge for the founder, Drew Houston. It is because the problem was intertwined with the “way of doing things”, and users were not aware that it could be done differently for a better experience; a factor that made investors reluctant to bet their money on it. But Drew Houston had faith in the solution, and he was determined to test the leap in faith question—” if we can provide a superior customer experience, will people give our product a try?” To prove this point that they could sell a “better experience”, they needed a workable software, a prototype. But as the product was complex, even building a prototype would have taken years and required huge technical talent. And what if no one needed it? To save all those efforts and money going down the drain, Drew Houston built a demo video: He rolled out this video to a community of early adopters for their feedback and suggestions. Drew recalls, “It drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away.” This approach of MVP development for startups is known as the Explainer video format. However, it is not viable for all product types. For instance, if you are building a solution for an operations team in a service department, a demo video may not always be a valuable solution to get feedback from non-savvy users. They need something in hand. Well, there are several other types of MVP approaches that popular companies have used in the past.

Types of MVP

Minimum viable product development validation approaches are of two types: Low-fidelity MVP validation is the first type, that helps you identify the problems of the customers, but the quality of proof may not be highly reliable or enough to pursue the idea. The second is high-fidelity MVPs, that help delve deeper into customers and validation channels with strong evidence to validate the solution. While both types of MVPs help in getting “validated learning” about the problem and customer’s requirements, the purpose of using a particular type may differ. For instance:

1. Strategic Objectives of Low-Fidelity MVPs are to:

• • Understand how critical the problem is to the customers and how willing they are to solve it

• Explore slight variations/changes that could maximize the value proposition
• Find out the most critical requirements of early adopters

2. Strategic Objective of High-Fidelity MVPs are to figure out:

• Is the “value proposition” worth buying? Would the customer pay for it?
• What are the best channels to get validated learning from?
• Strategic decisions to build or kill the product

Here, take a look at various types of MVPs that fall into the category of low-fidelity and high-fidelity approaches and the strength of the evidence.

Below is a detailed description of how companies have used these top 5 MVP approaches successfully.

1. Landing Page MVP Approach

A simple landing page is an easy way to get early customers’ responses to your product. For example, Joel Gascoigne, CEO and Co-founder at Buffer used this approach to test “if a scheduling feature for Twitter clients and apps is worthy of its own application”. The application would queue up tweets without having to schedule each tweet individually. To validate his idea, he first launched the following landing page:

Image source: buffer.com He tweeted the page and asked people about their interest in the solution. Few people then mailed him and discussed the kind of product they would like to have, which he considered his first “validated learning” about customers. But it was important for him to know whether customers were willing to pay for it. So next he launched the landing page with a price range.

Image source: buffer.com When people started clicking on the paid plans, he got his clear validation and he began building the product without delay.

2. The Wizard of OZ MVP Approach

This approach addresses two of the fundamental challenges of software development—time and complexity by creating a fake impression that the application is already working. Zappos, acquired by Amazon in 2009 at $ 1.2 billion, had used this approach to create an effective prototype of their footwear eCommerce startup to test the market response.

Zappos’ early website Nick Swinmurn, the founder, wanted to test the assumption that people would buy shoes online or not without actually trying them. Instead of building a costly inventory and an automated platform to manage the backend, he just went to the local stores, took a picture of the product, and then advertised it on the website. If someone orders, he would go to the store, buy the pair, and process the backend work manually. Gradually, the application gained momentum, and the rest is just history.

3. Concierge MVP Approach

The Concierge MVP approach is the younger sibling of Wizard of OZ, with a little difference. While it too uses manual work to replicate an automated program until the solution is validated and developed, a critical difference is that users know about this “little trick” unlike in the Wizard of OZ approach.

4. Single Feature MVP Approach

It is a traditional MVP approach and works best when you know that the key factor that solves the problem. For example, Spotify knew that people love listening to music and they were about the white spaces the product would fill in. They offered the solution which Napster was providing illegally and Apple was charging $2/piece. Today it is a fancy product but it initially started out as a technical prototype to get rid of “buffering” while listening to music. They first shared this prototype with friends and family.

When they got thumbs up from their circle of friends and family, they began working on the product and launched the beta version in 2007. To test this version, they chose influential music bloggers from Sweden. Soon the word spread, and they expanded from the freemium version to the premium version.

5. Crowdfunding MVP Approach

One of the greatest examples of achieving success with the crowdfunding MVP approach is Oculus Rift. The company raised $2.5 million in a Kickstarter campaign followed by series A and series B rounds before Facebook acquired the company. This MVP approach is loosely based on give-and-take principles. The early adopters fund the product in lieu of some “rewards”, for say, a discount on the fully-developed product.

While these are commonly used MVP approaches, there are several others such as email campaigns, blogs, the piecemeal MVP (used by Groupon), and digital prototypes to test the assumptions or business hypothesis for a solution. Choosing the right MVP approach is always a challenge. The water in the ocean is not the same everywhere, and if you want to test the water, you must choose the right spot, which in this case is the channel and the early adopters.

Choosing the Right MVP Approach for Your Business

Your approach to MVP in software development depends on the factors that drive the business environment at different stages of the MVP cycle. A full-cycle of minimum viable product development look like this:

At each stage, ask key questions related to the problem you are trying to solve to uncover the potential of the solution and approach to prove the solution.

Ideate

Ask relevant questions that would help you understand the problem better and take effective action to find a reliable solution. Ask yourself—

What are you trying to solve?

One of the tricks to be sure of assumptions is to create an assumption stack by listing all your problem assumptions, core solution assumptions, and implementation assumptions alongside their hypotheses. Here you would daisy chain assumptions to understand which problem is built on top of the other problem. Once your assumption grid is ready, you could see which assumption has a higher chance of failing, which if fails will make other assumptions irrelevant and would ultimately kill the software product. Let us take an example of a video chat application, similar to Google Meet.

Now let us evaluate the risk factors for every assumption and hypothesis, for instance, what happens if the number of companies adopting remote work start decreasing. Would the solution stand the test of continual requirement, growth and scale? The next hypothesis is that employees of such companies use mobile devices. Have you done any research on what type of devices are used by the workers of targeted markets, such as iOS or Android or Windows devices? What if most of them use Android whereas your application is designed for the iOS platform? Or what if most of them work on laptop/desktop and do not find it feasible to use mobile devices during work? The riskiest assumption must be handled first, as it might be about the problem that you are going to solve. And that is why it is important to conduct experiments, market research, and customer interviews to validate your assumptions and associated hypotheses before you start building a software application.

Are you the first? Or close to the first?

Providing a one-of-a-kind solution or being second or third in the row with a “unique value proposition” may need you to create a more impactful MVP to convince the customers that they even have a problem. Like what happened with Dropbox? Users were not aware that file synchronization is a problem, which could be solved. Before your approach mvp development companies and engage in the product development process, you must have an understanding of user awareness reality as in:

• Do customers know that they have a problem?
• Do they want to solve the problem?
• Are they willing to pay to solve the problem?
• Do they understand that your product is the solution?

Who will be the early adopters?

Early adopters are generally those users who will overlook the not-so-attractive aspects of the software and use it for the problem it solves. Segment your early adopters on the basis of their industry, budget, demography, and tech-savviness to understand them better. Focus on:

• Any potential solution they are using to solve the problem
• What workarounds do they use?
• Are they fully aware of the critical challenges and opportunities they are losing due to that specific problem?
• Is your solution the straightforward solution to their problem?
• Are they just interested or willing to pay for the solution?
• Does the amount they can pay prove a business case? Can it make a profitable business?

Having the right early adopters is critical to the software product development process because you learn through them, and their feedback extensively contributes to your next step.

Build

Start building for early adopters. An important step at this stage is to define the full vision product and simultaneously define essential MVP features required to let early adopters realize the value proposition of your product. Ask yourself—

Have you prioritized the features of your MVP?

What is the full vision of your product? And where stands a “minimum viable” solution?

Start by deciding on the elements of “minimum viable”—minimum+viable.

Prototyping Phase

If most of your assumptions have been already validated in customer interviews or market research, you may begin deciding on the elements of MVP (Minimum but Viable). A lot of times, you may also build a clickable prototype, for example, in a B2B SaaS, you may build a clickable prototype with a basic MVP software design to evaluate the market /user reaction and a potential fit. Besides, MVP is not just about product validation. It is about giving a taste of your product to customers and at the same time, evaluating the strategic fitment of your product from business perspectives. So for say, if the fully envisioned video chat application contains 10 high-end functionalities, as similar to Google Meet, your MVP must contain minimum features that help your customers realize the value of the product, see its benefits, and continue using it. For instance, a comparison between the features of MVP and a fully envisioned video chat application may look like this:

Usability testing

Modern software users are habituated to using “convenience” features, for example, swipe or drag-and-drop features, instant registration via. mobile device, access to contact list, and so on. While in MVP, early adopters may disregard high-end functionalities, but not these basic features of convenience. It makes using the product simple for them, and helps them to focus on its value. A/B testing of mvp software design elements by actual users will help you identify such requirements and get high-end feedback on app’s usability.

Iterative and incremental development

Assumptions are subject to change with new learning. Following an Iterative and incremental software development model is recommended so that product managers and software developers can test the components based on new assumptions or requirements without the risk of losing too much time and effort. Iteration may include a complete overhaul of an MVP app development project or simple errands that could make the application user-centric. “it’s not iterative if you only do it once. Teams need to make a commitment to continuous improvement, and that means not simply refactoring code and addressing technical debt but also reworking and improving user interfaces.” —Jeff Gothelf (Lean UX: Applying Lean Principles to Improve User Experience) Work with an MVP custom software development agency that specializes in agile project development management. In this methodology, the project is split into smaller, independent software development cycles thus allowing product managers to make necessary revisions until satisfactory results are produced.

User Representation and Validation

Who have you talked to for your MVP app development project? Have you let actual users test the MVP? Will they recommend your product to others? It is important that your validation or beta testing circle includes actual users as they would give you a better perspective of the challenges they are facing and the value they need.

Learn

Collect and read data. What does it say? Do customers love your product? Are they paying for it? Will they continue to pay for it? And most importantly, is your app or web development MVP a profitable project. Ask yourself—

Has the MVP proved how the problem is solved?

This really depends on how rigorously you have tested your assumptions on the metrics of low-fidelity and high-fidelity MVP approaches, and the performance of your product on critical metrics. According to Eric Ries, entrepreneur and the author of The Lean Startup, there are 5 stages of growth that matter to MVP development for startups, and at each stage, they could learn about the product performance on the metrics specific to your product type. Take a detailed look below: At each stage, you can use the following metrics to measure the growth of your solution in context to the learning you need.

Image source: slideshare.net Evaluations on these metrics will help you understand customer and market response to the MVP, following which you can move ahead with your strategic decision to build or kill the product. Next Step—Learn, Build, Repeat MVP is a continuous process. To keep this process up and running, and achieve excellence, make sure that you prioritize customers’ responses instead of being possessive about your idea of the product. A great idea sometimes may not be a not great product. Or it may not realize the ROI you have initially expected. Staying true to customers and market responses and developing your capabilities around it helps you navigate the challenges and build a solid, successful product. Need help to build an MVP? Write to us at info@finoit.com or schedule a no-obligation consultation now to get an expert opinion.