编辑导语:作为一个典型的从一线产品经理成长起来的“组长”，作者的专业能力在这个成长过程中不断提升，也经历了很多辛酸的泪水。笔者将团队管理的实践经验分享给大家。希望这些总结和见解能帮助到很多像作者一样的成长中的初级管理者！

我是典型的从一线产品经理成长起来的“组长”。网上有很多解释团队管理的文章，大部分都是理论性的。我的分享比较实用，是一些现成的方法和工具。希望我的总结和感悟能帮助到很多和我一样成长中的初级管理者。

先说团队。

首先是组织架构层面。这个团队最初是一支纯粹的R&D团队，由一名R&D团队负责人和三名R&D团队组成。在我入团之前，这个团队运营了30个左右的小工具，这些小工具的用户数量有大有小，成熟度也不一样。

我是2018年12月加入集团的，我是这个团队的第一任产品经理，直属R&D领导。

2020年组织架构调整，独立出了一个产品组。2020年下半年，产品组组长和R&D组长都换了，产品组组长空缺席了一段时间。

从2020年12月开始，我暂时代理组长，新的R&D组长也来了。

2021年5月，R&D团队负责人变更，新的产品团队负责人被任命为R&D团队负责人。

其次，就人员比例而言，这一组中的R&D人员一直在40人左右。但是之前没有产品经理，产品经理也不是突然从0增加到10，而是从1 →2 →3，用了3年多的时间慢慢增加到10。另外，这个群体之前没有前端。从2021年下半年开始有自己的前端，一年后发展到4个前端。

综上所述，这个群体用了三年多的时间才达到各种角色比例平衡的状态。

从我入团的2018年底到2020年底，基本都是当兵的。这期间，我的专业能力迅速成长，也充满了辛酸的泪水。后面我会单独开一篇文章分享，下面的分享和总结就从我这个临时组长开始。

一、接收团队后的三座大山

不管是管理者空下来还是内部成长，接手一个新的团队后，基本需要解决以下三个问题:

定义团队价值和目标招聘合适的人、定义这些人的分工、建立各种协作机制做好年度、季度、月度工作规划、借助管理手段确保绩效落地

如果你是空出身的管理者，会有一个额外的过程，那就是“识人→知人→用人→建立信任和权威”。

就产品组而言，我没有这个流程，因为我是第一个产品经理，是最熟悉产品和所有一线工作的同事，之前已经建立了一些专业的权威。但是和我一起工作的R&D团队负责人和他手下的团队负责人都换了，所以和他们有一个磨合和建立信任的过程。

2021年上半年合作的R&D团队负责人是其他组的老R&D人，之前就认识，所以整个建立信任的过程相当快。从合作到产生一些成果，我们只需要一个月的时间。这个在2021 空倒下的领袖就不一样了。对他(我现在领导)来说，他当时有这样一个建立信任和权威的过程。在我开始在产品/团队管理方面有一些实际行动之前，我花了大约三个月的时间与他磨合。

下面说说我解决三座大山的过程和感受。

1. 定义团队价值和目标

整个2020年，团队比较乱，直接领导和间接领导换了两次，2020年也有人不认可自己在做什么。另外，这个团队以前是一个人操作一个小工具，组与组之间几乎没有接触。因此，这个团队的成员，无论是产品还是R&D，普遍感到困惑，他们普遍不知道这个部门的目标和价值观，不太赞同他们所做的事情。基本上，他们可以使用“一

我接任R&D团队负责人后，恰逢集团2021年工作计划。我同意R&D团队领导的观点，我们需要关注这30个工具。我们根据工具的成熟度、使用范围以及工具本身的差异化价值，对所有工具的后续开发进行了分类。

把全集团内有一定成熟度和差异化价值的工具拿出来作为后续重点建设的工具；那些没有差异化价值的工具，无论应用面大小，都是离线的，允许用户迁移到集团的其他同类工具；我们尽量不扩展那些有差异化价值但构造不成熟的工具的使用，按需构建。经过这样一波操作，我们需要重点关注的工具其实只有五个。经过这件事，我们也建立了一个价值准则，“我们只做全集团有差异化价值的工具，一定要做好，绝不重复造轮子”。

后来这个价值准则和我们对这些工具的做法得到了大家的普遍认可，于是我们都有了第一个共同目标——推广不太可能产生大价值的线下工具。

