一句话总结
Staff PM的真正权力不在于头衔，而在于当你开口时，四个部门的负责人愿意放下手头的事来听你说——这种影响力是积累的，不是任命的。
在Google、Meta、Stripe这些公司，Staff PM没有审批权，没有预算控制权，甚至没有直接下属。但他们能让一个涉及法律、财务、产品、工程的复杂项目在三个月内上线，而一个仅有title的PM用六个月也搞不定。
这中间的差距，不是个人能力的差距，是影响力构建方式的差距。大多数Staff PM甚至没有意识到，他们从Senior PM升上来的那一天，手里握着的权力反而变小了——因为Senior PM还能靠"这是我的项目"来推动事情，而Staff PM必须证明"这不是我的事，是我们共同的问题"。
适合谁看
这篇文章不是给刚入职的PM看的。当你还在回答"这个功能怎么做"和"这个需求优先级是什么"这些问题时，影响力是副产品，不是你的核心课题。
这篇文章的目标读者是已经在管理复杂项目的PM——你可能带着三到五个人做一个小产品，或者你是某个大产品线的核心推动者。你感觉自己的角色开始变了：以前你只要搞定自己团队就行，现在你发现真正卡项目进度的不是你的团队做不出来，而是别的团队不配合。你开始频繁遇到这种情况：你的项目需要Design团队的优先级调整，但Design Director说他们有两个更重要的项目；
你想让Eng提前两周给一个技术原型，但Eng Manager说他们的sprint已经排满了。你隐约意识到，光靠"这是公司战略"这个理由已经不够了，你需要一种新的能力。
具体来说，如果你符合以下任何一个条件，这篇文章就是为你写的：你正在向Staff PM的title冲刺，或者你已经升到Staff PM但发现事情变难了；你负责的项目需要四个以上的跨部门团队配合，但你没有直接的行政权力命令他们；你已经经历过至少一次"项目delay是因为别的团队没跟上"的挫败感；你想知道为什么有些PM说话别人听，有些PM说话别人当耳边风。
如果你是Individual Contributor的PM（IC track），这篇文章尤其重要，因为你没有管理岗位带来的天然权威，你的影响力必须纯靠个人信用来构建。
核心内容
为什么你升到Staff PM后反而变难了
你从Senior PM升到Staff PM的那天，HR发了一封邮件恭喜你，title前面多了"Staff"两个字。然后你发现了一件奇怪的事：以前你能推动的事情，现在推动起来反而更难了。
这不是你的错觉。这是有结构性原因的。
Senior PM的运作模式是这样的：你负责一个产品或功能，你有明确的所有权。当你说"这个功能要在Q3上线"时，团队知道这是你的目标，你的老板也支持这个目标。这种" ownership + sponsorship"的组合给了你一种隐性的权力——不是行政权力，但足够让事情往前跑。
Staff PM的情况变了。你可能同时负责三到五个项目，这些项目涉及不同的产品和不同的团队。你没有"这个产品是我的"这种天然 ownership了。你对任何一个团队的优先级都没有决定权。你对任何一个项目的roadmap都没有最终话语权。但公司对你的期望是：你要推动那些没有人能单独推动的复杂项目。
这里有一个关键洞察：Senior PM的推动力来自于"这是我的事"，Staff PM的推动力必须来自于"这是我们共同的问题"。
这不是一句正确的废话。这两种模式对协作方式的要求是根本不同的。
当你认为"这是我的事"时，你天然站在项目的中心，你需要别人配合你，你的沟通模式是"我需要你帮我做X"。这种模式在只有一个核心团队时是高效的。但当涉及四个以上的跨部门团队时，这种模式会让你变成一个到处求人办事的角色，而求人办事是有极限的——别人可以帮你一次两次，第三次就会说"我真的很想帮你，但我们团队真的有别的priority"。
当你认为"这是我们共同的问题"时，你的沟通模式变成了"我们一起面对这个挑战，你觉得怎么解决最好"。这种模式的核心差异不是礼貌用语的变化，而是你把解决问题的ownership分担出去了。
一个真实的例子。2019年Google Cloud有一个涉及支付、风控、法律三个团队的企业级功能上线项目。
项目本身的ownership在支付团队，但支付PM发现要让这个功能在Q2上线，他需要风控团队在两周内给出新的风险评估模型，需要法律团队重新审核用户协议中的三条条款。支付PM的第一反应是："我需要风控团队的sprint里插入这个任务，我需要法律团队尽快排上这个review。"
他用了一个月的时间分别跟两个团队的负责人沟通，每次都是带着"我的项目需要你们帮忙"的框架。结果是：风控团队说他们正在做另一个紧急项目，这个评估最快也要六周；法律团队说他们的review queue已经排到了Q3。
然后支付团队的Staff PM介入了。她做的第一件事不是去跟那两个团队继续沟通需求细节，而是问了支付PM一个问题："这个功能延迟上线，对风控团队有什么损失？对法律团队有什么损失？"
答案是：对风控团队来说，这个功能如果能提前上线，他们的风险模型可以在真实环境中得到验证，这对他们的年度OKR有帮助。对法律团队来说，这个功能涉及的用户协议条款修改，是他们一直在推动但没人响应的事情——因为没有产品需要这个修改。
这就是关键。不是"你需要帮我做什么"，而是"这件事做成之后对你有什么好处"。
Staff PM介入后的做法是：分别跟两个团队的负责人开了一个会，会上她没有提任何需求。她只问了一个问题："你们团队这个季度最重要的目标是什么？有没有什么是你们想做但一直缺一个产品合作机会的？"
这个问题的答案，让她重新设计了整个项目的协作框架。她把"支付团队需要风控团队的评估"重新定义成了"风控团队需要真实产品环境来验证他们的新模型，支付功能正好提供了这个环境"。她把"法律团队需要审核条款"重新定义成了"法律团队推动了两个季度的条款更新，终于有产品需要落地了"。
最后的结果是：风控团队主动把这个评估排进了sprint，因为这是他们的机会不是别人的任务；法律团队甚至派了一个senior counsel来跟进这个项目，因为这是他们这个季度唯一能落地的项目。
这个案例的教训不是"要善于发现共同利益"这种正确的废话。教训是：当你用"我需要你帮我"的框架去推动跨部门协作时，你在把自己变成一个request发起方，而request是可以被拒绝的。当你用"我们共同面对一个问题"的框架时，你在把对方变成问题owner，而问题owner是舍不得让自己的问题不被解决的。
影响力不是从天上掉下来的——它是一套系统的建设工程
很多Staff PM以为影响力是"做多了自然就有了"。他们相信只要项目做得好，别人自然会认可你的价值。这在某种程度上是对的，但这个进程太慢了，而且你很容易陷入一种困境：你的项目需要影响力才能推动，但你没有影响力因为你没有做出足够多有影响力的项目。
这是鸡生蛋蛋生鸡的问题。解决这个问题的办法是：把影响力当作一个独立的建设目标来做，而不是当作项目成功的副产品。
在Google和Meta，我观察过大量Staff PM的影响力构建方式，成功的案例都有几个共同特征。
第一，你在加入项目的第一天就要建立跨部门的信任存款，而不是在需要帮忙的那天才去认识别人。
一个在Stripe工作的Staff PM告诉我，他每次加入一个新项目时，前两周什么都不做，只做一件事：跟所有相关团队的成员各聊三十分钟。这些聊天不聊项目，不聊需求，只聊三件事：对方团队这个季度最重要的目标是什么？对方个人在这个团队最有成就感的事情是什么？对方在过去协作中遇到过什么问题？
这些信息听起来没什么用。但当你正式进入项目推进阶段时，这些信息变成了你的 superpower。当你知道Eng团队的tech lead最有成就感的事情是搭建可扩展的系统架构时，你不会在项目kickoff会议上说"我们需要快速搭一个MVP"，你会说"我们需要搭建一个能支撑未来三个产品的架构，这样你们后续不用重做"——同一件事，不同的框架，说服力完全不同。
当你知道Design团队的某个senior designer最困扰的问题是她的设计方案总是被后期需求变更推翻时，你不会在项目中期突然增加一个新需求，你会提前跟她同步可能的变化让她做可适应的设计——她会因为你理解她的痛点而愿意在关键时刻帮你一把。
这不是。这是在你不需要别人帮忙的时候先去建立关系，这样当你需要帮忙的时候不是请求是召回。
第二，你要让自己成为信息中枢，但不是以PM的身份，而是以"最理解问题全貌的人"的身份。
在一个涉及多个部门的复杂项目中，最大的摩擦往往不是"谁不想干活"，而是"每个人只知道自己团队的信息，不知道别人的信息"。Sales团队不知道Eng团队的技术约束，Eng团队不知道Product团队的战略考量，Product团队不知道Sales团队对客户承诺的细节。
Staff PM的核心价值不是做需求管理，不是排优先级，不是写PRD。Staff PM的核心价值是成为唯一一个理解所有维度信息的人，并且能够把这些信息用别人能理解的方式传递出去。
这要求你做大量的信息整合工作。具体来说，你需要建立一套跨部门的信息同步机制。不是那种每周一次的status update meeting——那种会议通常只会让每个人都觉得自己团队的进度最重要，其他人的进度是噪音。
有效的跨部门信息同步需要满足三个条件：只同步影响其他团队决策的信息，不同步纯内部进度；同步的信息带有上下文和影响分析，不是"我们做了X"而是"我们做了X，这对Y团队的影响是Z"；同步的频率和渠道根据信息的紧急程度来决定，紧急的走Slack channel，重要的走同步会议，不紧急但需要留档的走文档。
一个具体做法是：每个跨部门项目都有一个living document，这个文档不是项目计划书——项目计划书是给管理层看的。这个文档是给协作团队看的，它的结构是"当前项目状态 + 接下来两周需要其他团队配合的事项 + 已识别的跨团队依赖 + 每个依赖的风险等级"。这个文档每周更新一次，发布在所有相关团队都能访问的地方。
关键是：这个文档的维护者是你，但内容来源是每个团队。 你要做的不是自己写每个团队的进度，而是建立一种机制让每个团队愿意主动更新自己的部分。当你能做到这一点时，你不需要每次自己去催进度，因为团队知道如果不更新文档，别人就会看到他们这部分是空的。
第三，你要学会在关键时刻做"桥梁"，而不是做"裁判"。
跨部门协作中最容易出现的角色错位是：PM把自己当作裁判——"你们两边的方案我都听了，我觉得A方案更好，所以我们就做A"。这种做法在短期内可能有效，但长期来看你会失去一边的信任。
更有效的做法是成为桥梁：帮助两边理解对方的约束和目标，然后让他们自己找到解决方案。
一个具体场景：Eng团队说"这个功能的技术方案需要八周"，Product团队说"客户承诺的是六周"。典型的PM做法是两边压一压，最后定一个七周。
更好的做法是分别跟Eng和Product各开一个会，先彻底理解Eng的技术约束到底是什么——是八周是因为技术难度，还是因为团队排期，还是因为需要等另一个依赖？再彻底理解Product的六周承诺到底是什么——是客户合同上写的，还是sales为了赢单随口说的，还是真的miss不起的？
当你有了这两边的完整上下文，你就可以做一个更有质量的判断。或者更好的结果是：你发现其实不需要八周，Eng团队可以做一个简化版本先用六周上线，完整版本在第二阶段做。或者你发现六周的承诺其实可以协商，客户那边有空间。
关键在于：你不是在两边做和事佬，你是在帮两边看到他们之前没看到的信息。 当你能做到这一点时，Eng团队会信任你因为你没有随便答应Product的timeline，Product团队会信任你因为你没有随便接受Eng的拒绝。
什么时候该用影响力，什么时候该找老板
Staff PM最容易犯的一个错误是：过度依赖个人影响力，试图用"沟通"来解决所有问题。另一个极端是：遇到任何阻力就去找老板施压。
这两种方式都有问题。
用影响力解决一切的问题在于：有些事情确实不是影响力能解决的。比如，两个团队的资源冲突本质上是因为公司层面的优先级排序，这种事情不是靠你跟两个团队负责人关系好就能解决的。比如，一个团队拒绝配合的原因是他们的老板给他们设了不同的OKR，这种情况下你影响力再大也大不过OKR。
找老板施压的问题在于：每一次你找老板帮你推动项目，都是在消耗你老板的信用。当你频繁找老板来"解决"跨部门问题时，你在传递一个信号——"我搞不定，需要你帮我搞定"。这会影响你下一次升职的讨论，也会影响你在其他PM中的信誉。
那什么时候该用影响力，什么时候该找老板？
一个清晰的判断标准是：如果这个问题是因为信息不对称或协作机制不清晰导致的，用影响力解决。如果这个问题是因为资源冲突或优先级冲突导致的，找老板或者找能够做优先级决策的人。
具体来说，用影响力解决的场景包括：两个团队对彼此的工作内容或进度有误解——这种情况通过信息同步和桥梁沟通可以解决。一个团队不知道另一个团队的约束条件是什么——这种情况通过帮助两边理解对方的上下文可以解决。协作流程上的摩擦——比如审批流程太长、沟通渠道不清晰——这种情况通过优化流程和建立机制可以解决。
需要找老板或上级决策者解决的场景包括：两个团队的资源分配冲突——比如Eng团队只有两个人力，无法同时支持你的项目和另一个项目，这种情况下你需要有人来做优先级排序。一个团队拒绝配合的原因是更高层给他们设了不同的方向——这种情况你找那个团队的负责人是没有用的，需要找能改变那个方向的人。
项目涉及的风险超出了你的权限范围——比如合规风险、法律风险、财务风险，这种情况下你需要上升到能审批这些风险的人。
一个实用的做法是：当你需要找老板时，不要带着问题去找老板，带着解决方案去找老板。 不是"这个项目卡住了，需要你帮我跟Eng团队说一下"，而是"这个项目需要Eng团队的更多资源，目前的优先级冲突是X和Y，我建议的解决方案是A，理由是B，请您确认是否可以按这个方向推进，如果可以请帮忙跟Eng的director沟通一下"。
后者比前者多花五分钟，但效果完全不同。前者让你变成一个问题报告者，后者让你成为一个问题解决者——而且你老板也能从你的建议中学习到你思考问题的方式。
处理跨部门冲突的真实场景训练
你读了很多关于"如何做跨部门协作"的文章，听了很多"要以双赢为目标"的道理。但当你真的坐在一个会议室里，Design负责人和Eng负责人当面吵起来了，你说的话没有任何人听的时候，这些道理毫无帮助。
因为真正的跨部门冲突不是在"双赢"这个层面展开的。真正的冲突是：每个人都觉得自己是对的，而且每个人确实都有合理的理由。
这里有几个真实的冲突场景和应对方式。
场景一：你组织了一个项目kickoff会议，Eng lead和Design lead在会议上就一个功能的实现方式产生了分歧。Eng lead说"这个设计在技术上不可行，我们需要简化"，Design lead说"这个设计是用户研究的结论，不能简化"。两边都有道理。现在会议室里所有人都在等你表态。
大多数PM在这种场合会做一个错误的尝试：居中调解。"我觉得两边都有道理，我们能不能找一个中间方案？" 这种话在这种情况下毫无作用，因为中间方案往往意味着两边都对自己的核心诉求做了妥协，而妥协是世界上最难达成的事情。
更好的做法是：先把冲突从"方案层面"拉到"目标层面"。 你需要问一个问题："我们所有人的目标是一致的——做一个用户需要的功能，在技术可行的范围内做到最好。现在我们分歧的点是设计和技术之间的权衡。
请Eng团队先告诉我们，哪些部分是完全不可行的，哪些部分是有挑战但可以尝试的。请Design团队告诉我们，哪些设计元素是用户体验的核心，必须保留的，哪些是可以根据技术约束调整的。"
这个问法的关键在于：你不是在让两边妥协，你是在让两边先把不可商量的边界划出来。 当边界清楚了，解决方案通常就自然浮现了——因为真正不可商量的东西通常没那么多，大部分"绝对不行"只是因为沟通不充分。
场景二：你已经跟一个团队沟通了三次，他们每次都答应配合但每次都delay。你已经失去了耐心，你想在下次沟通中"更强势一点"。
这是一个陷阱。当你"强势"时，你实际上是在用权力来弥补影响力的不足。但你没有权力，所以你的强势只会让你看起来像一个在虚张声势的人。更糟糕的是，这会损害你之前积累的关系资本。
更好的做法是：先诊断为什么delay。 每次承诺了但没做到，背后的原因可能完全不同。有可能是因为他们团队内部有更优先的事项——这种情况不是沟通方式能解决的，需要上升到优先级层面。有可能是因为他们之前答应得太快了，没有真正评估过可行性——这种情况你需要帮助他们做更准确的评估。有可能是因为他们在等你的某个信息而你忘了给——这种情况是你的问题。
一个具体的诊断方法是：在下一次沟通中，不要问"进度怎么样了"，而是问"上次我们约定的那个事情，在执行过程中遇到什么问题了？" 如果他们能说出具体的问题，说明他们在认真做，只是遇到了障碍。如果他们说不出来具体问题，只是说"比较忙"，那说明优先级本身就有问题。
场景三：你在一个跨部门项目中发现了严重的风险——某个团队的工作质量可能会影响整个产品的成功，但你不是那个团队的负责人，你没有权力要求他们改进。
这种情况在Google的复杂产品中非常常见。比如你发现另一个PM负责的某个功能在用户体验上存在严重问题，可能会影响用户对整个产品的评价，但你不能直接告诉那个PM"你的设计不行"。
处理这种情况的关键是：不要在公开场合质疑另一个团队的工作质量，要通过"用户反馈"或者"数据"来表达关切。
具体做法是：收集相关的用户反馈数据或者产品数据，带着这些数据去找那个团队的PM或负责人，不是说"你的设计有问题"，而是说"我在分析用户反馈时发现了一个趋势，这个趋势可能跟某个功能的设计有关，我想跟你讨论一下有没有什么可以改进的"。
这种方式的好处是：你不是在质疑他们的能力，你是在帮助他们改进。你提供的不是意见，是数据。而数据是客观的。
准备清单
如果你想系统性地提升跨部门协作能力，以下是可以直接执行的具体行动：
第一，建立一份你的"跨部门关系地图"。列出所有与你当前项目相关的团队和关键个人。对于每个人，记录你了解到的三个信息：他们团队这个季度的OKR是什么，他们个人在这个项目中最大的动力是什么，过去协作中出现过什么问题。这份地图不需要给任何人看，它是你自己的工具。
第二，设计一个适合你项目的跨部门信息同步机制。这个机制不需要复杂，只需要满足三个条件：同步的是影响决策的信息，不是进度汇报；每个相关团队都能从这个机制中获得对他们有帮助的信息；信息的更新是可持续的，不会变成额外的负担。在你的PM面试手册里应该有类似的跨团队协作框架，可以参考一下里面的checklist。
第三，在下一次跨部门会议中，尝试把讨论从"方案层面"提升到"目标层面"。当出现分歧时，不要急于调和方案，而是先问"我们各自最想达成的目标是什么"和"哪些是不可妥协的，哪些是可以调整的"。记录这次尝试的效果，看看是否比之前的直接调和更有效。
第四，建立一个"影响力存款"习惯。每周花三十分钟与一个跨团队的同事进行非工作内容的交流。不是汇报进度，不是请求帮忙，而是纯粹的关系建设。这种交流在短期内看不到回报，但在你需要帮助的时候会发挥巨大的作用。
第五，明确区分"信息不对称问题"和"优先级冲突问题"。当你遇到跨部门阻力时，先问自己：这个问题是两边信息不充分导致的，还是两边的优先级本身就冲突的？用不同的方法处理不同类型的问题。
第六，培养自己在会议中的"翻译"能力。当Eng团队说"这个技术风险太高"时，不要直接传给Product团队说"Eng说不行"。你需要先理解Eng团队说的"风险高"具体是什么意思，然后把这个信息翻译成Product团队能理解的语言："Eng团队评估后认为这个方案在时间上有两个主要风险点，第一是X，第二是Y，如果我们要降低这些风险，可以考虑A或B方案"。
第七，在下一次你需要上级支持时，带上你的解决方案而不是只带问题。练习用"问题 + 原因分析 + 建议方案 + 需要上级确认的事项"的格式来组织你的请求。
常见错误
错误一：把"影响力"等同于"当老好人"。
BAD版本：你在跨部门会议上永远不发表有立场的意见，你总是说"我觉得两边都有道理"，你害怕得罪任何人也害怕做任何决定。结果是没有一个人尊重你的意见，因为你在他们眼里不是一个有价值的协作伙伴，你只是一个会议组织者。
GOOD版本：你有自己的判断，并且你在充分了解各方观点的基础上，清晰地表达你的立场。但你表达立场的方式是"基于我了解到的信息，我的建议是X，理由是Y"，而不是"你必须这样做"。当你表达立场后，如果有人提出你有没考虑到的因素，你愿意重新评估你的判断。
关键区别：有影响力的人不是不说"No"的人，是说"No"但还能让人愿意继续合作的人。
错误二：在跨部门项目中过度保护自己团队的利益。
BAD版本：你负责的项目需要其他团队的支持，但你总是先确保自己团队的资源和优先级不受影响。当出现资源冲突时，你的第一反应是"那不能动我们团队的资源"。结果其他团队很快就会发现跟你合作意味着他们总是要做出牺牲，他们就不再愿意跟你合作了。
GOOD版本：你清楚地知道自己团队的目标和约束，但你同样清楚每个合作团队的目标和约束。当你发现资源冲突时，你的第一个问题不是"谁让步"，而是"有没有办法让两边都达成目标"。你愿意在自己团队的舒适区之外寻找解决方案。
关键区别：当你愿意为合作团队考虑时，他们才会愿意为你考虑。
错误三：把"跨部门协作"当成"跨部门沟通"。
BAD版本：你以为跨部门协作的问题只是沟通不够，于是你组织更多的会议，写更多的文档，发送更多的状态更新。但问题并没有解决，因为问题的根源不是信息没传达到，而是利益冲突没解决优先级没排开。
GOOD版本：你意识到跨部门协作的核心不是"让他们知道我们在做什么"，而是"让他们愿意跟我们一起做"。这需要你理解每个团队的动力来源，需要你在项目设计中为他们的目标创造空间，需要你在关键时刻为他们提供支持。
关键区别：沟通是必要条件，但不是充分条件。协作的核心是利益的整合，不是信息的传递。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
问题一：Staff PM的薪资到底在什么范围？如果我用影响力而不是权力来推动工作，薪资会受到负面影响吗？
在硅谷，Staff PM的薪资结构通常是base salary加上RSU（限制性股票）和bonus。Base salary的范围大约在$180K到$250K之间，具体取决于公司规模和地区。RSU的年化价值通常在$100K到$400K之间，按四年 vesting。
Bonus的target通常是base的10%到25%，具体取决于公司。总体包（total compensation）通常在$300K到$700K这个范围。
用影响力推动工作不会影响你的薪资。相反，在Google和Meta这些公司，跨部门协作能力是Staff PM评估中的核心维度之一。
你的performance review中会有一项专门评估你"cross-functional impact"——也就是你在多大程度上推动了不是你自己团队的项目。在某些情况下，推动跨部门项目的成功对你升职的帮助可能大于你自己产品线的成功，因为公司需要能够打破组织壁垒的人。
问题二：如果我试了所有影响力方法，对方团队还是不配合怎么办？
这种情况一定会发生。你需要接受的一个事实是：不是所有跨部门协作问题都能靠影响力解决。 当对方的团队真的面临更重要的优先级冲突时，当他们的老板给他们设了完全不同的方向时，当资源确实不够时，影响力是无力的。
在这种情况下，你需要做的是两件事。第一，准确诊断问题的性质。如果真的是优先级冲突而不是沟通问题，那就不要在影响力层面继续浪费时间，直接去找能做优先级决策的人。第二，管理预期。如果这个问题暂时解决不了，你需要让你的stakeholder知道这个项目的风险在哪里，而不是假装一切都在控制之中。
一个常见的错误是：PM害怕承认"我推动不了"因为这显得自己能力不够。但事实上，准确判断一个问题的可解决性本身就是Senior和Staff级别PM的核心能力区别。Senior PM会尝试所有方法，Staff PM会快速判断哪些方法值得尝试。
问题三：我刚升到Staff PM，发现以前跟我合作很好的团队现在不太配合了，是不是因为我变成了Staff PM所以他们嫉妒了？
这不太可能是真正的原因。更可能的解释是：你现在的角色要求你推动的项目跟以前不一样了。
当你还是Senior PM时，你可能主要在管理自己团队的工作，跨部门协作是辅助性的。现在作为Staff PM，你可能同时涉及三到五个跨部门项目，你需要别的团队配合的地方更多了，但不是每个团队都有capacity来配合你。
另一个可能的原因是：以前你跟某个团队的合作是基于个人关系，他们帮你是因为喜欢你这个人。现在你需要他们配合的规模和频率超出了个人关系能支撑的范围，你需要建立更系统化的协作机制。
这种情况下，不是他们不配合了，是你需要升级你的协作方式——从"靠个人关系"升级到"靠机制和共同利益"。这不是你变了，是你的角色要求你掌握新的技能。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。