一个需求值不值得做，我主要看这 5 件事

现在我做产品，已经越来越少问一个问题：

“这个需求能不能做？”

我更常问的是：

“这个需求到底值不值得现在做？”

这两个问题看起来很像，但后面的结果差很多。

因为“能不能做”，讨论的是实现。而“值不值得做”，讨论的是判断。

前者通常会把人带进技术细节里。后者才会逼你回到产品本身：这个东西到底有没有必要，现在做是不是对的，做了之后会不会真的带来结果。

我现在越来越觉得，很多产品不是死在做不出来，而是死在做了太多不该先做的东西。

功能一个一个看都不大，需求一个一个听都挺合理，做的时候也都会觉得“这个加上会更完整一点”。

但最后最容易出问题的，恰恰就是这种“看起来都可以做”的需求越来越多。

因为产品不是功能堆出来的。真正好的产品，很多时候不是因为做得多，而是因为筛得准。

所以现在我判断一个需求值不值得做，主要会看下面这 5 件事。

1. 这个问题是真的存在，还是只是我觉得它应该存在

这是第一层判断，而且经常最重要。

很多需求之所以会看起来“挺合理”，是因为它在逻辑上说得通。流程也能讲通，场景也能脑补出来，甚至一眼看过去还挺像那么回事。

但逻辑上成立，不等于现实里成立。

我现在会更在意的是：

• 有没有真实的人反复提过这个问题
• 这个问题是不是在真实流程里经常出现
• 它是一个长期存在的摩擦点，还是偶发抱怨
• 是少数人的个人偏好，还是有一定共性的真实需求

因为很多时候，需求不是假的，但它的“必要性”是被高估的。

你觉得很重要，用户未必觉得。你觉得早晚都要做，现实里可能根本轮不到现在做。

所以我现在不会只因为“这个需求听起来对”就决定做。我会先看：它到底是现实问题，还是只是我的想象。

2. 这个问题够不够痛

有需求，和有强需求，不是一回事。

很多东西用户当然会说“如果有就更好”。但“更好”这种需求，往往不是当前最值得做的需求。

因为产品资源永远有限。尤其是一个人做事，时间、注意力、开发成本都非常贵。

所以我现在很在意一个问题：

这个问题如果不解决，用户到底有多难受？

我会更偏向去做那种：

• 不解决就会持续卡住流程的
• 不解决就会明显增加成本的
• 不解决就会让人放弃使用的
• 不解决就会让目标无法推进的

而不是那种“做了体验更好一点”的需求。

不是说后者不重要，而是顺序不一样。

产品早期最怕的，不是做得不够细，而是把很多“以后可以做”的东西，提前当成了“现在必须做”。

真正痛的需求，通常会逼着用户自己想办法绕过去。而不够痛的需求，用户嘴上会提，但不影响他继续凑合。

这两种需求，优先级不能一样。

3. 这个需求是在推动结果，还是只是在补完整感

我现在会特别警惕一种需求：

它看起来没错，也确实有用，但做它的真实作用，更多是在让产品“显得更完整”。

这个坑我自己很容易掉进去。

因为一旦开始做产品，人天然会想把东西补得像样一点。后台要不要更完整，配置要不要更细，权限要不要更全，数据要不要更丰富，流程是不是要再顺一点。

这些东西都不是没价值。但问题在于，它们很多时候并不直接推动当前最关键的结果。

比如：

• 它并不能帮你更快验证需求
• 也不能明显提升留存
• 也不能更快带来付费
• 也不能决定用户会不会继续用

它更多是在补“完整感”。

而完整感这件事，很容易让人上瘾。因为它会制造一种很强的推进感：

我在做事，我在完善产品，我在让系统更专业。

但很多时候，这种推进感只是让你自己安心，不一定真的在推进结果。

所以我现在看一个需求，会问：

它到底是在推动结果，还是只是在补完整感？

如果只是后者，我通常会更谨慎。

4. 这个需求现在做，是不是时机对了

有些需求不是不对，而是现在做不对。

这个判断很重要。

因为很多产品问题，不是需求本身错了，而是阶段错了。

比如：

• 产品还在验证期，就开始补很多复杂配置
• 用户还没稳定留下来，就先做很重的后台系统
• 付费路径还没跑通，就先花很多时间做边角优化
• 核心流程还没收敛，就开始做大量扩展能力

这些需求以后可能都要做。但“以后要做”不等于“现在该做”。

我现在越来越在意的是：

这个需求是不是符合当前阶段的主要目标。

如果当前阶段最重要的是验证，那需求就该服务验证。

如果当前阶段最重要的是交付，那需求就该服务交付。

如果当前阶段最重要的是稳定，那需求就该服务稳定。

很多时候，需求不是值不值得做的问题，而是现在做会不会打乱当前节奏的问题。

阶段感一乱，整个产品就会很容易越来越散。

5. 这个需求做完之后，会不会带来可验证的变化

这是我现在很重视的一条。

因为有些需求做完之后，很难判断它到底有没有价值。你做了，产品也更“像样”了，大家看着也都觉得不错，但最后很难说清楚，它到底带来了什么变化。

我现在会更偏向优先做那种：

• 做完之后能看出用户行为变化的
• 做完之后能验证某个关键假设的
• 做完之后能明显减少某个阻力的
• 做完之后能更快判断方向是否成立的

换句话说，我更愿意做那些“做了之后能知道值不值”的需求。

因为产品早期最宝贵的不是功能数量，而是认知更新速度。

你越快知道什么是对的，什么是错的，产品越有机会活下来。

反过来，那些做完之后也很难验证价值的需求，我现在会更谨慎。因为它们很容易消耗时间，但不给你新的判断依据。

所以现在我判断一个需求，核心不是“想不想做”，而是“它该不该现在做”

如果把上面这些压成一句话，大概就是：

我现在看一个需求，不再先看它有没有道理，而是先看它是不是当前最值得做的。

具体来说，我主要看这 5 件事：

1. 这个问题是不是真实存在
2. 这个问题够不够痛
3. 这个需求是在推动结果，还是只是在补完整感
4. 这个需求现在做，时机对不对
5. 这个需求做完之后，能不能带来可验证的变化

这五条不会让我每次都判断对。但至少能让我少做很多“看起来也合理，做完却没有太大意义”的东西。

我现在越来越觉得，做产品最难的不是想功能，而是敢不敢不做那些暂时不该做的功能。

因为很多需求都能做，但不是很多需求都值得现在做。

所以现在我看到一个新需求，已经不太会直接进入“怎么实现”的状态。

我更常先停一下，问自己一句：

这个需求，是当前最值得做的吗？

很多时候，真正拉开差距的，不是做得快，而是筛得准。