与最终被丢弃的原型不同，开发团队会将最初的 MVA 纳入 MVP 的一部分，因为它是产品的第一个版本。通过一系列敏捷方法迭代（例如 Scrum 中 Sprint 冲刺）MVP 一样， MVA 也需要迭代。在任何时候，产品都应该满足已知的 QAR，这样就不会基于猜测和假设给产品增加负担，通过后续纳入新的QAR或者需求，以一种可持续的方式实现业务功能的持续交付。

我们可以从概念层面来描述这种方法：

团队最初只提供可以满足已知 QAR 的架构，快速构建出可供真正客户使用的可行产品。

然后，随着团队更多地了解客户的真正需求，他们不断地改进产品以满足额外的需求或需求变更（包括 QAR）。保持架构的灵活性是必要的，应用可持续架构的原则之一——“延迟设计决策，直到绝对有必要”——是实现这个目标的有效方法。

简而言之，随着团队对产品需求的了解越来越多，他们只构建最小可行的产品，只做出满足已知需求的绝对必要的架构决策。产品仍然是 MVP，架构仍然是支持 MVP 的 MVA。这么做的原因很简单：团队可能会花费大量的时间和精力实现产品的特性和 QAR，结果却发现客户并不认同他们的价值。相信什么是有价值的仅仅是一种假设，直到得到客户的验证，而这才是假设和实验发挥作用的地方。

所谓的假设，就是对某些尚未被证实（或被否定）的观察结果提出解释。从需求方面讲，它是一种信念，认为做了一件事将导致另一件事的发生，例如交付特性 X 将导致结果 Y。实验是用来证明或否定某些假设的。

每一个特性和需求（包括 QAR）实际上都代表了一个关于价值的假设。实证的目标之一是让这些假设变得明确，并有意识地设计实验对特性和需求的价值进行明确的测试。实际上团队不需要构建出完整的特性或需求来确定它是否有价值，他们只需要简单地构建最小可行产品和架构，就足以对能够证明其价值与否的关键假设进行验证。

对于 MVA，团队将在每次迭代（Sprint）中验证他们关于解决方案的假设，根据经验对其进行测试，然后根据了解到的东西做出决策。例如，Scrum 团队会通过对产品需求项进行排序来决定他们需要了解什么。产品需求项包括功能需求（比如特性和用户故事）和 QAR。

当团队在计划一个 Sprint 时，选取一些产品需求项作为 Sprint 的目标，这不仅是对产品能够为客户提供的价值的假设，也是对增量产品如何随着时间推移而持续迭代的假设。产品需求项（包括 QAR）的顺序将因此迫使团队聚焦关于价值和产品如何可持续交付价值的假设。