一、概述
最终，赋能产品团队的核心在于赋予团队解决难题的任务，并给予他们自主解决问题的空间。
赋能产品团队*：对结果负责，并拥有较大决策自主权来发现和交付解决方案的产品团队。
但是，我们该如何决定哪些问题应该由他们来解决呢？
回答这个问题正是产品战略的核心所在。
值得注意的是，我遇到的大多数产品组织甚至都没有产品战略。
他们手头不乏正在推进的功能和项目，而且所做的一切都有其理由，但正如你将看到的，他们并没有产品战略。
如果你还没看过这段精彩的 《南方公园》短片关于“内裤生意”的，我建议你暂停一下，花一分钟看看（如果你是在上班时观看，可能要注意音量不要太大）。
说真的，这正是我在走访的许多公司中所看到的情况。他们拥有的产品团队更准确地说是功能团队，他们整天埋头苦干，不断推出功能，却很少更接近他们期望的结果。
功能团队*：按预先指定的功能或项目执行开发任务的团队，通常对结果缺乏完整责任。
这导致了两件事：第一，存在大量令人沮丧的浪费努力（主要归因于他们对产品路线图的依赖）；第二，他们没有将足够的集中智力投入到最重要的事情上，以实现公司所需的结果。
你可能会好奇，为什么这么多公司没有一套好的产品策略。我自己也常常思考这个问题。
“不是计算失误，糟糕的战略是对制定良好战略所需艰苦工作的主动回避。选择回避的一个常见原因是选择带来的痛苦或难度。当领导者不愿或无法在相互竞争的价值观和各方之间做出选择时，糟糕的战略便是其后果。”
—— 理查德·鲁梅尔特在《好战略，坏战略》 中所述
那么，产品战略到底是什么，为什么它如此重要？
“战略”一词含义模糊，因为它存在于几乎所有事物的各个层面——商业战略、融资战略、增长战略、销售战略、发现战略、交付战略、市场进入战略……
无论目标是什么，你的战略就是你计划如何实现该目标的方式。战略不涵盖细节；那些是我们用来达成目标的战术。战略是整体方法，以及选择该方法背后的理由。
尽管战略有多种形式，但我在此关注的是产品战略。简而言之，它意味着：我们如何在满足公司需求的同时，将产品愿景变为现实？
我遇到的许多公司都有目标（例如收入翻倍），也有产品路线图（即战术），却找不到任何产品战略。
就产品团队而言，产品战略帮助我们决定要解决哪些问题；产品探索帮助我们找出能实际解决问题的战术；而产品交付则构建出解决方案，以便将其推向市场。
那么，为什么产品战略如此困难？
因为它要求大多数公司难以做到的四个方面：
第一，愿意在真正重要的事情上做出艰难的选择；
第二，涉及生成、识别并利用洞察；
第三，涉及将洞察转化为行动；
第四，涉及积极的管理，而非诉诸微观管理。
选择意味着专注。决定你真正需要做的少数几件事，因此也就决定了所有你不会去做的事。
但我无法告诉你，我去过多少家公司，他们在某面墙上或电子表格上列着整整50个主要目标或计划。
每个产品团队都向我抱怨，他们真的没有时间专注于自己团队的产品工作，因为他们的义务已经覆盖了超过100％的可用时间，更不用说那些“维持运营”的工作和处理技术债务了。
此外，这50个主要目标或举措中许多都是真正的难题，仅靠十几个不同产品团队各自分得一小块时间且缺乏明确归属，几乎不可能产生任何实质性影响。
因此，专注源于认识到并非我们做的每件事都同等重要或具有影响力，我们必须选择哪些目标对业务真正至关重要。
产品战略始于专注，进而依赖于洞察。
而洞察则源于研究与思考。
这些见解源于对数据的分析以及从客户身上学到的东西。这些见解可能涉及我们的业务动态、我们的能力、新兴赋能技术、竞争格局、市场演变趋势，或是我们的客户。
一旦我们确定了哪些事项至关重要（聚焦），并研究了全局以识别杠杆和机遇（即洞察），那么我们就需要将这些洞察转化为行动。
在一家重视赋能型产品团队的公司里，这意味着要决定哪些目标应由哪些产品团队来推进，并为这些团队提供必要的战略背景，以便他们能够解决我们需要他们解决的问题。
但我们的工作并未就此结束，因为产品战略从来都不是一成不变的。
当产品团队追求各自目标时，有些团队进展更快，有些需要帮助或遭遇重大障碍，有些发现需要与其他团队协作，有些意识到自身缺乏关键能力，或者遇到其他上百种可能的情况。
妥善管理这一过程需要聪明且投入的领导者践行服务型领导力。
在我职业生涯的大部分时间里，我一直在研究产品战略。经过数十年的实践，我认为自己在这方面还算擅长。我最喜欢的活动仍然是解决难题（产品探索），但如果要我选择，我会说产品战略是更重要的技能，当然也更具挑战性。
二、聚焦
我指的不只是决定做什么和不做什么，而是挑选那少数几件真正能产生影响的事情。
这是另一个类似“公司是否关心客户”的话题；在我遇到的几乎每家公司中，领导者们都已经相信自己相当擅长聚焦。
但通常，公司的领导者在这个话题上需要一次现实检验。
他们认为至关重要、且必须在本季度或本年度完成的事情数量，往往多出了一个数量级——我是字面意义上的。不是2—3件真正重要的事，而是至少有20—30件。
平心而论，我理解为什么这些关键领导者相信自己相当擅长聚焦。
他们已经开了无数次会议，在会上同意了许多他们真正想做、但今年却无法完成的事情。所以，从他们的角度来看，他们认为自己已经知道什么叫说“不”和做出牺牲。
这在很大程度上反映了领导者觉得需要下很多赌注，而非选择最佳或最有影响力的赌注；害怕错过；需要应对每一个竞争对手；应对每一笔流失的交易；满足每一个客户需求；这些都是可以理解的反应。
但在这种情况下，他们需要干预，并重新定义“专注”在产品组织中的真正含义。根据我的经验，许多组织都需要这种干预。
让我们谈谈一个不懂得专注于真正重要事物的组织是什么样子的。
大约五年前，潘多拉的一位高管分享了“潘多拉优先级排序流程”，该流程发表在同样出色的《First Round Review》上。这位高管分享了公司决定做什么和构建什么的流程。
我未曾与他们共事，但读到这篇文章时，我立刻意识到产品战略的完全缺失，尤其是缺乏聚焦。这并非糟糕的产品战略，而是根本没有产品战略。
再加上他们依赖功能团队，且毫无真正产品管理的迹象，显然这会导致大量功能被构建，但成果或创新却寥寥无几，公司也难免走向衰落。
而在接下来的几年里，我们亲眼目睹了这一切。一只在 2011 年以每股 16 美元 IPO 的股票持续下跌，直到股价约 8 美元时，他们终于被 “解脱了痛苦”。
多年来，我一直将这篇文章作为“如何不做好产品”的典型案例来分享。
许多公司都采用某种类似的、由利益相关者驱动的路线图流程，本质上是在试图找到一种“公平”的方式，将工程能力分配给不同的业务利益相关者。
这又是一个明显的例子，说明功能团队努力服务于业务，而产品团队则致力于以对业务有利的方式服务于客户。
尽管这种做法很常见，但它尤其明显地体现了产品战略的缺失、真正重点的缺失，以及更广泛意义上的产品领导力的缺失。
公平地说，这种工作方式很少是产品负责人所期望的；相反，通常是 CEO 和利益相关者希望这样运作，而产品负责人被迫充当协调者的角色。
无论原因是什么，这都是一个公司在排序优先级，但并未真正聚焦的例子。
用这种方法很容易产生工作，但难以产生成果：
“产生活动并不是问题；事实上这很容易。正因为容易，真正的问题反而更难解决。问题在于完成正确的事情——那些重要的事情，那些会产生影响的事情，那些公司为了确保成功而努力实现的事情。”
—— 斯蒂芬·邦盖
这是领导力中最重要的教训之一，成功的领导者都以某种方式领悟到了这一点。
尽管我在职业生涯早期就学到了这一点，但这个教训深深烙印在我脑海中，我发现这一原则在科技业务的诸多方面都适用。
当我刚成为一名软件工程师，在惠普应用研究实验室工作时，我刚刚大学毕业，这意味着我对理论有所了解，但对实践知之甚少。
当时我们的工作方式采用了一种如今被称为“结对编程”的做法，我与一位经验丰富得多的工程师搭档，我们“一起”编写软件。我之所以用引号，是因为实际上大部分代码都是他写的，而我主要是观察和提问。
我们当时处理的是相当底层的系统软件，这类产品在当时——如今某些类型的产品依然如此——性能至关重要。系统和应用程序常常慢到无法使用，因此“性能优化”是我们持续承担的责任之一。
好消息是，我们检查的几乎任何代码区域，都不难想到重构以提升性能的方法。我不断指出可以改进的地方，但他始终只说“可以改，但没必要。”
最后他说：“好了，该处理性能问题了。”接着他打开了性能分析工具，让我们能测量软件的性能表现，并清晰地看到时间究竟消耗在哪里。
他指出，虽然几乎整个代码库都能优化，但其中绝大部分努力根本无关紧要。事实上，这些优化甚至不足以让用户感知到。
然而，有少数几个地方几乎消耗了所有时间，如果能改进这几个关键区域，就能产生实质性的影响——这才是我们需要聚焦的方向。
他指出，在大多数组织中，他们告诉每个人“性能很重要”，因此每个团队都在性能上投入一些精力，但绝大多数这些工作毫无意义，而在少数几个本可以产生影响的领域，却得不到足够的集中关注。
这是一个关于专注力力量的非常具体的例子，但更普遍地说，这正是我在许多公司中看到的关于专注和产品策略的情况。
如果不“选择你的战场”并专注于少数真正关键的问题，那么大部分正在进行的工作都不会产生影响力，而对于真正重要的优先事项，又缺乏足够的关注来真正推动进展。
专注于少数真正关键的问题也有一个非常实际的原因。
大多数科技产品从业者都了解在制品（WIP）限制的概念。在使用看板等交付流程的产品团队中，这一概念尤为常见。
其核心思想是，如果我们限制产品团队在任何时候同时处理的任务数量，就能完成更多工作（吞吐量）。对大多数团队而言，这个数量通常为数个事项。如果没有这些限制，工作就会在瓶颈处堆积，导致我们不断切换上下文，最终交付的成果反而更少。
这不是一个难以理解的概念，大多数产品团队每天都在见证这一现象。
然而，尽管这一概念在产品团队层面确实有用，但在更广泛的产品组织层面，它变得至关重要。
当一个组织同时有20个、30个甚至50个“高优先级目标、计划或项目”在推进时，我们面临同样的问题，只是情况严重得多。
首先，如果你有哪怕20个高优先级的计划，这很可能会压垮你的组织，每个团队都会疲于应对这些计划，而不是专注于服务客户——或者追求他们团队自身的使命。
其次，对于组织而言，尤其是领导层，每项高优先级的任务或举措都伴随着实际成本，涉及管理时间、决策、监控与追踪、人员配置等诸多方面，而同样的在制品限制概念在此同样适用。
归根结底，如果一个组织一次只专注于少数几项关键工作，就能完成更多重要任务。
因此，我们必须依据真正重要的事项来挑选战场，并限制同时着手解决重大问题的数量。
每一个优秀的产品策略都始于这一核心关注点：
“好的战略通过将精力和资源集中在一个或极少数关键目标上，从而实现一系列有利结果。”
—— 理查德·鲁梅尔特
如果领导者不愿或无法做出这些选择，那么产品战略从一开始就注定失败。
洞察
你可能听过这样的故事：关于客户行为的洞见如何推动早期 Netflix 实现快速增长与盈利；关于新用户引导的洞见如何促使早期 Facebook 爆发式增长；或是关于客户试用体验的洞见，如何让 Slack 和 Salesforce.com 像野火般在企业间迅速蔓延。
在本文中，我们将探讨这些关键洞见从何而来，以及如何确保你能发现它们——因为它们可能隐藏在你收集的成千上万其他数据点之中。
在我们深入探讨之前，有几件事需要先说明清楚：
首先，如果你期望找到某种按部就班的操作手册或框架来得出这些洞察和扎实的产品战略，那我直接告诉你，这里没有，省得你浪费时间。
正如我在整个系列中一直强调的，产品战略需要真正的努力和思考：
“好的战略……并非源自某种‘战略管理’工具、矩阵、图表、三角形或填空式方案。相反，一位有才华的领导者会识别出局势中的一两个关键问题——那些能成倍提升努力效果的支点——然后集中力量与资源于其上。”
—— 理查德·鲁梅尔特
其次，在我所知的每一个案例中，包括我自己能够为产品战略做出贡献的每一次经历，这种从未在缺乏真正准备的情况下发生。
你或许会在淋浴时灵光一现，但那只是在你花费数小时研究数据、客户、赋能技术和行业之后才可能发生。
战略背景中的信息——公司目标、公司记分卡／仪表盘以及产品愿景——是任何重大洞察的基础。因此，研究这些内容都是作为产品领导者“做好功课”的一部分。
第三，重要的是要认识到这些洞察可能来自任何人或任何地方。你可能会在 Stratechery 的行业分析、与销售人员的交谈、一项新的赋能技术、客户看似随意的评论或一篇学术论文中找到灵感。
但如果没有这种准备，即使洞察就在眼前，你也可能无法识别。我在这里想强调的是，你永远不知道什么能帮助你串联起线索，所以请始终保持警觉和开放的心态。
尽管如此，有四个持续有效且极具价值的洞察来源，优秀的产品领导者会将大部分清醒时间用于思考这些方面：
1、定量洞察
在我们所做的大部分工作中，构成成功产品战略基础的重大洞察都源于对产品数据的分析。尤其是与你的商业模式、获客漏斗、客户留存因素、销售执行数据以及数百个其他反映公司状况的重要指标相关的数据。
你可能对哪些客户对你的产品反应最佳有自己的理论，于是你进行分析，并意识到在某些情况下，你的产品具有显著的优势。你意识到，你要么可以寻找更多类似的客户，要么努力在其他类型的客户中复制这种动态。
通常，你会对数据产生一些想法，然后需要设计一个测试来获取你所需的具体数据。这是正常的，你的组织越早擅长进行这类实时数据测试，你获得持久成功的可能性就越大。
如今，产品团队几乎持续不断地进行实时数据测试是很常见的。每次测试你都会学到一些东西，但偶尔，你会学到真正重要的东西，一个潜在的有价值洞察。
关键在于，你要有足够的知识去识别这一学习成果，然后将这一学习成果转化为有意义的行动。
2、定性洞察
用户研究的核心在于洞察，正因如此，我非常推崇在组织中配备强大的用户研究人员。他们产生的洞察大多是定性的，因此不具备“统计显著性”，但别被这一点迷惑——定性洞察往往意义深远，甚至能彻底改变公司的发展方向。
用户研究界通常将洞察分为两类。第一类是评估性洞察，本质上是指，我们从测试这个新产品创意中学到了什么？它是否奏效？如果没有，原因是什么？第二类洞察是生成性洞察，这意味着，我们是否发现了之前未涉足、但或许应该去探索的新机会？
这实际上是产品团队中一个非常常见困惑的根源。在大多数情况下，在产品探索中，我们的学习是评估性的。我们已经被要求解决一个问题，所以我们不会主动寻找其他问题来解决——我们专注于找到一个真正有效的解决方案。
我们当然有很多产品想法，我们会用原型在真实用户身上测试这些想法，并且我们能很快了解到这个产品想法可能成功或失败的主要原因。
但每当我们与用户和客户互动时，我们都有机会更深入地了解他们，有时我们会发现比当前正在探索的更大的机会。即使他们喜欢我们正在测试的新事物，如果我们保持开放心态，我们可能会意识到存在一个更大的机会。这是生成性洞察的一个例子。
或者，即使产品团队并未主动针对某个特定问题进行探索，但作为团队每周与用户和客户互动的一部分（你确实在这样做，对吧？），我们也会发现新的、可能很重要的问题需要解决，或者未被满足的需求。
太多组织要么没有持续进行这种对客户的了解，要么即使进行了，也没有建立起利用这些洞察的机制，因此这些学习成果往往被忽视。
3、技术洞察
赋能技术不断变化，偶尔会出现一种新技术，让我们能够以新的、刚刚成为可能的方式解决长期存在的问题。
如果技术是全新的，你的团队中很可能没有人接受过这项新技术的培训，这一事实最终会吓跑许多领导者，或者他们偶尔会认为必须与具备必要经验的第三方合作。但如果这项技术对你很重要，你的公司就需要学习这项技术。
好消息是，这通常并不难。你最好的工程师们可能已经在考虑这项技术，并且很乐意有机会进一步探索。
在最佳组织中，往往是工程师识别出这些赋能技术，并主动将可能性带给领导者，通常以原型的形式呈现。
4、行业洞察
从整个行业中总能学到很多东西。我指的不只是你的竞争格局，还包括主要行业趋势、可能与你所在行业相关的其他行业洞察，以及世界其他地区类似市场的见解。
我之前写过我最喜欢的行业洞察来源，但总有一些分析师几乎覆盖每个领域，你应该关注那些你认为最优秀的分析师。
不少 CEO 认为获取这些行业洞察的最佳方式，是将其外包给麦肯锡、贝恩或波士顿咨询等管理咨询公司。
我对此持复杂态度。这些公司的人才通常非常出色，但他们面临两大不利因素。首先，他们的关注点和经验几乎总是集中在商业战略上，很少涉及产品战略（而且他们往往甚至不知道两者的区别）。其次，他们参与项目的典型时长，通常不足以让他们深入了解你的业务，从而开展真正的产品战略工作。
因此，结果是他们的见解通常不被产品负责人或产品团队视为相关。部分原因在于，他们的见解确实不相关，但另一部分问题在于，第三方发现的见解很容易被忽视。
我发现，如果你能招募到这些管理顾问中的一位加入你的产品组织，他们往往可以被培养成非常出色的产品经理和产品负责人。
3、共享学习
在强大的产品组织中，这四类见解始终是领导层和产品团队层面关注和讨论的主题。
但这场战斗的一半，尤其是在大型组织中，在于将相关洞察在恰当的时机传递给正确的人。
产品团队所学到的东西往往令人惊叹，尤其是在他们针对重要问题进行产品探索时。然而，这些学习成果很容易只停留在该产品团队内部。
产生的洞察需要被分享和传达。不幸的是，大多数团队尝试分享这些学习成果的最常见方式是将其写在某个地方——电子邮件、Slack 或报告中。遗憾的是，这种方式很少有效。
产品负责人或设计负责人往往是第一个在不同团队的学习成果之间“串联线索”并看到真正机会的人。
关键在于确保这些学习成果，无论它们来自数据、客户拜访、使能技术、行业分析还是任何其他来源，都能传达给产品负责人。
在许多方面，领导者获得的是他们要求的数据，而非他们需要的数据，尤其是在做出富有洞察力的战略决策时。
这是每周一对一会议的一个重要优势。
这也再次证明，被赋权的产品团队需要的不是更少的管理，而是更好的管理。这些领导者需要汲取经验教训，并将其传递给可能从中受益的其他团队，更广泛地帮助构建他们对整体业务的理解。
我长期倡导的一个做法是，产品负责人应汇总其负责领域内所有团队的关键经验与洞察，并在每周或每两周的全员会议上，总结其中最重要的内容，与整个组织分享。
这次分享有几个目的：
首先，这有助于更广泛的组织——包括其他产品团队以及利益相关者——更好地理解产品组织中每周发生的学习与洞察。
第二，这确保了领导者真正深入理解所有关键洞察，而不仅仅是通过电子邮件传递一些状态信息。
第三，很难准确预判关键洞察将在何处产生最大影响，因此广泛分享这些洞察至关重要，尤其是在其他产品团队之间。
无论如何，作为产品领导者，你需要识别出能够利用的洞察，以产生必要的影响。
在这一点上，我们聚焦于少数对业务真正重要的问题，并确定了我们认为能够推动这些问题取得进展的关键支点。现在，我们准备将这些洞察转化为行动。
三、行动
此时，我们已经聚焦于极少数关键问题，并付出了艰辛努力，识别出支撑我们产品策略的关键洞察。现在，我们需要将这些洞察转化为行动，但实现这一目标有两种方式。
这正是道路分岔之处，也是我们判断一家公司是真正致力于赋能型产品团队，还是仍沉迷于功能型团队的关键时刻。
我需要在此承认，即使公司选择继续使用路线图和功能团队，只要拥有强大的产品战略，他们的处境仍会好得多。这显然比那些没有产品战略、仅依靠功能团队的大多数组织要强得多。
真正的区别归根结底在于：你是交给产品团队具体的功能去构建，还是交给他们需要解决的问题。
大多数情况下，这种区别显而易见（例如“为在线帮助系统添加视频”与“提升新用户引导成功率”），但有时差异更为微妙（例如“我们需要一个应用程序”与“我们的用户需要能够随时随地访问我们的服务”）。
在第一个例子中，添加视频只是新用户引导方面可能存在的数百种改进方案之一。
在第二个例子中，添加应用很可能是实现随处访问的主要方式，因此差异很细微，两种表述方式可能都不会产生太大影响。
如果领导者认为他们清楚产品战略所需的功能和项目，那么他们很可能会将这些信息列入产品路线图，并将工作分配给相关团队。
然而，如果领导者希望产品团队对问题有主人翁意识，并负责发现和交付能够带来预期成果的解决方案，那么他们很可能会给予相关团队尽可能多的自由度，以提出有效的解决方案。
值得指出的是，第一种方式正是我们所说的“雇佣兵团队”，而第二种方式则是我们所说的 “传教士团队”。
雇佣兵团队**：主要按指令执行任务、对使命认同感较弱的团队。
传教士团队：高度认同问题与使命，主动寻找最佳解决方案的团队。*
当然，我推崇赋能团队模式早已不是秘密，因为我深信这种模式能持续产出更优成果，尤其在创新和达成预期目标方面。
如果你仍执意要为团队提供功能与项目路线图，那么建议你在此停步，因为本文剩余内容将聚焦于如何通过赋能产品团队模式启动行动。
在赋能团队模式中，我们的意图是为每个团队提供一系列需要解决的特定问题，然后给予他们自主空间，由他们决定解决这些问题的最佳方案。
管理这些待解决问题有多种技巧和体系，其中最流行的是 OKR 体系，即目标与关键成果法。目标是我们需要解决的客户或业务问题，关键成果则是衡量进展的方式。
我们已经讨论过公司目标作为战略背景的关键部分。但要启动行动，我们需要为产品团队提供他们各自的目标，这些目标被称为团队目标。
在即将推出的关于团队目标的系列文章中，我们将深入探讨如何在赋权团队模式中有效使用 OKR 技术。
但在我们讨论 OKR 技术之前，重要的是要指出，你实际上并不需要该技术或任何其他技术来实现这一点。
真正需要的只是让一位有见识的领导者与相关产品团队坐下来，解释包括产品战略在内的战略背景，然后告诉每个团队你需要他们解决哪些问题，以及他们应该衡量哪些业务成果。
如果团队具备正确的知识和技能，他们就会开始工作。
OKR 系统是一种将这些讨论正式化的技术，但只有当团队由被赋权的产品团队组成，领导者已制定出有效的产品策略，并愿意且能够信任其产品团队去解决我们需要他们解决的问题时，它才是一种有用的技术。
无论如何，仅仅因为你在赋权团队，这并不意味着我们可以放任团队不管，指望一切顺利。要成功实施产品策略，仍然需要大量的主动管理，这正是我们接下来要讨论的内容。
四、管理
虽然这些都是为需要完成的工作所做的必要准备，但我可以凭经验告诉你，如果领导者止步于此，季度末你将会感到失望。
这是因为没有哪项产品策略能在初次接触现实世界时幸存下来。
将会出现各种各样的问题和障碍，虽然每个产品团队会自行处理这些问题并做出大部分决策，但在许多情况下，他们需要你来清除障碍和壁垒，或提供其他帮助：
产品团队意识到他们对另一个团队有依赖，而那个团队正忙于自己的目标。
在产品探索过程中，团队意识到他们需要使用一种目前无法获取或不了解的技术，因此可能需要快速获取并学习。
出现了一个重大客户问题，组织正在紧急寻找最佳方式来照顾客户，同时仍能推进团队目标。
几个产品团队意识到他们都依赖于同一个平台团队的变更，而该平台团队正努力确定最佳方式来处理和帮助他们的同事。
一位高级利益相关者提出了一个影响关键目标的主要关切，产品团队需要迅速做出决策。
希望你能明白我的意思。这些情况并不罕见，但除非领导者积极参与识别、跟踪和解决这些类型的障碍，否则进展将微乎其微。
产品领导者的主要信息来源将是与产品经理的每周一对一会议。当然，如果有紧急情况出现，你应指导产品经理立即联系你，而不是等到下一次一对一会议再讨论。
在本次会议中，你将听到各种问题或障碍，并会就最佳处理方式进行指导。在某些情况下，你需要通过与关键利益相关者沟通、寻找另一位工程师、与其他团队讨论他们需要协助解决的问题，或处理上百件类似的事情来提供帮助。
请不要将此与命令式管理混淆。你并非接管控制权并指示团队该做什么；而是在回应他们的求助请求。更准确地说，这被称为仆人式领导。
在公司日常的种种紧急事务和干扰中，很容易在季度过半时发现团队目标进展甚微。这正是每周辅导如此重要的原因。作为管理者，你要确保产品经理在推进工作，同时，当重要的学习成果或洞察被发现，或重大问题时，他们也会与你分享，以便这些知识能够被汇总并传递给相关团队。
策略的指导与管理并非截然不同的职责，而是同一讨论的两个方面。
再次强调，对于拥有自主权的产品团队而言，你需要的不是更少的管理，而是更优的管理。