编辑导读：随着越来越多人从事产品经理，这个职业的规范程度也在不断提高。而面对复杂的工作，跨部门的沟通，产品新人应该如何成为一个优秀成熟的职场人士呢？本文作者将从认知、习惯、协同、决策、项目、带人六个方面进行深入的分析，希望对你有帮助。

本文是作为跟谁学产品团队新人指南的一篇文章，来自于日常的团队管理和经验习得，通俗易懂。如果你觉得自己在产品工作中遇到了成长的阻碍，那么以下内容在认知、习惯、协同、决策、项目、带人六个方面做了要点的梳理。首次公开，供你查漏补缺，希望能帮到成长中的你。

一、认知篇

1. 产品经理是一个高杠杆工种

一般来说，产品经理和研发的合理配比是1：5。不难看出，产品经理本身就是一个高杠杆的工种。那么高杠杆有啥特性需要我们关注呢？我想最最重要的就是少做错误方案，因为一旦方案做错了，5个研发陪葬，这里损耗的成本让人心疼，也是行业内研发经常吐槽产品的关键所在。因此，不是人人都是产品经理，产品经理的专业度和成功率将决定整个产研的基础效率。

其次，产品团队不适合一下招太多新人，至少要保证在一段时间内，有值得信任的“老师傅”们能一对一带才可以，从而避免新人大量不成熟的方案产出，让研发跟着受累。

2. 产品设计师到产品经理最大的蜕变在于是否敢决策并承担决策后的结果

产品设计师和产品经理最大的差别就是，产品经理会把自己当老板来进行决策，并且愿意承担自己决策的后果。当然，我们知道后果有两种，一种是出问题了，需要背锅，一种是取得了不错的成绩，那么荣誉也自然归属于这个人的。

在这样一个氛围之下，很多小伙伴不敢去承担结果，怕出错。而这道坎，如果你迈不过去，那么你永远只是一个产品设计师。事实上，大可不必畏手畏脚，任何产品经理的最终决策，团队leader都会过目且会承担连带责任，因此在有人帮你撑着天的情况下，你更应该大胆决策，锻炼自己的决策能力和强化自信心。所以赶紧变身为老板去推进项目，那么你能收获更多，成长更快。

3. 不盲目崇拜技术，但需深刻理解“异步”、”解耦“、“抽象”等计算机思维及其应用场景

很多文科出身的产品经理没有学过计算机相关的课程，会对计算机方面的知识产生不可越过的敬畏，然后去学某门具体的编程语言。但事实上，产品经理和研发沟通经常不在一个位面的问题和编程语言本身一点关系都没有，最重要的是计算机思维。比如，“封装”是指一种将抽象性函式接口的实现细节部分包装、隐藏起来的方法，这就像我们产品经理和技术的协作，我没必要知道你具体怎么做的，只要你告诉我啥时候开始，啥时候完成就好，开发过程可以对我不可见。

比如，“异步” 是指计算机多线程的异步处理，与同步处理相对，异步处理不用阻塞当前线程来等待处理完成，而是允许后续操作，直至其它线程将处理完成，并回调通知此线程。那么类比来看，在沟通的时候，有些事情我如果只需要一个答案，且时效性没有要求很高的情况下，我没必要跟他打电话或者面对面，而是在企业微信上留一段信息，等到对方看到并回复之后，我再进行处理和下一步动作。这就是“异步”的沟通。除此之外，“解耦”、“抽象”、“实例化”、“接口”等概念及背后代表的一种思维方式确实在很多场景下有其价值。比如所谓的“中台能力”，其实就是把一些通用的、基础能力进行“抽象”，当哪个业务部门需要使用的时候调用“实例化”即可。

4. 产品经理除了逻辑和数据，还要懂文案和设计：优秀的产品经理本身就是一个感性和理性的综合体

往往工科出身的产品经理在逻辑、数据层面都是很好的，也知道沟通和协作的重要性。但经常忽视一个“软实力”，文案及审美。这个真的是在某些产品经理身上是一个非常严重的问题。文案倒不是指要写出多优美的文章，而是在标识、通知、海报、商业长文等不同使用场景、不同字数要求下，能否专业地表达，让用户能迅速明白你的意思，不会觉得别扭。

