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

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

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

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

构建“最小可行性产品”

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

Photo from Pexels

确定“用户群“

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

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

Photo from Pexels

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

像用户一样思考

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

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

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

像一名企业家去思考

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

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

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

1. 复杂性/相关成本/可行性

2. 用户的期望值

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

明确优先级,确定重心

将高价值、低成本的故事排在前面,低价值、高成本的故事放在后面,但也要顾及有些产品功能之间天然的强相关性。在许多情况下,因为技术原因,会要求首先实现某些功能,尽管它们的成本很高,预期的用户值也很低。这些制约关系需要被明确,也许还能在用户故事图中可视化地表达出来。

综上,我们可以将MVP定义为:拥有最少产品功能并可以提供“恰好程度”的产品体验,引起用户参与,并能为之后的产品开发奠定基础的产品。你可以按照“制约性”给产品功能排序,然后按“用户价值”降序排列,再按照“复杂度”和“可行性”升序排列。当然你也可以结合预算限制,团队速度和进入市场的战略,来帮你确认MVP的样子。

事实检验

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


本文由墨刀团队编译自 George Krasadakis 的 How to define a Minimum Viable Product

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