这篇文章，我们将讨论如何应用一个科学方法及其组成：产生假设-测试-评估-产品计划。

一个让人望而却步的问题：如何像Amazon和Facebook这样成功的公司一样，持续运行用户测试和收集大量数据？从何入手？可行吗？

好消息是，如果你开始行动，甚至是在一个小问题上，你可以基于公司文化建立这种快速的测试。下次在会议讨论、辩论或者争执中，你可以这样问： “我们可以测试一下吗？” 你可以把注意力从解决问题转变到理解问题，然后转移到测试中去寻找正确的解决方案。

这里，我们将讨论如何应用一个科学方法及其组成：产生假设-测试-评估-产品计划。

假设

来自维基百科：假设是对现象的一种可能的解释。

好，我们先在这里停一下。对产品来说，我们从“现象”中寻找“问题”。设定一个假设可以帮助我们清晰的理解我们所观察的问题，这样我们就可以创建一系列的实验去测试潜在解决方案。我们的假设是用来回答“问题是什么，发生的原因是什么？”

我来举个来自我自己公司的例子，这里给产品经理很多工具。我们发现产品经理经常纠结于定义产品路线图。根据当前的现状去获悉所谓“价值”是很难的。大多数优先排序方案归结为成本与回报分析。你寻找低成本的计划，你期望产生高回报。但是，你如何对高回报（高价值）的做出明智的猜测呢？

我们的假设是，产品经理很难清楚地确立和捍卫其优先事项，因为很难对一项提议的价值综合多个视角进行总结和分析。收集和筛选来自销售、市场和技术等不同群体的独到见解是一个大难题。如果每个人都不理解事件优先级背后的排序逻辑，那么这种不理解可能会导致整个组织对排序结果的不信任。

让我们用定义假设将这个过程分解为两个部分：

我们观察到什么现象（问题）？

• 产品经理在初步评估价值的时候比较困难。
• 组织纠结于如何理解优先级排序。

发生的原因是什么？

• 在评估的时候，组织内部协作有限。（我们大都基于经验，而非协作）
• 在评估的时候，与客户的协作有限。
• 在评估的时候，对于决定价值的“为什么（要做）”沟通有限。

这让我们可以深入研究假设

产品经理之所以很难评估产生的价值，是因为对内部团队，比如销售、市场、技术和客户成功所知有限。

记住，这并不一定是问题的唯一的原因。我们选择一个我们认为是最有可能的原因，然后去收集数据来帮助我们确定我们是否正确。未来，我们可能放弃这个假设，然后回去寻找可能的原因。

测试

既然我们已经设定了假设，我们可以开始寻找帮助产品经理在制定产品路线图时评估优先级的可能解决方案了。一种方案是把团队成员说的每句以 “我认为……”、“我们应该……”、“如果我们……”的话转变成“如果……会怎样”语句。即便我们不知道尝试的结果，但是会让我们无法忽视假设的结果。

这让我们的假设变得：

• 如果在每次为产品路线图添加新特性的时候，发送谷歌调研问卷，会怎样？
• 如果我们建议产品经理每隔一段时间就和某个团队会晤，会怎样？
• 如果我们建立一个Slack机器人来收集团队评估，会怎样？
• 如果我们在会议中建立一个AppleTV的应用，将评估游戏化，会怎样？

我们发现Slack机器人对我们来说是最好的选择——可以与组织中大量人员进行互动而不会产生摩擦。通过这条建议，我们为产品经理在评估每个倡议的价值时将数据收集工作分解为两点：

• 这一倡议对我们正在寻求解决的客户问题的预期影响是什么？

• 这一倡议对我们业务目标的预期影响是什么？

我们的Slack机器人将会生成一个问卷让团队成员来打分，分值范围是1~5。我们也支持对这些问题进行开放式补充回答：“为什么你认为预期影响是（3）？”

然后，我们将这些信息反馈给产品经理。反馈的界面包括评估分数的范围以及每个参与者对开放问题的回答。我们的目的是让产品经理获得考虑路线图优先级时的普遍观点和见解。

我们的测试完成啦！填写下面的模板，我们可以对测试做一个简洁明了的概述。

如果我们<尝试一个解决方案>，我们可以<期望一个结果>。

