一个功能是否要做，并不是说在规划或者feature里就可以的。还要看场景、进度。这篇文章，作者就分享了自己的经验和观点，供大家参考。

测试同学偶尔会来问：为什么这个**功能现在不做呢？

对啊，为什么大家明明都想到了确实没有主动做上去呢？

产品规划里面存在一些feature，一定会等需求方提出了才会去做。对于不同的使用用户，是b、还是c、是可接触的、还是屏幕背后的，我们当然要用不同的策略来管理，你说呢。

产品路径中我们曾遇到过敏感的数据地带，涉及到多个上下游的业务相关方，如果产品对于某个环节的数据提供出现偏驳，或者说具备了不客观的色彩（比如：是不是系统有了自己的想法，也就是产品策略和业务策略产生了的点点分歧），那么产品运营方自然也要被介入到业务的纠扯中不能自拔。这时候产品策略就依赖业务策略的建设，而业务策略的沉淀又依赖到其他一些产品功能的应用落地。

上面其实是之前经手有款产品其中一个feature，是个小算法，核心是给用户提供系统匹配计算的数据推荐，减少业务人员的数据筛选动作。这个数据我们大张旗鼓，呐喊叫做“相似数据”，就是匹配找到的高相似度的数据。哪怕是一模一样，我们也说这是个“高相似度”的数据。而最终的确认行为，是由用户自己主动核对过后进行点击操作完成。

究其为何，就是前文所说的敏感数据，涉及业务相关方多个，容错率低、业务风险高。虽然在产品规划中，早早识别了对业务的效率价值较大，但仍然按住了节奏，待前置的一些关联功能业务都落地后，才研发上线了该功能。并对其中相关的数据指标进行了审慎的命名，都是在引导用户能够对自己的行为有清晰的认知和定位。

类似的敏感的功能设计不少，比如：商品价格的管理、更新等机制，在实战里面则会以策略、技术储备先行，业务诉求迸发后才会迅速动手开干，而非主攻形态。而有些功能性效率改革价值大的，则会主动推进研发、引领业务方去落地应用。

以上当然有背景，是面对的复杂的b端内部用户。如果是c端用户，我们可能很难拿到如此真实的临场的感受，更多的是通过数据、用户行为分析得到的结果，而对于注意力管理，保持的形态更多应该是战斗形态。

产品的规划过程中，某些点看到了不做，其实不代表这些点不需要、没有价值，价值对于用户是一个动态的效用组合，需要结合场景、约束等外部因素，以及用户自身的感受、情感，以上综合决定了某个产品点的“效用”大小，也隐含了合适的时间窗口（产品时机）。