Agile Zone is brought to you in partnership with:

Roman Pichler is an agile product management and Scrum expert. He is the author of the book "Agile Product Management with Scrum" and writes a popular blog for product owners and product managers. Roman is a DZone MVB and is not an employee of DZone and has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

The Minimum Viable Product and the Minimal Marketable Product

  • submit to reddit


The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience. The MVP helps you acquire the relevant knowledge and address key risks; the MMP reduces time-to-market and enables you to launch your product faster. This post discusses both concepts, and it shows how you can use the minimum viable product to create a minimal marketable one.

The Minimum Viable Product

The minimum viable product (MVP), as defined by Eric Ries, is a learning vehicle. It allows you to test an idea by exposing an early version of your product to the target users and customers, to collect the relevant data, and to learn form it. For instance, to test the viability of using ads as the major revenue source, you could release an early product increment with fake ads, and measure if and how often people click on the them.

As lack of knowledge, uncertainty, and risk are closely related, you can also view the MVP as a risk reduction tool. In the example above, the MVP addresses the risk of developing a product that is not economically viable.

Since the MVP is about learning, it’s no surprise that it plays a key part in Lean Startup’s build-measure-learn cycle, as the following picture shows:


The MVP is called minimum, as you should spend as little time and effort to create it. But this does not means that it has to be quick and dirty. How long it takes to create an MVP and how feature-rich it should be, depends on your product and market. But try to keep the feature set as small as possible to accelerate learning, and to avoid wasting time and money – your idea may turn out to be wrong!

While the MVP should facilitate validated learning, I find it perfectly OK to work with MVPs such as paper prototypes that do not generate quantitative data, as long as they help to test the idea and to acquire the relevant knowledge.

The Minimal Marketable Product

The minimal marketable product (MMP) is a different type of product. It is based on the idea that less is more. The MMP describes the product withthe smallest possible feature setthat addresses the user needs, creates the desired user experience, and can hence be marketed and sold successfully. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one.

Creating a product with just the right amount of features sounds like common sense. Why would we create more features than necessary? Sadly, I have seen many projects develop over-engineered products with lots of shiny features that provided little value to the users, but cluttered the product and increased the maintenance cost. And it’s not just the others: I am constantly tempted to add just another cool feature to a product, or to write a few extra lines in a blog post. Using the concept of an MMP helps me focus on what really matters, and remove unnecessary features (and lines).

A great example of an MMP is Apple’s original iPhone launched in 2007. I know that the first iPhone was a complex product, and that many people worked incredibly hard on it. But I find it amazing how many features the phone did not provide compared to its competitors: no copy-and-paste, no Outlook integration, and no voice recognition, to name just a few. Nevertheless the phone was still a staggering success. How come?

The key to creating a successful MMP is to “develop the product for the few, not the many,” as Steve Blank puts it, and to focus on those features that make a real difference to the users. To discover the right features, the MVP is a fantastic tool.

Combining the MVP and the MMP

To combine the two concepts, develop one or more MVPs to test your ideas and to acquire the relevant knowledge. Then use your new insights to create and launch the MMP – a product with just the right features and a great user experience, as the following picture shows:


Note that a minimal marketable product differs from a viable one: It is complete enough to be ready for general release, as indicated by the gift wrapping in the picture above. What’s more, launch preparation activities have to take place for an MMP, for instance, creating advertising campaigns, or for some products, gaining certification. So some of your MVPs are likely to be throwaway prototypes that only serve to acquire the necessary knowledge; others are reusable product increments that morph into a marketable product.

More Information

You can learn more about applying the two concepts by attending my Agile Product Planning training course. You can also find a more detailed discussion of the minimal marketable product in my book “Agile Product Management with Scrum“.

Published at DZone with permission of Roman Pichler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ian Mitchell replied on Fri, 2013/10/11 - 4:04am

Hi Roman

As you say, in Lean Startup MVP is positioned as a tool for validated learning. In fact the lessons that are drawn from the release of MVP are considered to be more important than the initial sales. This is because while early revenue can look good, as a "vanity metric" it is potentially misleading. It can divert an organization from more substantial gains that an MVP-driven learning opportunity might reveal.

MVP helps an organization to decide whether to "pivot or persevere" with an offering. A pivot is more than just an inspect-and-adapt opportunity after a release; it implies a revised MVP. The make-or-break equation for a start-up is how many times it can build MVP, test it, and pivot to a new proposition before funding runs out.

I'd suggest that this is where MMP should come in. Although an MMP release will be based on a prior MVP, it should be focused on revenue. It throws money in the pot...and at least some of that should be used to build runway for future pivots by the learning organization.

Roman Pichler replied on Fri, 2013/10/11 - 5:23am in response to: Ian Mitchell

Hi Ian, Thanks a lot for your comment and for pointing out that MVPs can facilitate pivot decisions. I did not cover the concept of pivot and persevere in my article to keep it focused and concise. But I have written about it in earlier posts.

Andy Wickson replied on Wed, 2013/10/16 - 7:39am

Should that be 'develop the product for the many, not the few' rather than the other way round?

Dean Thrasher replied on Wed, 2013/10/16 - 8:33am in response to: Andy Wickson

 Actually, no, according to Steve Blank. When creating a new, unproven product it's more important to delight a handful of early adopters than it is to satisfy a great many general users.

There are lots of reasons for this, but the key one is that it takes something special to attract people to a new product. Getting customers to change their habits and adopt a new service or product can be difficult. So it's better to make something that's ideal for a few core users than something that simply meets expectations for the masses.

It's also a lot easier to design a minimal feature set to solve a specific problem for a particular user. To work for many users, you'll often need to add features, polish the design, and consider edge cases. These are all very expensive from an engineering point of view. Best to address those after you have proven the product and established a small market niche.

Only after you've garnered your initial customer base and proved that the product is viable do you need to start worrying about broadening its appeal.

Ian Mitchell replied on Wed, 2013/10/23 - 8:53am in response to: Dean Thrasher

That's right, but it is a counter-intuitive concept for many, and it has lead to some contention in the agile community.

For example, Dean Leffingwell (the founder of the Scaled Agile Framework) maintains that "crappy code doesn't scale". This may seem like an uncontroversial statement to make, but it is the sort of assertion that Eric Ries challenged at IMVU. In his book, Eric recalls that the initial offering was terrible and full of bugs. However it allowed important lessons to be learned by testing the product on a small market. That process of validated learning is at the heart of Lean Startup.

It would be fairer to say that "technical debt doesn't scale"...and that isn't the same thing as "crappy code" that has been written for the purpose of a validated learning exercise.

All of this requires a new understanding of fitness for purpose, and what it means for quality to be invariant.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.