11 个回答
两个角度：
第一：评审会是干什么的呢？不只是工作，也是你展示自身价值的时候，从初期的需求框架、业务框架、功能框架、设计细节，这些阶段（不限于这些）每一个评审会都可以突出你的价值，而不是开个会走个过场，协商个排期，讲解个需求就完了，这样肯定没有价值显现的；单纯的原型、文档，这是执行类的初级产品，开发大部分不知道初中高的说，所以从产出物的角度，不就是画图的么？
核心是价值怎么展现～
第二：就是沟通，没有沟通，协作就会吃力，开发无法理解产品的角度是正常的；
我们产品人平时怎么锻炼自己的思维能力？不就是多看多想多分析，然后验证优化迭代……
举个简单的例子
抽根烟（本人男）的功夫简单聊聊日常，
可以是（找些吐槽点）以前的产品不太好啊？之前工作流？全当请教工作方式
跟着开发一起吐吐槽之前的产品？
或者偶尔（日常的耳观六路，眼听八方哈）听到他们午休时候聊了什么，引过来当谈资，当然你得懂。
很多时候你把开发当作一类用户，思考如何介入他们，了解他们，你才能共情。
你可以共情，他们的社交坚冰就一定可破，破了就是朋友，所以这类问题一般都是在刚入职的时候就要做好基础，这和产品规划没太大区别，为了自己未来工作环境的质量，提前做准备是有益的……
举个例子，按照技术的逻辑推理顺推得到以为是正确的结果，反而是错的。
精准扶贫政策，穷人享有比其他人更多的优惠，给穷人的贷款利率（扶贫贷款利率）比其他人更低，穷人要还的利息少，才能帮助穷人。
这样顺推的逻辑听起来是正确的，但是实际上是错的，因为最终结果是富人、真正需要钱、真正需要投资的人会想方设法去争取这些比市场利率更低、穷人才能得到利率，给穷人一些钱，穷人就帮你借钱，让你拿到这个贷款利率。实际上并没有帮到穷人，反而帮了富人。
你知道，我知道你知道，你知道我知道你知道，这才是产品设计面对的常态，是和用户动态的博弈，产品应该多一些海盗分金的思维，少一些一条路走到底的思维。
表象上，工作内容似乎确实是这样 ，可是如何干好就是另一回事了。
厨师看起来就是把原料和调料放到锅里搅和搅和，但实际上对烹饪的时长，材料的选取，都不是外人直接就能看到的。
调整心态，最终做什么还是产品决定，不行就放大招:改需求 嘿嘿