Minimum Viable Product

Minimum Viable Product


One of the most important concepts in all of software is the notion of minimum viable product (often referred to as “MVP”). But if you’ve been around software products for a while, you know that term is used in many different ways, and while the term intuitively resonates with people, there’s often a lot of confusion about what this really means in practice.


You can find it defined as the smallest possible experiment to test a specific hypothesis, all the way up to the tangible realization of a product vision.


I’m not arguing here that any of the definitions out there are right or wrong, but I am arguing that the confusion is not helping product teams, and this is simply too important of a concept to have so much ambiguity.


I have long defined minimum viable product as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.


I love the concept popularized by Eric Ries of the smallest possible experiment to test a specific hypothesis, but I refer to that that as an “MVP Test” so that people don’t confuse an experiment with a product.

我喜欢由Eric Ries定义的最小可能的实验去测试一个特定假设的通俗化的概念,但是我指的是“MVP测试”,因此人们不会混淆一个产品的实验。

But beyond the definition, it’s equally important to recognize that it’s not enough just to think you have defined MVP (which is what most product owners do – it’s their opinion), you need to have evidence that you have this – we call this validated customer learning.


Further, I define product discovery as the process of how we identify the minimum viable product and get this validated customer learning.


While my definitions above hopefully sound straightforward, I still get many questions from product teams about this critical concept:


  • How do we rapidly converge on an MVP?
  • 我们如何快速聚焦到MVP上?
  • How do we know we have actually achieved MVP? What level of “proof” do we need? How many customers need to agree to buy it?
  • 我们如何知道我们事实上完成了MVP?我们需要哪些级别的“证明”?客户需要如何同意购买?
  • Is the MVP intended to be something that we sell, or is it just an experiment?
  • MVP就是我们期望要销售的,或者它仅仅只是一个实验?
  • If it’s something we intend to sell, what if a customer won’t buy it? Does this mean it’s not MVP?
  • 如果我们试图销售,如果一个客户不想购买呢?这不是意味着不是MVP吗?
  • Who is responsible for discovering the MVP?
  • 谁为发现MVP负责?
  • Who makes the decisions regarding MVP?
  • 谁针对MVP决策?
  • How long should we keep trying to achieve MVP before we give up?
  • 在我们放弃之前,我们应该持续努力去实现MVP多长时间?
  • What should we do when we identify a pivot opportunity?
  • 当我们确定了一个关键性的机会的时候,我们应该做什么?
  • Do we need to wait until we have identified MVP before we start building production software?
  • 在我们开始构建生产软件之前,我们需要等待知道我们确定出MVP吗?
  • Is MVP the same as “minimum product?”
  • MVP和“简化产品”是一回事吗?
  • Is MVP the same as “product vision?”
  • MVP和“产品远景”是一回事吗?
  • Is MVP the same as MMF (Minimum Marketable Feature)?
  • MVP和MMF(最小适销特征)是一回事吗?
  • What happens after we have achieved MVP?
  • 在我们完成MVP后做什么?
  • How do I go from MVP to backlog items?
  • 我如何从MVP到积压的事务?
  • Is MVP a moving target? Can I lose it once I’ve found it?
  • MVP是一个变化的目标吗?一旦我发现了,我能失去它吗?
  • Is there only one MVP for a given market or could there be many?
  • 一个MVP只针对一个市场或者能够针对多个?
  • Do we handle MVP the same way for products for consumers as we do products for businesses?
  • 当我们为企业做产品的时候,我们用同样的MVP方法去处理产品和客户吗?

These are all important questions and I can understand why people can get confused, so I thought I would try to address these with a series of articles. I’ll do my best to make this abstraction real, so you can see the value and hopefully put this fundamental concept to work for you.


分享到QQ 分享到微信 分享到微博

0 条评论



  • 昵称 *
  • 邮箱 *
  • 网址