The “Lean Startup” approach has become *the* development approach for startups in the past few years, and at its heart, the MVP.
By definition, an MVP is a version of the product with minimum functionality. The MVP is supposed to enable the bootstrapping startup to receive validation (or lack thereof) of the product viability, customer base and market potential – with minimum investment. The idea is to confirm, revise or dismiss assumptions about the product and its users as early as possible in the development process, and by so doing prevent wasted investment in the wrong direction.
This process is intended to be iterative, with different cycles of MVP and market testing, until the startup reaches a successful product – or a decision to stop development and discard the idea.
Unfortunately, the concept of “MVP” is often understood by entrepreneurs superficially as a one-off project that delivers crystal clear results. The thought goes: “If I only invest the minimum in developing a minimum product, I
will receive a clear answer from the market as to whether my product will succeed or not. Either the MVP will prove itself, and then I’ll get funding easily, or I won’t even need funding. Or it won’t, and then I will know as soon
as possible that this product won’t be a success and save myself unneeded investment.”
It would be nice if reality worked like that. Unfortunately, it doesn’t.
MVP: No Crystal Ball
The reality is much more complicated. There is a small percentage of entrepreneurs whose MVP leads to a clear black and white answer: immediate success or an immediate capital investment on the one hand, or discovery (without the shadow of a doubt) that the idea is a loser, on the other hand.
Most entrepreneurs, however, end up in shades-of-grey situations like these:
1. The market feedback was excellent, so I think it’s worth investing a little more myself to develop the product further. That way I can give away less equity when I get funding.
2. The product failed, but I understand what my mistakes were, and I think that it still has a chance.
3. There was a lot of interest in the idea, but the implementation wasn’t complete enough to get an accurate idea of long-term use and viability.
4. The app got many more downloads than we expected, but it crashed all the time because we hadn’t anticipated and planned for such heavy usage.
These situations don’t have clear answers of “success” or “failure.” They indicate a chance (but not a guarantee) of success. In all cases, the startup will need to continue gradual development of their MVP until external investment enables them to do more rapid development, or until the product succeeds on its own, without external investment.
A Waste of an MVP
The above situations would be fine – providing the MVP was built in a way that enables continued gradual development. Unfortunately, when the perspective on an MVP is that of a one-off, crystal ball job, it often is
not built that way.
The tendency is to invest as little as possible in the quality of the MVP, treating it as a temporary prototype to be discarded upon receiving the hoped-for external investment. Entrepreneurs choose cheap technologies or less professional developers that they would never use for their “real” product: friends, unexperienced freelancers, unprofessional outsourcing firms or firms that will only develop in a limited set of technologies. Here – in the “quick and dirty” MVP – is where future disappointment and frustration lurk.
Hiring an unprofessional construction team to build your foundations doesn’t usually end well for your building. If the foundations of the MVP execution are shaky, the cost of the application’s future development is likely to be much more expensive than it could have been. Sometimes everything you put into the MVP will need to be scrapped and the product built from the ground up, at great expense and a significant loss of time. The whole process of “do-over” can prevent your startup from moving forward at the rate
you had planned.
When the MVP is a Stumbling Block
Sometimes it’s not only a loss of time and money. Sometimes a not thought-out MVP can itself cause the product to fail, even if the idea is wonderful. While it’s understood that you don’t compromise on UX when designing your MVP, that’s not the only critical component. Operations, stability, trustworthiness, data and market penetration elements – any and all of those,if not dealt with the right way during the MVP stage, can sink an otherwise successful startup.
A common textbook example of an MVP is Zappos, who started their online shoe store with complete manual operations. I run into clients who have read this example and assume that means that no MVP ever needs any type of automation. Unfortunately, they usually pick the wrong MVPs to assume this about. A service with dynamic or limited inventory needs some type of operations automation, or you’re likely to end up with customers completing an entire order, only to be informed afterwards that their order is not in stock. That is an easy way to end up with unsatisfied customers.
Another way that your MVP could fail your customers is by not being equipped to deal with everyone who wants to use it. If your MVP has potential for an enthusiastic response from a large user base, you must take that into account when planning the MVP – or face the consequences. I was recently told about an application that garnered tens of thousands of downloads a day. The implementation had not been done well, however, and so actual usage was close to zero. Now the company wants to redo it, but the greater challenge will be overcoming the market’s negative first impression left by the failure of the MVP.
The MVP that Shoots Itself in the Foot
Sometimes, as soon as the MVP goes live, another company sees the idea and decides to build a competing product. This is most common when the startup’s MVP presents a threat to the business of a large firm. Firms like these have deep pockets and can easily pour resources into developing an application based on your idea or adding your idea to their existing applications. The only chance you have against this kind of competition is to stay ahead of them. But if your MVP will need to be rebuilt from the ground up, then it did not provide you with any advantage, giving all the advantages to your competitors. So what IS the correct balance between minimizing investment
and risk and giving your product a fighting chance?
Growing MVP
The answer is to look at your MVP – from the outset – as agile and dynamic, where even the definitions of “Minimum” and “Viable” are dynamic and in constant flux.
Here is the process every MVP should go through in order to be a firm foundation for future growth:
Stage 1: Planning the MVP
Goals:
1. To understand the short-term expectations from the product
2. To identify the long-term vision and what needs to be taken in account from the outset in order to
achieve that vision
3. To analyze what needs to be
present in the initial product, along with a rational path to success
4. To make sound decisions about where to invest
5. To define the MVP from standpoints of technology, functionality and UX design
Stage 2: Initial MVP Development
Goal:
Build and launch an MVP where:
1. It works well, correctly and impressively
2. It’s built with an infrastructure that enables easy gradual development
3. Its data model takes important future requirements into account, so it won’t need to be restructured.
4. You can rapidly scale the number of users
5. It gathers data that will be needed in the future, even if it is not needed for this iteration
Stage 3: Dynamic Growth of the MVP
After the initial launch, there is dynamic development of the product until reaching its final form. During this stage, the goals are:
1. To measure and draw conclusions from the market results
2. To check where development stands in relation to the original plan, and if the original plan should
continue to be used or if there is a need to create a new plan
Unlike the traditional Agile sprints, the process needed for a successful startup is more akin to a high-tide, low-tide cycle: a cycle including periods of rapid development, marketing and launch, and periods of cessation, observation, data-gathering and drawing conclusions to be used in the next development push. One example of this cycle would be spending an intense three months developing and launching an application, and then pausing for the next few months to gather feedback from the market before deciding whether to invest further – and where to invest.
The goals and pace of the different iterations of development are based on market feedback, product usage growth rate, progress with funding/liquid assets and other business considerations.
The Growing MVP is the optimal approach for a
future-thinking startup. It enables you to take smart, full advantage of your resources while minimizing risk and maximizing success.