在快节奏的产品开发生涯中，你是否也渐渐沦为需求的执行机器？本文直击产品经理的职业困境，提出6个关键问题助你重拾产品决策权，从需求价值评估到ROI分析，教你如何从工具人蜕变为真正的产品缔造者。

工作时间长了，感觉自己是一个工具人，需求给到自己，所有的人都开始催，马上上手开始分析，画流程，画原型，写文档，开需求评审会，跟开发，跟测试，到上线验收。本来是一个产品经理的角色，结果慢慢变成了一个需求处理机器。能明确说明那个字段怎么对应，那个按钮点击啥效果，啥交互，缺忽略了用户，功能上线后，没人反馈就是没问题，也不会去看数据，马上又投入了下一项需求，周而复始。

思考下：你是不是工具性产品经理？

产品经理说是产品的缔造者，可是上面有领导，对接有运营，真正决定产品走向的是一个个人的声音。在这些声音中渐渐迷失了方向，自己已经没有能力决定这个需求做不做了。重新坚持自己吧，或者找出能说服自己的证据。

功能要不要做

• 这个需求是谁提出的？
• 业务场景是什么？
• 业务场景下用户规模是什么？
• 是否还存在其他业务场景，其他用户？
• 目前用户现状是什么，流程是什么？
• 这个需求要是实现能改变什么？

再接到需求的时候，先问一下，这6个问题想明白了吗？

1、这个需求是谁提出的？

提出者的职位，他所处行业环境，对他这个需求有没有必要性。

提出者：领导，且有明确的时间限制，是一个自己没接触的项目或者功能，这种情况下，我们可以先执行工具人的做法。

如果是自己跟的项目，或者说是没有明确时间限制，那么就要想一想这个功能为什么领导要做，当前现状是啥问题，或者我们可以直接跟领导沟通，当然我建议先想想剩下的5个问题后，存在疑问时带着疑问让领导解答。

不想问领导，那就问大模型，说明目前行业，简述需求，设定大模型的职位是产品总监，让大模型帮你回答需求的必要性，同时自己也可以根据之前的想法对大模型进行反击，有时候身处职位不一致，所对应的考虑或者想法方向有很大差距。可能以你职位觉得这个需求没有做的必要，但是领导从商业化或者系统稳健性方面出发，这个需求是必须做的。

2、业务场景是什么？

提出者，不一定是使用者，业务场景必须是使用者，什么情况下，为了什么，才会使用这个功能。

这就需要与真正的使用者进行需求讨论了。使用者只关注自己的流程，他不具备抽象功能的能力，只能描述自己的使用过程，这就需要你进行抽丝剥茧，总结，举例，确认，确保双方理解的业务场景是一致的。

3、业务场景下用户规模是什么？

这个就需要与使用者上一级进行沟通，上一级对于使用者规模，所处理的业务量，所占用的时间等。有一个平均的了解。在这个阶段也能知道这个需求是否要做A,B测试，影响的范围。

4、是否还存在其他业务场景，其他用户？

这个就是上面的那个延续，需要多借助业务了解是否存在其他的。

5、目前用户现状是什么，流程是什么？

这个是从第二个业务场景下的一个延伸，目前业务现状是不是阻断的，流程是可行的，目前需求是优化了那个方面，减少了那个节点等。知道用户的现状，分析痛点，我们才能知道这个需求怎么做，可以在哪一步进行优化。

6、这个需求要是实现能改变什么？

这个就是在问这个需求的价值，他值不值得做，同时也要评估需求的ROI成本与收益，阻断业务流程的，性价比高的需求。 耗时短、效果明显可以放到高优先级。

不值得做的话，业务真正的痛点是那个，我相信在之前的几个问题中你已经得到了答案。

有时候我们是没有时间想，有时候也是因为自己习惯了执行。只关注与分析与设计，忽略了做不做。

需求做的值不值

• 量化指标对比
• 用户反馈
• 复盘总结

等完成之后，需要再次判定这个需求值不值，这就要看数据了。通过量化指标对比之前的变化是什么。涉及到用户规模大的，也需要看用户的反馈。通过对需求值不值的判断，可以沉淀下经验，后续汇报或者年终总结，再或者面试的时候我们能拿出数据，证明这个自己的工作能力。