您的位置 首页 > 体育运动

【足球经理 自创球员】制定“小目标”,了解产品管理中的结构化思维

指南编辑:产品经理如何在问题或问题上找到最佳解决方案?也许你应该通过小目标拆解,实现产品的最终落地。

本篇文章里,作者阐述了如何利用结构化思维来制定目标、实现最终产品成功的实操策略,不妨来看一下。

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

  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

原文:

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

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

题图来自 Pexels,基于 CC0 协议

关于作者: luda

无忧经验小编鲁达,内容侵删请Email至wohenlihai#qq.com(#改为@)

热门推荐