制定 “小目标”，了解产品管理中的结构化思维

文章插图
产品经理不断被要求解决问题。毋庸置疑，解决问题就是我们的工作。对于我们许多人来说，利益相关者每天都会向我们提出 “添加这个模块” 或 “构建那个功能” 之类的请求——这也是雷区所在。你必须从无穷无尽的机会、痛点、问题和解决方案中筛选出最合适的选项。通常分为三步：

了解真正的问题或机会；
根据领导层传达的明确目标，评估问题或机会的真伪及价值；
最后，提出有效的解决方案。

这个过程可能令人倍感压力。在这篇文章中，我们会谈及以下话题：

为你的时间确定好优先级，做出更好的决定。
确定问题 / 机会：痛点、成功、限制、参与者。
框定问题：问题发散、问题收敛、问题陈述。
分解问题：创建等式、行为压力、待完成的工作（JTBD）、用户访谈。
陈述你的假设：发现隐含条件。
验证与风险管理：四种风险类型、进行事前调查、通过廉价的测试降低风险。

这篇文章的目标是将 OKRs（Objectives and Key Results，目标与关键成果法）这一高层组织思维所具有的严谨性和结构，扩展到个人问题的分解和解决。
我承认这远不是一个原创的想法，但是，我坚信在这个过程中建立结构是有价值的。
一、为你的时间排出优先级，做出更好的决定 Prioritize your time and make better decisions我不打算在这篇文章中讨论整个产品的优先级问题，已经有很多关于这方面的文章了。我想从产品经理的视角出发，指出我们的痛点——决策疲劳。我们的确有责任做出非常多的决定，但我们不能对每一个决策都那么严格。
在决定做出决定之前，先问问自己以下问题：
1）决定是否容易逆转？
想象一下，如果你尝试了一些东西，但你不喜欢结果，你能轻易改变方向并尝试别的东西吗？杰夫·贝佐斯（Jeff Bezos）将“退出成本较低的决策”称为双向决策。如果你可以以较低的成本在苹果上多咬一口，请不要在这里花费太多精力。
2）决策的风险幅度是多少？
比如，即使你打错了电话并且无法重试，最坏的情况是什么？如果潜在的不利因素是有限的（包括机会成本），那就不值得花费大量时间做决定。
3）该决定的结果是否有助于你的团队实现既定目标？
【制定 “小目标”，了解产品管理中的结构化思维】如果没有，请深入思考做出此决定的原因。
4）你需要哪些信息来提高你的决策质量？是否有可能获得这些信息？
如果是这样，需要多少努力 / 时间？等待更多信息是很诱人的，但时间成本必须考虑在内。
在做出决定之前花更多的时间来评估决定，我承认这个提倡有点讽刺。但这种深思熟虑的做法有助于抵制一种自然倾向——去选择那些最容易理解的事情而非最有价值的。
二、定义问题 / 机会 Scope the problem / opportunity注意：这部分可能对很多人来说非常容易，但是，我依然认为有必要明确说明。因为我看到了太多问题的出现——由于人们在基本理解上不一致。
有时候，第一个应该问的问题不是“问题是什么”，而是“我知道的足够多，能否陈述问题” 。在深入研究之前，请确保你可以清楚地描述由问题引起的相关症结，阐明成功的理想样貌，了解你工作中存在的限制，并准确识别你将要共事的合作伙伴。下面我们将展开详细讨论。
1. 症状对于每个问题或机会，你目前所处的位置（观察）和你想要达到的位置（愿望）之间都存在差距。这些差距代表了有待确定的问题症结。
例如，你目前有 10 万用户，但希望拥有 25 万用户，那么这 15 万的差距就是症结。这是一个简单的例子，但症结可能来自用户访谈、分析、请求等，你只需要明确现状和愿望即可。
识别症结需要注意：
1）某些简单的说明并不是症结
例如，有人可能会说用户界面令人困惑。这不是症结——这是某人对更基础问题的说明。将症结与简单说明区分开来很重要，因为如果你接受了表面的说明，就可能会忽略其他潜在的解释。
2）明确且具体现在需要解决的问题
在大范围内解决模糊问题是不可能的，请确保及时明确症结。如果说现实与愿望之间的距离是一个永恒的问题，比如“我们想赚更多的钱”，那么它是一个过于模糊的症结，无法指导行动。
3）考虑外部 / 环境因素
你不是在真空中运作，重要的是承认环境的变化可能会引起症结或创造机会。
2. 成功如果你不清楚成功是什么样子，就很难解决问题。提出以下问题是一种有用的技巧，可确保你的团队保持一致，以免陷入用解决方案定义问题的陷阱。
这个项目会在何时取得巨大的成功？它的模样会是怎样？
弄清楚如何衡量成功可能很困难。水晶球测试是一种有用的技巧，在了解人们如何使用产品的基础上，继续追问，产品成功的样貌应该是怎样的？
想想人们如何受益，以及某种改进后可以观察到什么？遵循价值。
3. 约束清楚你的项目边界是非常重要的，以便你在探索解决方案时了解各种限制。

