成为一个C端产品经理

成为一个C端产品经理，记录一些工作中的flash。有些是观察别人工作过程得到的启发，更多的是自己踩的坑。以此为记。
走出舒适圈不一定有好的结果，但是一定会付出代价。

一、逻辑严谨

（写需求前看一遍）

将所有相关人员都当成从来没有接触过此项需求和业务的人来面对；
关于我自己对业务的了解，就要付出更多的努力了；

• 业务闭环+数据闭环

  • 需求优先级是什么？是否需要插队？
  • 需求来源是哪里？需求目的是什么？需求涉及哪些模块或部门？大概什么样的功能可以实现brd的目的？是否已经有类似功能存在？
  • 功能入口在哪？落地页都有那些？各个落地页之间是否可以完成完整的业务链？
  • 数据如何产生？哪个部门负责？数据生成需要依赖什么前置条件？当前是否已经存在类似数据？
  • 数据是否需要二次加工以满足不同部门组装调用？
  • 每个移动端的区别是什么？是否需要同样对待？
  • 考虑显示规则，方便设计出图，开发有规则；
  • 如何埋码来校验这个功能效果？数据收集的周期是多久？定期观测埋码数据进行优化和改进；

• 目标向导+开发复用

  • 清楚明确需求如此设计的原因和目标，不要盲目借（chao）鉴（xi）;
  • 在目标导向的基础上尽量考虑开发组件复用，减少开发抵触心理和工作量；

• 冷启情况+异常情况

  • 网络异常、结果异常（结果为空）、场景异常、极限情况；
  • 在所有场景都无法兼容的情况下，懂得取舍；当然，满足一切场景是目标；
  • 初始页面和场景、页面显示规则；

• 遍历对象所有属性；

  • 页面属性：名称、入口、结构、交互、内容；
  • 遍历数据对象属性：比如电商行业的商品、优惠券等；需要知道基本属性及关联；做需求时，尽量将对象所有的属性情况考虑清楚；
  • 了解对象类型；需求涉及到的对象要列清楚类型和属性的影响；

• 懂一点技术

  • 知道C端的公共组件、公共页面；有利于确定需求的影响范围；
  • 知道数据库的基础知识；有利于了解数据存储规则，提前规避没有可行性的需求；
  • 知道接入层、中台设计规则；有利于规避高风险、高难度带来的不必要损失；

二、沟通交流

• 尽量记住所有工作相关的人的名字和工作职责，至少要知道做什么事情找什么人；
• 能百度的问题不要开口问；不能百度的问题大胆问；
• 不紧急的事情发微信文字，久不回复再语音；紧急的事情先发文字然后语音或者干脆直接语音；
• 任何人都会对产品有意见，有效意见有，指手画脚也有，出于自身利益进行抨击的也有。挨怼是常态，越是好的产品，证明他坑的开发越多，心理要强大；

三、项目推进

• 不要开发说什么时候发版，什么时候开发完毕都要听，适当的可以催一下，多问一嘴，多走一步

• 会议

  • 开会前要知道会议需要哪些人参加，预约会议提前通知开会时间、地点、主题及会议内容的大概的顺序；提前将需求文档发送到每个人手中；
  • 开会中记录存在的问题、解决问题的人，将解决问题的时间确认好；
  • 会议结束后给每个人发送会议总结；

• 开发人力处于大项目、紧急项目的时候，开发不愿意做；

• 一个优化的需求，针对一个页面，对多个小的功能进行优化；有的地方只需要移动端调整，有的地方只需要接入层调整，有的地方需要接入层、服务层、移动端甚至更多部门参与；
  • 将需求根据参与的部门或者其他维度，分成若干个部分；
  • 明确出来哪个部门需要负责哪些功能，必要的时候可以拆分文档；
  • 针对不同功能涉及的不同部门分别进行排期；需要关注多部门合作时的工作包顺序；

四、性格缺陷

• 玻璃心不能有；承受能力和抗压能力是当今社会的标配；
• “想到”和“做到”中间有个“做”，执行力是产品经理标配；
• 太敏感也不好，大多数人都很nice，不是故意不理睬你，也不会随意轻视你；
• 强烈的自尊容易引发自卑；自卑便不能恣意，畏首畏尾、缩手缩脚如何能大展身手；

五、随笔

• 20211015
  今天听到产品抱怨：让验收结束，测试却没能测完；设计抱怨：让验收结束，技术却根本不能按时改好；都在抱怨技术不能开发完毕。但是技术也在要求所有一线人员每天的bug都日清。立场不同看到的东西就是不同的。开发领导压迫产品必须按时验收，但是一线开发无法修改完毕所有内容，那产品就只能在一定程度上做让步。压迫设计人员尽快验收，一方面是不够重视UI，一方面是不了解UI设计的工作量。测试、设计、产品一起压迫技术，这也是程序员996的原因之一。
  我会说，造成这个情况的原因有很多，老板因为各种原因压缩工期，产品经理规划做的不够详细、开发人员技术不够、项目经理流程管理不行……但是啊，我从来没有看见过风平浪静、完全按照计划执行的项目，项目管理，注定是一地鸡毛的吧！！！

• 20211102
  我发现，不管是产品、设计还是开发，都有个共同点，优秀的人出方案解决问题，能力欠缺的，一直在问问问……

• 20211103
  与领导谈话有感：
  好的产品，用户思维一定很好，也肯定对心理学有所涉猎；善于创造，优于洞察力；
  好的领导，要善于引导下属做事，而不是监控工作。好的领导带领的团队，其凝聚力也一定很好；
  刚入行，要切换思维，用户思维，产品思维；
  我不想当一个翻译，或者，不想当一个简答的直译翻译；
  做产品有思考：数据什么样？市场什么样？竞品什么样？什么缺陷？什么有点？什么地方可以改进？可以达到什么样的效果？

• 20211109
  同事问我，开发和产品的区别是什么？
  之前我会回答，开发做单线程任务，产品做多线程任务；
  现在我的回答是，开发做确定的事情，确定时间完成确定的需求，产品做不确定的事情，跟不确定的人对接不确定的需求，最终慢慢形成一个确定的功能交给开发；
  可以对技术人员指手画脚的只有能力比他强的人，可以对产品发表意见的可以是所有人；
  开发可以牛逼轰轰，不diao任何人，只要你技术能力强。产品要是牛逼轰轰不diao任何人，专业能力再强有时也无法推动项目进行。开发考验智商，产品考验情商加智商。

• 20220119
  不要被技术牵着鼻子走，也不要做业务方的翻译机。

• 20220217
  接收需求->确认需求优先级->需求BRD->需求对接BP->产出原型方案->与业务方对接方案->确认方案->确认可能会涉及到的部门和人员->技术评审（需要带上业务方及所有相关人员）->方案细节&技术细节调整->可能需要反复评审->prd最终版->确定排期（设计、开发、联调、测试、验收，关注固定发版时间）；