How to Build a Successful Minimum Viable Product

I’ve spent my career in Silicon Valley, deeply immersed in its vibrant entrepreneurial culture. Every startup is on an exciting and often perilous journey into uncharted territory, and I’ve embarked on that journey a number of times―as a software engineer, an engineering manager, a CTO, a founder, and a freelance developer. Many of the products I built reached audiences of thousands of people―and some, millions.

In my experience, one of the most potent tools in the Silicon Valley toolkit is the ability to balance speed and depth when launching new products. Eric Ries’ bestseller The Lean Startup encodes this philosophy within the concept of the minimum viable product (MVP).

Why MVPs Are More Useful Than Ever

One of the main reasons the notion of the MVP has proliferated in recent years is the unprecedented speed and scale with which we can now obtain and act upon customer feedback. In 2009, my iPhone game Slingshot Cowboy was downloaded by millions of people within a week of its launch, and quickly worked all the way to the top of the charts (it reached the #1 Free Game position a number of times over its lifetime). A big part of this success may have been luck, but if I didn’t collect rapid feedback and apply core MVP principles early on, I wouldn’t have been able to sustain that momentum for long.

Lean principles boil down to being able to iterate quickly, being smart about spending your energy and resources, and being nimble, focused, and open minded. But we believe the applicability of this methodology isn’t limited to startups―teams within large enterprises can maximize their pace of innovation by creating successful MVPs.

Achieving the balance between velocity and quality is one of the most important drivers of innovation for organizations of any size. As you lead the development of your own minimum viable product, here are our strategies to help keep these two essential ingredients in balance.

Making sure your MVP is ‘V’

If your product isn’t viable, your team’s development efforts are in vain. For the successful creation of a minimum viable product, you need early insider feedback to broadly define it, ongoing feedback to properly shape it, and tools like A/B testing to keep it thriving.

Get early opinions from the right people

Getting negative user feedback on your MVP can be so discouraging that you feel compelled to scrap the project. Innovators can avoid this devastating blow by soliciting early opinions from stakeholders with a deep understanding of the space, well before contemplating an MVP. It’s even better if you have knowledgeable advisors who can help define your MVP at the concept stage.

When an innovation team has a promising idea, it may be tempted to shroud the creation of the MVP in secrecy: “We’re in stealth mode, can’t tell you much about it yet.” That might be worthwhile in some cases, but in general, getting feedback is more important. If you think your product represents a truly original invention, you can always file a provisional patent.

Collect definitive user feedback

Even if you consider yourself a visionary in your industry or sector, your ultimate judges are your users, and they may prove you wrong on many things. Collecting user experience feedback and tracking user behavior are among the most important objectives of the MVP.

Enter analytics. Collecting comprehensive data is the key to achieving one of the main goals of your MVP―”validated learning,” a process in which one learns by trying out an initial idea and measuring it to validate (or invalidate) the effect. That doesn’t mean you want to track everything about the UX you possibly can―instead of getting overwhelmed with volumes of raw data, identify the metrics that matter most.

Use A/B testing to iterate quickly

A/B testing has become a staple of the enterprise when it comes to product refinement. Whenever you need to choose among alternative product behaviors, A/B testing is a way to do so in real time without having to roll out a new version.

For example, if your product is a game, you may want to try different game settings and then examine your analytics to deduce which combination positively affects your key metrics: longer game play, better stickiness, etc. That’s exactly what I’ve done for most of my games: every aspect of gameplay was controlled by a setting I could tweak in real time. This form of validated learning helped me determine the optimal combination of settings for my target market.

For further reading, Stanford’s Steven Dow explores variations of this concept in How Prototyping Practices Affect Design Results.

Watch your product’s space

No matter how original your idea seems, rest assured that someone has already thought of it. If your minimum viable product addresses a timely and pressing customer need, chances are that by the time you are done, your competitor is getting traction, too. Stability is important―as the next section emphasizes―but it’s OK to tweak your MVP from time to time, drawing inspiration from competitors and shifting focus to emphasize the features that are your competitive advantage.

Finding the balance between “minimum” and “viable” is an intuitive skill, and one that you will need to exercise repeatedly, especially if the market shifts before you ship your MVP.

Finding the ‘M’

Once you’ve determined a viable product that addresses a clear need for your target market, it’s essential to narrow your team’s focus.

Define your product

An MVP is like a matryoshka doll: There is always a smaller MVP inside. Product definition consists of finding the most practical minimum, depending on your goals.

If your product is user-facing, start with wireframes―this is your first, innermost MVP. The next “doll” around it might be a “click dummy,” an interactive demo that doesn’t do anything for real but allows you to see it on the target platform and get your first experience with the user flow.

Once you are happy with that prototype, begin crafting the bigger doll, the layer that starts to provide real value to users. At this stage, you may choose to start fleshing out core features. The bottom line: clearly define mini-milestones, don’t jump ahead, and make sure that you’ve met your own criteria before moving further.

This is true for the MVP your enterprise initially brings to market, but the minimum viable mentality should also continue throughout the entire lifecycle of your product. Think of every new release as a bigger MVP―when you add a new layer of new features, make sure it fits snugly on the previous one by making the fewest changes necessary to achieve a viable new version.

Finding the balance between “minimum” and “viable” is an intuitive skill, and one that you will need to exercise repeatedly.

Manage with discipline

Whether your most vocal stakeholders are within your enterprise or external clients, they would do well to be informed of the dangers of feature creep and suppress their urges to add new ”must haves” at the last moment.

Unchecked, a tendency to stray from the defined minimum will drain morale. The proud moment when developers finish connecting all the components becomes anticlimactic. Constantly moving goals fuel product instability.

Especially in the enterprise, the process of building successful MVPs will benefit from executive sponsors reminding their peers and other stakeholders―as often as needed―that “We need to stop now and push this feature out. It may not look good enough to you, but it will be much worse if it’s broken.” As an executive, it’s your job to buffer the developers from external influences, setting an example within your work culture of sticking to priorities.

Engineer with discipline

Conversely, software developers and their managers should appreciate deadlines and keep their perfectionist aspirations under control. Here is a common scenario: “This piece of code looks ugly, that one is really inefficient; we have to clean up and refactor.”

Developers may be right to say this―but their managers should still push back. As a technical manager, you may be happy about their attention to detail and want to act on it. But it’s a matter of timing―keep in mind the important consideration of shipping and getting feedback, and instead make a note of non-mission critical issues, cleaning them up in the next iteration.

Lean principles in action

Your product’s success depends completely on the dynamics of the market you are about to enter. But wherever you draw the product definition line for your MVP, we offer two additional practical tactics that successful enterprises use to get their MVPs shipped.

Make use of third-party components

To the greatest extent possible, innovation teams should not reinvent the wheel when creating MVPs. You can always replace third-party components later with something developed in-house, when the time is right. The shame of unoriginality is long gone: It’s common practice now, and many of the building blocks are open source and customizable.

For example, if your product includes real time communication, there are excellent third-party solutions that are easy to integrate and include key features like customizable UIs, communication infrastructure, and encryption. Likewise, if you are building an app, achieving a professional look with snappy animations and transitions may not require an in-house designer―your developers can save time with third-party components.

It’s true that few third-party solutions will ever fit your use cases perfectly. But they don’t have to―yet. As long as they allow you to ship a product that can validate future investments in custom solutions, you’re still ahead.

Cut development time, but don’t sacrifice a solid foundation for the future

Your first developer has to be top-notch. Don’t start with interns: invest in talent from the very start. This may sound like a contradiction of the core premise of the “lean” methodology, but “cheap” isn’t necessarily “lean.” Though even enterprise budgets can be tight, a developer’s hourly rate is just one component of the cost―development time grows in inverse proportion to the hourly rate. Multiply the two together and your cost advantage is gone already.

Add the time you spend on mentoring and chasing bugs that should not have been there in the first place. Consider the overhead of every lost day: Office space, other employees’ salaries, server fees, etc. Factor in intangibles like the opportunity cost if you arrive too late to the market.

Doing the math, you realize that you will be much better off hiring one “expensive” and experienced developer to produce an MVP versus a bunch of juniors. Junior developers can come later once your product’s foundation is built and you can start thinking about optimizing long-term cost.

Here is a real-life example. One entrepreneur friend of mine wanted to add a couple of seemingly trivial features to his MVP. He had one very experienced developer on the team who had been producing great results at $120/hour. Thinking the next features could be cheaper, my friend hired an intern at $30/hour.

The intern finished four days later. On a cursory examination, the features appeared to be working, and my friend moved on to the next stage. The experienced developer got involved again, and he realized that not only was the code failing in some corner cases, it was unmaintainable going forward. So he spent a whole day rewriting it.

Four days of an intern’s work ($960) plus one day of rewriting ($960) = $1920. If the experienced developer had worked on the feature in the first place it would have been done right in a fifth of the time and cost less than half of the money, even without other costs factored in.

Perfection is not the goal yet, but there is risk in overcorrecting against quality―you may completely discredit your product by releasing something that is crashing left and right, unpolished, clunky, and simply unusable. As a result you may not get a second chance.

Sharpen your instincts and enjoy the adventure

We’ve only touched on a few aspects of MVP development here. But even with an exhaustive guide, there will always be more to the process than you believed, more work than you predicted, and more challenges than you anticipated.

At some point you have to draw the line and get your product out to the world. This is the most chilling and exciting moment, and there is no exact science to it. You have to trust your gut feeling, but following lean principles in the process will help you hone your instincts and make that crucial decision easier. And once you reach that first milestone of positive feedback and have confidence in your vision, you can begin pushing further and further out, into the deep, towards the product of your dreams.