Skip to content
- 产品经理权责一致。如果产品经理需要对产品负责，那么产品经理有权参与产品决策讨论和沟通。产品的工作性质和内容决定了产品经理必须全面透彻地了解需求背景目标和投入。如果前期决策讨论未纳入产品经理，那么产品经理有权拒绝为最终结果被黑锅。
- 深刻理解邮件、微信、会议、RTX和当面交流等沟通方式的优劣和使用场景。
- 产品经理是信息流通中枢，第一时间传递和更新市场、运营、开发、测试、设计等环节信息，产品经理不能成为信息的终结者。
- 当面交流+白板手绘是信息交流最高效信息传递最丰富的沟通方法。
- 打开Axure前请用笔画好流程图和信息组织分类。
- 按模块或系统平台（Web、iOS、Android）划分产品团队分工会直接导致产品模块割裂，各自为战视野局限，这于产品和团队的发展都是非常不利的。
- 产品团队按目标分工。产品有一个主目标，主目标分解到团队成员子目标。子目标以可量化的产品数据指标来衡量，为完成目标可规划设计调动所有产品资源。
- 产品团队规模与团队目标相匹配。任何子目标负责人只有一个，新目标安排新负责人。
- CTO兼任产品负责人是非常不好的组织架构。CTO对接开发造成产品架空，产品讨论易陷入实现细节，CTO缺乏宏观产品方向把控，产品经理会沦为打下手的。
- 运营方案规划后，产品经理方开始设计运营性产品方案。运营驱动的功能特性必须有运营方案支持，否则极易浪费开发资源。
- 面向消费者的需求验证可行后再付诸产品形态化。未验证的需求以轻量的运营活动或灰度发布验证。
- 拍脑袋的想法90%不靠谱。
- 善于甄别运营需求和用户需求。业务部门提出的需求是他们想要的，还是用户想要的，区分两者很重要。
- 产品经理站在公司层面集中考虑项目优先级。项目优先级与产品目标优先级一致。
- 杜绝临时的市场营销需求导致的产品功能变化。临时的单独性页面承载临时的营销需求。
- 定期向需求方（业务部门、老板等）反馈需求处理意见、需求进度，避免陷入需求方无穷催问的被动境地。
- 先沟通确定产品方向和形态后输出产品详细方案，避免多次无效劳动。
- 全部需求按版本拆分。全部要做的需求分拆到几个版本里去，前一个版本进入设计后即可启动下一个版本的规划。
- 产品团队内部共同维护一份版本目标表，每个版本功能特性的目的是什么，上线后是否达到了目的，每个版本回顾更新，保持版本间的连续性与整体性。
- PK 产品方案的正确方式：1）逻辑推理；2）用户验证与反馈；3）成熟产品案例。
- 谨慎上线新功能，宁缺毋滥。
- 产品经理需要懂点技术。不仅为高效与开发沟通，产品经理判断需求要求哪些开发协作，敏感察觉并应用最新的技术。
- 开发过程中，一位开发担当开发Ower，协调开发阶段的实现细节讨论、联调提测等，产品经理就可以集中精力设计产品。
- 测试团队担任Bug的发现、收集与跟踪。Bug发现者可将Bug转交产品，产品再转交测试，测试负责跟进。这样，产品经理也可以适当从Bug处理中解脱出来。
- 发布单独作为一个项目环节。重视发布环节和发布质量。
- 迭代，是指产品的功能和体验已达到上线标准，发布后产品进入下一阶段的设计和策划，而不是产品功能和体验未达标就上线，上线后紧急修复纠正各种bug。
- 测试环境定期更新线上真实数据，以覆盖测试真实的数据场景。线下测试后进入线上环境UAT测试。
- 大版本在QA测试结束后，发动全员内测。全员内测：1）测试的版本一致；2）真实数据测试；3）测试激励机制。