一篇文章帮你搞懂什么是“最小可行性产品”(MVP)，以及如何实现！

从“概念“到“最小可行性产品”

"最小可行性产品"这个词虽然诞生已久，但不同的人对其的理解不尽相同，也算是目前科技领域中最被误用的术语之一。 它经常会被等同于一个“原型”，一个demo，甚至是一个项目的第一版输出品。

在产品开发中，最小可行性产品（MVP）是一种具有刚好可以满足早期用户需求的功能，并为未来开发提供反馈的产品。

构建“最小可行性产品”

假设你有了一个很棒的想法，你需要开始构建一个产品了，更准确的说，是构建一系列产品功能，使其能以最小的成本和风险去实现你的产品目标。接下来就说说如何从一个“想法”走到一个“最小可行性产品”。
Photo from Pexels

确定“用户群“

确定“环境”——考虑可能出现的问题、环境和机遇。 观察市场上已有的应对相同痛点的产品，确认你产品的用户群体类型，以及他们会如何跟产品产生交互。记录这些用户群体，他们的需求/ 遇到的问题/他们的期待/以及他们可能会拥有的最好的体验。

能思索”最小“的“可行性产品“中的，其实就预设了你已经拥有了看到全局的能力和产品视野。一个常见的错误便是，团队随便地把一系列“明显”的用户案例看作“最小可行性产品”，而没有一个清晰的产品愿景和全局意识。
Photo from Pexels

更多探索：《 How (and why) to write great User Stories》

像用户一样思考

在明确“大环境”之后，来确定能够满足一个特定目标的一系列最精简的功能。目的是满足你的用户。同时你也需要批判性的用户想法和反馈，这些反馈可以帮你指导产品的下一次迭代。

所谓明确“大环境”是指明确能覆盖产品各类用户群体的“一大套”用户故事。创造出丰富的用户故事好处多多：迭代的时候考虑各类型的用户群像，并尝试构建符合他们需要和期待的用户故事。可以使用Scrum中提到的一个公式：作为一个（用户角色），我想要（做什么活动），这样我就可以（获得好处）。在这个阶段你不需要考虑优先级的问题，此时只需要给各个用户故事一个简单的标题，来做分类整理。

一旦你清楚了你产品的功能点，你需要评估它是否能成为一个“产品”。在用户故事里寻求延续性、同质性以及补足性。再说一次，要像一个用户一样思考。使用同理心去明确互动方式/使用场景以及用户故事。除此之外，你还需要去收集用户反馈，来验证你的用户故事和产品。一般可以通过专家建议、用户访谈、正式或非正式调查或公开的数据资料参考来收集反馈。

像一名企业家去思考

从同理心的角度出发、以用户的角度思考是一件富有创造力的事，你可以暂时忘记现实世界的挑战（比如技术和财政限制）。你的目的是聚合用户故事中的所有产品需要，以满足、吸引所有不同类型的用户。

不过接下来必须也得作为一个企业家去思考了。你需要考虑和记录实施成本、优先级、战略优势和竞争差异。除此之外，你还要去估量每个用户故事的开发成本，以及量化产品对用户带来的价值以及商业价值。

明确产品功能最合适的“最小集”是一件复杂的事——需要在用户故事阶段就估量出以上所有因素。对每个用户故事，你都需要衡量：

复杂性/相关成本/可行性
用户的期望值

一旦你有了这些估值，你就可以对这些用户故事进行排名。也可以制作一个表格，对每个用户故事的复杂程度和其潜在用户价值做个权衡。

明确优先级，确定重心

将高价值、低成本的故事排在前面，低价值、高成本的故事放在后面，但也要顾及有些产品功能之间天然的强相关性。

在许多情况下，因为技术原因，会要求首先实现某些功能，尽管它们的成本很高，预期的用户值也很低。这些制约关系需要被明确，也许还能在用户故事图中可视化地表达出来。

综上，我们可以将MVP定义为：拥有最少产品功能并可以提供“恰好程度”的产品体验，引起用户参与，并能为之后的产品开发奠定基础的产品。

你可以按照“制约性”给产品功能排序，然后按“用户价值”降序排列，再按照“复杂度”和“可行性”升序排列。

当然你也可以结合预算限制，团队速度和进入市场的战略，来帮你确认MVP的样子。

事实检验

但实际上，这只是MVP的一个初步定义。在理想的场景中，是需要通过原型，焦点小组，市场调研，竞品分析等方法是获得真实用户对功能的反馈和验证。 获得真实用户的信息越多，你就越有信心该产品概念已经具备了“可行”的所有条件(也奠定之后的执行/实现/发布)。

本文由墨刀团队编译自 George Krasadakis 的 How to define a Minimum Viable Product，已联系作者允许转载。

作为一款在线的原型设计和协作工具，墨刀可以让设计零基础的人轻松画出产品原型，从而不断测试验证和展示想法，也让你快速作出一款MVP。