最近听到一句话感触很深“你们做的这些竞争力特性就算不用我这个产品我的产品也照样卖”一台手机上的功能能被用户真正使用的功能是很少的一部分有 20% 吗就当有 20%那么还有 80% 的功能都在干什么呢扎心的是开发这些功能的费用是分摊到这台手机设备上的。用户真的需要这些功能吗还有更扎心的是一旦功能特性上线之后就很难被“日落”掉。原因一特性曾经受益者的直接或者间接的“阻挠”如果特性日落就说明当初推动这个特性上线的“领导/专家”决策有问题当初给这些“竞争力特性”发的一些奖励都成了笑话。谁来承担这个后果万一这个特性是哪个一级/二级/三级部门的领导呢每次想到这里都觉得天天喊的一些价值观诚信、以消费者为中心等等都真的只是口号践行起来困难重重。原因二对产品经理来说费力不讨好的“额外工作”对于推动日落这个特性的人来说后续的工作也非常麻烦到各种评审会上去说明日落这个特性的理由并获得各个产品线相关领导的同意。这种会议通常很多至少 3。基本上你要准备特性的过去半年/一年的使用率、留存率、日活、月活、NPS、NSS评估特性日落不会产生舆情/舆情可控。评估一下日落特性的详细应对方案例如对于升级产品来说是否还继续保留这个特性对于从带有这个特性的产品通过数据 clone 到新的产品之后是否要继续保留这个特性针对日落这个特性要给一线客服提供 FAQ有用户热线询问的时候能在一线客服就闭环。制定好特性日落时的舆情监控策略安排好相关人及时闭环现网舆情防止舆情等级上升。这个工作顺利将特性日落并不会给你带来多少好处一旦出了问题反而会背锅。原因三对开发团队来说减少投入的目标秒变双重压力本来日落特性可以为开发团队减负因为减少了维护的特性节省这部分人力。但是一旦升级产品还要保留这个特性就给开发团队增加了额外的工作量每次动这个特性相关的代码随着时间推移软件架构腐化共用部分的代码变动就得测试两种情况是否有影响。总结日落特性对于开发团队来说也是出力不讨好还是干一些产品的买点、卖点特性绩效才能更好一些。 当你在绩效输出中写上半年日落2个特性其中一个引起C类舆情尽管你付出很多但是最终的绩效一定是不好的那么谁还愿意做这些处理不讨好的事情呢