我经常被问到如何将产品经理提升到更高级别。事实上，升职往往是一场复杂的游戏。是的，你的技能和成就发挥了作用，但其他因素也起着重要作用，例如你的经理对人才培养的关心程度、你的同事的优秀程度和任职时间、公司的政治化程度等。

所以这篇文章不是关于如何晋升为高级 PM 的，而是关于如何提升你的思维并成为更好的 PM 的。任何人都可以像高级 PM 一样思考，无论他们的头衔如何——仅仅因为一个人拥有高级 PM 头衔，并不意味着他们真的当之无愧。

下图显示了您“做产品”的不同方式，具体取决于您对问题和解决方案的了解程度。为了提高您的产品工艺，您必须在清晰度的各个级别上自如地操作，并学习在每种情况下可以使用的不同工具。

你怎么知道一个问题是否清楚？一些明显问题的指标：

您可以阐明对业务和用户的影响，
你很清楚问题的根本原因，
您已决定现在应该解决这个问题，而不是其他问题。
如果出现以下情况，您可以说解决方案很明确：

您确信此解决方案可以解决问题，
您已经考虑了一系列解决方案，而这个解决方案在成本/收益方面胜出，
您的团队知道如何交付解决方案。
在本文中，我们将介绍您可以在不同情况下部署的工具，最后，让我们谈谈需要注意的陷阱。

打好基础：出色的执行力

当问题已经被明确定义并且解决方案已经达成一致时，你的重点就是真正地执行它。这通常是初级 PM 的主要竞争环境。当然，高级 PM 也必须掌握这方面的知识，但他们可以选择少动手。

“我们怎样才能快速发货？”
这一切都是关于管理积压的：确保工单写得清楚、大小合适、优先级正确并且有效地处理。它还可能包括运行使团队能够实现上述目标的仪式，例如冲刺计划、改进和回顾。

在传统的 Scrum 团队中，这是产品负责人的责任。在更成熟的组织中，我经常看到这是由技术主管负责的。如果您有幸在您的团队中拥有优秀的技术主管，请不要担心！作为 PM，您可以通过以下方式带来您的独特价值：

确保工程师了解工作的愿景和背景，以及它如何为业务目标做出贡献
帮助他们将工作垂直分割成可独立交付的块。
根据功能的复杂程度，交付整个功能可能需要几个月的时间。如果你能找到一种方法将功能分成更小的块，这些块仍然可以为用户带来价值，那就是一个胜利。更快的交付也意味着更快地从用户那里获得反馈，即降低花费数月时间构建错误事物的风险。

“我们如何确保我们做好这件事？”
这就是测试和实验的用武之地。您可能希望在要求工程师编写任何代码之前使用原型进行可用性测试。您可以选择逐步推出功能或在推出获胜版本之前进行 A/B 测试。

不同类型的测试和实验就像工具箱中的工具。您必须了解每个人的作用，以便您可以针对正确的情况挑选和选择正确的工具。

— 原型可用性测试

它的作用：测试用户是否知道如何使用您的解决方案。
它没有做什么：测试用户是否想使用您的解决方案。

事情是这样的：你展示一个可点击的原型，并要求某人完成与你的解决方案相关的任务，例如“你能告诉我你将如何上传照片吗？”

然后你的工作就是静静地观察并做笔记。他们是否凭直觉知道点击哪个按钮？他们是否了解当他们采取某种行动时会发生什么？副本是否使他们感到困惑？

此测试是一种快速且低成本的方法，可确保您不会浪费宝贵的工程资源。您可以使用像 usertesting.com 这样的平台，它允许您在当天注销之前设置测试，瞧！，第二天就有结果了！

如果您为一家非常小的初创公司工作，Usertesting.com 可能是一个成本高昂的选择——在这种情况下，您几乎可以与任何人一起测试原型，除了那些已经非常熟悉该产品的人。

— 逐步推出功能

这意味着您不是立即向 100% 的用户推出该功能，而是逐步进行。这在一些用例中很有用：

您要确保此功能不会破坏任何东西。作为 PM，您必须了解您的“控制指标”是什么。控制指标是您在发布新事物时不想损害的事物，例如应用程序崩溃率和客户投诉数量。
您想要衡量您的功能的影响。通过仅向一部分用户推出它（或者你也可以做相反的事情，保留一小部分没有得到该功能的拒绝组）一段时间，你可以展示你的功能对你的指标带来的影响想搬家。只要确保您均匀地分配用户即可。
PS：从技术上讲，这也算作 A/B 测试，但在本文中，我将 A/B 测试一词专门用于两个或多个不同的解决方案。
何时不这样做：当您的用户尖叫着寻求解决方案而您即将发布的解决方案不会让事情变得更糟时。当情况如此糟糕时，我什至会牺牲衡量影响的能力。

