从“自己干”到“带人干”，是每位产品经理成长路上的必经之路。本篇聚焦“野生产品经理”晋升为主管的关键阶段，拆解角色转变中的认知升级、能力重构与管理误区，为正在经历跃迁的你提供实战参考。

管理是本人一直想写又不想写的一块内容。想写是因为管理是产品经理成长的必经之路，当产品经理能力越强，能力覆盖的范围越大，就不可能有太多时间画原型、写文档，而是需要带着团队一起干，让整个团队发挥最大效用。本人不想写是因为，过往履历中本人并非正式的“管理经理”，而是小组长、负责人的这类角色，又因为管理时要接触更多形形色色的人，对上对下的态度都要控制的非常巧妙，对本人而言，实在是有点难度，并不觉得自己做得有多好。

然而，最近一次和同行的交流让我明白，应该尽早下定决心做“管理”，至少要做好“管理的准备”。

从企业的角度来说，肯定希望人才有管理能力，哪怕企业暂不需要。同样的工资，企业肯定更愿意愿意招一个能力更全面的人才，而一个有管理能力的人才，意味着可以适配未来企业的规模扩张需求。

工作近十年，在大中小企业供职过，深刻体会到上级管理好坏对团队员工能效的影响巨大，上级管理得当团队就像所向披靡攻城拔寨的精锐之师，工作难题都能迎刃而解，在公司各部门之间享有威望，上级管理不当团队则如一盘散沙，人才流失殆尽，团队遭人奚落。

思虑再三，还是要积极向上，本人已做好“管理的准备”。

以下是三段本人值得分享的管理经验。

产品小组长——下属人数：3人

缘起

本人在大业务部门（将近2000人）的系统平台室担任产品经理，科室里有10名产品经理和1名负责经理，10名产品经理中既有工作三年以上的，也有三年以下的初级产品，有在企业服务多年的老员工，也有一半左右刚入职的新人。而我是新人里面产品经验比较丰富的，很多新人都在三个月内被淘汰了，唯独我一直留下来。

大约入职快一年的时候，领导开始把一个新人“交给我”，其实也就是部门会议上口述了一句“那个新来的***工作你来带他”。

一开始的时候，我只把“带人”当做一种任务，将其视为跟产品工作不相关的任务，因此，在帮助新人完成入职流程、业务培训、告知工作基本要求后，我觉得这个任务就已经完成了。并没有意识到这是“领导对我的栽培”，更想不到需要用管理的思维去带人。当时，我经常对新来的同事表示嫌弃，觉得对方产品工作习惯不好，对方讲话太油腻不直接……总之，就是觉得人家很麻烦。

后来，被投诉了。新员工觉得我太严厉了——东西我只教一遍，对方再问我便埋怨他“这都不懂？”。领导也教育我：把新人分给你带，就表示“你们俩绑在一起了”，他工作做不好，也就代表你的工作没做好。

我逐渐意识到“带新人”的任务，一方面是领导对个人的器重，另一方面这跟我以往单打独斗完成工作的思维方式不一样了。于是，我开始刻意培养自己的“管人”的能力，开始反思怎样的上级受到下属的喜爱，去请教组内比较有经验的同事，还看一些管理的工具书，比如：《一分钟经理人》、《向上管理》。

why me

1、产品能力：我的产品工作能力已经完全能胜任部门的要求，可以独立负责一个产品的从0到1，而同期进来的新人还停留在系统功能模块的需求建设。

2、领导需要分而治之：对于一个10人的科室来说，经理直接管理10个人精力有点分不过来，比较好的方式将其中分为2-3个小组，经理平时只对2-3个小组长直接沟通、派活，小组内的工作就由小组长负责。当时虽然还有三个老员工，但他们其中有两个本来就在同一组，所以小组长就“轮”到了我。

3、人员流失：部门工作压力较大，新人流失换人频繁，同时部门老同事另谋高就，一年的时间我已成了科室“老四”。

工作内容

