怎样在已经足够精简的设计流程中尽量降低产品风险呢？文章将会为你解析。

在创业公司中，在开发一个产品前往往并没有充裕的时间和人力做商业价值分析和市场分析。小的创业团队需要快速的开发，让用户使用产品并验证产品是否是用户想要的。但这并不意味着，脑袋里灵光一闪的“绝妙的点子”就要立马投入开发。怎样在已经足够精简的设计流程中尽量降低产品风险呢？

简单的来看一下精益产品设计的流程，下图是Henrik Kniberg在《How Spotify builds products》文章中的一个图表。

图一

上图，蓝色曲线代表运作成本；红色曲线代表产品风险。

横坐标把产品设计流程分成4个阶段。借用网易云课堂中“精益产品设计”中的思想，我们可以把它翻译为构想、打造、测试、迭代。

这个图表在下文中我会多次提到，由于作者在文献中并没有对它特别命名，我们先简单的先命名它为“产品风险与成本图”方便指代。接下来我们逐个阶段来看，如何能降低产品风险。

一、构想

通过产品风险与成本图，我们可以看到，在构想阶段的运作成本较低，在这一阶段一般只需要产品和设计动动脑筋，在此期间进行初步假设和推敲是可以降低产品风险的。但假如在这个阶段马上投入设计和开发，相当于把产品推向一个高风险高成本的状态中。

硅谷创业家Eric Rise在《精益创业》中提出了“精益创业”（Lean Startup）和最小化可行产品（Minimum Viable Product, MVP）的概念，许多产品经理对这些概念的理解容易沉浸在“精益”和“最小”中。而在本书的前言，作者对本书内容的概括介绍“你会了解从一个极需严格检测的大胆假设开始，到如何开发最小化可行产品来验证这些假设”，本书也专门有一节叫“概念基于假设”。我们应该把更多的目光投向假设和检验。

关于假设，我们又该怎么做呢？

• 定义产品，并想清楚这个产品解决什么问题；
• 提出假设。你的目标人群通过使用你的产品功能，达成了一个怎样的结果；
• 验证假设。跟用户充分沟通；建立用户画像（Persona），描绘具体场景（Scenario），找出痛点（Pain），把以上三个要点代入到你的解决方案（Solution），是否能够满足用户需求。即PSPS模型（从网易课堂接触到，作者没有查到有关此模型的其他确切来源）。

我们可以这样提出假设，比如我们为有注意力不集中、总是不能按时完成作业的学生开发一款带有奖励与惩罚机制的作业日程表，可以让学生每天都能按时完成作业，通过观察目标人群是否提高了每天完成的作业量来验证。

而验证假设，我们需要YY自己是那个注意力不集中的学生，在晚上开着小台灯做作业一边看电视剧，通过使用带有某种奖励和惩罚机制的应用，关掉了电视剧一心一意做作业并完成了当天的作业。

二、打造

在打造阶段，我们需要打造出一个MVP，那什么是MVP呢？

MVP是Eric Rise在《精益创业》提出的一个概念，“精益创业”的核心思想是“开发-测量-认知”（Build – Measure – Learn），先做出一个最小可行产品MVP（Minimum Viable Product, MVP），发放给用户测试并收集用户的反馈，然后快速迭代，不断改进产品，最终适应市场需求。

在这里需要注意的是，许多产品经理过于关注“最小（Minimum）”而忽略了“可用性（Viable）”，这是很可怕的。一来最小可行产品对用户而言是需要有他的核心价值的，二来最基本的功能也是用户能使用通畅的。

在产品与风险图中，我们看到在打造阶段，运作成本是非常高的，而产品风险在这一阶段线条平稳，也没有降低的可能。我们当然要想方设法的去缩短打造阶段所需要的时间。由于有了构想阶段“产品定义-提出假设-验证假设”的准备，这一阶段只要尽快去打造MVP就可以了。

我们见到很多产品经理喜欢随意改需求，在构想阶段没想清楚、打造阶段继续想，随时要设计师和开发改并称“改需求是常态”。可这么做会拉长打造阶段的时间，占用设计和开发的资源，也增加了不少沟通成本。往往导致设计反复修改，开发也不能按时完成任务，产品经理自己也会在反反复复修改的过程中影响最小可用产品的“可用性”。那什么时候可以改？如何有依据的跟设计和开发沟通？在测试阶段我会提到。

关于“可用性”，相信了解MVP产品经理应该都听说过“轮子、自行车、摩托车”的例子。下图中，MVP是一辆自行车，摩托车是自行车的升级版，完整但成本较高，而轮子是简化到根本不可用的。而某些产品经理在对摩托车的矫枉过正中把自行车打造成了一个轮子，欺骗自己“这是一辆自行车”并用这个轮子进行下一阶段的测试，然后告诉整个团队自行车是不行的。

图二

三、测试

我在打造阶段留下的问题在这里说明，“那什么时候可以改改改呢？”能让设计和开发信服的改动至少也应该是有依据的，而不是脑袋里随意想想就要设计改十几个版本。产品经理应通过用户反馈和数据来优雅的跟设计和开发沟通。

图三

在测试阶段，我们已经有了一个最小可行产品。我们应该：

• 把这个产品发布给少数用户，观察用户反馈，查看用户数据；
• 通过反馈和数据进行分析改进，再判断这个产品是否能够符合市场需求，能否扩大测试用户规模；
• 如果可以，扩大测试用户规模，并重复以上步骤，观察用户反馈和数据并不断改进，然后扩大用户规模；如果不可以则继续优化产品；
• 通过以上步骤不断扩大测试用户的规模，完善产品。

如果过程中存在设计难以解决或比较犹豫的问题，针对这些功能对用户进行A/B test。

注意：在前期的阶段，验证功能符合市场需求后，需要继续对核心功能进行优化。这一点往往容易被忽略。随着扩大用户测试规模，核心功能会遇到各种各样的挑战。比如做一个IM软件，你的软件在现在这个时代还不能发短视频，又或者加好友功能可用，但模糊搜索非常糟糕。此时去做一个自定义个人资料皮肤的功能就是非常不理智的。需要产品经理判断好各种需求的开发时机。

四、迭代

基于之前构想，打造、测试的三个阶段，我们证实了这个产品是符合市场需求的。接下来就可以再一次的通过构想、打造、测试的方法对产品进行优化并开发新的功能了。

注：图1，图2，图3来源于Henrik Kniberg的《How Spotify builds products》

作者：米小可，公众号：产品萌新米小可

本文由 @米小可 原创发布于人人都是产品经理。未经许可，禁止转载。