有评论人员认为HubSpot已经有一定功能蔓延（feature creep，指在发展过程中产品或设计的需求增加大大超过他们原来预期的趋势，导致其功能不是原本计划的）的趋势。但是，其产品的鲁棒性很强，它承诺为你的营销和销售需求提供一站式服务。产品的复杂并不是它的缺点，也不是它在随大流。恰恰相反，HubSpot的产品向客户传递的就是当初承诺的价值。
在产品管理领域， “功能蔓延”已经成为一个大家最讨厌的词汇。不少公司给产品添加了越来越多的功能，最后它们不禁思考，自己是否也成了“功能蔓延”的受害者。
有时候，产品的复杂化完全没有必要。但如果你怀疑自己的公司已经深陷“功能蔓延”的泥潭，那么你要明白：功能蔓延并不是根本问题，它只是一种表象。一大堆功能并没有提升你的产品价值，那你一定要在功能蔓延的概念之外去思考。
功能蔓延的神秘性掩盖了真实的问题：你的产品并没有传达核心价值。
透过表象看问题
一种简单的产品并不能一直传递你的价值。从另一方面看，修复一项复杂的产品，并不是要你简单地去掉大量的功能。你要看清楚哪些功能在推动着公司，然后把那些没用的删掉。
为什么公司最初打造的产品都会有一些多余的功能呢？随着产品团队和其他团队以及股东慢慢地打交道，产品管理的难度也会渐渐上升。这个过程中还会关系到你的客户，这意味着你必须经常思考应该如何向客户传递价值。
如果你认为公司正在经历“功能蔓延”，那么一些根本问题已经开始对你产生影响了：
一支团队无法向目标市场传递核心价值，或者客户需求的价值并没能被满足。那么他们就不能明白客户真正需要什么，只会开发一大堆没用的功能。
当然有些团队的产品开发是由多个人完成的。每个人都会给出自己的建议，但开发团队和用户的真实需求并没有合拍。那么他们开发出的功能其实也不能很好的实现用户的目的。
我们来仔细观察一下那些会引起功能蔓延的问题——以及一些解决方案。我们会探索应该如何向不同的客户群传递产品的核心价值，以及你应该如何根据客户激励来组织团队。
在表达产品愿景时，应该考虑不同的客户群体
如果公司设计了一堆不必要的功能，那么可能你不了解你的市场需求。
产品愿景应该能帮助你的客户实现自己的目标。但问题是，随着你的发展，公司客户越来越多——创企、中小型企业、大企业——每一类客户都有不同的需求。你应该针对不同类的客户建立不同的团队。
为每类客户设计一些通用的、但不关系产品愿景的实用功能也很简单。例如添加一些简单的ad hoc（点对点）功能能丰富你的产品。但是，如果你想要战略性地针对不同类客户，让他们都能从产品的核心价值中受益，那你一定要刻意地让产品的功能符合他们的需求。
如果许多类客户都对你的核心价值有需求，那么谨慎的扩张能帮助你实现发展。对许多公司而言，不为新客户提供支持，那么就百害而无一利。通过比较Trello和JIRA，我们就能更好地理解。
JIRA最初只是一款简单的针对开发者的漏洞追踪工具。
在过去的15年里，JIRA已经发展成了一个一体化的产品管理套件。这家公司打造了一系列功能，为不同类的客户带来价值，但这些最终都关系着产品的愿景——团队协作的记录和管理。
JIRA开发出的产品关系紧密，针对不同的团队都有特定的计划。
例如，它的功能包括：
分发特定任务，记录每个人的工作，这对于小团队而言非常有用。
灾难恢复功能和全新的安全授权，对于大企业的团队来说，这很关键。
另外还能制定工作流程，这对任何规模的团队都很有价值。
而Trello的发展就恰恰相反。Trello最初也是一些轻量化的功能。但它并没能针对不同的使用案例进行开发，也没有为不同的客户开发出一个统一的产品。它的发展速度远没有预期的那没快，最终被收购。
和简单的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设计的消息传递系统）——因为你不能假设每个人都同步。
3.让你规划的路径透明公开。整个团队应该都能看到未来前进的路线，并以此来指导自己的工作。同时，你要有一个具体且透明的计划来应对开发进程的延缓。Asanato和Airtable这些工具就能帮上你。
当然你也不可能完全摒除外界的干扰。但你可以在团队内部控制产品的开发动机，确保每个人都有具体的且彼此相关的任务。你构建的团队需要每个人都有相同的动机，同时还要评估每个人以及整个团队的进度。
强大的愿景和执行结构
为用户打造一款相关度高的产品，并不需要你急着去管理“功能蔓延”。因为这相当于治感冒的时候就治流鼻涕。背后的问题确实存在，功能蔓延只是表象，你需要深入到根源，了解公司可能发生的问题。
首先你要确保产品的确给目标客户群传递了价值——也就是常说的“市场匹配模型”。我最近对Slack的市场匹配模型进行了分析，告诉公司们如何寻找自己的目标客户。
这个过程基于Sean Ellis对市场匹配模型的定义，它是很好的出发点，能帮助你确定自己的产品是否给客户提供了他们需要的价值。在Slack的案例中，人们用于描述Slack价值最常用的词汇就是“交流”和“团队”。这恰恰符合Slack最初向客户承诺的价值——“你所有你需要的资源和利群集中起来，帮助你完成任务”。
总结下来，产品价值的实现主要分为以下几个步骤：
1.了解哪些客户群体能从你产品的核心价值中受益，他们的需求是如何与产品的总体目标相符合的。
2.采用一种统一严格的框架来为所有客户评价你的新功能。这能防止你弄出一堆没用的功能。
3.确保你的团队拥有共同的目标，并且它的结构能够激励那些能对产品开发产生直接作用的群体。
4.你的产品规划能够被团队的每一个成员知晓，让他们明白为什么要朝着这个目标前进。
总是担心功能蔓延并不能让你获得成功，解决背后的问题才是根本。只要你集中精力去做好每一件传递价值所必须的事，那么你就不用担心创造出来的产品是否跑题或者太过臃肿。
,