但是，我们选择了下一个关键构造的工具，并不意味着我们已经明确了团队的目标和价值观。那五种工具之间几乎没有关联，人们仍然不知道我们为什么存在。说实话，那时候我还没有定义目标和价值观的能力。我没有那种感觉。之前当兵的时候，刚造完工具，推广使用，降本增效。我从来没有站在公司的角度考虑过我们在公司解决了什么问题。后来我了解了价值的一些基本维度——运营成本、运营效率、销售收入、客户体验。

当时去混沌学院上课，学习一些最基本的定义问题和思考问题的逻辑，看案例，对比自己的作品。当时针对这五个工具做了几件具体的事情:

站在公司的视角、用户的视角上看这些工具解决的到底是怎样的一个问题，产生的价值属于什么维度。去市场里找同类产品，搞清楚自己做的这个工具到底是不是市场化的一个产品，市场上是怎么量化这个工具的价值的。把这些工具当B端产品看，定义清楚这些工具的客户、用户、合作伙伴。理想情况下这个工具的产品架构、能力清单。

最后，我们从几个角度总结了我们工具的价值:

公司视角下，提高特定类型需求的研发效率、同时控制系统安全风险。业务视角下，提升客户导入效率、提升一线运营效率。产品视角下，为公司贡献基础技术组件，未来有商业化的可能。

接下来，年度目标的定义自然是基于这些数值，比如“减少客户导入周期”、“构建系统安全防护能力”、“商业项目应用及收益”。

一般来说，这个阶段不需要太多的管理技能，主要是考验管理者的“认知能力”，表现在几个方面:

多角度看待问题的能力：从部门、公司、行业、市场等不同层次不同视角来看待问题。定义关键问题的能力：我们到底要解决的是谁的什么问题，如果你定义的问题对于任何一个角色来说都不是问题，那这个问题或许确实是个问题，但没有价值。把价值转化为目标的能力：当定义了一个有价值的问题后，那么用什么手段来解决这个问题呢，我们要建一个怎样的产品能力或运营体系，达到怎样的一个目标，怎么衡量目标是否达到了。2. 招聘、分工、协作

招人的时候，并不是说有了人员就可以随便招一个人，人越多越好。我从以下维度评估是否招聘新人:

公司是不是有编制和预算？有的话才能考虑加人，否则只能替换现有人。目前的总工作量是不是让团队严重超载了，除去那些可做可不做的工作外，团队是否需要高强度加班才能完成全年目标？加人是不是能提升团队产能？如果工作量严重超载，并不是一定要加人进来，可以考虑降低目标；如果不能降低目标，也要看加人是不是能提升产能，如果可以提升则可以考虑加人；如果不能提升产能，就要考虑去提升现有人的能力；是不是找到了新的价值点，有一个很大的问题需要专门的人来解决？这个人来了之后跟其他人的分工是不是能划的清楚？如果是有新问题要解决，一般考虑新招人，但如果不能把相关的活都拆出来给到这个人，则要考虑调整现有人的职能分工，否则新人来了会施展不开拳脚，还会降低其他人的生产力。团队中是不是有人出问题了，明显不能胜任工作？这个时候是招一个新的人替换现有人，不需要新的编制。同时也还是要从不同的维度考察这个人，即便真的要淘汰，也要做到管理留痕。

如果决定招聘一个新人，首先要明确自己想要什么样的人，给这个人贴上标签，这样才能招聘。常见的通用标签有:

要一个经验丰富的还是一个初级选手？取决于你需要怎样的人才梯队。要一个男同学还是女同学？不同性别会给团队带来不一样的力量补充。要一个基础能力扎实（学习能力等）还是要一个领域经验丰富的？通常在市场上很难找到基础能力又扎实，又刚好做过这个工作的同学。

当时我的团队很年轻，我其实是任职时间最长的产品经理，所以需要一些有经验的人。队伍中女性众多，需要男性力量的平衡；我个人比较看重那些基础能力比较扎实的，然后来了之后会学习相关领域的知识。关键是我在市场上找不到做过类似产品的人。

在线上，首先淘汰了少数在愿望和价值观上不符合预期的人，换上努力的应届毕业生。同时，我们换掉了不符合预期的人，然后增加了两个有经验的人。在淘汰人的过程中，都给了下家。这些人的能力不是很差，但是不适合这个团队。折腾下来，用了一年多的时间，组建了一个相对健康的团队。

