如何将复杂程度和返工工作量最小化，将迭代开发最小化是其中的一种实现方式。为了越早用最少的能力获取经过验证的最大数量，尽早的获取价值，减少资源浪费和获得最短的计划周期，精益-敏捷里提到了MVP(最小可行产品)。
MVP是最小的可用系统，MVP是边验证边学习，它应该完全以用户问题为中心，而不是以解决方案为中心；MVP并不是你想传达给用户的功能的最小集合。
MVP类似与硬件和嵌入式系统的最小系统，均满足最小的可用的功能，那么如何定义MVP为最小呢？
MVP是可用的最小化，强调刚刚好，而不仅仅是最小的，最小但不等于不可用，开发了“最小”但“不可用”的产品，这就需要通过用户访谈，多多测试产品，多去了解用户痛点，将产品调整到“可用”上来（图一）。
但是在开发MVP的过程中，可以借鉴《精益-敏捷项目管理》里提到的：“只开发在此刻需要的功能，并且以这种方式-当有新问题发生时，系统可以快速的升级-——来做开发。软件设计的目的不是设计一个满足所有需求的软件框架，它只是去定义系统主要概念之间的关联关系，因此，当新的需求或者新的变更出现时，让系统做出的修改对系统本身的影响有限。”
也就是说，在我们设计最小的MVP时，需注意上述的原则，“当新的需求或者新的变更出现时，让系统做出的修改对系统本身的影响有限。”
Eric Ries在《精益创业》书中给出的定义是：
“所谓最小化可用产品，是让开发团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。”（图二）
MVP增加了很多额外的工作，产品迭代、验证需求都要耗费大量的时间和精力。但对于后续的工作，精益-敏捷提供了如下的方法，首先“开发MVP-通过用户验证”是创造好产品的第一步。接下来就是用“构建-测量-学习”的方式，在限量测试或者正式运营中，对产品进行循环迭代，就可以实现我们的最终目标，最大化的产品理想状态。（图三）
