需求判断的决策树：小团队如何在半小时内过滤掉80%的伪需求

几年前我带第一个产品时，最头疼的不是没需求，而是需求太多。每周都有用户反馈、老板想法、友商动态，叠起来能写满两块白板。一开始我照单全收，结果团队疲于奔命，大部分功能上线后几乎没人用。后来我才意识到，小团队不需要更好的优先级排序方法——我们需要一个能在半小时内把80%的伪需求直接丢进垃圾桶的决策树。

这个决策树不是完美的，它只是我在过去几个产品（AI写作、语言学习、工具类App）里反复摔打之后，总结出来的一套低成本判断流程。它的前提是：你至少有3个月的产品数据（哪怕很粗糙），并且你愿意在每次评审前花30分钟走一遍。

节点一：场景颗粒度——谁在什么条件下用？

大多数伪需求死在这一步。用户说“我想要一个语音输入功能”，但你得追问：是写长文时用，还是记笔记时用？是在手机端还是PC端？每天用几次？如果用户答不上来，或者描述的场景超过三种以上，那就不是需求，是愿望。

我自己的规则是：一个需求只指向一个具体场景，且场景的触发频率不低于每周一次。对于工具类产品，频率低于一周一次的场景，除非能带来付费转化或者极高留存，否则不值得专门做。假设例子里有个用户希望我们在AI写作产品里加一个“历史版本对比”功能，听起来合理吧？但我们追问后发现，他最常用的场景是每周写一篇周报，对比版本的需求其实是“怕改错了回不来”。所以我们没做版本对比，而是增加了一个简单的撤销回溯（Ctrl+Z多步），开发量从3天缩到2小时，用户满意了。

节点二：替代方案——用户现在怎么凑合的？

如果用户没有替代方案，需求紧迫；如果有替代方案，看看他是不是很痛苦。我习惯问用户一句：“现在你没有这个功能，你是用什么办法解决的？”如果他说“暂时没做”“等你们做”，那就是不痛；如果他说“我不得不把内容复制到另一个软件里做，很麻烦”，那痛点明确。

曾经有个用户要求我们做一个RSS聚合功能，理由是“每天要看好几个网站”。我们问他怎么看，他说“我手动打开书签”。这个替代方案虽然低效，但每天只花5分钟。如果我们做RSS功能，至少一周开发，还要维护解析规则。最后我们做了一个简单的链接收藏夹，支持自动更新标题，开发量两天，用户也觉得够用。替代方案越“差不多能用”，伪需求概率越高。

节点三：不做会怎样？——用户流失校准

这是最难但最值钱的判断。需要冷静评估：如果这个需求三个月内不做，有多少用户会因此离开？注意，是离开，不是抱怨。抱怨是常态，离开才是信号。小公司没有大数据做回归分析，但可以找一个简单的替代指标：跟用户直接聊，问“如果这个功能半年内都不做，你会继续用我们的产品吗？”如果回答是“可能会吧”“那我考虑一下”，那就是伪需求；如果回答是“那我肯定不续费了”或者“我只能换一家”，这才是真需求。

前面提到的语音输入需求，我追问后，用户说“没有也能用，就是打字累”。而有个核心用户说“你们如果没有批量导出功能，我下个月就不续费了”，团队马上做了。结果导出功能上线后，那个用户果然续费，还介绍了两个客户。这和节点二的逻辑一致：用户现在有替代方案（打字），但痛苦值高到足以触发流失，那就得做。

节点四：工程成本与维护成本——不只是开发时间

小团队容易低估维护成本。开发一个功能可能花三天的代码，但之后每次版本升级都要兼容、测试、修bug，甚至还会引入新的性能问题。我的决策规则是：如果维护成本超过开发成本的50%（按半年估算），这个需求必须额外证明它带来的长期价值。

举一个假设例子：我们考虑加一个Markdown导出为PDF的功能。开发大概两天，但PDF渲染在移动端有各种字体、边距、分页问题，每次系统升级都要重新适配。后来我们发现用户需要PDF的真正原因是“方便打印文件”。于是我们没做PDF导出，而是在Web端提供“打印视图”，用户自己用浏览器打印，效果更好，开发只需半天。维护几乎为零。

节点五：有没有更简单的方案？

这是最后一道防线。哪怕以上所有节点都通过，你仍然可以问：能不能用现有功能组合？能不能用自动化脚本？能不能由运营人工处理一小段时间，验证需求后再开发？

我曾经收到一个用户希望我们支持“自动生成周报摘要”的需求。听起来是个AI功能，但我们评估后发现，用户已经有日记录，只要把每日数据按模板组织一下就行了。最终我们用3天花板写了一个简单的合并脚本，没做新功能。用户很满意，我们也没增加长期维护债务。

什么时候该放弃这个决策树？

这套框架不是万能的。当产品处于0到1的探索期（比如你还没找到PMF），或者需求涉及全新赛道（你甚至不知道用户是谁），这时候直觉和快速试错更重要。决策树依赖已有的用户行为和反馈，如果你只有几十个用户，样本太小，节点一的“频率”和节点三的“流失”都不可靠。另外，有些需求虽然频率低，但能带来口碑传播，比如某个小众但极致的功能可以吸引关键意见领袖。这时候需要放开决策树，用定性判断补充。

但如果你已经做了3-6个月的产品，月活跃用户在1000以上，那么这个树足以帮你屏蔽掉大部分噪音。我自己的实践是：每两周开一次需求评审会，会前每个人用这个树过一遍自己提的需求，至少有一半在会前就被划掉了。团队不再为“要不要做”争论，而是讨论少数几个真需求怎么做。

只做最痛的那个

写到最后，我想说：小团队不怕做错功能，怕的是做了太多“还行”的功能。每一个“还行”的功能都在稀释团队注意力和用产品体验。决策树的核心不是找到“最好”的需求，而是过滤掉“够用但浪费资源”的需求。当你把资源集中在用户真正痛的点上，留存、口碑、营收才会自然跟上来。 PaxLee