一、什么是 VUCA 时代？

1. 概念解析

VUCA 这四个字母分别对应着一个英文单词的首字母。

• V：Volatility 易变性

• U：Uncertainty 不确定性

• C：Complexity 复杂性

• A：Ambiguity 模糊性

可以这样简单地理解，VUCA 描述的其实是时代特征，就是在说我们这个世界的变化速度太快，问题也越来越复杂。所以，如果你还是在用传统做产品的方法，往往会做出一个市场不要的东西。

也许你对这句话没有什么直观的感受，但是借助《启示录》这本书中的一个故事，或许就可以明白在 VUCA 时代下我们到底在面临什么样的困境。这本书的作者 Marty Cagan 当时在如日中天的惠普公司，和优秀的团队一起开发一款技术领先的软件。他们辛勤工作一年多，牺牲了无数个夜晚和周末，为惠普增添了不少专利，也开发出了符合品质要求的产品。然后，团队把产品翻译成多种语言、培训销售团队、做媒体公关，都收到了良好的反馈。产品发布后，正当大家以为万事俱备，准备开始庆贺的时候，问题出现了——没人购买这款产品。

如果你熟悉软件工程，就知道他们的工作模式是很成熟的瀑布模型，确定目标，然后设计、开发、测试、发布。但，这个方法论的有效性是有隐藏前提的，那就是，在开始定目标到发布的这段时间差里，需求不会发生变化。

而在 VUCA 时代，以上假设能成立吗？显然不能。

1. VUCA 时代下产品创新的应对策略

信息无时无刻不在变化，用户的需求无时无刻不在变化。百度一下，可以发现，各行各业推出了很多的解决方案。

可以看到，各行各业的应对策略虽有不同，但背后的思想都是同宗同源的，那就是都有这样几个关键词的影子：迭代、试错、小步快跑。而这些关键词在互联网界其实早已流行，且各大公司都早已付诸实践。那么，在 VUCA 这样一个背景下，在当今互联网产品如此丰饶的情况下---当我们打开 AppStore 排行榜时，可以查看到各个细分领域、各类场景下都已经有着数不胜数的 App 产品，我们应该如何从中获取自己的产品创新方法论来做指导呢？下面将介绍“MVP 框架”理论。

二、产品创新方法论：四轮 MVP 框架

这里所说的 MVP 框架不同于最小可行性产品(mvp)，这里的 MV 是 Minimum Valuable，代表最小有价值，而 P 则分别代表纸面研究（Paperwork）、原型（Prototype）、产品（Product）、推广（Promotion）四个英文单词。我们将这 4 种组合称为四轮 MVP。每一轮 MVP 对应着不同的产品方法论。

第一轮 MVP 中的 P 是 Paperwork，产出物是纸面研究的结论，用的方法是 Discovery Sprint，中文可以叫做探索冲刺。这个阶段，产品创新还在想法阶段，验证的重点是问题本身。也就是说，你需要确认，你的问题到底是不是一个真实存在的问题，有多少人有这样的问题，是否已经有人解决了这个问题等等。在这一阶段，要做的任务可以由单人完成，基本上是纯案头工作，通过查看行业报告、做竞品分析、和用户聊聊天，据此来过滤各种不靠谱的想法。

第二轮 MVP 中的 P 是 Prototype 原型，通过第一轮 MVP 的想法，会进入第二轮 MVP。用的方法叫 Design Sprint，即设计冲刺，这个方法是谷歌创投最先提出的，已经应用了不少年。在这个阶段，验证的重点是解决方案。但因为还没有真正的产品，所以是用某种形式的产品原型（或者叫样机、Demo）来验证。我们要考察用户是否能理解这个解决方案，这个方案和既有方案相比，是否有足够的额外价值让用户愿意转移，等等。这时候，我们需要有原型能力的角色加入团队，在方案层面“先发散，后收敛”，做出原型，并让用户试用原型，获得反馈后，不断修正原型，甚至回到第一轮 Paperwork 修正想法。

下面将分别对上述两轮 MVP 框架进行介绍。

第一轮 MV Paperwork

1. 从理解用户开始：故事、生态、画像、旅程

