, , , ,

Minimum Viable? Maybe It’s Minimum Learnable or Saleable Instead

I’ve written a few articles about Minimum Viable Products (MVP), and after deliberating with various entrepreneurs about what they believe is their MVPs, I wanted to do more research about the concept.
I found an article by Vishal Chandra called “Understanding Minimum Viable Product : MLP vs MVP vs MSP” referencing not just an MVP but two other Minimums: Minimum Learnable Product (MLP) and Minimum Saleable Product (MSP).
Eric Ries, author of the Lean Startup, defines a minimum viable product as the initial step to begin the learning process as quickly as possible – paramount to the central idea of the ‘build-measure-learn’ feedback loop.
Vishal distinguishes what an MVP is by defining the two other types:
  • Minimum Learnable Product – the minimum product needed to learn what will need to be built for the MVP. These can include designs, articles/ blog posts and the conversations that flow from them, surveys, etc.
  • Minimum Saleable Product – the minimum product that motivates customers to pay for the product. In this case, Vishal cites an MSP for B2B customers may include additional features like security, integrations to other tools, etc.

I definitely see how MLPs and MSPs fit in the startup cycle (product, marketing, sales, etc.). However, I’d argue that MVPs can be saleable, too, but not necessarily SCALEABLE.

For example, a new clothing subscription service may manually curate subscription boxes while charging customers. That enables the startup to learn the process, pricing, etc. But as the company grows, they may then build a robust “fitting” engine that takes earlier learned lessons into an algorithm. There was no MSP per se as much as the MVP evolved as they should as the product reaches product-market fit.

What are your thoughts on distinguishing other minimum viable/ learnable/ saleable products? What are other minimum _____ products, and how would they work?

/by
, , , , ,

Downward Trends of MVPs

At Body Boss, we built features on feedback that coaches would buy and be more engaged, but we didn’t see upticks in conversions once features were built. Instead, sometimes, the best customer discovery occurs when you’re actually testing an MVP – minimum viable product.
I’ve been working with several startups since Body Boss and each claim to be building an “MVP”. But instead, they’ve overbuilt their products adding complexity in features and user experience.
From these “MVPs”, I’ve noticed common trends leading to poor adoption and significant rework:
  • Developing an MVP in silo. By nature, entrepreneurs believe they know the “right way” to address a problem, so they starting building their vision. However, the right way may only address the problem for a few versus a mass market. Building an MVP alongside customer-partners from the beginning mitigates risks of missing bigger opportunities or building unwanted features.
  • Inability to adapt hypotheses and approach. Entrepreneurs can be extremely bullish in their beliefs of what is right, resisting the pull of the market. This can be a terrible trap where the market isn’t listened to. If they aren’t heard, they won’t buy.
  • Focusing on one side. In startups with two markets (think: Uber, Airbnb with supply and demand), it’s hard to successfully recruit one market without the other. There is no “chicken” or “egg” in priority anymore. Yet, I’ve seen too much effort focused on one side, while the other is ignored.
  • Building too much, too soon. A startup should evolve as the market evolves and matures. However, many entrepreneurs try building their visions of grandeur on Day 1. As a new startup, there’s a high level of education for the market and low degree of trust. Building too much early on can overwhelm consumers (bad experience!) and potentially dilute the startup’s value proposition.

What are your thoughts of customer discovery via an MVP? What trends have you seen when building an MVP? How have startups over built MVPs that you’ve seen and the problems that have come about?

/by