说白了，底子还是语文能力，但可以通过多模仿、多琢磨来达到效果。而设计这事儿，在原型方案及设计沟通方面，因为对设计的认知差异将会带来特别大的沟通差异，不专业的表达比如“你这个方案差点意思啊”，“这个图标太丑了”，“整个排版我不太喜欢”，只有情绪化、形容词化的表达，而专业的表达是“这两块文字之间的间距是否合适，看起来有点挤”，“这个按钮对于产品方案是非常重要的元素，能否在视觉上强化一下”。

二、习惯篇

习惯篇的大部分内容都是你说的对，但是我不能坚持做下去，所以持续的“自律”本身就是一种核心竞争力。

1. 不能忙于输出，忽视输入；需要持续学习，持续精进自己

大量的有效信息输入，才能有卓越的输出。因此，系统读书、竞品分析、用户调研等各种有效输入信息的方式都需要我们融入到日常工作中，我们才能有更高阶的输出能力。这种能力俗称“站在巨人的肩膀思考问题”，朴素但极度有用。

但往往我们沉迷于那些短时见效的技巧，而忽视了费时费力的积累。这也是我把“习惯篇”单独拿出来的原因，因为这些“习惯”即使你知道是对的，但大部分人因为心力有限或自控不足，导致无法做到这一点，从而没有办法成为一个优秀的产品经理。

2. 均衡输出是产品经理高效工作的关键

很多产品经理会炫耀，“我昨晚撸了一版原型，撸到3点”，从而显示自己在短时间出活能力很强。当然， 这本身是一种能力。但放到产品经理一周的工作，一个月的工作，一个季度的工作，一年的工作中，这只是一次不持久的峰值输出。而优秀的产品经理应该是能持续均衡地、高质量地持续输出，比如每天工作量都稳定在0.8，而不是今天特别鸡血做到1.2，第二天状态不好变成0.4。

之前我和新人小伙伴有这样一个节奏要求，“至少一个项目在开发中，一个项目在确定需求下的原型方案中，一个项目在前期的需求调研及讨论中”，这样有节奏地、持续稳定地内容输出慢慢也能会让设计、技术的节奏共振，大家就都能均衡输出，避免瞬时负载过大或者空转，因为后者一定会带来资源的浪费。

均衡输出对于产品经理来说，还有一个需要关注的重点工作是提前计划，因为产品经理是一个需要大量协作的工种，比如需求调研和业务部门沟通，方案设计在产品团队内部沟通，设计评审和设计沟通，需求评和研发沟通等等，一个项目做下来要开N多会议。高手和低手之间最大的差别就在提前计划和事先准备上，优秀的产品经理会结合对方的时间安排，尽量把协作方时间提前占上，避免临时约会由于和其他会议冲突导致无法安排上。

比如今天老板安排了一个项目，需要和业务部门调研，然后你突然想起今天和明天业务部门休息，导致只能约后天时间，这种因为时间节奏没踩好的情况下会让一些周期较长的项目晚一周到一个月上线是非常正常的事情，而且一般人还看不太出毛病，觉得每个环节都跟上了啊，怎么还有浪费。事实上，如果提前把时间节点更好地进行设计和规划一下，会让很多环节的衔接更加紧凑，从而节省时间。

3. 学会使用高效的沟通方式进行协作，并达成目标

产品经理要对低效的沟通保持敏感度。但有时候大家在忙碌过程中会失去对时间的感知，导致某一个会议已经明显偏题了，没人叫停，或者陷入不必要的争执，没有中止。

一般的沟通方式有IM群、IM点对点、电话、面对面讨论、会议、邮件等方式，要学会区分这些方式适用于哪些场景，比如IM群适用于时效性不太强的异步沟通；邮件适用于结论同步，而不适用于讨论，面对面讨论适合一些临时突发的紧急问题，把大家拉在一起迅速达成结论；会议适合相对较长的讲解和沟通，以及复杂问题的讨论。大家可以在实践中把握不同沟通方式的精髓，学会组合使用他们，为自己的沟通目标服务。

