Minimum Viable Products TIPS

GET THE LATEST TIPS EACH WEEK

Don't worry, we hate spam, too.

The four types of MVPs

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.

Why enterprise product managers should choose MVEs over MVPs

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.

How to maximize your minimum viable product

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 origin of the Minimum Viable Product

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.

Five pitfalls of running lean startup experiments

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.

A guide to validating product ideas with quick and simple experiments

An effective experiment must include these four elements — a hypothesis, your riskiest assumption, the method, and a minimum criterion for success. So says Grace Ng, who provides details on how to assemble each of these. First, a customer-problem hypothesis is formed (a problem-solution hypothesis will be formed after it’s been validated), then your riskiest assumption will be identified for testing, then the method of testing chosen, and finally, your expected outcomes defined.

The 7 habits for running highly effective lean startup experiments

Even the most celebrated scientists are not immune to cognitive biases. Ash Maurya quotes Richard P. Feyman who said: “the first principle is that you must not fool yourself and you are the easiest person to fool.” Although a product manager need not go to the lengths required by the scientific community to ensure valid results, you still must vigorously test your own assumptions. Maurya teaches that you can develop habits that will help you do this on a continuing basis. These include clearly defining expected outcomes from the start, accepting imperfect information sources, depending on quantitative data, and becoming adept at turning your assumptions into falsifiable hypotheses.