你有多少时间？截止日期背后的原因是什么？
有哪些资源可用？
开发解决方案时的风险偏好如何？
成功指标的限制是什么？

对于最后一点，可以借鉴反向护栏地概念。例如，你可以通过将产品成本减半来提高注册转化率，但这现实吗？尽早进行这些讨论将有助于澄清界限，了解哪些权衡是可以接受的。
4. 演员从最终用户到利益相关者，重要的是要明确：

谁正在经历这些症状；
谁负责项目的各个方面；
谁最终对成功负责（提示：很可能是你，PM）；
开发解决方案时应该咨询谁，需要谁批准。

尽可能多地收集信息，并与你的团队一起审查以确保每个人都保持一致。可能会有一些领域你不完全清楚——这是意料之中的。但至少你明确了已知和未知，而不是隐含的假设。
三、构建问题框架 Frame the problem

很多时候问题比答案更难。如果你能正确地表达这个问题，那么答案就是简单的部分。
——埃隆·马斯克

构建问题框架，是我们在面临艰巨挑战时所采取的最重要步骤之一，但它常常被忽视。你是否在被人问过一个事后看来非常明显的问题后，极大地改变了你处理问题的方式？也许这一切会让你感到惊讶，但这就是优秀框架的力量。这些 “催化” 问题可以揭示盲点并开辟新的探索途径。
缩小框架以创造焦点与扩大框架以鼓励创造性解决方案之间，存在着一种自然张力。在确定问题范围时，应该通过与更广泛的团队讨论相关限制，找到两者的平衡点。
对于分析选项来说，聚焦更为重要；如果想要扩充更多选项则不宜过早聚焦。一般的经验是：在问题探索的早期阶段保持框架尽可能宽。
以下内容，可以帮助你发现 “催化” 问题。
1. 问题风暴在 Hal Gregersen 的《问题就是答案》一书中，他建议召集一个跨职能的利益相关者小组，并为他们提供问题的高级概述（症状、成功、限制、参与者）。
与其让小组头脑风暴解决方案，不如让他们头脑风暴问题。为了解决问题，他们想知道什么？他们对问题中隐含的假设有什么疑问？虽然许多问题都是显而易见的，但也有一些问题可能会跳出来，让你从不同的角度思考问题。
2. 限制性问题想一想你身处的问题语境。你可能想要回答数十个问题，但为了更加有效地解决问题，最需要被回答的是什么？如果只能问两个问题，你会问什么？这样的思考练习会迫使你深入思考什么是真正重要的。你会发现，一个非常好的回答，还可以解答其他许多问题。
3. 问题陈述当你完成了这些提问练习，就可以尝试创建问题陈述。
请记住，随着信息的不断获取，你可能需要修改它。一个好的问题陈述的标志是：这个问题的答案能够解决你在第2步中制定的基本成功标准和限制。
四、分解问题 Decompose the problem既然已经确定了问题的范围和框架，就很容易深入研究并开始提出解决方案。但是，要花时间从多个角度分解问题也很重要，以便识别单个要素并了解它们如何影响整体。
事实上，并没有一种万能的方法可以解决问题，你的问题的性质将决定什么才是最有意义的。以下是我发现特别有用的一些起点。
1. 创建一个等式产品团队开展分析工作（希望如此），也是一种将问题分解为更小部分的简单方法。当我在 NBC News 担任产品经理时，我用这样的等式将他们的业务分解为基本面：