4. 发现问题到正确实践之间存在一个巨大的GAP：工作必须复盘，复盘必须落实

自己想清楚某一件事情，并且意识到自己在这方面存在问题，到自己完全能克服这个问题并且保证未来在处理类似的事情不会再犯同样的错误，我们需要意识到，这之间有巨大的落差，夸张一点，和左撇子掰成右撇子是一样的。

具体凶险点如下，第一是我们在复盘看待整个过程的时候，是否能不留情面地认知到自己当时在某些方面确实存在不足，这是违背人性的，一般人都会给自己找借口，找外部原因，这是阻碍发现问题的“拦路虎”，因为你要客观意识到一定有人在当时能比你做出更好的决策，而这样的复盘才是有意义的，找到自己真实的短板。第二个凶险点就是复盘结束不落实，意识到了问题，但是行动上还是之前的惯性，一般纠正错误动作是需要专门训练的，然后才能形成新的肌肉记忆。

三、协同篇

1. 资源限制是常态，而产品经理需要习惯这个常态，但依然保质、按时推进高优项目

资源限制是常态，无须抱怨研发资源不够，因为一旦资源充分到没有任何阻碍，那么要么产品经理人少了，要么研发资源多了，这都是公司的损耗。而资源限制能更好倒逼产品经理权衡项目之间的优先级，在有限的资源下找到高杠杆的项目。除此之外，好的产品经理会把资源视野放到更大范围，比如我们的中台部门、兄弟部门等，在共赢的情况下去推进自己的关键项目，也是在资源限制下的有效手段。

2. 多思考一步，多行动一步

多思考一步的好处是让事情的成功率变高，原因在于在协作过程中，一般思维是负责好自己边界内的事情就好，但事实上任何协作都会存在一些模糊地带，且有时候这些模糊地带还很关键，如果没有处理好会达不到预期结果。因此，任何项目的推进，希望大家都多思考一步，比如产品上线之后需要运营、客服等其他团队配合哪些动作。Take one more step，是锻炼大家思考深度和全面性的关键，只有主动多迈出这一步，才能让结果大概率地被命中，减少“黑天鹅”事件。

3. 各司其职比相互补位更重要

既然互联网公司造就了各个职位及相互协同，那么每个职位的第一要素是完成自己职位对自身的要求。有时候，有些产品小伙伴会被运营的各种问题或者研发的各种建议所“迷惑”，主动去做运营问题解答（目前我们一般是有值班QA团队负责跟进线上问题并定位）或者和研发讨论一些优先级并不太高的建议，那么导致自己职位需要完成的需求调研、原型设计等工作被挤压，然后你去和他argue的时候，他一脸委屈说，我也很忙的，每天要应付各种事情。

那么，关于这样的问题，第一是大团队层面要建立标准流程及动作，该谁负责就谁来解决，没必要好心去帮忙承担。第二是作为个体，要对这些非本职位的事情尽快牵线给对应负责人，认为不重要的的事情直接回绝，不纠缠 。 只有各司其职，协同才是最高效的，否则本来到了你环节该处理的事情，没有第一时间响应，反而去帮别人去做事情，自然团队的整体协作效率更为低下。有小伙伴可能会反驳，你看你这态度是不是太不积极了，非得给自己的事情划边界，不是一个好的合作态度嘛。这里有明显的偷换概念，合作本身是基于岗位对自身的要求协作，如果在本职工作做完的情况下你愿意帮助别人，那是很好的事情，但是一定是本职工作优先。

4. 平等参与一切协作，特别是和比自己高阶的人更要鼓起勇气

很多产品新人在和业务部门沟通需求的时候，如果遇到比较强势的合作团队，容易出现畏手畏脚的情况。主要原因是怕自己的思路错了，或者对方是很高阶的人（比如有些需求会面对运营管理层），不敢质疑，所以更多宁愿选择安全地跟随别人的想法和需要，不经思考直接复制。

