精准创业实战第13章不要堆积功能

真正的好市场必须要有大量潜在客户，这样，市场的强劲需求会催生创业公司源源不断地制造产品。    ----------马克·安德森

13.1 功能必须靠催生，不能靠堆积

13.2 实施二八原则

13.3 限制在建功能数量

13.4 处理功能请求

13.5 功能的生命周期

13.5.1 用看板来跟踪功能

13.5.2 流程步骤详解

13.1 功能必须靠催生，不能靠堆积

不能堆积的原因：

• 过多的功能会淡化产品的独特卖点

产品越简单，用户就越容易理解和使用。

• 不要过早丢弃MVP

别慌着编译，先搞清楚客户为什么不买你的产品。-------贾森·科恩

• 功能也是有成本的

功能越多意味着需要做的测试、截图、视频都会更多，而协调工作也会增加，产品会变得更复杂，而且还会对用户形成干扰。

首先要会说‘不”。

• 你还不知道客户到底想要什么

功能堆着堆着就堆成习惯了。--------本杰明·尤可维奇

13.2 实施二八原则

在产品上线之后，你应该立刻把大部分的时间用来评估和改进现有功能，而不是追逐那些看似很炫的新功能。

13.3 限制在建功能数量

要想掌控好新增功能，你可以先限制当前在建功能数量。此外，你应该先验证新增功能的效果好坏(也就是针对这个功能做了客户学习之后)，然后再来做开发。

转换率信息板可以帮我们跟踪各项指标，而看板则可以帮我们追踪各种功能。二者都可以让你把注意力集中在大局上。

总体来说，在看板中，某个功能最先是放在最左边的一列， 在通过客户开发以及产品开发流程之后，才能进入最右边的“完成”列。

1、储备

把所有准备加入产品的功能都先放进“储备”列。加入“储备”列的功能可以是:

• 改进现存功能(比如改进注册流程)
• 客户提的功能请求
• 你自己想加入的功能(比如你之前没有做的那些“最好有”的功能)

最小可营销功能( Minimal Marketable Features，MMF )：指的是可以为客户提供价值的最小功能。

要想知道一个功能算不算最小可营销功能，你可以问问自己会不会写一篇博客或者发一封邮件告诉客户你做了这个功能。如果这个功能小到不值一提,那就不是最小可营销功能。

2、在建

“储备”列里的功能一般是按照和产品当前目标的关联程度来排序的。这样，我们就

能很容易从列表中挑出最重要的功能来实现。

限制工作队列是看板的核心理念之一，也就是说要限制任一时间在建功能的数量。这

样，你的效率才能提高，同时也可以减少浪费。

我建议你在开始的时候按照公司联合创始人人数或者团队成员人数来设定这个数字,后面再根据需要来修改。也就是说，如果你的联合创始人只有三个，那你就只能同时开发三个新功能。

3、完成

功能完成之后，就要转移到“完成”列。

对于精益创业公司来说, 一个功能只有在通过验证式学习并取得结果之后才能算是“完成”。

13.4 处理功能请求

13.5 功能的生命周期

13.5.1 用看板来跟踪功能

1、目标

你最好把产品的紧急目标和重点放在看板的顶部。这样做可以让每个人在为功能排序的时候都能遵循同样的标准。

2、在建功能的数量限制

在建功能的数量限制写在最顶部的标题框里。如果团队比较大的话，一般会再给各个子步骤(比如产品模型、 产品演示、代码等)设定任务数量限制,不过创业团队一般都比较小，所以也不用分那么细。

3、缓冲通道

流程中的每个步骤都分成了两部分。上面的功能正处于“工作状态”，下面的部分(也称为缓冲区)则是用来临时存放已经完成的功能，但还要等待有人接手下一个步骤。

4、不管功能进行到哪个步骤都可以毙掉

我们在功能生命周期流程中会进行多次客户验证。如果功能无法通过验证，则要么返回上一步骤重来，要么被毙掉。已经毙掉的功能应该用红笔注明。

