Building software is hard. There are libraries full of books detailing the failures and lessons learned. These days, the “lean” concept of a Minimum Viable Product (MVP) is all the rage in the software startup world but is still greatly misunderstood.
In the following paragraphs, I hope to help you understand how to succeed at building a software MVP based on our experience building custom web and mobile applications over the last 16 years.
In the beginning
In the “good ol’ days”, building software was war. Think of Napoleon marching into Russia during the cold winter of 1812. It took serious planning just to figure out how to feed 680,000 soldiers (which ultimately was a big problem for the Little Corporal). Building software was approached in a similar fashion. Product requirements documents were often several hundred pages of detailed specifications about what each screen would look like and what would happen on each button click or key press. Most software projects ended as well as Napoleon’s campaign in Russia.
Yesteryear’s waterfall model espoused careful plans, powerful tools, and lots of documentation. A quotation from Wikipedia says it best:
“The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. ”
The idea was that every contingency must be planned for so that each part of the project could flow into the next. These concepts came naturally from building physical things but don’t make sense when working in something more malleable like software.
Failure is inevitable
Waterfall is still used extensively in government software projects, in large part because of the necessity for fixed-bid contracts. I’ll discuss why fixed-bid projects are bad for everyone in an upcoming post.
The following from a great New Yorker article describes an all-too-typical outcome with waterfall software projects:
“Healthcare.gov involved fifty-five different contractors that each delivered a piece of the final system to C.M.S. for integration and testing. Whatever development processes those contractors used internally, the overall project was run according to waterfall principles. If the first testing of the complete system occurred in the last two weeks of September, then Healthcare.gov was only halfway through what Royce would have described as a complete waterfall development process. The experience for millions of Americans in the weeks since, predictably, has not been good. ”
More recent times
The Agile Manifesto helped to usher in ideas that have transformed our industry by pushing us all to focus on releasing software more frequently, in smaller batches, and with a greater acceptance of the inevitable changes. Hooray for these changes!
Enter the MVP
Entrepreneurs are faced with the challenge of trying to create something valuable with, typically, very limited resources. The MVP approach provides us hope by offering a path to reducing the costs associated with testing a product idea in the marketplace.
An MVP, per Wikipedia, is:
“…the product with the highest return on investment versus risk. It is the sweet spot between products without the required features that fail at sunrise and the products with too many features that cut return and increase risk. ”
But how can you, as a budding entrepreneur use the MVP approach to succeed with your product idea?
Some examples
There have been some smashing success stories powered by the MVP approach.
Twitter released a product with essentially a single feature–the ability to “tweet” a short message to the world. If Twitter had started with their full slate of advertising features, they may have missed the window of opportunity for the wildly successful social media channel and they would have spent far more money answering the most important initial question of whether folks would use the platform at all.
Instagram released a product that only ran on iOS. It had no Android product and not even a serviceable web product. Like Twitter, they were able to test the marketplace while investing a much smaller amount of time and money to test their main hypothesis.
Minimum versus viable
The brilliance of the MVP concept is that “minimum” is in tension with “viable”.
This is really important. I’ll say it again.
Minimum is in tension with viable
Great! So we can take our long list of potential features and hold each up into the sunlight and ask
“do we need this feature for our product to live?”
and then we just build all the features to which we answer yes!
Not exactly…
There is a better way.
Once you have a clear, concise product vision and a reason to believe there is a market for your product, do the following:
1) Work on the most important thing first
What is the one, single thing that is the most important feature your product needs? You can only choose one. No cheating. This should be the feature that most makes your customer’s heart go a-flutter. Do that one first.
2) Maintain quality
Minimum does not mean crappy. The code must be well-written or your future progress will grind to a halt with bugs. The user experience must be intuitive or your confused users will become former users. The design must be compelling because good design engenders trust.
3) Rinse and repeat
Once you have that most important feature built, ask yourself
“Is my product viable?”
We are asking ourselves whether this product solves a real problem for some group of users, not whether it can survive in the marketplace. Twitter had no way to generate revenue but could answer the important question of whether anyone would use the product. It was a viable MVP.
If your product now solves a real problem and we can learn something from our users, SHIP IT!
If not, go back to step number one.
Bingo!
See how this approach addresses the tension between “minimum” and “viable”? We keep building the most important thing until we have something that is viable!
But…
There are some obvious questions that come out of this approach:
How do I estimate the cost of my product so I can raise money?
How do I decide which feature is most important?
How does my team work on the most important feature (X) when X depends on feature Y?
These are great questions and I’ll address them here very soon