结合瀑布式和敏捷式开发流程，来获得两种方法的最佳优势，可以实现一个快速而简单的升级版流程，这种新方法有一个最小可行流程：足够的流程但不要太多。

它始于一个简单的认识，即任何产品开发流程都归结为两个需求：

​ 在需要做出投资决策的拐点处启用行政监督；

​ 指导团队降低风险。

传统流程经常需要冗长、繁重的审查，团队必须每隔几周或几个月证明其继续存在的合理性，这会造成过多的官僚主义，并使团队缺乏灵活性。

最小可行的流程方法涉及思想上微妙但重要的变化，传统流程的每个部分都有许多并发和可迭代完成的活动。在最小可行流程中，团队只需要与管理层进行三次审查，以证明概念是正确的、市场与产品之间是匹配的，并且为产品发布做好了一切准备，而不是完成一套僵硬的可交付成果。同时，没有预先设定团队必须满足可交付的成果后才能执行下一步，而是在整个过程中确认它正在满足定义项目的一组广泛参数。

​ 如果满足这些参数，管理层应该让团队独自负责；

​ 如果没有满足，那么团队需要一个精益上报流程来通知管理层并回到正轨。

在项目开始时（可能是在有了产品创意之后，但在公司投入大笔资金之前），开发团队和管理团队就项目的关键参数达成一致，例如：

​ 产品成本；

​ 特征；

​ 日程；

​ 质量；

​ 可靠性。

这些参数必须有一个团队不得超过的定量阈值或边界条件，这种也意味着团队已经做了足够的功课来准确地设置这些参数并使它们量化。

一旦团队和管理层同意这些边界条件，团队就可以独自降低或满足与每个条件相关的风险要求。如果团队正在实现其目标，管理层则不需要干预。此外，在最小可行过程中，没有对预制的可交付成果进行严格审查。

在整个过程中，开发团队满足管理层的需要，以确保其投资得到保护，这些审查被三次检查所取代。他们通过显示开发团队正在降低每一个可能类别的风险来证明这种持续投资的可行性：市场风险、技术风险、竞争风险等。

如果在任何时候，不仅仅是在预定的“关口” —— 团队意识到它将无法实现一个或多个边界条件（称为“边界突破”），那么开发团队将通知管理团队以做调整。团队需要就他们预期的边界条件中断进行沟通，团队还需提出边界突破的解决方案。

​ 如果管理团队同意此解决方案，团队则在此基础上继续前进；

​ 如果管理团队不同意提议的解决方案，则会召开面对面会议，所有利益相关者协商新的边界条件；

​ 然后，团队根据这个新规范继续工作。 

建立边界条件以及越界审查可以减少官僚主义和文书工作，这是一种新产品开发的精益方法，可以快速解决问题。最重要的是，它保持了管理团队对其投资的信心，同时通过制定一套明确的客观参数来指导开发团队不断降低风险。

下面详细介绍一下最小可行产品开发流程，关于越界审查可以参阅第五章内容。