Don't worry, we hate spam, too.
When you think you are designing a Minimum Viable Product you may actually be building a Minimum Marketable Feature (MMF). This is the case where your focus is to earn money with your product instead of to learn more about the product – the original intent of MVP. Kent McDonald takes a look at the difference between MVP and MMF and describes how to approach each one, and when.
Many product people “use the MVP as an excuse to be lazy. They cut corners, remove features and sacrifice the user experience in the name of ‘staying lean’ and ‘shipping.’”
Ward Andrews suggests that perhaps the V in MVP should stand for Valuable, not Viable and describes the MVP as a product that “has the fewest features necessary to solve the primary problem for your primary market.” He also looks at the right way to build a Minimum Valuable Product.
There are a variety of creative ways people have used to build an MVP in order to learn more about their customers and product. Damian Farnworth took a look at 10 examples of how people have created MVPs that you may find works in your situation.
If you consider an MVP to be a “product built from the smallest set of features that delivers customer value” then a story map can be a good route to take to determine what should be included in your MVP. The folks at Cayenne Apps explain 5 steps to building an MVP with story mapping.
Ravi Vadrevu describes a simple three step process that he uses to build an MVP. Those steps are:
These steps mirror the approach that Elon Musk used with Tesla and his other endeavors.
An MVP can take different forms, including Concierge. With this method, you are replacing automated services with unscaleable manual work. Ryan Law gives us an example — meal planning service Food on the Table dealt directly with their first customers, understanding specific requirements and then giving meal recommendations. This would later be replaced with sophisticated software once the product was validated. You could also simply create a landing page that sufficiently illustrates the value proposition and presents this to potential customers online or in person.
Startups will find it easy to throw caution to the wind and release iterations of a product to a live audience, even if there are serious flaws present. This approach is much more difficult for larger companies. Giving the example of a financial institution working on an MVP for a payment application, Michael Bamberger illustrates how unwieldy the process would be to get legal approval for each iteration. His suggestion is that you reframe your MVPs as MVEs (MV Experiments). Beyond altering some of the ways you approach the process, this seems to be mostly nomenclature. But it could make it a more digestible process for all levels of the business. Bonus: HBR has four other tips for launching MVPs in big companies.
There are plenty of good reasons to employ MVPs. As the HUGE team note, good product teams do so because they understand that you can’t assume you know what your customers want and that you should “focus your MVP on validating your assumptions about users, and listen to their reactions closely.” MVPs will also help your team focus on what’s important — testing key features as opposed to all of them and reacting iteratively based on what is learned.
The Minimum Viable Product (MVP) is a crucial component of the Lean Startup principles. But the practice can also be immensely impactful in more established companies. An MVP can be defined as a version of a solution that contains the minimum feature set that satisfies the needs of the customer. Importantly, an MVP must also establish that a customer would pay for the solution, assuming that this is part of the business model. An MVP is a step within a routine known as Build, Measure, Learn. First, an MVP is built, then reactions are measured and then learnings are accounted for, before repeating the process, refining the MVP each time. For more on the origin of MVPs, check out the official Lean Startup manifesto.
In another article, Grace Ng outlines some of the pitfalls to look out for when running experiments. She starts with one of the most striking — testing the wrong thing. In the effort to show progress, it’s easy to rush into an experiment without sufficient planning. The result is a poorly defined experiment and an MVP that is not a good representation of the solution you’re trying to test. Similarly, failing to keep the MVP lean, not defining your success criterion and asking the wrong questions will lead you down the wrong road.