— 进行 A/B 测试

A/B测试的字面意思就是测试方案A和方案B，看哪个表现更好。您可以对原型进行 A/B 测试，也可以在实时环境中进行 A/B 测试。你可以让它成为 A/B/C/D 测试，或者你可以在每个版本中使用不同组件的组合，等等。

这里的目标是确定解决方案的获胜版本。您可能听说过一个著名的例子，它说明了 Google 如何试验 41 种蓝色阴影并获得了 2 亿美元的收入增长。但是除非您拥有数百万/数十亿用户并且微小的百分比增长等于巨大的 $$$ 价值，否则我不建议过度使用 A/B 测试。有一些用户旅程你会想要改进，直到你确定你已经确定了它们，例如获取和激活旅程。这些接触点是您将访问者转化为付费用户的地方，并且 $$ 影响很容易衡量。但在旅程的其他部分，例如用户实际使用您的产品来完成任务的地方，简单的 A/B 测试通常就可以完成工作。

批判性评估（和深思熟虑的反击）

从这一点开始，我会说这是产品经理和数字项目经理之间的区别。项目经理的工作是成功交付项目。其他人已经定义了问题，认为它值得解决，并且已经找出需要交付的解决方案。

批判性地评估一个解决方案（“有没有更好的方法来解决这个问题？”）和评估一个问题（“这个问题值得解决吗？”）是将你的产品思维提升到一个新的水平。这也可能意味着说不，或回击您的利益相关者。

在某些情况下，这也可能是内部 PM 和在机构工作的 PM 之间的区别。通常聘请代理机构来执行特定项目。我想如果他们的 PM 得出根本不需要该项目的结论，该机构不会很开心。

“有没有更好的方法来解决这个问题？”

您可以通过不同的方式定义“更好”的解决方案。“更好”可能意味着构建速度更快、集成成本更低、对企业的长期价值更高，或者更有效地解决短期问题。

作为 PM，您的工作是了解您正在构建的问题的战略重要性，这使您能够为解决方案设置正确的约束条件。然后，您应该积累团队中人员（即工程师、数据科学家和设计师）的专业知识，以找出满足约束条件的不同解决方案。

— 了解问题的战略重要性

我见过 PM 在给团队下达指示时只坚持一个原则。这个原则可以是速度（“我只想尽快推出这个”）或尽可能最好的用户体验（“我们的产品必须是世界一流的”），或其他任何东西。这里的失败是他们没有认识到并非所有的问题和解决方案都是平等的。

作为 PM，您必须能够清楚地表达：

您试图通过解决这个问题来实现哪个公司目标？
您要解决哪些用户问题？（还有我最喜欢的后续问题：你怎么知道这是个问题？）
你怎么知道你是否已经解决了问题？哪些结果指标会受到影响？您将测量哪些输出指标以及它们将如何影响结果指标？
— 为您的团队提供背景和约束

我不喜欢 PRD（产品需求文档）的页面和页面，并且绝对不喜欢将 PRD“移交给”工程师来构建。您应该提供上下文（正如我们刚才讨论的——公司目标、用户问题、指标等）和约束条件。约束可以是：

资源（时间和工程师人数）
用户细分
应该/不应该涵盖的边缘情况
请记住，目标并不总是为每个人打造完美的东西。可以说“我们只想要针对用户群 X 的快速而肮脏的解决方案，我们不关心边缘情况 Y 和 Z”，前提是您已经仔细考虑过它们并且对权衡感到满意。

- 积累他们的专业知识以找出解决方案

现在是时候退后一步，让您的团队大放异彩了。给他们时间进行自己的思考、技术峰值和线框图。你应该仍然在那里提供指导、推动和澄清。在此过程结束时，如果有多个可能的好解决方案，您的工作就是做出决定。

设计冲刺是一种可用于执行此过程的格式。另一种方法是将其纳入您的常规冲刺中，有时也称为双轨敏捷。前者适用于需要您改变团队旧的思维和工作方式的大型或新项目。后者通常更方便且干扰更少，尤其是当您的团队有交付目标要实现时。

“这个问题值得解决吗？”
现在取决于公司以产品为导向的程度，质疑一个问题是否值得解决可能并不容易。产品请求可能来自非常高级的利益相关者，甚至是 CEO，而 PM 可能需要选择他们的战斗。