在这种场景下做事会出现两个问题，一是失去自己的判断和决策力，二是从结果上可能还会出现偏差。既然出现了产品经理这个职位，他没有被运营合并，也没有和研发放在一起，自然是有其价值。产品经理的价值往往是站在第三方角度客观冷静地去看待过程中的人和事，从中去梳理流程，抽象业务。所以，这个时候基于长期沟通和调研形成的常识，是应该大胆地去主导一些方案设计的，不需要太亦步亦趋地配合业务，甚至有时候因为竞品的调研和对比，还能发现业务中当前模型的问题。因此，请大胆一点，和合作部门进行一场“势均力敌”的协作。

四、决策篇

1. 可做可不做的，坚决不做

如果要类比产品经理的职能的话，产品经理更像医生，而不是画家。优秀的医生在面对病人的病症时，一定是“如无必要，不用猛药”的逻辑去处理病症，产品经理也是一样。经常看到产品新人在方案设计上做得特别复杂，特别是在一些二八原则下的20%场景的处理，会加上很多小策略、小细节显示自己的完整逻辑及细心，但事实上优秀的产品经理会想办法用尽量简洁的方案去覆盖大部分场景，相对忽略那些低频、不重要的场景的体验，从而让整个方案便于用户理解，开发成本也能得到很好的控制。

要知道，按照互联网产研团队的常规配置比例 1：5，产品经理的杠杆是很强的，多设计一个新策略平均都需要5个研发来配合，所以一旦策略不靠谱，后果就是研发会对产品经理产生信任崩塌。所以，如无必要，坚决不加！

2. 工作中的大部分事情应该是通过条件反射来解决的

我们会遇到很多事情，糟糕的产品经理会把每件事当做一件新事来做，而优秀的产品经理会把这些事情进行归类，用解决这一类问题的历史经验来处理，类比健身来说就是“肌肉记忆”。如果发现是一个新的事情，无法通过历史经验解决，那么才会思考新方案。在这样的做事逻辑下，才能保证在限时条件下的高质量的、稳定的输出能力。把大部分事情通过条件反射来解决，少部分没处理过的事情费心思进行思考，而不是每件事情都投入相同的精力来处理。

3. 不追求每个细节都符合要求，但对关键细节不做丝毫妥协

糟糕的产品经理会为了上线在很多产品细节上进行妥协。优秀的产品经理也会妥协，但只在不关键的细节上，但凡在关键的、能对结果产生绝对影响的细节，即使有各种技术阻碍、上线时间压力都会死咬不放。因为他们知道，一旦妥协这个项目得不到预期的结果，纵然上线也是枉然的。换句话说，面对目标决策，而不是面对困难决策。困难不值得妥协，非目标相关的问题随便妥协。

4. 围绕有效目标出发，动作不变形

站在行业来看，我们都很在意日活跃用户这个指标。假设老板定下关注这个指标之后，我们是否需要努力做些促进日活跃用户的事情呢？关于这个问题很长一段时间是我的心魔，一方面希望达成这个在行业达成共识且老板十分在意的指标，另外一方面发现我们有些动作如果去做了，数据层面上是会提升的，但是不能给用户带去真正价值。比如引导用户签到兑换学分、加强push策略等，从短期来看数据一定会提升，但我们都知道一旦这么做了，就基本上把自己陷入KPI中，而忽视了客户的体验和APP的价值。因此，我们在决策上，要围绕有效目标出发，动作不变形。

五、项目篇

1. 运营系统在设计上应该先放再收，在没有逻辑问题或额外较大工程量下尽量满足业务复杂场景的需要

我们在设计运营系统上，经常会遇到业务部门五花八门的需求，比如以退款为例，可能你为了财务计算的方便和系统的简洁，希望提供一个建议金额的退款功能即可。但事实上，但当你调研需求的时候，你会听到希望可以仅退部分款但不退课、退款金额允许超过或者少于建议金额（预收款-确认课酬），退款可以设置哪些课节可以访问或者整个课程均不可访问等各种需求。而事实上，当一定的用户体量之下，以上几种情况都是合理的运营动作，都需要产品提供支撑。

因此，在规划运营系统时，建议出发点是尽量开放和支持的，避免过多限制导致在运营过程中的不灵活和不方便，从而无法被运营真正用起来。当然，灵活需要有一个度，如果灵活之下带来较大额外的技术开发或者逻辑问题，那么我们需要收敛一下，通过限制、隔离去控制需求复杂度。

