框架是很有用的工具，它可以帮助加快思考、弥补偷懒、激发创意，甚至可以避免心理偏见。Waze的首席产品官Rapha Cohen分享了5种基本的产品框架及其用法。产品经理、分析小组、设计师、开发者可以分别选用来帮助自己的工作。原文发表在Medium上，标题是：Waze’s 5 Essential Product Frameworks。

作者 | Rapha Cohen

原题 | Waze’s 5 Essential Product Frameworks

译者 | boxi

转自 | 36Kr.com

框架是非常强大的工具——但是并不是万能的解决方案。虽说没有适用一切的银弹框架， 但Rapha Cohen认为，在合适的情况下使用合适的构架可以“加速思考、弥补偷懒、激发创意，甚至可以避免心理偏见。” Rapha在工作中，为自己产品组织的特定团队确定了五个有用的框架。

下面，我们将深入探讨Rapha的框架：

1.目标—信号—指标（GSM）框架

含义：目标（Goals），信号（Signals）与指标（Metrics）

适用对象：产品经理

怎么用：GSM框架的目的是通过从产品北极星（或首要目标）后向求解来选择指标。目标就是如果你产品成功后世界的未来状态。目标就是你应该能够用一个很短的故事就能表达清楚的东西。

接下来，你需要确定信号——也就是用户行为的证据，来表明你的目标已经实现。最后，你需要识别出特定的量化指标，以此来告知自己是否看到了那些信号。

例子：比方说，在Waze这里，团队可以把Waze的目标设定为用户导航app的首选。信号的例子可以是开车用Waze导航的用户比例在增加，这反过来又非常清楚地表明了要跟踪的合适指标是什么。

团队应谨慎选择信号。比方说，如果团队关注的是用Waze导航的行驶里程数指标的话，可能就会无意间引入一些诱因无端端地增加用户行驶的里程数。你就需要把理想的信号和指标调整成具备实际的用户和社会价值的那些。

2. KPI图示框架

含义：用一张图来表明KPI性质的相关性

适用对象：分析小组

怎么用：Rapha认为KPI图形法要比更传统的KPI树表示法更好一些。传统的KPI树是把所有的KPI都分解为子KPI。这种分层方法的问题在于，它没有考虑到“网络效应”或指标性质的相互关联性等问题。通过KPI图示，可以深入了解一个地方的动作会如何影响到其他地方的指标和行为。就像Thomas Packer所说那样：“KPI图示应该能减轻员工的压力。如果他们能够理解哪些东西真正起到“推动变化”的作用，他们就不再会强调起不到作用的那些，哪怕讨论得再多也不会理会。”

例子：在Uber这里，更多的乘客会激活更多的司机，从而缩短等待时间，这反过来又会激活更多的乘客，从而创建出一个循环。用树来表示就捕获不到这种结构。

3. HEART框架

含义：愉悦度（Happiness），参与度（Engagement），接受度（Adoption），留存率（Retention）以及任务完成率（Task Success）

适用对象：设计师（往往用于“用户之旅”）

怎么用：HEART框架与GSM框架相关，而且经常跟GSM框架结合使用。HEART根据五个以用户为中心的指标来评估用户体验：愉悦度，参与度，接受度，留存率与任务完成率。

要实施HEART，只需要画一张有两条轴的表即可：GSM（目标、信号、指标）在x轴上，而HEART的指标放在y轴上。然后把里面的每个框认真填好，一个评估产品成功的详细框架出来了。

HEART非常有效，因为这种框架会让可以同时考虑用户与业务目标。愉悦度可跟踪用户的情绪，而参与度跟实际指标有关（比方说：用户开车是对app的使用情况是不是增加了？）。接受度与留存率跟激活与引导流程有关。任务完成率衡量的是用户之旅完成任务的程度。

4. HOSKR框架

含义：假设（Hypothesis），目标（Objectives），信号（Signals），关键结果（Key Results）。

适用对象：功能开发

怎么用：HOSKR可以看作是OKR与GSM框架的混合体。主要区别在于HOSKR将指标和目标与基本假设联系起来。

跟其他框架一样，HOSKR也会从具体的世界观入手，也就是产品会如何影响世界的愿景。根据这个假设，你可以制定一系列的目标，用来证明自己已经实现了那个首要目标。在这之后，再去实现用来表明用户行为实际上已受到你的产品的影响的那些信号——并用衡量指标（或关键结果）进行衡量。这可以提供一个定量的框架，用来确定假设是否已得到验证。

5. OKR框架

含义：目标与关键结果

最适合谁：团队

怎么用：OKR框架是最著名的目标设定框架之一。这种框架一般用于整个组织自上而下的目标谁都能够。如果你对OKR还不熟悉，可以去看看Google的OKR手册或John Doerr的《衡量重要的东西》。

OKR在Waze内部被广泛使用，这一点并不奇怪。不过我们有机会进一步了解Rapha和他的团队是怎么在组织范畴利用OKR，并确保它们在日常工作中始终具有可操作性的。

怎么才能避免OKR变成一长串的工作清单？

这绝对是CPO工作的本质之一——要确保始终将重点放在结果而不是功能上。对话应该始终放在要实现什么，而不是要开发什么上面。

OKR怎么跟团队结构联系在一起？

理想情况下，你的OKR应该跟技术基础设施是对应的，这样团队才可以独立运转。从较高的层面而言，每个人对团队结构可能会发生多快的变化的预期都应该保持一致。

OKR是公司范围目标的首要框架吗？

在Waze这里 ，高层管理团队会制定初始的世界观和目标。基于这些目标，团队会设立自己的OKR。然后，团队的关键结果会为管理层设定的组织关键结果提供参考。一旦组织的OKR建立起来之后，团队就开始使用自己独特的框架。

要不要区分工程OKR与产品OKR？

理想情况下，工程和产品应该有着共同的目标。一般来说，对于那些没法靠以用户为中心/以业务为中心的目标捕捉的东西，你就需要工程相关的目标。并不是每个目标都是以用户为中心的。

你应该多久设定一次OKR？

这要取决于企业所处的阶段，团队，基础设施等。如果改变有用的话，那就不要害怕改变。每个人都应该就改变的可能性保持一致。Waze曾经试过每年设定一次OKR，然后又变成每季度一次，现在我们已经改成每半年回顾一下。