理解用户永远是产品工作的第一步。不管是基于公司/部门的某个战略方向出发，还是从 0 到 1 打造一个创新产品，加深对用户的理解是产品前期工作的切入点。我们可以将“加深用户理解”的过程分为四个步骤，分别是用户故事、用户生态、用户画像、用户旅程。自始至终，有没有产品不是关键，关键是充分理解用户。

比如说，我们今天有一个 idea，我们认为亲子出行或许是一个很好的市场？此时，我们需要验证一下我们的想法，亲子出行到底有哪些痛点、用户感受如何？现在是否已经有解决方案？带着这样一些问题，不妨试试下面这种方法。

用户故事

理解用户的第一步就是去接触他们。不用很正式，有点像朋友闲聊，只要你去做了，就会有收获。我们不妨找几个身边的有孩子的朋友，试着向他们问以下几个问题：

问题 1：能否说说您和孩子最近出行时发生的有趣故事吗？

这个问题是为了引起用户兴趣，营造轻松交流的氛围。

问题 2：回忆一下，最近的某次出行，有没有孩子让你担心的情形？

这个问题是为了把用户带入产品涉及的领域，去体会用户的感受、情绪、痛点等等。我们在聊的时候除了听用户怎么说，还会关注她的表情、肢体语言等一切可以传递信息的方面。

问题 3：为了避免各种意外，你最近一次带孩子出门，做了什么准备呢？出门以后又是如何防止发生危险的？

这个问题是为了探索现有解决方案，毕竟，任何一个真正值得解决的问题，用户一定已经开始尝试解决了。

从这些问题中你应该可以感受到，这就是朋友之间的闲聊，针对任何一个问题都可以充分地展开。这一步的产出物，是一个个的用户故事——谁，在什么情况下，碰到了什么问题，有什么感受和情绪，现在又是怎么做的，现在的做法中又有哪些痛点，等等。

用户生态

有了用户故事之后，你应该就能体会到，任何一个产品领域，用户都是多种多样的。所以，第二步我们要梳理用户生态。你需要了解，在产品所涉及的领域中，有哪几种用户，他们之间的关系是什么。以上面的亲子出行场景为例，用户有父母、孩子、出行目的地的工作人员，如果是远途出行，还有同路的乘客等等。

在这个用户生态中，我们需要注意以下几点：一是颗粒度、二是边界、三是优先级。

比如针对家长用户，有没有必要把爸爸、妈妈、和其它长辈分别对待？针对孩子，有没有必要把男孩女孩分别对待。我们是应该重点考虑父母对出行的需求还是孩子的出行兴趣爱好。以上这些问题都需要根据我们的产品目的、公司情况等背景进行分析。

用户画像

用户画像是我们用一些关键特征词来描述一个重要的用户群体的一个工个。这个小工具可以帮助我们时刻牢记我们的产品是为谁服务的，让我们的日常讨论中，能够始终以用户为中心。用户画像应该具备一些基础的要素：

• 用户基本信息：包括自然属性和社会属性；

• 描述用户的特定信息：也就是与该产品领域相关的信息，比如生活方式、价值取向、心理预期等；

• 选几句在收集用户故事的时候，听到的用户说的有代表性的话，增强真实感。

用户旅程

如果说用户画像是静态的，那我们最后做的用户旅程，就是让用户“动起来”。选一个重要的用户，思考他在解决相应问题的时候，都会碰到什么状况，做什么事，有什么感受和情绪。这时候，“有没有产品”依然不是重点，重点还是关注用户的言行举止。一般，我们会把用户旅程分为三段：做某事前的准备；做某事的过程；做完某事之后。早先我们在第一步中收集到的用户故事，这时候就可以各归其位，通过用户旅程把故事串起来，目的是跟着用户一起去体会一段“真实旅程”。

此外，我们也可借鉴扎根理论的方法来更好的进行用户调研。

https://baike.baidu.com/item/%E6%89%8E%E6%A0%B9%E7%90%86%E8%AE%BA/8233319?fr=aladdin

1. 竞品生态：有效的竞品分析

我们经常可以看到，大家在做产品创新的时候，都会分析现状，其中的很大一块就是分析竞争对手，我们把这个过程称作竞品分析。最常见到的竞品分析是这样的，挑选了三五个竞品，然后做一个表格。

