最低限度可行产品（MVP）一词有很多隐含的含义。这个短语被扭曲到人们认为它与实际含义完全相反的地步。
经过多年的努力，我建议所有客户和产品负责人培训生停止使用“ MVP”一词。
几乎可以肯定，我发现软件公司“制造者”方面（开发人员，设计师，产品人员，DevOps，技术作家……）和软件公司的“推向市场”方面（销售，营销，支持，客户）成功..）各种术语对MVP的定义不可调和。
MVP定义：任何需要最少工作量的产品或功能，而赋予组织最大程度地了解客户的能力。
这可能是文本描述或Balsamiq草图或无效的Web原型或活页簿，这使我们有机会向局外人展示我们的意思。它不是用于销售或收入，而是用于快速学习。
而进入市场的组织或部门确实想要某种东西进行市场营销和销售。因此，尽管我们进行了长期的学术争论，但他们仍将重点放在“产品”一词上。这个产品最常见定义是“我现在可以卖给某些客户以获取当前收入的东西，而不是再等几个季度就可以获得完美的产品。” 在几分钟之内，它缩短为“我现在可以卖的东西”。 每个人都对吸引现场客户感到兴奋，即使到目前为止我们只使用模拟的组件。
这种混乱常导致一些不良后果：
- 我们从未完成我们的MVP。由于我们无法发布没有功能A，B，C，X，Y和Z的实际收益产品，因此利益相关者不断扩大“完成”的定义。这会缩短学习速度并减慢交付速度。工程和产品被视为浪费时间。
- 我们提早启动对外营销/支持工作。市场营销需要大量后期资产：屏幕截图，经过验证的收益表，ROI计算器，明晰的细分，参考客户。支持需要安装指南，培训课程，常见问题解答，错误报告类别。这些（当然）还不存在，因为我们仍在概念测试问题陈述以及功能/特性和技术要求。大多数情况都会改变，在添加/删除/更新功能时会进行几轮返工，并用最终的视觉效果替换模拟；修改价格和包装。很多无奈和浪费时间。但是，对于过早资产的压力是不可抗拒的。
- 我们急于将“学习”的MVP吸引给付费客户或认真的潜在客户。销售人员认为这是真实的，并且参与得为时过早。由于它仅具有部分工作功能（或根本没有功能），因此每个人都感到尴尬。现场团队发誓永远不会出售成品，无论何时成品都可能出现，并得出结论说制造商团队无能为力。功能齐全的产品在到达时已失效，已经被标记为故障。
- 产品和设计/ UX使用者不得再向付费客户展示任何原型。客户团队不惜一切代价保护个人客户（以及我们的声誉）时，验证和销售之间的明显区别就消失了。制造商愿意就可能的用户反应询问我们自己的员工。这削弱了设计师和产品经理在产品周期的早期需要实时用户的直接反馈和反应的原因：平衡内部近视，新近度偏倚，缺乏技术背景以及我们的许多错误假设。我宁愿我们在交付前几个月就以很少的成本学习辛苦的教训，而不是为v1.0道歉。
该怎么办？
这通常不仅仅是词汇问题。但是我们可以通过选择含义清晰的明确词来减少混乱/沮丧。这是一组替换项：
“问题验证”或“概念测试”（无收益）
- 工具可能是待完成的工作，画布，旅程图，纸制原型，英雄故事，您购买的代替面试的工具
- 目标：了解我们是否确定了正确的根本问题。我们能否了解真正的缺陷并测试一些假想的解决方案？潜在的前景如何？
“概念性工作流程”或“ UX测试”（非收入）
- 资产可能包括模拟或活动簿或没有内部逻辑的可单击Web界面
- 目标：查看样本用户是否可以完成任务。我们缺少什么投入？我们命名正确吗？工作流程A或布局B的测试效果更好吗？
“工程概念验证”（非收入）
- 可能包括通过部分算法或可伸缩性测试或用于API集成的“ hello world”代码运行的示例数据
- 目标/问题：X是否有效？它会炸毁我们的云服务器吗？我们可以在数据中找到可行的信号吗？我们的建筑合理吗？早期的技术试验会改变我们的范围还是确定缺少的功能？
“技术Beta测试”（无收入）
- 可能会使用具有核心功能的早期版本，但安全性有限，错误检查，极端情况，文档。我们可能为受害者测试用户安装/配置它。
- 目标：看看一个或两个友好的客户是否可以完全免费使用早期的产品版本。我们可以了解他们的环境吗？他们在哪里卡住？成功进行批量部署我们还需要什么？
“早期采用者计划”（REVENUE）
- 我们需要一个针对狭窄的实际客户的功能非常完备的产品，并辅以大量的TLC和动手帮助。产品管理人员应具有详细的资格核对表，以确保他们是符合我们所有技术要求的“友好”客户。理想情况下，目前没有人与我们就大型许可协议进行谈判。
- 目标：完成后，我们希望他们向我们付款并成为销售参考。
“市场全面供应”（收入）
- 我们拥有签署一系列成功的付费客户所需的一切。其中包括经过全面测试的软件，文档，定价/包装，零件号，营销资产，目标潜在客户，竞争情报，支持培训，问题升级，合作伙伴/渠道材料等。
- 目标：推出获奖产品，以获得可观的收入，市场赞誉，激动的客户并反映制造商团队的荣耀。