如果我们“假设良好的意图，如果不是能力”（正如我们在 Meta 喜欢说的那样），所有的产品创意和要求都有一定程度的优点。也许它们都不是真正的垃圾——这使得反驳变得更加困难。

让我们为您配备一些可以帮助您做到这一点的工具。

— 量化影响

这是最明显的一个，但我认为值得重复。您可以通过考虑这些因素来量化影响，然后将其转化为美元价值：

Reach：受影响的用户数量
强度：当前状态对这些用户来说有多痛苦
用户细分：用户细分对您的公司有多大价值（即影响范围可能最小，但这一小部分用户可能会带来您一半的收入）
尽可能带上硬数据和数字，减少主观性。

— 了解功能的真实成本

估算构建一项功能的成本通常非常简单。从工程师那里估算时间，然后乘以他们的薪水。但是你必须记住，除了建筑成本之外，还有其他类型的成本：

维护成本。该功能上线后，您的团队还负责维护它并解决出现的任何问题。
膨胀的成本。由于此功能，您的代码库将变得更加复杂，并且由于额外的复杂性，构建其他任何东西都将花费更长的时间。新加入者将需要更长的时间来理解代码库。
改进的成本。您可以祈祷该功能一旦发布就可以完美解决问题，但这种情况很少见。您可能需要修改它、更改副本、调整设置等。
协调成本。你和你的团队将不得不参加会议、写电子邮件、提交更新、提醒相关团队等。
显然，您还必须考虑机会成本：否则我们还能如何利用我们的时间？错失机会的潜在损失是什么？

— 了解时间敏感性

问题并不总是“这个问题值得解决吗？” - 也可以是“为什么是现在？”

墙上的一个小裂缝现在可能不会产生令人印象深刻的影响数字，但忽略它可能会给你带来巨大的问题。了解什么都不做的代价和延迟的代价将帮助您确定问题及其紧迫性。从这篇文章中引用我自己：

有些问题就像一场大火——你要么现在就解决它们，要么以后再重建。其他问题就像屋顶漏水——它会慢慢变得越来越糟，直到整个屋顶倒塌。其他一些问题就像一滩水——它很烦人，但只要每个人都知道绕过它就不会伤害任何人。

• 深思熟虑地推回去

现在，您已经完成了所有练习，并且确信这个问题实际上不值得解决，至少目前是这样。反击是工作中必不可少的一部分——正如沃伦·巴菲特所说，“成功人士与真正成功人士的区别在于，真正成功的人几乎对所有事情都说不。”

我的反击原则：

不要拐弯抹角。如果您不打算满足他们的要求，请尽早直截了当地说出来。
表明您已仔细考虑了他们的要求。谈谈导致你得出这个结论的思考过程。
相反，展示团队正在做什么。他们正在构建更有价值的东西，你必须能够清楚地表达这一点。
— 即使在不同意之后也承诺

我们都去过那里——HiPPO 发表了意见（最高薪人士的意见），你必须发表你不同意的事情。向团队发泄和发泄是很诱人的。

亚马逊的杰夫·贝索斯 (Jeff Bezos) 普及了我个人喜欢的不同意和承诺的概念。（如果你还没有阅读整封信，我完全建议你阅读。）你可能在背景上不同意，但作为 PM 和团队的领导者，你必须与领导层形成统一战线并为这项工作。

采购战略机会

现在我们谈论的是最高级别的歧义：问题和解决方案都不清楚。这是退一步看大局的好机会。

3我们应该关注的最高价值问题是什么？
回答这个问题需要深入了解您的用户为什么以及如何使用您的产品，以及他们在切换到和离开您的产品时考虑的因素。哈佛教授 Clayton Christensen于 2016 年首次推出该框架，自此成为最受推崇的产品开发框架之一。

— 了解用户要完成的工作 (JTBD)

JTBD 的主要原则是了解用户在“租用”您的产品时想要完成的事情。答案通常比显而易见的更深刻。假设您管理的产品是一个 MBA 项目。人们出于各种原因攻读 MBA：转行、在当前的职业道路上取得进步、开创自己的事业等。

您可以深入挖掘这些原因。例如，对于那些说他们正在攻读 MBA 以在当前的职业道路上取得进步的人。它到底是什么意思？现在是什么阻碍了他们？他们缺乏信心吗？他们有知识差距吗？他们只需要学位来证明他们的资历吗？

了解更深层次的原因将使您能够确定可以在产品中实施的改进机会，以更好地满足用户需求。

— 了解用户的切换因素

当用户决定使用您的产品时，他们会从之前使用的产品中切换。即使他们之前没有使用任何“产品”也是如此——什么都不做是一个合法的选择。

