The Minimum Viable Product

The lean start-up is almost a religion for many technology entrepreneurs, complete with sacred texts with titles that include the word “lean” (The Lean Startup, Running Lean, Lean for Dummies, Lean Weight Loss).

According to lean start-up dogma, a start-up should build a Minimum Viable Product as quickly as possible.

Perhaps the ultimate lean start-up was LoveRoom which started out with nothing more than a wild idea and a hacked together landing page on Launchrock. The LoveRoom landing page allowed them to collect email addresses of people (men) who were interested. They also attracted press coverage (sex sells). Eventually, LoveRoom got seed funding from the start-up incubator 500 Startups.

The Minimum Viable Product (MVP) is supposed allow you to collect early feedback and gather data about the market and product demand. With this data in hand, you add more features, release the next version, gather more data... Iterate. In short, move fast, ship broken things.

The problem with dogma of all kinds is that it does not provides much guidance in the face of real world complexities.

There is no single definition for an MVP that applies in all cases. What works for a start-up focused on building a phone app (see this post on building an app he called “YayNay”) will not necessarily work for a start-up that is building a large scale web application (nderground).

People often ignore the V (viable) in MVP. For a product to be viable, it has to be useful. The product has to attract users and keep them. In order to keep users the product must be reliable and have the minimum features needed to keep users coming back to use the product. In most cases the minimum set of features that users will find compelling are going to take long to build than you think.

There is one MVP principle that everyone does agree on: get a product with a minimum set of features into the hands of a small group of early users. This will help find errors in the code and get feedback on usability. Often these early users will be friends and family who can be prevailed upon (begged, browbeaten, blackmailed) to use the web application when only a few core features exist.

Early nderground users have given us important feedback:

  • An early nderground user found the “hamburger” menu icon confusing so we changed it to a button labeled “Menu”.
  • A user found, to their dismay, that posts could be deleted by accidentally clicking on the delete link at the bottom of the post. We added a check box to avoid this kind of accidental deletion.

Early users have also found a number of software bugs and have pointed out important features that we need to add.

The very nature of an MVP means that only a few core features exist. This can present a problem when it comes to collecting usage data. The bar for attracting user attention is high. There are many applications that compete for a user’s attention. Without sufficient features, early users will stop using the application.

Along with sufficient features to attract user’s attention, the application must be reliable. If the application is too buggy to be used, early users will abandon it after using it briefly. All software has bugs, but the early software must be reliable enough that it does not drive away early users.

Building a foundation, not a throwaway

One tenet of MVP dogma is that you should build a quick and dirty product that you throw away.

In the case of nderground, we can’t afford to throw away a prototype version. We are leveraging decades of experience designing and implementing large software systems to construct a solid foundation for the future. The architecture of nderground was carefully designed and implemented using Grails. As we get feedback, improve the software and add features, we will have a solid foundation to build on.

Building a Scalable Web Application

We built nderground to scale from a few users to hundreds of thousands or millions of users. Scalability is not something that can be added later. It must be designed in from the start (we will describe the nderground architecture on Amazon Web Services in a future post).

Most start-ups dream of achieving the viral growth that will attract venture capital and allow the company to grow. If the software will not scale, the opportunity for viral growth will be squandered. You cannot assume that you will get a second chance.

Twitter was unreliable and crashed a lot…

When I have described our approach, some people have argued that reliability and scalability are not critical features for an MVP. Twitter, they point out, didn’t scale and crashed frequently (displaying the infamous “fail whale”). Despite the unreliable early software, Twitter succeeded and has been able to re-implement much of their software base.

This is an argument that is larded with survivor bias. What we don’t know is how many start-ups failed because they were abandoned by users who gave up because the software tried their patience.

Launch in Stages

Successful web application start-ups are based on strong, ideally viral, growth. This growth protects against competitors and builds a foundation so that the start-up can grow. If the strong growth that start-up founders dream of doesn’t take place at the right stage in the start-up’s development it can kill the start-up.

Developing software to the point where it becomes a compelling application always takes longer than you think it will.

Software releases must be carefully managed so that wide release only takes place when the software has the features needed to attract and keep users. The launch must be managed in stages:

Alpha release: this takes place when the core features are available so that the web application has basic usability. The early users are generally going to be friends and family. Feedback can be collected on areas where the application is confusing. Bugs can be identified and fixed. With only a basic feature set, early users may not continue to use the software.

Beta release: this release will take place when the developers believe that there are sufficient features to attract and keep users. There should be enough beta users to test basic scalability. Additional bugs will be uncovered. Happy beta users will provide the foundation for the general release.

A basic data collection infrastructure should be built to track use of the beta release. This infrastructure can provide feedback on how users are using the software. The data collection infrastructure will be an important foundation for analyzing the general release.

General release: If there is a solid base of beta users, it’s show time! Use of the web application is opened up to a large (or unlimited) number of users. This is the critical release where, it is hoped, strong growth will take place. True scalability will be tested.

Usage data can tell the start-up whether growth is simply slow or users are abandoning the application. At this point if users are not attracted to the application, adding additional features may not help. The early months of the general release are a make or break time for the start-up.

This is one of a series of posts on the architecture of nderground. Please click the recommend button so that other readers will see this post on Medium.

Show your support

Clapping shows how much you appreciated nderground’s story.