83 个回答
这个问题可大可小，有的新功能简单扫两眼数据就可以决定，有些却需要严谨的分析与调研，是否添加跟新功能的与产品规划吻合程度、开发难度、涉及用户范围、功能定位，乃至于上线时间都有关系，是个综合考虑的过程。
根据问题，我就假设新功能已经被策划出来了，是否添加可根据以下几点来衡量：
1、与产品定位的吻合程度：
不得不承认，我们有时候在策划出来的新功能后会觉得很兴奋，会抱有强烈的期望，觉得“上线必火”。但经济学中有一个知识点，叫“禀赋效应”，指的是当人拥有A物品时，对A的价值评估比没有拥有A物品时要高，简单的说就是“自己家的肯定比别人好”。在决定添加前，结合产品定位，再对新功能进行一次反思，或许有更清楚的认识。其实在策划新功能的时候已经结合产品定位进行过思考，这里相当于“考后检查”。
我一般会简单的问自己几个问题：
* 真的有对应的实际场景吗？
* 最终策划出的新功能符合最初设想的目的吗？
* 真的不是为了“新增”而新增吗？
如果回答都有满意的答案，那这一关就算OK。
2、开发难度：
这点我们不是开发，最终新功能能否开发出来决定权不一定在我们手里，我相信沟通到位的情况下绝大部分开发都会努力实现，但技术限制有时候就在那，不得不面对现实。这里多说一句，作为产品经理，你要假设所有功能的都是可以实现的，先想什么做是对的，再来想怎么做。
3、涉及用户范围：
这里要辩证的考虑，不是单纯说影响用户少就可以不添加。假设新功能只针对5%的用户，但这5%偏偏是重点用户，当然不可以忽视；假设针对90%的用户，但都是普通用户，乃至于游客，考虑到影响人数，也是需要重视。但假如仅针对10%的普通用户，那当然新功能的必要性就弱很多。
4、功能定位：
这里就可以应用到KANO模型理论了，估计所有产品新人一开始都阅读过的材料，评估新功能是处于哪种类型：魅力因素、期望因素、必备因素、无差异因素、反向因素。
* 属于魅力因素、期望因素的新功能添加前最好都再考虑一遍与产品定位的吻合情况，因为即使受用户欢迎，也不见得和自身规划吻合。
* 必备因素就简单的多，看下相关数据，或者日常用户反馈就可以决定是否添加，有些甚至可以直接上，譬如电商的购物车、社交的IM等等..
KANO模型主要用于用户调研的，但对每个新功能进行用户调研显然也不现实，新功能属于哪种因素多数就需要依靠产品经理的工作积累进行判断了。
5、上线时间：
某些功能活动性质较强，是需要配合节点的，过了节点自然就弱了很多，还记得接着春节前后火起来的微信红包吗？
总得来说，新功能是需综合考虑的过程，如果在上述因素中都有较满意的答复，那就必上无疑了。
对于一个新功能的是否添加，我认为是要十分慎重的。
产品经理在判断是否添加新功能的时候需要考虑许多因素，如考虑用户需求的强弱、用户增加的价值及产品的的复杂性等。
首先要判断的可能是用户需求的强弱，或者新功能为用户增添的价值，但这种判断一方面比较主观，而且不同产品经理可能难以形成统一的意见，尤其是一些新功能可能会增加产品复杂度，对用户反而造成干扰。
1.用户需求，非做不可；
在产品规划时，首先基于市场分析和用户研究之后对产品目标进行优先级排序，看新功能对这些优先级的影响程度而定。
2.跟风而坐，同行的产品都在做，都有这个功能，希望自己的产品不落伍。比如现在的弹幕，每家都在做。
3.KPI需要。比如说增值服务，大老板定了目标数据，不得不去完成。
4.看产品功能是不是符合产品的定位，偏离了核心主线的功能可能会被抛弃。
5.产品战略，需要大胆尝试某些创新的功能。
6.运营驱动型产品，运营来的需求功能。
7.开发资源，是否能做的功能。
8.评估市场的前景，如果市场前景不明朗，那么就可以砍掉啦！
另外，对于已经上线了的产品，其新功能的添加应该更加慎重。
最后，如果你开发资源有限，那你就问自己一个问题“如果不加这个功能用户是否就会离开？”
如果你还有一些资源可以做一些事情，那你就问自己“这个功能有多少人用？用的频度怎样?能带来什么增加的价值？增加的价值是否是核心的部分？”
暂时想到的就是这些啦。
简单说，判断核心就是「能否驱动产品短期目标的达成和长期目标的布局」。
展开说，就接着啰嗦了。
首先要明确产品目前所处的阶段，以及产品的短期目标和长期目标。
如果是初创产品
初创产品的短期目标一般是快速验证产品核心需求，获取第一批种子用户；长期目标因公司战略而异。
对于初创产品来说，最重要的就是时间。每一个新功能都需要谨慎思考，因为新功能一般都意味着投入不小的开发资源和时间。这时候考验的就是产品经理对市场的嗅觉和对产品的理解了。
评判标准：
1.是否与产品定位一致
2.是否是主场景
3.能否极大提升核心流程体验
4.是否在短期或长期持续带来用户
5.是否在短期或长期持续带来商业价值
黑名单
1.别人家的产品有这个功能
2.这个功能现在很火
如果是成熟产品
成熟产品的短期目标一般是促进活跃增长，为产品带来商业价值；长期目标一般是建立持续的壁垒和盈利。
对于成熟产品来说，最重要的就是少犯错，很少有成熟产品因为一个新功能能再次爆炸或质变的。这时候产品经理更多需要通过市场调研和数据分析来驱动自己的判断。
评判标准：
1.是否与产品定位一致
2.是否促进用户持续活跃
3.是否提升商业价值
4.同类产品是否有这个功能，效果怎么样
5.能否为运营和市场打开局
黑名单
1.极大提升产品复杂度，开发风险高
2.KPI完成度无保障的情况下玩情怀
先这么多吧，想到了再补充
产品经理如何判断一个新功能是否应该被添加？
第一：
产品开发之前只要进行会议讨论的吧。会议上会讨论同类竞品做了没有，为什么要这么做？这么做满足了什么需求？这个需求是真需求还是伪需求？如果不开发会怎么样？等等。几个小时的会议，开几次下来如果确定这个功能还是要添加的就可以开始干了。
第二：
功能开发肯定走的是敏捷开发，快速将功能开发出来，然后内测收集结果，如果内测不过关，就不必再继续了。如果内测过关，就灰度测试咯，然后做数据分析。
第三：
正是发布到迭代版本，然后收集运营数据，了解用户对这个功能的使用情况。如果扩大了产品使用量，用户反馈积极信息，就可以开始下一轮的数据挖掘，需求拓展。这个功能目前为止算是成功的，应该被添加。
以上是功能添加的常规思路之一，也是大型公司的常规做法。
而如果你是创业公司的话，那么就简单得多。
第一：头脑风暴确定需求，第二敏捷开发第一版，第三迭代上线分析数据。
当然，牛逼产品经理和普通产品经理的不同之处在于它对功能是否应该开发有精准的直觉，他可能不是你，但是你一定有这样的长辈，朋友，师父。多请教一下他们。从不同角度思考一下功能的合理性。
这样，你多半能够完善功能，设计出新的功能，或者更加了解这个功能背后需求的本质。
以上。
从我的”自然生长“理论这个情况可以拆解成两类来做出判断：1、在主线生长线上，这个功能处于什么样的地位，参考@夏癮也是王小兴的四象限法则，2、为了填补某项数据，例如为了拉新，会增加邀请给予奖励等措施，但有可能这一功能会“生长”成为产品的主线路，参考滴滴的优惠券。
还有就是千万别从用户需求（想清楚到底什么是需求，什么是需要）层面来思考，做产品大忌，真心的。
另外可以参考一点就是实际情况，这个维度涉及很多，平台用户量级，投入产出比等
已上线产品添加新功能，是件相对谨慎的事情。
看过这么一个规则：当你准备往产品里加一个功能时，要准备好以后都要对这个功能负责。给用户加一个功能很容易，但把一个现有的功能拿掉试试看用户会有什么反应？简而言之，产品功能尽量简化，否之容易造成用户的纠结感。
那么，回到这个问题，如何判断一个功能是否是一个有价值的功能？
1.需求从哪里来？目标客户是谁？
2.客户群体有多大？是否为客户用户？需求的紧迫程度如何？
3.场景是什么？功能上线后对用户带来哪些价值？
4.上线后对流量有何影响？
如何判断一个功能是否应该被添加？
我觉得可以运营先行。
如果产品经理从用户这边、从上级这边、从自身这边感觉需要做某一个功能，但无法评估出这个功能会给公司带来多大的价值，会给产品带来多大的影响和变化，可以让运营先去尝试，如果能够跑通，再进行产品化的改造。在把这个流程产品化。
运营先行的办法，有利于降低试错的成本，避免伤害用户，可以通过运营去看用户的反馈，收集用户的信息，进行分析，切记用户都不是你免费的小白鼠，所以能够运营先去尝试的，暂时可以不用产品功能的改造来试错。
如果这个功能确实有做的必要，但是没有时间去运营尝试一段时间，可以和开发评估开发的量，争取投入最少的开发量，产生最大化的收益。
如果公司不是这样运营先行的风格
那么可以进行分析
如果这个功能没有被添加会造成什么样的影响？最坏的影响是什么，这个影响的结果我是否能够承受
如果这个功能被添加能够给我带来什么利弊？
进行一个综合的评估
接着可以去进行用户访谈，收集用户的反馈，带着用户的反馈进行理性的分析，把这个总结和公司的领导商量同时和开发的同时沟通确定开发量是否能够实现。
对该问题，记得时间管理里有一个四象限法则（重要且紧急、重要但不紧急、非重要但紧急、非重要非紧急），我觉得在这里也同样适用，当我们获取到一个新功能的需求时，我们需要分析该功能（需求）对用户来说，是处于四象限中哪一个位置（此时的四象限可能有很多评估标准，可综合参考其他朋友的回答：人、财、物、需求本身合理性等），来判断是否需要添加，优先处理重要且紧急和重要但不紧急的事项，因为非重要紧急、非重要非紧急最后都有可能变为不处理；
做到这一步还不够，还需要进一步判断，因为资源有限，不可能需求来了立即就有资源可以投入，可能在其前面已经有好多其他功能正在排队，此时，我们需要将队列中的需求进行优先级重新排序，同样，优先处理重要且紧急的需求，最终我们来决定该共功能是否需要添加；
首先还是分析需求，需求的本质是在什么情况下，为谁解决什么样的问题。是添加了新场景，还是业务方新需求，或者是填以前的坑。
其次，明确了解决谁的问题和问题产生的背景，结合目前产品已经有的流程或者功能来判断通过优化，适当的小变更能否解决新的需求致使需要新增加的功能。如果不能的话，再考虑添加新功能，不过对于为了弥补以前的坑而添加的新功能通常只能解决燃眉之急，不能从流程优化上起作用。
最后，确定了只能添加新功能才能让需求更容易满足，这个时候需要对成本（开发，运营人，客服等）和用户价值（用户使用频次，用户平均付费虑）进行平衡。