1、招聘：招初级产品经理，面试的时候主要考察产品基本功、思维意识、沟通表达能力；还有就是对接外包公司，大部分新人产品都通过外包人力招聘。

2、带教：一次性的带人工作有入职流程、PRD标准、熟悉业务；会多次带教的工作主要是需求方案、原型设计、文档标准，以及跨部门沟通、办事思维，一般也不会超过3次，如果反复带教还是不合格，会将其辞退。

3、评估：工作态度方面的评估，特别忌讳的点有我不会丢给上级、明天再试下、教了还是老样子，比较喜欢下属至少带一个方案来找上级沟通、干不完主动加班、一教就会；工作能力方面的评估，PRD质量、组内产品/技术/业务同事对其的评价、对岗位的适应情况、工作能力的进步。

下属的故事

有一位Z同事，是业务转的产品经理，招进来的时候说是有3年产品经验。Z年龄跟我差不多，我也是一般对待的带教他工作。

很快就发现Z的能力水平只能勉强及格初级产品经理，需求没想明白他会拖，或是交付一个有点差劲的需求方案。我们一般对新人会包容一两次的低级错误，并指导他改进，然后，再根据他后续的表现评估其是否“可造之才”。

Z很快就把两次机会用完了，其中有一次问题比较严重：Z设计一个新功能时，没有考虑老版本用户的兼容问题，关键是他没跟我沟通方案，非常自信的跳过了我，直接把需求甩给技术开发，最后需求上线，导致不更新的用户无法使用。当时我真的非常生气，脑子里闪过无数次“刀”了他的念头，后来跟科室经理沟通，考虑到部门实在缺人，便调整其工作内容，把最简单的需求分给他，并且所有需求提给开发之前都要跟我过一遍。

Z干了半年，最后主动提了离职，理由是要回老家了。

Z的工作一直是磕磕绊绊不稳当，受到的质疑和批评远多于认可，他觉得自己可能干不好产品经理的工作，至少在这家企业他的实力不够。同时，他过年期间相亲了个女友，因此便选择了回家乡城市找一份产品经理的工作。Z离职前跟我说的几句话让我至今难忘，他说：“……我的离职我不会怪你，是我自己的能力问题……你平时的要求比较严格，但你也教了我一些东西，我内心是感谢你的……”

那一刻，是我第一次作为小组长得到认可的时候。

产品运营负责人——下属人数：2人

缘起

所在的公司不大，百来号人，成立也有十年的时间了，但大部分运营工作还是依赖人工处理，就比如：库存。公司是销售ETC设备的，每个ETC都有设备序列号和卡号，以前运营就是靠Excel来处理的十几个上游厂商、五个仓库、近百个下游出货渠道的库存管理。不同时期不同的运营人员的Excel格式还不一致，几十万行数据盘点起来要头晕眼花。

我被委以从0到1搭建ETC的库存系统，目的就是希望通过系统工具为运营部门降本（减少库管人数）增效（提高库管工作效率）。

why me

1、运营负责人遭遇了管理信任危机，运营负责人请了长假，加之部门的管理有点乱，导致库存管理员纷纷离职，新招进来的库管也光速走人，我所在城市的仓库出现了停摆。公司需要有人站出来，我便响应，成为了库管总管，美其名曰库存产品运营负责人。

2、我是库存系统设计者，我最清楚系统功能，直接负责运营工作后，又让我最清楚业务痛点，有利于我设计出更符合业务的功能。

3、库管的运营工作不是很复杂，我作为外行也能快速理解，主要是入库、出库、盘库、售后等，并将相关的商品产品、数量、仓库等信息登记到库存系统，确保线上线下的数据一致，基本就是库管工作的所有内容了。

工作内容

1、培训：不仅是写培训手册，演示一遍系统功能，一定要手把手教会每一个库管，保证他们将系统运用于工作，因为一旦库管的运营工作卡住，公司的发货收货就会有问题，就会影响企业生意。