良好的分工是提高团队生产力和个人成就感的最基本条件。如果职能重合，不仅浪费资源，还会挫伤个人积极性，因为这份工作的绩效是有争议的，一半的人获奖，没有人愿意放在一边。另一方面，团队中的分工也不是一成不变的，需要根据当时的目标和人力进行动态调整。和我自己的团队一样，每个季度都会对分工职能进行调整。当我进行自己的职能分工时，我遵循以下原则:

每个人必须有一整块的活，这块活略微超出这个人的现有能力，可以独立考核，可以支撑这个人成长、出业绩、晋升。每个人的分工对他的能力要求跟这个人的特点尽量匹配，具体说来这个活是要求抽象能力、架构能力，还是要求执行能力、需求分析能力，还是要求沟通协调能力 等等。人人都能互相备份，包括大家能备份我，不存在一个活说只有一个人能干，所以至少一年会有一次大的职能调整，我每个季度侧重跟进的产品也不一样。

说实话，做分工不是一件简单的工作。要求你熟悉产品架构，对实现目标的途径有清晰的认识。只有团队成员不被你的分工拖累，才能在你的分工设计下相互配合，达到1+1=2而不是1+1 < 2，实际上是1+1

由于我基本上做过所有的产品，非常熟悉，所以分工对我来说不算太费力，但中间也出现过问题。

招聘和分工之后，再说协作。按照整个产品从需求调研到上线运营的流程，协同可以分为几大块，包括产品内部协同、产研协同、产研测协同、产品运营协同。正常情况下，遵循R&D过程是可以的，但总有一些场景不在正常的R&D过程中，比如“当客户反馈在线问题时，我们如何快速解决在线问题并及时修复缺陷”，比如“如果迭代日历中给出的测试时间太紧怎么办”。

这些问题没有标准的工作流程，每个团队都有自己的风格，所以只能让关键人物参与讨论可行的协作流程和职能分工，监督执行，反复优化这个流程。

但是在协作过程中需要注意的一点是，不能偏袒产品团队，不要有屁股，要客观看待问题，判断责任，否则会失去公信力。一个单一的R&D不会承认你是一个人，然后所有的协作和协调都将变得困难。

3. 工作规划和落地执行

这就需要丧失专业能力和一些基本的管理方法。在工作规划方面，你要能设定明确的年度目标，并分解到季度。在执行方面，就是一般的项目管理能力和戴明周期。这部分比较手工。刚开始的时候，我制定了所有的计划，包括目标和落地计划，大家都会去执行，但是这种工作并不能调动大家的积极性。好像这是我的目标，而不是团队成员自己的。后来逐渐形成了产品规划体系，分为两部分:

年度产品规划:

每年春节前领导和几个组长定好年度OKR，并与各级领导对齐。这些Object成为本年度我自身的考核指标，也是部门的KPI。这里面的一部分KeyResult变为组员的Object，组员要将自身的Object拆解为下一级的KeyResult，形成组员的考核指标。这些拆解会形成一篇总的年度OKR的文档，在做季度总结和规划时我会翻出来看一看，年度总结的时候也要对照这个文档来。

季度产品规划:

每季度的倒数第二周，我会根据年度规划+当时的情况，定好下一个的OKR，并与领导对齐，在周会上与组员同步。每季度的倒数第一周，组员要拆自己的OKR，要写上达成KR所需的Action，并跟我来对齐。最终形成产品组的季度OKR文档，注意这个文档里只放OKR，不是工作清单，现实中每个人除了OKR（主要任务）外还会有很多杂活要干。这个周我还要做本季度的工作总结每季度的第一周，我们单独开规划同步会，跟研发同步上季度产品建设和运营的情况，并讲解下季度的规划和工作思路，同时这一周组员还需要将工作拆解开来形成工作排期表，排期表上不仅包括OKR中的任务，还包括其他细碎的任务，需要写清楚每项工作的起止时间。每季度的第二周，微调OKR和工作排期表。当周给隔级领导汇报上季度工作总结和本季度公祖规划。

季度规划前后一个月很累。接下来每周都会根据工作进度检查工作进度，辅导团队成员达成目标。最难的部分是OKR的公式。在制定OKR时，经常会出现几个问题:

OKR写得高大上，既不定性也不定量，不可衡量O和KR之间不是因果关系，达成KR并不会达成OKR个数太多，外加一堆Action，根本做不完，实质是没找到关键KR

在制定OKR时，我经常问我的团队成员几个灵魂问题:

现在的KR描述地太泛了，你这个词指的是什么？你要做的是A还是B还是C？你觉得拿到这些KR，O就能达成了吗？这个指标的统计口径是什么，现在已经有数了吗？怎么才能统计出来？怎么考核你这个KR达成没有，拿到什么结果我该给你打A？

关于我对OKR的理解还有一点，就是整个部门的O可以是一个有向的O，是一个虚的O，然后用KR来衡量O是否实现。而且不同的阶段可以用不同的指标从不同的维度来衡量O，所以KR一定是一些非常具体的阶段性结果。

然后就是一些日常管理工作，比如团队成员的积极性建设，团队成员的能力培养，资源协调，解决合作问题等等。我看过这本参考书《10人以下小团队管理手册》来加速这个。只要我在认知上知道自己应该做什么，在思想上和身体上都不会觉得懒惰，也不会有太差的运气遇到很棒的选手。日常管理可能比较累，但是并不难。

二、通过机制让团队逐渐变好

解决了以上三座大山，一个团队几乎就可以运转起来，为组织持续创造价值，但并不代表这个团队就是一个积极向上，蒸蒸日上的团队。

事实上，整个2021年我都很累。一个是一切都要从0到1，一个是我要做一些管理，要做一线战士，所以每天都很累。好像这个组合没有我也未必能成就业绩(其实地球没有谁也照样转)，我总是忐忑不安。

现在回想起来，虽然我当时明确了团队成员之间的职能分工，但我自己和团队成员之间的职能界限并不清晰。不知道该做什么，不该做什么，该做什么。

1. 分享型组会，团队成员的凝聚场

2021年底，我们在产品内部开了一个复检会，思考为什么会有这么多的合作问题，这么多的矛盾隐藏了很久，才在这一年爆发出来。最后我们得出结论，我们产品组的会议太少，无法让上级、下级、平等人及时意识到一些问题。我相信大家看到这个都会笑的。一般他们觉得会议太多，但是我们组的人都同意会议太少。

其实这是我个人风格的直接结果。我个人不太喜欢开会。最后大部分会议的效率都很低，漫无目的的讨论就是浪费生命。所以，我基本上从不开会。如果有什么事，直接打电话给我。如果我能解决，我绝不会逃避墨迹。最直接的结果就是我们的产品组基本上一整年都没有开过小组会。我通过周报或者私信了解大家的工作进展，日常问题没有合适的渠道让团队成员反馈给我。

但是我不想开干群会。传统的小组会议是大家汇报本周工作进展，然后领导讲问题。我也在网上看了很多开群会的方法。当我以一个普通员工的身份去感受整个团拜会的时候，感觉充满了来自上级的压力，很不开心。久而久之，这样的小组会议就会变成“一人独大”——只有领导在那里发言，小组成员都不愿意发言。小组会议气氛沉闷，成员普遍感觉与自己无关，这也是事实上大多数小组会议的现状。

当时我面临一个核心问题——团队成员专业能力不足导致业绩和产品效果不理想。此前设立了季度学习制度，每个季度一个学习主题，月底轮流分享学习成果。这个制度最后执行的很差，人们普遍没有花额外的时间去学习和总结。因此，我把“专业能力提升”和“横向信息沟通”作为小组会议的两个核心目标，并逐步形成了以下小组会议模式:

组会之前，每个人不用花时间去准备长篇大论的汇报材料的，轻松参会就行，每个人轮流做会议纪要。组会上大家不用汇报工作进度，工作进度在组会之后以简报的形式发在群里。组会的第一趴是我来分享一些横向的信息，比如说「最近公司的营收很大，咱们要多多支持创收的需求」，比如说「618到了，研发要备战，大家可用的研发资源实际上是比上个季度要少的，可以侧重做一些运营工作」。这个期间大家其实会简单的讨论一下这些大的环境的变化对于自身工作的影响、如何调整工作节奏和优先级，整体持续大概10分钟。组会的第二趴是大家提问，主要是需要我知道的重要的外部信息、需要我支持的地方、需要我帮忙解决的问题，比如说「跟业务的目标对不齐，需要我去找业务负责人对齐目标」，比如说「有个内部客户期望购买我们的产品，有什么要注意的」。一部分问题我会当场解答，另一部分问题会留给我的待办，期间也会有简单的讨论，整个过程持续约15分钟。组会的第三趴是个人工作分享，事先我会指定一两个同学分享近期的工作成果，比如说「产品的市场调研报告」，比如说「产品商业化计划」，一般是讲10分钟，然后大家点评、讨论，这个过程中，我会顺势指定一下下一次的分享人。整体持续30分钟左右。组会之后，会议纪要发给所有的产品和研发，要求研发侧按照会纪要中的内容配合我们工作。