文章插图
将等式的每个部分分解成其子组件，可以让团队了解各种杠杆是如何相互作用的，以及优化后的各个组件的敏感性和潜在影响——有些组件可能具有更好的 ROI 潜力。
2. 行为压力归根结底，解决方案通常只是改变一群人的行为。人们目前正在做X，而我们希望他们做Y 。在马特沃莱特的《从终点开始》中，通过行为变化和压力分解的视角——导致行为或多或少发生的因素，去进行问题的分解。
为此，请尝试编写行为陈述。行为陈述是从行为视角出发，对我们试图创造的世界进行描述。行为陈述的简化版 “mad-libs”：

人们 = 你想要改变其行为的人群。
动机=人们为什么要从事这种行为？是什么驱使他们这样做？
行为 = 你希望看到什么行为发生改变？
数据 = 你将如何衡量这种行为变化。

这方面的一个例子是：当有了行为陈述，你就可以与团队共同探讨促进压力（什么会鼓励期望的行为？）和抑制压力（什么会阻止期望的行为？）的想法。
“反事实” 可能会帮助你拓展思路——什么会促进和抑制你想要看到相反的行为？许多想法或许不可行，或超出你的影响能力，但也可能产生很有见地的想法，让你从不同的角度考虑问题。
3. 要做的工作你可以通过 “待完成的工作” 这一视角来思考问（这个框架来自 Clayton Christensen）。用户使用你的产品来完成什么工作？是什么激励用户做这项工作？如果你陷入困境，这种宏观层面的观点可能会有所帮助。
4. 用户访谈分析会告诉你是什么，但他们不会告诉你为什么。为此，你需要收集定性反馈。这里有一些策略可以帮助你更深入地了解问题。
5 个为什么——百试不爽。针对问题探索步骤中列出的每个症结，邀请不同参与者进行 “5 个为什么” 练习。“为什么” 的数量并不重要，它只是一个指南，帮助你剥开洋葱层，了解症状的根本原因。
妈妈测试——Rob Fitzpatrick 在他的同名书中概述了这个过程。它本质上只是一个聚焦用户的访谈——之所以这么命名是因为热爱和支持他们的妈妈们，可能会给出令人鼓舞的答案，而这些答案可能会让你走上注定失败的道路。
“妈妈测试” 的核心原则是：

谈论他们的生活 / 经历。不要谈论你对解决方案或问题的看法。
询问过去的细节，而不是泛泛而谈，或讨论对未来的看法，人们往往无法准确预测自己未来的行为。
少说多听。

请尝试梳理以下信息：

用户今天的行为如何？
哪些限制影响了他们的选择和行动？
什么让用户感到沮丧或被激励？
用户目前如何做出决策、花费金钱/注意力并最终确定价值？

与人们谈论问题时，请记住最重要的一点：你不能告诉他们问题是什么，作为回报，他们也不能规定解决方案。一般情况下，当他们试图为你提供解决方案时，你需要了解他们建议背后的理由。他们拥有问题，你拥有解决方案。
五、陈述你的假设 State your hypothesis

很多人认为他们在思考，而他们几乎只是在重新排列他们的偏见。
——威廉·詹姆斯

