制定 “小目标”,了解产品管理中的结构化思维
编辑导语:产品经理要如何在问题或痛点之上,找到解决方案的最优解?也许,你需要通过一个个小目标的拆解,来实现产品的最终落地。本篇文章里,作者阐述了如何利用结构化思维来制定目标、实现最终产品成功的实操策略,不妨来看一下。
产品经理不断被要求解决问题。毋庸置疑,解决问题就是我们的工作。对于我们许多人来说,利益相关者每天都会向我们提出 “添加这个模块” 或 “构建那个功能” 之类的请求——这也是雷区所在。你必须从无穷无尽的机会、痛点、问题和解决方案中筛选出最合适的选项。通常分为三步:
了解真正的问题或机会;
根据领导层传达的明确目标,评估问题或机会的真伪及价值;
最后,提出有效的解决方案。
这个过程可能令人倍感压力。在这篇文章中,我们会谈及以下话题:
为你的时间确定好优先级,做出更好的决定。
确定问题 / 机会:痛点、成功、限制、参与者。
框定问题:问题发散、问题收敛、问题陈述。
分解问题:创建等式、行为压力、待完成的工作(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 创建了一个很棒的免费资源,称为真正的创业手册,将这些风险分为两个方面:
市场问题与产品问题——你是否需要了解市场 / 客户 / 痛点或者产品 / 价值主张 / 解决方案。
生成性问题与评估性问题 —— 你是否有可证伪的假设要测试,或者你是否需要生成一个清晰的想法?
资料来源:The Real Startup Book(真正的创业书)
每个象限你都可以找到产品经理应该问的各种问题,以及问题的详细说明——可以为你提供答案的低成本实验。
本文翻译已获得作者的正式授权(授权截图如下)
作者:Jasper Curry
原文:https://medium.com/geekculture/structured-thinking-in-product-management-37ba50171ca7
译者:孙晨宇;审核:张小玺、李泽慧、张聿彤;编辑:孙淑雅
作者@TCC翻译情报局 翻译
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!