这种形式的小组会议，对我个人来说，有三个好处:

通过工作分享大家共同点评的方式减轻了我作为监督者的工作量自然而然地给到分享者适度的工作压力，并且是定期给到压力自然而然让每个人都能相互了解彼此的工作，一个目标的实现不再只是某个人的事，大家群策群力

对于团队成员来说，还有三个好处:

不用光听我一个人说，自在~每周顺便学点别的领域知识，省事~同时可以过一把点评者的瘾，开心~

整个团拜会的气氛比较好，经常有人笑出声来。目前的问题是我话太多。后来我定了一个规矩，只要我连续说话超过三分钟，任何人都可以打断我。之后我会继续改进小组会议的模式，尽量让大家多说话，互相促进，我只是扮演服务大家的角色。

事实上，这种小组会议模式要求管理者了解每件事情的方式和进展，这样他们就可以直接谈论问题，而不是在小组会议上汇报工作的细节。所以这种模式应该只适用于10~20人的小团队，管理者直线管理所有人。如果人多了，管理者几乎不可能知道所有事情的进展。他们必须依靠下一级的组长来管理整个团队。

2. 一周一个戴明循环，即循环团队也循环自己

一年在春天到来，一周在星期一到来，星期一是我一周中最累的一天。既然大家都没有在小组会上汇报工作的进展，我肯定要再找个机会把我的工作思路和大家对齐，这样才能保证一周后我们能得到一些确定的结果。于是每周一，我会对照大家整个季度的工作安排，逐项检查工作进度，然后找到相应的人，让他告诉我想法，风险，需要沟通的人，需要协调的部门，然后纠正他。逐一查看大家的想法和进度后，我会规划自己这周要做的事情，形成待办清单。老板找我，有急事，或者有即兴会议，这一天基本都是从早忙到晚，疲惫不堪。

周二周四相对轻松，30%的时间用来支持团队成员的工作，70%可以做自己的事情，思考未来要解决的关键问题和问题的解决方案，做产品规划，做横向项目，了解行业咨询等等。周五是各种会议(PRD评审会，小组会)+周报写作。

周六是学习+放松。一般周六上午会看混沌学院的直播课，周日花两个小时补充一些知识。比如新项目有知识盲区，老板推荐的好书，文案或者心理学等产品经理的基本功。剩下的时间用来放松——打球、唱歌、吃饭、看戏、尝试新食谱。

比起之前的状态，还是好多了。之前很焦虑，工作没有计划和节奏，每天在每个细节上折腾自己。我一发现问题就会找我的团队成员谈话，这让我的团队成员不清楚问题的轻重缓急，没有节奏感。此外，我不可避免地要在周六和周日加班完成大大小小的事情。现在周一是比较忙的一天，后面就比较轻松了，可以腾出时间做一些有挑战性的事情。大家好，我很好。大家都知道，我有一本《九阴神功》练习册，每周占一页。该页面有三个部分:

第一部分是我这一周的待办事项清单，一般会有七八条，再多我也干不完。这个待办清单由两部分组成，一部分是上周组会留给我的待办，一部分是我自己规划这周要做的事情。第二部分是产品组会上我要同步的信息，这些信息是在我这一周工作过程中记下来的，一般会有三四条。第三部分是我要在产研组会上同步的信息，也是一周工作过程中总结出来的，一般涉及到协作问题、工作方向和策略。

这个星期实际上是一个小戴明循环PDCA。周一是计划，周二到周四是Do，周五的小组会议是检查，周会上的待办事项实际上是改进措施法案。这个戴明循环逐渐转向后，一个人的状态会逐渐从疲惫变为忙碌但不累，团队成员会比以前更投入工作。但是，这种工作方法也要求你一周一周地做好每一件事，不能拖延，保持一贯的适度工作强度。我也有情绪状态不好的时候。一般来说，那一周我自己做的事情比较少。球队需要我做的事情，我绝对不会拖延，不会拖累球队。

有时候周一到周日会失眠。这种情况下，我一般会去客厅看书催眠，随机看一些书。总的来说，阅读的进度是一个月一本书，强度不是很大，但重要的是坚持。自读的一个特点就是转化率极高。虽然读的书不多，但大部分都可以写下来，可以用，有时还可以讲给别人听。