横向的表头是我们的产品、竞争对手 ABC，纵向的表头是每一项功能特性，然后在表格的每一格里，打勾勾、写说明：这个功能我有 A 没有，那个功能我没有 B 有，还有个功能我和 C 都有，但是 C 要强一点点……这样的竞品分析固然有价值，但是也有其局限的地方。它只能带来渐进式的产品创新，如果你想要做到颠覆式或者说跳跃式的创新，就远远不够了。

如果从产品创新的思路出发，我们首先要先搞清楚问题，再搞清楚解决方案。通过“问题”和“方案”这两个指标的异同，来界定竞品生态的组成。

这 4 大类竞品的特点分别是：

问题同方案同：很难做到颠覆性的创新；

问题同方案异：用不同方案解决相似问题的产品，往往会成为行业里的下一代产品；

问题异方案异：占用了相似的不可再生资源；比如产业链上下游；

问题异方案同：需求不同但解决方案有相似之处；

1. KANO 模型：雪中送炭与锦上添花

在这里，介绍一种对用户需求进行分类和需求优先级进行排序的工具-KANO 模型。通过这个模型我们可以快速评估产品功能对用户满意度的影响程度。

象限图中 X 轴指的是产品功能的实现度，用来表示一个功能有没有做完。最左侧的一点代表某个功能尚未开始，最右侧的一点则代表功能实现已经很完善。Y 轴指的是用户满意度，越靠近下端表示用户越不满意，越靠近上端则表示用户非常满意。

而我们整个产品的功能通常可以分为三类：基础功能、亮点功能和期望功能。不同类型的功能，在 KANO 模型图中有着不同曲线。下面逐一说明。

（1）基础功能-痛点

以数据开发模块为例，登录、任务列表、任务查询、运行状态查询、任务回溯、实例重算等等这些基础功能没有实现时，用户对产品是“极其不满”的。但是，即使这个功能做的再限，用户也会认为是“理所应当”。

如上图所示，图中的红色曲线即代表的是当前产品的基础功能，我们可以根据产品前期的调研情况来将基础功能定义成两个坐标点，分别代表：基础功能不完善时用户的不满意度、基础功能极完善时用户的满意度。随着功能的完善，用户满意度虽有所增长，但并没有突破 0 点，最多就是趋近于 0。我们将这种线条形态的功能叫做基础功能，基础功能是必须要实现的功能点，但它无法带来高满意度，只能消除不满。

那么，怎么判断一个功能是不是基础功能呢？这主要靠产品人的领域知识。

你做某个领域的产品，就得知道该领域有哪些基础功能。比如，要做一个美图的应用，就必须知道它要能拍照，还要有几种基本的滤镜和一些类似拼图这样的核心工具，用来处理拍完的照片。如果你的领域知识不够，无法做出正确判断，还可以通过问用户两个经典问题来补救：

• 如果产品没有功能 A，你觉得如何？请从很满意、一般满意、无所谓、不太满意、很不满意（或 5、4、3、2、1）这五个评价选项中选出一个来作答。

• 如果产品有了功能 A，你觉得如何？同上给出相应的答案。

然后，在 KANO 模型图中为以上两个答案对应的坐标点之间做个连线，就能看出这一功能所属的类型了。这个方法对接下来要讲的几类功能同样适用。

（2）亮点功能-爽点

当这个功能没有做时，用户并不会不满意或觉得有问题，因为已经“习以为常”。但是一旦有了这个功能，用户就会大为惊喜，甚至“赞不绝口”。为什么会这样？主要因为这些功能通常是新的，用户事先想不到产品居然还能有如此妙用。

亮点是忠诚度、口碑传播的基础。

如今，一个没有亮点的产品，用户也许偶尔会用，但不会与产品建立正向情感连接，更不会主动帮我们传播。想要低成本引流，让老用户带来新用户，产品必须找到自己的亮点。

那么应该做什么样的亮点呢？常见的亮点特性有“用户没见过”“未经市场检验”和“如果被认可就能获得巨大回报”这几种。由此可知，选择亮点不能一概而论，大公司和小公司，已经很厉害的产品和新生的产品，都会做出截然不同的判断。

（3）期望功能-痒点

例如上图中的绿色的线条代表的就是期望功能。它是一条直线，表示随着功能的完善（x 轴数值的增加），用户满意度（对应的 y 轴数值）从负数开始渐渐增长到一个正数，并且穿过坐标系原点。这类功能，少了用户有点不爽，但还不是无法接受；多了用户会觉得不错，但也不是欣喜若狂，对产品而言往往是“多多益善”。这类的产品功能选择起来也比较简单——先做性价比高的。之所以取“期望功能”这个名字，是因为这类功能都是用户的期望。