2、编制操作规范：操作规范是库管基于使用库存系统后，日常工作操作规范的文档，需要把一项工作的每一步的详细操作写清楚，让一名普通员工对着文档就可以开始干活。为保证库管严格按照操作规范工作，还要制定奖惩措施。

3、学习业务知识：作为库管运营负责人，除了保证每天进出库正常之外，还要对接上游供货商，还要处理售后退货，还要对接财务盘点库存资产。这些都是产品之外的内容，要对接很多人，恶补很多业务知识。

下属的故事

有一位库管小伙G，00后，小伙很壮，体重240+，之前在盒马生鲜干过一年库管，后来绩效制度变了赚不到钱，跳了出来。

小伙G平时看起来睡眼朦胧，因为他经常晚上熬夜泡妞打游戏，又因为他胖，第一印象并不被人看好。可小伙G实际很聪明，入职前他并没有怎么用过Excel，而vlookup、数据透视图那样的高级功能，小伙G一教就会。此外，在培训的时候，小伙G不像其他库管，只管学会操作，他能记住不同场景下使用不同功能的原因。可以说，小伙G的表现是让我喜出望外的，后来我把培训其他库管的工作交给他。

私下里聊天，会发现小伙G的心态跟当年的我是完全不一样的，他在任何人面前都很自然，不谄媚、很洒脱。跟领导开会他不知道说啥就沉默，跟我们熟点的同事出去吃饭可以侃侃而谈前女友背叛的故事，分享自己买了一台很划算的二手笔记本电脑，还给我们介绍靠谱的按摩技师。小伙干活很利索，商品进出库搬货他一个顶俩，干完了就回到工位颓一会儿，每天下班到点基本他也把活都干完了，放下公司的鼠标键盘，回到家拿起自己的键盘鼠标，继续泡妞打游戏到凌晨。

小伙G虽然挣得不多，不指望富贵，但也怨天尤人。他说：“每天把工作做完了，自己能养活自己已经很了不起了。如果我在上海混不下去了，也可以回老家靠家里关系再谋份工作，但现在还年轻，我还想在外面多玩两年。”

小伙G让我意识到，对工作，我们不用那么严肃，也不需要把全部的自己投入进去。有时候，我会希望社会上多一些这样的小伙子——完成工作，全情生活——这样的人多了，职场压力问题或许会有所改善。

项目经理——下属人数：2人（间接管理6人）

缘起

产品经理干项目经理的活可以说是天经地义，毕竟要是不把项目的人心拢齐，就算产品方案设计得再好，产品也无法落地。在大企业里会有专门负责项目管理的项目经理，但是在中小企业、互联网基因没那么强的企业，产品经理往往要兼任项目经理的职责。项目管理不深入业务和技术，比较容易被取代，这两年互联网行业下行，很多企业不会招项目经理，而是招一个会项目管理的产品经理。

H企业近几年一直走在“系统去自研”的战略路径上，因为H企业认为“自研系统”不如“外采系统”来的省钱、省事。本人就是在这么个背景下加入H企业，并在担任产品经理岗位期间做了大量项目经理的工作。

我的小组里有1个UI设计师和1个项目助理，但因为管着项目，其他小组的6个开发人员（2后端Java、2个前端、1个Android、1个iOS）的工作也由我分配、追踪、推进。

why me

1、我有PMP管理证书，在之前的工作中有实际的项目管理经验。当时的面试官是看中了我的项目管理背景才选中我的，进公司不久，就给我分配了一揽子项目管理的工作。

2、没人会管项目，也没人爱管项目。部门先后离职了两个项目经理，确实琐事太多了，技术人力又不够，而因为某些原因，业务部门的需求还无法回绝，项目经理什么事都要沾边，也意味着什么事都有可能背锅。

3、沟通能力比别人强些。此前技术直接与业务沟通，总是被业务提的需求吊打，或者跟业务因需求“不合理”吵起来。其实只要掌握一些沟通技巧，放低姿态、多倾听，把问题带回去分析，不当面拒绝业务，及时告知进度等，这些都是产品经理必备沟通技巧，是安身立命之本。