5、持续部署

如果你有一套持续部署流程,可以把代码提交 –> 测试 –> 部署 –> 检测这个循环全部都放在“代码”一栏。

6、两步验证法

要定量地验证一个功能需要花很多时间,这里我只定性地验证一下,然后就把功能标记为“完成”。这样我就可以摆脱在建功能的数量限制，在为上一个功能收集反馈的同时，腾出空位来实现其他功能。

13.5.2 流程步骤详解

功能生命周期中的各个步骤：

一、认识问题阶段

储备

在第12 章结束的时候，我们给出了一个简单的流程，用来快速审核储备列表中的功能。先把这些功能需求都放到“储备”栏的上半部分，因为这些功能还没开始做。由于在建功能有数量限制，所以你必须仔细地根据产品的当前目标来给储备功能排序。

在你收到功能请求之后，首先必须看看这个问题是否值得解决。如果你找不到做这个功能的充分理由，那就马上毙掉它。

• 客户提出的请求

如果功能请求是客户提出来的,那你跟客户通个电话或者见一面。虽然客户只是想知道具体的解决办法，但你需要找出问题的根源所在。试着引导一下客户，不要让他光想着要这个功能，而是让他告诉你为什么应该增加这个功能。

这个功能是“必须有”还是“最好有”?这个问题是否值得解决?这个功能会对产品的整体有何影响?在电话或者会面结束时，你对这些问题应该心中有数了。

• 内部请求

如果这个功能请求是团队成员提出的,那你也应该按照对待客户的方法来和这名成员谈谈。同样，你也必须能回答：这个问题是否值得解决?

二、解决方案阶段

(1)产品模型

如果你确定这个功能值得做，那就用我们在第8章中介绍的方法来做一个产品模型。可以先用纸和笔画些草图,然后尽快转换为你的产品所使用的技术，比如HTML/CSS。

(2)产品演示

有了产品模型之后，你就可以开始做客户访谈了，访谈的形式可以参照之前的解决方案客户访谈。你可以不断地对产品模型进行改进，改进之后再做访谈。必须在客户非常满意之后，才能继续下一步。

(3)编码阶段

在验证完产品模型之后，你就可以开始着手正式实现这个功能了。最好把这个功能拆分成比较小的编码任务,然后使用任务板来追踪这些任务的进度，并使用你的持续部署系统把这个功能逐步地加入到产品中。

三、定性验证

(1)部分部署

现在，功能编码已经完成并正式加入到了产品中。你需要做的是先把拥有这个新功能的产品部署给少数客户。

(2)定性验证

用类似MVP访谈的方式来做一些可用性测试，并解决问题，然后再对修改后的版本进行测试。如此循环，直到把问题都解决掉。

四、定量验证

(1)全面部署

现在，你可以开始做全面部署了。在全面部署之后,这个功能就将放到“完成”栏,不再占用“在建”名额。你可以把“储备”栏里排在这个功能之后的那个功能拿出来,开始实现。

(2)定量验证

功能全面部署完成之后，就可以把功能部署前后一周的转换率拿来对比一下，从宏观上确认一下功能的效果。

对于有些功能来说，你可能还需要再做一次分离测试。不过，在这个阶段,到底要不要做分离测试完全取决于你的判断。

如果你同时进行很多分离测试的话，功能的验证周期就会拉长，而这有可能会影响其他实验，而且会让群组分析变得很复杂。所以，你最好仔细考虑一下， 什么时候该做分离测试，什么时候不该做。

针对这个问题，我有几点经验。

• 我一般不会对全新推出的功能做分离测试，因为可以直接拿没有用过这个功能的群组来做对比。
• 如果某个功能在定性验证阶段得到了客户的高度好评,那我也不做分离测试。

如果某个功能在定性验证阶段得到了比较好的评价,而且又属于改善或者流程修改类的功能，那我建议你做一下分离测试。