Mitigate Risk with a Minimum Viable Product

Custom software development is hard and scary – especially when you run a startup or a small business. Years of horror stories make every business aware that there are a lot of risks: an amazing number of software development projects fail. The “lean startup” movement uses the idea of a minimum viable product (MVP) to reduce the risk early.

Agile methods of software development are intended to reduce the risk of the software project gone bad by delivering increments throughout the project — but development methods alone aren’t enough. You must also plan out the development in a way that minimizes the risk your product won’t be viable in your business and in its market. The combination of small incremental deliveries and the desire to understand and minimize the risk leads us to build one — or more — products to reduce that risk.

Mitigate the Risk, Minimize the Investment — with an MVP

The easiest way to minimize risk is to minimize the investment made before you have feedback on the project. Agile development is intended to give the business early feedback in the development process. That alone doesn’t give a lot of information on the key problem: will the new product actually provide value?

The “lean startup“ movement proposes to solve this problem through early delivery of a low-cost initial application that produces business value early: this is the “minimum viable product“ or MVP.

By producing an MVP, the product can be exposed to the market – potential customers, beta users, even early adopters. If there are initial problems they show up early. They can be resolved or mitigated in the next delivery. If the product isn’t meeting a market need at all the project can pivot towards a better fit. Worst case, if the basic idea was just wrong, the product can be abandoned before too much has been invested.

What is the Minimum Viable Product?

What is the minimum viable product? Somewhere on the spectrum between a static “hello world” webpage and the full implementation of the $1 billion application you hope for must lie an implementation that is both a viable business application and yet has nothing extraneous or expensive. But where does this implementation lie?

Start with Objectives and Key Results

The problem lies in the word “viable“. What makes a product viable is capable of infinite debate. Instead, take a step back and ask, “what do I hope to learn from this product?“ In fact, Eric Ries, one of the original proponents of the MVP, defines the minimum viable product in terms of what you hope to learn from the MVP:

[T]he minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

The answer becomes the objective. The next step is to identify key results from which you will learn, along with measures by which you will observe progress. This is a management approach called “Objectives and Key Results” (OKR) and is used by many startups — and ex-startups, like Google.

Objectives establish your overall goals. Key results provide a way to measure business value returned. Key results should be stated in terms of how they’ll be measured quantitatively. Thought and care must be applied to decide on the important measures and on the important results.

How OKR can help define your MVP

This all can seem a little abstract, so let’s work through an example. The example is a web and mobile application to help freelancers.

Objective: Attract 100,000 freelance workers to manage their goals in business using a combination of the website and the mobile application.

This is a pretty aggressive objective, but one of the key ideas behind the OKR approach is that your objectives can be aggressive.

An application to support 100,000 users must support workloads that require a lot of expensive infrastructure. This is a perfect opportunity to develop an MVP. We want to find out if the application has a chance before building that expensive infrastructure.

Now, we need to decide what we want to learn from our MVP. Here are 3 possible questions you might ask yourself.

1. Can we attract enough attention to risk building the application at all?

For this question, we’re simply hoping to assess the possible market. In this case, the MVP can be extremely simple: a webpage describing the potential product, and a sign-up form for a mailing list.

Our key result is whether we can get enough sign-ups, so the number of people on our mailing list becomes the key result measurement. According to Ash Maurya, one of the gurus of lean startups, this kind of MVP is also called an “offer”. Build a simple sign-up page connected to a mailing list processor like MailChimp, invest in some basic marketing, and you’ll quickly know if you can attract enough people.

Of course if we’re sufficiently confident in the concept we might go beyond a simple offer page.

2. Can we attract users who’ll register and stay?

A common business model on the web is the “freemium model”: You provide partial functionality for free and then get people to pay for premium functionality. The question now is whether the implementation is attractive enough. Will people register? Will people who register continue to use the free service? Those people are the ones most likely to be willing to pay for more features.

The key results now are measured by the number of registrations and the proportion of users who are still using the system after some length of time.

This obviously requires a more complicated MVP. It must provide at least a minimal set of basic functions. But this is still a more limited application then the full application would be — and therefore less expensive. Good adoption and retention for this application would be very encouraging.

3. Have we set an agreeable price point?

Now we’re getting to the hard questions. Can we make this product financially feasible? Can we make a profit? What’s the optimum price?

These are hard questions, much harder than the technical ones, but they have technical implications. An MVP that can answer these questions will need to have pretty complete functionality — after all, we’re going to ask people to actually pay money to use it. That being said, we should implement payment functionality in order to start making money. An example of this would be Paypal, a credit card processor, that integrates with an existing platform like Amazon Payments. This then presents other problems, such as site security. While PayPal is secure, the farther along you go toward revenue, the more attention you need to pay to site security overall.

At this point, this “minimum viable product” no longer looks very minimal at all. A more traditional approach would mean building everything before a big “launch event” with a much greater risk that the product won’t hit a good market niche, and that the functionality doesn’t appeal to customers.

“Minimum“ is a Moving Target

Notice that each of these “minimum viable products” makes perfect sense in itself: the difference is what question you want to answer.

What may be less clear is that it also makes sense to build each of these MVPs, working step by step through the process of delivering a fully-fledged product. This is a key feature of an “agile” development process: delivering new functionality periodically, at each step revising and rethinking to maximize the delivered value, while still reducing the costs. In the real world, we can think of every release as a new MVP, answering new questions about the business, the market, and the customers.

Interested in building an MVP, but don’t know where to start or how much it might cost? Try our free custom software estimate calculator!