工作内容

1、项目管理软件。原先部门是用Excel表格记录开发人员的工时的，然后，H企业选择项目管理软件是禅道免费版。为此，我给部门做禅道使用的培训，教会大家将项目、需求、任务进行拆解，精确记录工时、项目进度。

2、版本迭代。建立双周发版的迭代机制。发版当天需进行上线方案的预演，发版时间设置在晚上业务量少的时间，相关的产品、测试、开发人员都会留守，直到生成验证通过。

3、建立沟通机制。杜绝业务部门“随口”提需求，所有需求通过需求单提交给产品经理，需求必须要有合理的背景、目标、价值。产品经理要把方案、原型设计完成后与业务部门同步，再提交开发。需求上线后，业务要反馈使用效果。

4、运维管理。建立权限申请、数据采集、系统支持的运维SOP，让业务部门知道什么事情找谁走什么流程。

下属的故事

有一位理工妹子S，来H企业三年了，一直都在做总监助理的工作，说直白点就是打杂，有时候派去商务接待，有时候处理业务投诉，有时候负责合同管理……与S打过几次交道后，发现她的脑子很灵光，思维逻辑胜过大部分开发同事，尤其是对接业务的工作，S从来不会把事情烂在自己手里，她能发挥个人主动性解决一些问题，不会的事情她会及时“捅”到上级。

S对助理的工作游刃有余，而彼时部门正是缺人之际，我便找到S交谈，表示她做助理屈才了，问她未来有没有想从事其他岗位，她说以后更倾向于做项目经理。于是，我便和总监沟通，把她调到我们组，担任项目助理。然后，我在日常工作中，会刻意多指导一些项目管理技巧，而不只是单纯给她派活。

S的优点是聪明、积极、乐观，项目管理的流程、机制，基本是教一遍就会了，80%的项目管理工作都可以交给她；S的缺点是文档能力一般，对复杂一点的项目事项耐性不足（这需要经历过比较多的破事才会有养成）。

后来因为某个破事，S遭到了牵连，含冤被罚，于是不久便离职了。S去新单位后，成了一名正式的项目经理。

我不认为S转型成为项目经理我有什么功劳，她在我问她职业规划之前就已经想过要当项目经理了。我只是想表达“在别人成长的路上，能助其一臂之力，是件很开心的事情”。

选用育留

我对管理的认知和实践都停留在非常浅的层面，我希望未来能在管理这块做得更好，最后分享一个很实用的管理框架——选用育留。

选：主要是招聘。要结合企业部门的情况（行业经验、加班、项目管理、领导喜好、企业文化等）挑选合适的候选人（产品思维、专业水平、技术能力、经验/潜力、综合素养等），管理者要通过面试技巧和提问完成对候选人的判断，面试通过率一般只有10%，为了招到合适的人选，需要做好持续面试的准备。

用：主要是分工、派活。分工既要尽量均衡各个组员的工作量，又要尽量根据团队成员的能力和特长，发挥其最大效能；派活时一定要说明工作目标和期望成果，不然员工很可能会交付一个“不咋地”的结果上来。PS：只会一股脑儿往下派活的领导，会得到下属员工的怨恨。

育：主要是培养。首先要营造一个相对包容、积极向上的团队文化，鼓励团队成员尝试新方法和技术，允许他们失败并从中学习，其次是要跟下属一起制定他们的目标KPI，如果能结合他们想做的事情则更好，这样如果目标达成了，下属会很有成就感，如果目标没达成，下属也能自觉反思而不是怪罪公司环境和领导。

留：淘汰/留用。淘汰员工需要一个比较明确的机制，需避免因为领导偏好、同事恩怨等心理因素导致人才流失，同时，一旦下属符合淘汰要求，则需尽快完成脱落。留用员工对于直属上级而言，一是创造互相信任、积极的团队氛围，二是适当为团队争取奖励和晋升机会，确保优秀的员工能够看到自己的发展前景，从而提高留任率。