3. 多定标准少发表意见，最大化释放团队创造力

指导队员的日常工作是不可避免的。一开始别人问我他的输出有没有问题，我一般会指出很多具体的问题，告诉他们更好的办法是什么。但是，久而久之，我会发现团队成员越来越依赖你，什么事情都等着你做决定。甚至当方案最终出错时，团队成员也会说:“这是你说要做的。”那一刻，我感到无助。

后来觉得自己有点不对劲，就去看书搞清楚哪里不对劲。有一天看了一个短视频，突然开窍了。别问我为什么，有时候两个看似不相关的问题却能相互启发。俗话说，授人以鱼不如授人以渔。之前我只是告诉别人正确的做法，就是“鱼”。什么是“钓鱼”？想了很久，我突然明白了“钓”是衡量作品好坏的标准。我的做法在这个尺度下是好的，但在这个尺度下可能还有其他好的做法。所以如果我能总结出衡量标准，那么只要团队成员的产出在这个标准之上，就是好的产出。

后来我开始不断总结不同产出的衡量标准:比如PRD。什么样的珠三角才是好的珠三角？我来总结一下PRD的构成，注意事项，优秀的PRD案例，然后给我看一下PRD。我先问一下是否符合这个标准，再给你看复合后具体的业务问题。具体来说，比如你做一张海报，它有宣传目的，有明确的目标人群，有明确的你想传达的信息点，你找10个人看海报就能得到这些点，而且海报有转化用户的外链，那么这张海报就是好海报。

总结这些标准的过程是痛苦的，有时候你会发现自己的专业水平也是短板，一下子分不清什么是好。所以这一整套逼着我进一步提升自己的专业能力。

经过一段时间的“授人以鱼”，很明显大家的投入程度都上来了，对自己的要求也更高了，会做出一些意想不到的惊喜。其实你再想想，这确实是事实。之前大家真的很迷茫，也不知道我做的事情为什么好，相当于被束缚。当他们知道了标准，我不再限制达成目标的方式，我的创作能量被激发出来。他们自然会找到最适合自己的前进方向，整个群体走向良性循环。

三、总结

最后说说我对管理的总体感受。这个领域我应该还是刚刚入门，但是网上说的“没有100个人我不知道怎么做管理”，我还是个小弟。

在这些委托给初级管理者的职能中，“定义团队价值观和目标”是最难的一项，它要求管理者具备“与众不同”的“认知能力”，而这种能力并不是很快就能达到的。真的需要经验、眼光和思考，他们只能靠自己积累，有玄学；其他诸如落地目标、团队建设等职能，我个人觉得只要真心带好团队，不偷懒练好最基本的管理方法，半年之内就能完成。

当然，如果是几千人的团队，管理者会有更多的稳定团队、传承文化等抽象职能，会有一些玄学，但这是中高层管理者考虑过的，这是后话。

下面推荐几本好书和课程，希望对我这样的“组长”有所帮助。如果还有其他好书，请推荐给我。

10人以下小团队管理手册： 这本书的内容篇幅并不多，1天就可读完，里面都是最基本的管理理论，日常管理过程中几乎全会用上，个人认为这个就是初级管理者的工具书，必读且需常常温习，市面上很多初级管理者培训营的培训内容也不会超越这本书，非常实用。场域领导力-关系视角下的高绩效团队打造： 这本书的篇幅也是1天就可读完，但就有点玄学，是从 性格和心理上来讲解不同类型的组员对于团队的影响，但也算是管理者的基本知识了，组建团队的时候一定是需要知道自己团队缺什么样的人。极简工作法：对常用的工作方法做了个介绍，例如「清单工作法」「番茄工作法」，所有职场人都应该掌握这些方法，混沌学园 – 人力资源工程是CEO的第一工程：这个课可以帮助建立最基本的人力资源的概念，我个人非常受用，反复听了几遍。混沌学园里面的课程都是讲认知、哲学、创新的，专为企业用户打造，每周都更新课程，学费1000多一年，并不便宜，内容偏玄学，建议高级产品经理和管理者看。个人最喜欢的是其中认知思维和理论与商业案例结合的课程，可以很直观的感受到认知理论是如何应用于实际工作的。

本文由@斌哲原创发布。每个人都是产品经理。未经许可，禁止复制。

来自Unsplash的图像，基于CC0协议。