《产品日思录》是我个人公众号上每天更新的系列文章，记录了我在做产品过程中的思考、总结、经验积累，也希望在这里和简书的大家分享~
今天的思考源于一场产品内部需求评审会，会上产品部的同学针对需求合理性进行了激烈的思想碰撞，我作为需求提出人，难免在受到质疑时本能进行辩解，但这一过程存在着或多或少的准备不足和表达不当，这里做个总结，也希望和大家分享下需求评审会，作为需求提出人，哪些话不该说。
1、这个功能，我看XX产品做了，挺有意思，既然别人做了，就有存在的理由。
因为别人做了，我们就可以做，这句话有很大逻辑漏洞，根本站不住脚，别人做了不代表他们觉得有价值，或者用户觉得有价值。这种话如果说出来，很容易让人质疑你的能力。
2、这个功能XX说了好几次了，优先级肯定很高，需要快点做。
别人说了好几次的需求，不代表现在要马上做，要确认当时提需求时，是否和特定场景相关，很可能当时很紧急的需求，到现在并不紧急了，这个得具体问题具体分析。
3、虽然这个功能是为这个活动做的，但以后我们也可以用在其他地方。
具体讲解时，需要考虑全面了再说，也就是要明确“其他地方”都有哪些，是否一定要用这个功能实现，投入产出比如何？其他方案是否也能满足需求，如果长期考虑用途不大，只是为了一次性活动，那就要根据开发成本考虑最简实现方案。
4、这个功能做了，可以拿来售卖啊……
一个功能是否值得做，需要先考虑其在特定场景下的用户价值，然后再提商业价值。有些功能的商业属性是很弱的，单纯拿出来作为理由站不住脚，还是要结合场景来说。
此外，我觉得，在讲述一个需求时，还应该注意如下事宜：
1、依据场景进行需求描述，什么情况下，谁，为什么会用到这个功能，以此来传递需求价值。
2、有些需求是需要跨部门配合才有价值的，就要提前说清楚，这样的需求，是否已经和对应部门进行过沟通，他们的看法如何，是否可以提供足够的支持等等
其实还有很多值得注意的点，但这次主要就今天的会议内容做下反思，避免以后再犯，大家如果有什么好建议欢迎留言回复哦~
