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

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

编辑导语:产品经理要如何在问题或痛点之上,找到解决方案的最优解?也许,你需要通过一个个小目标的拆解,来实现产品的最终落地。本篇文章里,作者阐述了如何利用结构化思维来制定目标、实现最终产品成功的实操策略,不妨来看一下。

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

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

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

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

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

这篇文章的目标是将 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 功能 。如果在开始之前,我们花点时间来揭示假设中隐含的假设,就会意识到我们的假设中还包含以下两种假设:

  1. 相当一部分想要购买我们产品的用户希望在结账时使用 Apple Pay。
  2. 相当一部分想要使用 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 创建了一个很棒的免费资源,称为真正的创业手册,将这些风险分为两个方面:

  1. 市场问题与产品问题 ——你是否需要了解市场 / 客户 / 痛点或者产品 / 价值主张 / 解决方案。
  2. 生成性问题与评估性问题 —— 你是否有可证伪的假设要测试,或者你是否需要生成一个清晰的想法?

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

资料来源:The Real Startup Book(真正的创业书)

每个象限你都可以找到产品经理应该问的各种问题,以及问题的详细说明—— 可以为你提供答案的低成本实验

本文翻译已获得作者的正式授权(授权截图如下)

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

 

作者:Jasper Curry

原文:https://medium.com/geekculture/structured-thinking-in-product-management-37ba50171ca7

译者:孙晨宇;审核:张小玺、李泽慧、张聿彤;编辑:孙淑雅

本文由@TCC翻译情报局 翻译发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

随意打赏

提交建议
微信扫一扫,分享给好友吧。