第二轮 MV Prototype

在第一轮 MV Paperwork 后，我们对产品的背景、要解决的问题、意义和目标已经有了较为明确的认识，在这一轮，我们需要将问题变成解决方案，并通过设计原型，来低成本验证解决方案。这就是第二轮 MVP---Minimum Valuable Prototype。

1. Y 模型：把问题变成方案

在下面的配图中，你可以看到一个大写的字母 Y，有三个线段、四个节点。左上角的起点我们标记为 1，中间那一点我们记为 2，右上角的点记为 3，最下方的点记为 4。

• “节点 1”代表的是用户需求场景，经常被简称为用户需求。这是起点，是表象，是表面的需求，是用户的观点和行为。

• “节点 2”是用户需求背后的目标和动机，是用户言行的原因。不过产品经理在思考用户目标时也要综合考虑公司、产品的目标。

• “节点 3”是产品功能，是解决方案，是技术人员能看懂的描述。

• “节点 4”是人性与价值观，或者说是用户心智，是需求的最深层体现，是需求的本质。

Y 模型的不同阶段，各自需要回答一些问题，可以总结为 6 个 W 和 3 个 H。“节点 1”这个阶段的问题主要是 Who（目标用户是谁）、What（需求表现为什么）和 Where/When（何时何地，什么情况下）。“节点 1”到“节点 2”和“节点 2”到“节点 4”这个阶段，对应的是对用户需求的层层深入。这个阶段要回答 Why 这个问题——要不停地往下深入挖掘需求，了解用户为什么会有这样的言行、为什么会有这样的目标和动机。“节点 4”到“节点 2”再到“节点 3”的过程中，你要想清楚 How——也就是要想清楚问题应该怎么解决。这个叫浅出，先深入后浅出。我们对用户需求理解得要深，这叫用心听，但是给用户呈现的解决方案要尽量简单，把复杂留给自己，把简单留给用户，这叫不照着做，给出创新的解决方案。最后的“节点 3”中，要回答 Which、How many、How much 三个问题。Which 是指选哪一个方案，做哪一个功能，这背后其实是对价值的判断，比如怎么评估性价比和优先级。How many 是指这一次做多少个功能，考验的是对迭代周期，产品包大小的把控。How much 原意是多少钱，这里引申为多少资源，是对时间、金钱、团队等资源的评估。

1. 借假修真：用"原型"低成本验证

通过前面的介绍可以知道，要把用户真实的需求“想清楚”并马上提供一个切实可行的方案并没有那么简单。其次，即使产品做出来了，也需要很多调整。这里的“调整”不仅仅是指技术难度方面，而更多的是说，你如何保证你做出来的东西，确实是用户需要的？如果我们直接上手做真实的产品，往往需要投入大量的人力、财力和时间。退一步说，就算你不在乎钱，但时间浪费掉以后，市场机会也有可能一去不复返。所以，如何用最少的人、最少的时间、最少的花费，做出一个确实能验证解决方案（而不仅仅是验证问题）的东西。假”，是说产出物并不是真实产品，“真”，则是说它可以验证真正的解决方案是否靠谱。

比方说，我们要做一个电商 App，那肯定是要做交易流程，但退款退货的功能要不要做呢？一开始可能决定不了，因为这和你卖的商品品类有很大关系。那么，我们可以这么做，开始的时候先做一个退款退货的“假按钮”，点击以后并没有相应的系统，而是让人工客服介入，处理退款。这样跑一段时间，如果发现退货退款的订单太多人工处理不过来了，再考虑上系统，如果退款退货的量一直不大，那就一直人工处理好了。

这样的例子有很多，这里推荐一个示例网站：https://demo.axureshop.com/?url=https://cloud.axureshop.com/FCY0YV&buyurl=https://www.axureshop.com/a/3562.html

参考资料：

1、苏杰，《人人都是产品经理：低成本的产品创新方法》，2022-09-01

2、苏杰，译，《启示录：打造用户喜爱的产品》，2022-09-01

3、梁宁，《产品思维 30 讲》，2019，https://www.doc88.com/p-20839762931212.html?r=1