每当产品经理想要创建或更改产品时，他们都会陈述一个假设，因为他们认为这会导致某些事情发生。人们常常对问题、机会和解决方案抱有模糊的想法，但不会花时间确切地阐明他们在说什么，或者提议成功的前提是什么。如果你想要思考清晰、发现偏见，并在整个团队中建立一致性，那么写出清晰的假设并使其隐含的假设明确，就是关键所在。
最基本形式的假设是一个对预期因果关系的明确命题。
提出假设是轻松的。不幸的是，隐含的假设经常有缺陷，却被假定为正确的。好在证实或证伪你的假设要比对假设进行实验容易得多。
发现隐含假设如果你想发现隐含的假设，请问问自己，如果我们有以下假设：
如果我们在结账流程中实施 Apple Pay，那么我们预计会有更多客户完成结账，这是通过结账转化率衡量的。要验证这一假设，我们必须通过适当的实验设计，即设置成功标准、实验持续时间等，然后实际构建 Apple Pay 功能。如果在开始之前，我们花点时间来揭示假设中隐含的假设，就会意识到我们的假设中还包含以下两种假设：

相当一部分想要购买我们产品的用户希望在结账时使用 Apple Pay 。
相当一部分想要使用 Apple Pay 的用户在结账时放弃了，因为他们的首选支付方式不可用。

只有这两个假设都必须为真，我们的假设才成立。知道了这一点，我们可以轻松地将这些假设转化为用户自己的假设，并创建一个快速实验来了解：

如果它是一个选项，有多少用户会在结账流程中选择 Apple Pay？
当他们发现点击 Apple Pay 会出现“即将推出”的提示时，这些用户中有多少会选择放弃？

六、识别和管理风险 Identify and manage risks创建新功能或产品的过程是有风险的。风险本身并不坏，但产品经理需要确保能够理解和管理风险。他们总是倾向将风险降至最低，这在某些情况下是有意义的。例如，优化低风险、高回报的活动。然而，最终你会达到收益递减点，就需要进入创造新事物的冒险世界。
1. 四种风险掌控产品风险世界的第一步是能够识别项目中的所有风险。Marty Cagan 有一个很好的框架来帮助产品经理认识经常面临的各类风险：

价值风险——人们会发现我们提议建造的东西有用吗？
可用性风险——人们能够弄清楚如何使用它吗？
可行性风险——在现有资源的情况下，我们真的可以构建出想要的东西吗？这包括技术风险和交付风险。
可行性风险——该产品/功能对企业有意义吗？是否有适当规模的市场？

产品经理需要专注于协作发现、确定优先级和应对风险。如果想要发现风险的话，请考虑进行预检。
2. 进行事前预防预检是由 Gary Klein 开发的一种工具，可帮助团队在项目开始时识别风险并建立一致性。
要做到这一点，你需要召集跨职能团队，让他们想象现在是目标发布日期的第二天，事情进展得并不顺利。从这个想象的未来角度来看，让每个人独立写下由于团队的行动或决策导致事情进展不顺利的 5 个原因。另外，列出 5 个你无法控制的失败原因。最后，让团队尝试找出最大的未知数（显然这些并不容易预测，但值得讨论）。
如果你想详细了解如何进行有效的预检，我强烈推荐 Shreyas Doshi 撰写的这篇文章《如何使用预检来预防问题、失误和灾难》。
3. 通过廉价的测试降低风险风险是由预期结果的不确定性引起的。减少不确定性的明确方法是：发布新功能或产品时，衡量其影响——但这样做成本很高。当产品团队依靠发布最终的产品作为“测试”对象时，时间和机会成本会最大化。我们都知道 MVP 的概念，但更有用的概念是 RAT——最高风险假设测试。
对于上面列出的每一种风险类型，通常都可以用相对较少的成本进行实验，以快速获得信息。虽然这些实验不会给你明确的答案，但它们可以提供定向反馈，帮助决定是否需要额外投资或路线修正。
产品经理通常遇到的最大和最常见的风险属于价值和可行性风险。来自 Kromatic 的 Tristan Kromer 创建了一个很棒的免费资源，称为真正的创业手册，将这些风险分为两个方面：