如果我们利用Slack机器人收集团队成员价值评估反馈，我们可以提升产品经理对优先级评估的参考数据广度。

评估结果

到此为止，我们还有一个步骤。我们如何得知效果如何？我们需要一种来评估预期结果的方法。

这常常是使用测试的最大障碍和困难。评估让人望而却步，热别是组织习惯基于直觉和情感进行决策。然并卵，衡量执行评估团队的情绪不会让我们的产品或者巨大的成功，或很微小的成功。

你的评估指标应该聚焦在用户行为上。业务目标很可能与收入、持有或收购有关。这些指标非常重要，但很难快速测量进而做出决策。你需要找到能够实现这些业务目标的关联指标。关键是找出你认为的用户正在朝着预期结果前进的模式。

对我们来说，假设产品经理处理了更多的来自不同团队数据，他们将会更好的了解预期价值，并做出更好的决策。因此，需要向他们提供他们以前没有的数据，并跟踪这些数据是否影响他们的决定。我们希望能够在这个过程中进行测试和调整，并且知道是否有机会达成目标。如果测试的成功与否是基于用户行为的，那么我们可以稍后返回并评估业务指标。

现在，我们只需要给这些指标进行打分。当你第一次使用指标分析时，会发现这更像是一门艺术。如果你有一个稳定的基线，并且所在组织会进行收集分析，你可以得到细颗粒度的结果。如果你刚刚开始尝试，我建议假设大概有1/4的人的回复是无效的或者不回复。如此一来，大致有75%的用户从漏斗顶部进入，有25%的用户数据是有效的。我们使用这种方式以期可以获得更有效的数据。

• 75%的评估会由Slack机器人成功发送
• 其中，60%的热团队成员会响应Slack机器人
• 在看过团队成员的评估后，产品经理更新了30%的时间评估
• 其中，25%的更新来自团队成员低分评估，25%的更新来自团队成员高分评估

这项技术的关键在于在测试早期不要纠结于这些百分比，而专注于数据收集。75%是怎么来的？部署这个功能，用户会减少50%吗？我们能改进这些数据吗？还是说这些数据只是现状的描述？其实，你在查看数据并且与用户沟通之前，你是不会知道这些问题的答案的。检查这些指标的一个方法是，开始与相关人员进行对话、讨论，这意义远比获得答案更深远。

再完整的概括一下上述内容。

假设：

“产品经理之所以很难评估产生的价值，是因为对内部团队，比如销售、市场、技术和客户成功所知有限。”

测试：

“如果我们利用Slack机器人收集团队成员价值评估反馈，我们可以提升产品经理对优先级评估的参考数据广度。”

期望结果：

• 75%的评估会由Slack机器人成功发送
• 其中，60%的热团队成员会响应Slack机器人
• 在看过团队成员的评估后，产品经理更新了30%的时间评估
• 其中，25%的更新来自团队成员低分评估，25%的更新来自团队成员高分评估

在测试中，我们会检查所有的信息：

• 对观察到的假设以及可能的原因进行清晰的陈述
• 测试用来检验造成观察到的结果的假设
• 在具体环境中通过一系列的产出校验我们的假设

这个测试会为我们提供数据告诉我们是否在解决客户问题和支持假设上方向正确。这种测试会成为我们项目初始化的主要推动，或者他们会成为一个没达成我们期望的好主意的垃圾堆。不论如何，这个过程让我们对如何让创意成功不那么重视，而将注意力转移到观察这些创意的效果，并反思这些数据对我们下一步行动的启发和建议。长此以往，我们的协作会更顺畅，我们的组织会更成功，我们将更加信任作为决策者的产品经理。

你在自己的公司内部如何进行测试？耗费多久？

设置期望成功的指标的流程是什么？在收集数据时有足够的灵活性吗？

为测试收集数据是否对你们公司制定路线图的决策有帮助？

作者：Danny Gold

译者：小婧，一名行走在实践路上的资深业务分析师（BA），个人公众号：与小婧同行 （xiaojing-jessieyj）。

原文地址：https://medium.com/pathtoproduct/applying-the-scientific-method-to-product-management-953ca4a51758

本文系人人都是产品经理翻译团队@小婧 翻译，未经本站允许，禁止转载。

题图来自PEXELS，基于CC0协议