程序员和产品经理的战争中，说得最多的就是，产品经理每天就知道加功能“蹂躏” 程序员。
但实际上，作为一名产品经理，每天做的最多的事情就是砍功能：一是，删减产品需求文档上的功能，只保留最重要的功能；二是，已经决定了产品功能，但出现了突发情况，需要临时决定到底要不要砍功能。
第一种情况下，砍掉产品的哪些功能主要考虑每个功能对总体指标的贡献有多大，以及工程难度有多大；而第二种砍功能的情况往往出现在产品发布之前，还可能会涉及和其他组合作的情况，需要考虑各个方面的因素，操作起来比较复杂。
平时在Facebook工作中，我最常问的一句话是: “这个是不是launch blocking? ”即没有这个功能会能会不会影响产品发布。我经常在以下两种情况下问这句话：
1、我们的产品在刚开始内测时，一般会让公司内部所有员工进行测试，然后再开放给一部分用户使用。如果我们收到用户反馈说让人功能哪里哪里不好用，那我们就会讨论到底要不要把产品发布时间推后，先把这个功能修复好再发布产品。
2、我们的产品需要和其他组合作完成，但其他组出现了突发情况，以至于某个功能无法按时完成。比如，我所在的视频组要和搜索组合作，完成允许用户通过关键词搜索视频的功能，但搜索组突然出现了问题，无法按照预定的发布时间实现“自动推荐关键词”，我们现在就会讨论到底是先砍掉这个功能直接发布产品，还是等搜索组的问题解决后再发布这个产品。
往往第二种问题会比较复杂，处理起来需要考虑的因素也非常多。所以接下来，我以一个实际产品为例分享一下， 和不同的产品团队合作时，应该怎么处理产品发布前出现的突发情况。为了保护隐私，我稍微改动了一下产品细节。
砍功能要有科学的思考方式
我们产品要发布的新功能：帮助一类明星用户宣传自己，让这些明星用户获得更多普通用户的关注，从而提升明星用户的点击量。明星用户需要先完成一些任务，才可以得到宣传机会。这个新功能主要包括两部分：一、普通用户的部分；二、明星用户完成任务后开启这个新功能即可得到平台的内宣传，并且可以查看因此增加的点击量。
要和我们的产品同时发布的还有其他几个针对明星用户的产品，这些产品对应的明星用户是一样的。
经历了一段时间的开发，第二部分明星用户的功能已经开发完毕，第一部分的功能也接近尾声了。突然，负责普通用户部分开发制iOS工程师说:“大事不好，我刚刚发现了一个Bug，这个功能上线后，只有5%的iOS普通用户能看到，而剩下的95%的ios用户都看不到，我也不知道原因是什么。”
那么问题就来了，iOS一周才会发布一次新版本，新版本给到App Store 还要经过一周的审核，因此如果这个问题解决不了，那么这个新功能的上线就要延迟两周的时间。但是，这个功能在Android平台已经测试完成，并且参加测试的明星用户好评如潮。
所以，我们需要做出决定：是先解决iOS平台部分的问题，然后两个平台同时上线，上线时间延后两周；还是先在Android平台发布新功能。
砍功能也需严谨的决策流程
现在这个问题其实涉及普通用户和明星用户：对普通用户来说，IOS有没有这个功能并没有什么影响，因为这次更新的功能只是增加了一个可以让他们看推荐的明星用户的板块；而对于明星来说，我们需要显示这个新功能给他们增加多少点击量，来保证他们有足够的动力完成预设的任务。
因为要同时发布的这几个产品对应的明星用户是一致的，所以如果我们产品的这个新功能在所有平台都晚发布两周，那么其他几个产品的功能就会不完整。但是，现在公关方案已经接洽好了，如果把这几个产品全部延后两周发布， 必然损失惨重。这是把Android端和iOS端全部延后发布的风险。
如果只有Android端的用户可以看到推荐，那这个明星用户的总体点击量会因为iOS端的用户无法看到推荐而降低，而功能发布两周内用户点击量的增加量，是明星用户评价这个功能好坏的关键。所以，如果这些明星用户看到点击量并没有因为使用这个新功能而大幅度增加，他们就会觉得这个功能不实用，以后也就不会用这个产品了，更不会持续完成任务。这就是提前给Android 普通用户发布这个功能的风险。
针对我们产品现在的情况，以及上面考虑到的风险，我们讨论出了三个方案：
方案一，产品普通用户部分的功能，先在Android端发布，晚两周再在ios端发布，明星用户部分的功能和其他几个产品正常发布。如果采用这种方案，我们需要考虑两个问题：
➢ 要和明星用户解释一下，普通用户部分的功能现在只在Android端发布了，iOS端两周后才会发布，所以两周后的数据才是最有说服力的。
这个方案是有风险的，虽然已经跟明星用户做了解释，但毕竟数据不好看，明星用户依然会对我们的产品丧失信心
方案二，先发布其他几个针对明星用户的产品，而我们产品在Andrid端和ios端的发布全部推后两周。这个方案的风险是，因为我们产品延后发布，导致其他几个产品缺乏完整性、用户体验不连贯。
方案三，所有的产品全部推后两周调试完美后再发布。这样做的风险是，全部计划包括公关计划都会受影响，损失修重，其他组不会同意。
其实，上面三个方案都不理想，我们需要思考一些更好的方法。所以，我们换了一个思考问题的角度: ios 端的普通用户点击量对整体点击量的影响有多大?
针对这个问题，我们专门做了用户调研。用户调研结果显示：.有写明星用户高达80%的访问量来自ios端，而有些明星用户的大部分粉丝都在用Android系统。
于是我们针对调研结果，把明星用户根据大部分访问量的来源分成了两类，并提出了两个比较聪明的方案：
第一个方案，产品普通用户部分的功能先在Android端发布，而明用户部分功能，选择先发布给大部分点击量来自Android端的部分明星用户。其他几个针对明星用户的产品，也先发布给Android粉丝占比较大的明星用户，这样一来，对外的新闻稿，可以把“今日发布给所有人”改成“今日开始发布”。两周后，我们把ios端的问题解决了，再做如下操作：在ios端开放我们产品普通用户部分的功能，同时把其他几个针对明星用户的产品开放给全部的明星用户。
第二方案，其他几个针对明星用户的产品，以及我们产品的明星用户部分的功能，正常发布；我们产品的普通用户部分功能先在Android端发布，但是等两周后iOS端发布这部分功能后，再向明星用户显示点击量提升的数据。
这样，明星用户可以先在两周的时间里做任务，毕竟做任务也需要时间，等所有的平台都发布完成之后，再给他们显示包含了所有iOS端和Android端用户的数据，“好看”的数据可以激励他们更好地完成任务。因此，先让明星用户形成使用习惯，再用数据激励他们继续使用，也不失为一个好方法。
这两种方式，我们产品的团队成员都可以接受，但是因为要和其他几个产品同时发布，所以需要选择一个最优方案。 其他产品的产品经理，希望他们的功能一步到位，发布给所有的内明星用户。
经过各种讨论、思考，最终愉快地决定，发布普通用户选择更灵活的第二种方式：除了我们产品在IOS端推迟两周发布普通用户的功能、并且在两周后才向明星用户显示增长的用户点击量， 其他产品照常发布。
总结
本节通过一个具体的案例，分享了如何权衡取舍，以及在产品发布之前部分功能出现问题时如何统筹。
通过这个具体的案例，要表达的内容包括以下四个方面:
1.要明确功能不能正常发布的风险以及受影响的人群。
2.要列清楚所有可行的选项，以及对每个群体的影响。
3.分析各个选项之间的风险。
4.要有大局观，选择最合适的方案。
