第一阶段：产品执行&用户体验
0-2岁的产品er大部分处于这个阶段，执行上面的想法，推动产品方案上线落地。这个阶段对于产品的好与坏的评判标准，基本是基于自己作为小白用户的视角。
如何避免在这个阶段被开发吐槽：
1.1 想清楚
方案idea可能是上面拍的，但方案细节是你自己定的，想清楚每一个交互细节和异常流，不要说想不全，可以拿着方案先和架构开发测试简单聊聊。
1.2 写清楚
写清楚的意思是每一个流程每一个步骤都写的条理清晰。拿一个普通的展示页面来说：
流程说明，主流程、分支流程、异常流统统写明；
跳转说明：点击返回/编辑/保存/取消等，分别触发什么。弹框是怎么进入怎么消失的。toast显示几秒，停留在当前页还是返回上一页；
显示规则，这个页面包含哪些元素，都是哪些字段，格式大小要求是什么，是否换行全部展示，过长或过短怎么展示，异常输入怎么显示、空态页显示什么等等；
排序规则：第一排序优先级是什么，第二排序优先级是什么，正序还是倒序排列等等；
分页规则：一页最多展示几个，一次拉取几个。下拉还是上滑刷新，是全页刷新还是半页还是指定区域刷。
等等等等………这还只是一个普通的前端展示页面，涉及后台逻辑的细节可以写的更多。建议：把评审会上被开发问住的点都记录下来，整理起来，以免下次写文档有所遗漏。同时可以多看看身边优秀的产品经理写的文档。
1.3 讲清楚
每次开发评审少则7、8人，多则30多人，紧张怯场一次两次可以谅解，长此以往就要反思自己。声音是否洪亮，是否照顾每个听众的反应，是否准备充分，把该强调的细节都强调了？文档要写的条理分明，评审要讲的逻辑清晰。例如：这个页面涉及哪几个功能，需要哪些开发支持，主流程是什么，异常分支是什么，特殊的规则和要求是什么。建议：自己讲完可以邀请关系好的开发复述一遍，就知道哪些地方要着重再讲一遍。另外，多观摩观摩别人是怎么评审的。
1.4 沟通沟通
沟是方式，通是结果。结果不对，方式肯定错误。那什么是好的沟通方式？不卑不亢。产品经理和项目组所有人都是平等的，你不是指挥他们干活的，也不用刻意讨好。平等的意思是，发自内心的尊重，耐心聆听的理解，相处自然舒服不添乱。
刚入行时，向技术提需求也会买零食请吃饭撒娇卖萌。后来渐渐发现，最佳的“讨好方式”是成为一个靠谱的产品经理。
第二阶段：产品架构&技术实现
之前有个同事，是清华计院毕业的产品er，他曾笑言，某次提需求时，开发说实现不了，他当场指导开发怎么去写代码 = =！
听得我好生羡慕，吭哧吭哧跑去学html学python，走了不少歪路。
产品需要写代码很牛逼么？不需要。产品需要懂技术实现吗？需要。
这是两回事，一个优秀的产品经理不需要会写代码，但要清楚技术的实现方案，以及，能够从业务角度，专业的回答很多个为什么为什么。
建议：
每次需求评审完，技术们都会私下再碰定下接口。产品er为何不索性再拉个技术方案评审会，听下前端客户端服务端是怎么商量确定接口，一来了解各自分工，二来了解数据流转。别觉得开发定接口和产品没关系，这直接关系到产品实现的交互细节。
大公司的产品er估计拿不到线上数据库权限，但可以私下找开发要开发环境或测试环境的数据库权限。要了数据库权限，不是用来装逼的= =！ 请看下你所负责的项目，共涉及哪些表哪些字段，这些数据的调用、流转、更新是怎么样的。
以上，简单来说：看看API文档