灵活之下产品经理还需要警惕的是兜底问题，比如退款金额不能大于实付金额，避免底层的数据冲突。

2. 工程量较大的项目需要进一步拆解，把MVP或者当前急需的功能闭环拆出来先推上线

在规划优惠券功能时，我们最初规划了三种优惠券（课程优惠券、品类优惠券、平台优惠券），并认为未来一定都能用得上。但这个时候，研发反馈三种优惠券同时做工作量较大，因此我们重新评估之下，认为当前班级和品类优惠券优先级更高，因此可以把这一块单拆解出来先评审开发上线，确保项目可以整体提前被运营使用。而平台优惠券放到了二期或者更后面的开发周期里。

这在大型项目里是一个非常受用的思路，把一个初看无法切割的项目拆出真正的MVP。

3. 重大项目上线前需要知会客服，并和运营小伙伴规划上线后的运营方案，让产品能够有效触达目标用户

项目上线前后才是产品真正面向用户的关键时刻，需要为此做好充分准备。重大调整需要知会客服，方便客服在遇到用户询问时能第一时间回答。除此之外，需要和运营小伙伴规划上线后的运营方案，准备运营资源并进行合理推演，保证项目上线后也能按照预期有效触达目标用户。这背后依然是协同意识，一个项目的成败需要不同工种的充分协同。

4. 从投入产出比来看，部分项目考虑用第三方工具支持，不一定需要自主研发

前一阵子看到不少微信场景的功能需求，比如批量回复48小时内互动用户等，很多微信场景的功能，第三方工具已经做得很好了，如果没有和业务有强关联性导致必须自主研发，可以强烈建议或帮助运营小伙伴找到合适的第三方工具。该思路同样应用于其他需求的判断，不是所有需求都要自己来做。同样，在语音评测、敏感词智能过滤、视频人脸识别等一些强技术领域，目前都有不错的第三方公司开放了服务能力，那么这个时候适当使用第三方技术来达成自己的商业目标，从投入产出来说确实性价比更高。除非这项技术对于公司的未来有着非常重要的地位，那么值得做长期、持续的投入。

六、带人篇

1. 我说你听，我做你看，你说我听，你做我看

阿里经典的带人口诀，但很多老人带人的时候都忽略了其中的部分步骤，比如第二、第三步。这两步有啥重要的吗？第二步很重要，特别是一些复杂的任务，比如做一次技术评审，主持一次需求调研会，完成一份高质量产品PRD，这些事情都是新人没有经历过的，老人需要做出示范性演示之后，新人才可以进行学习和模仿。

第三步关注的问题是在沟通的时候，由于接收方能力不够，不一定完全理解leader的意思，因此在执行层面出现动作偏离。而第三步能通过反向沟通会让新人更加明确自己的执行要素，所以新人最好的素质就是不懂就问，利用大家认为你是新人小白阶段，大胆问出那些自己可能觉得肤浅的问题。因为一旦过了新人期，大家就会按照老人的标准来要求和审视了，那个时候再犯低级错误就更不值当了。之后才是第四步，观察新人的动作并纠错。

2. 老人做新事，新人做老事；新人要做重要的老事

千万不能让新人一来就做新事，失败率接近100%，特别是老人都不确定该怎么做的事情。新人应该做老事，比如竞品已经完成了或者老人把大致思路已经理完并且确定了，这样的项目适合新人上手。而把一些偏探索或者不确定的项目，安排老人来完成，利用他们丰富的历史经验避免掉一些坑。当然，面对新事，老人也不一定成功，只是成功率一定远高于新人。

除此之外，要培养的新人即使在实习期也要安排重要的事情，千万不要认为实习就安排一些边角事情就好，这其实非常不利于新人的成长，而一些重要的老事，在老人的指导下推上线，将会极大增强新人的自信心和工作积极性。

作者：刘雨（订阅号  小雨哥Rain），跟谁学产品负责人，目前主要负责跟谁学产品线的整体规划，在社交和教育领域有些研究。

本文由 @小雨哥 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议