和简单的Trello相比，复杂的JIRA更像是落入了“功能蔓延”的陷阱。但实际上恰恰相反，这支团队分辨了哪些使用案例能实现盈利，同时也为不同的客户传递了同样的产品愿景。

　　为避免无关的功能，你一定要清晰地明白你的产品是什么，以及如何最好地将它带给某一类客户。这里有三种途径：

　　1.对功能进行经验测试。这种测试应该具备一个流程来确定某种功能的相关性，以及它会如何在特定的客户群体中帮助他们实现产品愿景。谷歌的HEART测试就是个很好的例子。它鼓励你去检测用户的幸福度、参与度、采用度、保留度和任务成功率，这些测试能迫使你去思考这项功能是否和你的目标客户相符，是否对他们有帮助。

　　2.拒绝功能请求。并不是所有的功能都拒绝，但要拒绝其中一部分。例如，Basecamp公开拒绝在产品中添加甘特图，哪怕有一位用户在博客上发表了不满言论，因为创始人Jason Fried相信，他和这位用户只是在“优秀的项目管理需要什么”这个问题上存在分歧。专注于产品的愿景，意味着你要仔细思考每一个功能请求(包括内部和外部的)，以决定是否要将它加入到公司的产品开发理念中。

　　3.如果你承诺了一些强大的功能，那么就不要去担心功能蔓延。想想Clearbit和ipinfo这两家API公司，它们对客户做出了不同的承诺，最终他们提供的产品相差也很大。ipinfo承诺用户能够“快速、简单地将IP地址写入脚本或网页中”。最终它提供了一个简单的API，实现了这个功能。Clearbit则承诺“打造企业智能API”。如今它针对市场、销售人员和开发人员推出的API系列并不是什么功能蔓延，而是变相地实现了当初的承诺。

　　这种设计过程可能会附带着开发出很多功能——也有可能开发出的功能不多。数量并不重要，但针对不同客户和整个客户群的相关性和效果如何才是关键。

　　围绕着客户激励来打造你的团队

　　如果你发现自己的产品无用的功能太多，那么你一定要想象这是谁导致的。每个人都有发言权，在产品设计中往往弊大于利。

　　在任何规模的团队中，我们常常容易看到，对于产品的发展方向，大家都有自己的看法。这些压力可能来自投资人，他们认为增加某些功能可以帮助公司盈利;有些则来自营销和销售团队，他们需要实现自己的季度目标;设计人员和开发人员会听取客户反馈，并试图打造一种解决方案以满足每一位客户的请求和抱怨。那些高度关注产品愿景的人，并不一定对你的大部分客户最有帮助。

　　各种不同的意见很快会把团队逼疯。你在忙活文件编辑器，因为股东想要它。他在设计搜索功能，因为客户需要它。然后彼此都不知道对方在干什么，以及为什么这么干。最后，产品开发的速度也会被拖慢，甚至停滞，因为大家都不协调。

　　笔者个人也经历过这种“群体设计”带来的危害。我和另一位Crazy Egg的联合创始人Neil Patel，就因为这个问题损失了100万美元。

　　在Crazy Egg之后，我们试着去打造一个类似Grid System共享主机平台，我们管它叫Vision Web Hosting。

　　每个人都有不同的动机，只会在一开始就模糊了产品开发的方向。每个人都有话要讲，这导致我们的开发进程很慢，产品发布也被推迟了。我们打造了一大堆功能，但它们并没有让客户之间的主机共享变得更加容易。

　　最终，它毁掉了产品和团队。我们的产品根本没有问世，两年后整个项目也被迫关门，这个过程中，我们的损失达到了100万美元。

　　加上我和Neil，Vision Web Hosting的团队只有五个人。我发现，相互矛盾的意见哪怕只有几个，也足够让人头疼了。在更大的组织里，产品意见的协调就更加困难，而且容易缺乏组织纪律性。这里有几个方法能帮助你协调团队(不论你的团队规模如何)：

　　1.给目标设定不同的登记，确保这些目标都与产品的总体愿景相关。谷歌拥有一个内部的评级系统，团队的每个成员都可以在里面设定自己的OKR(目标和关键成果)，而首席执政官则为整个团队设定OKR。接着每个成员的完成结果都会被评估，并根据整支团队的业绩评价管理层。

　　2.确保团队每个成员都知道你要打造什么。哪怕你设定了团队的总体目标，你也要让他们明白为什么要这么做，以及每个人应该如何让产品变得更好。这就需要每个人都了解产品的运作原理(正如Intercom设计的消息传递系统)——因为你不能假设每个人都同步。