有四种力量在影响某人的转换决定：

推动因素：围绕当前解决方案的痛点和不满
拉动因素：新解决方案的优势或好处
焦虑：对新解决方案的担忧和担忧
惯性：对现有解决方案的舒适和熟悉
作为 PM，你的工作是从你的用户那里发现这些转换因素，这样你就可以主动减少转换的障碍。让我们再次使用 MBA 示例查看这四个因素。

我们如何才能让我们的产品永不过时？

改进您的产品并不总是局限于您当前的竞争环境。激进的创新通常来自向外看，而不是渐进式改进。

— 了解您产品的竞争格局

正如我们在上一节中讨论的那样，您的产品的竞争对手不仅仅是显而易见的。X 大学不仅在推广其 MBA 课程方面与 Y 和 Z 大学竞争；它还在与训练营、在线课程、播客、高管培训甚至 Netflix 竞争。

在映射这些备选方案并将它们与您的产品进行比较时，您可以将客户需求作为轴的另一侧，并评估每个产品满足需求的程度。下面是一个简单的例子：

PS：进行补充练习也很有用：(1) 映射您的用户细分，因为每个细分都有不同的需求，并且并非所有细分对您的业务都具有同等价值，以及 (2) 将需求映射到卫生、性能和取悦者，又名卡诺模型。这篇文章已经太长了，所以我把它们删掉了！如果你想了解更多关于这些的信息，请在评论部分告诉我，我会写一篇深入探讨它们的文章。

现在想象一下，作为一名 MBA 项目产品经理，你的任务是找出一种颠覆 MBA 的全新产品。您可以获取客户需求图，确定当前可用解决方案未满足的需求，并创建具有强大价值主张的独特新计划。

— 确定扩展产品价值链的机会

可能破坏您的产品的不仅仅是竞争对手或新进入者。还有其他因素在起作用，正如迈克尔·波特在五力分析中所描绘的那样。在他的框架中，波特谈到了认识到客户和供应商的议价能力。如果您的供应商可以抬高价格而您别无选择，那您就完蛋了。如果您的客户可以毫无问题地离开您，或者可以将价格谈判到零，那么您就有麻烦了。

所以如果你想增加你的产品长期成功的可能性，你必须通过增加你的来降低他们的议价能力。

现在，他说的有道理，但那种构架方式让我感到不舒服。这意味着一方必须失败的权力游戏。我更愿意换一种方式思考：我们如何扩展我们产品的价值链？

我们以 Shopify 为例。它最初是一个在线商店建设者：一个小企业主可以配置他们的品牌和商店主题，添加他们的项目，瞧，他们在 15 分钟内拥有自己的在线商店。他们的目标客户是那些已经有业务和要出售商品的人，他们只需要在线展示。

然后 Shopify 发现了一个机会：有抱负的企业家想要开始自己的在线业务，但还不知道要卖什么？他们将产品扩展到批发市场和代销业务。

管理在线商店的下一步是通过将订单发送给客户来完成订单。Shopify 还决定通过提供自己的履行网络扩展到该地区。

Shopify 通过让自己变得有价值且不易被替换，让客户更难离开，或者让新进入者更难吸引客户。这是 Shopify 的胜利，也是客户的胜利。

给你的要点是：尝试绘制出你的客户完成 JTBD 所经历的过程。有没有一种方法可以通过在他们使用您的产品之前或之后帮助他们来扩大您的价值？

把它们放在一起

ew，那是一篇很长的文章。感谢您做到这一点。

如果您只能带走一件事，那就是：没有任何一种工具可以一直有效。您可以通过 1) 增加工具箱中工具的数量，以及 2) 知道何时部署每个工具来改进您的产品管理技巧。

就在我们走之前，我有一个简短的注释要添加。有两个陷阱可以落入：

质疑问题和解决方案太多。您不必总是为了看起来聪明或证明自己像高级产品经理一样操作而必须使用最先进的工具。如果思考的成本高于构建的成本，那就构建并发布它。如果你是对的，市场会告诉你。
质疑问题和解决方案太少。这通常是一个非常新的 PM（他们认为其他人已经完成了澄清问题和解决方案的工作）或一个非常老的 PM（他们对公司、用户和领域太熟悉了，所以他们认为事情是理所当然的）。顺便说一句，“新”和“旧”指的是他们在公司的任期，而不是他们的年龄。
如果您不确定自己对问题或解决方案有多清楚，我有一个技巧可以教给您：试着把它写下来。您可以以新闻稿、客户感谢信或简单地描述问题和解决方案的形式来撰写。