构建您自己的产品发现工具箱
已发表: 2020-03-16当产品团队开始一项新的产品发现任务时，他们的主要工作是减少不确定性。 最初的对齐和研究可能感觉是可预测的并且几乎是线性的。 但是一旦第一个假设被证明是错误的，团队就需要改正。
产品发现的复杂性让人感到难以抗拒，但试图通过其他公司开发的蓝图来克服它很少是可行的解决方案。 发展自己的方法更为重要。 在这篇文章中，我想分享为什么我相信你的产品团队的个性是有效产品发现的秘密超级力量。
个人故事：速度固定、数字绘画产品发现和实现
我亲身体验过严格的（和“可预测的”）产品发现方法。 而且我在没有创造清晰的情况下造成了我自己公平的无休止迭代。
当我在 2012 年收到 CSPO 证书时，我确信我对构建出色的数字产品了如指掌。 我确信我作为产品经理的突破性成功现在是不可避免的。 我所要做的就是确保我的用户故事包含足够的细节并遵循模板。 我能够按需背诵敏捷宣言。
我主要通过团队的输出和利益相关者对解决方案的满意程度来定义我的角色的成功。 我优先考虑提高冲刺速度和保持最后期限，而不是不断改善用户行为。 这就是我所关心的。
但有一次，我开始质疑新想法是如何在我们的积压工作中找到的。 必须有更好的方法，而不是抄袭竞争对手、抓住新的设计趋势、等待 CEO 最新的“好主意”。
在做了一段时间忙碌的产品经理之后，我被介绍了产品发现和双轨敏捷的想法。 我立刻爱上了这两个想法。
不幸的是，这个爱情故事的结局并不好。 我迷失在无休止的产品发现迭代中，并试图一步一步地跟随其他“著名”公司的流程。 当我不能完全遵循他们的方法时，我觉得我不知何故失败了。 我们没有探索问题空间并得出新的解决方案，而是成为我们在 Twitter 和 Medium 上挑选的模型的受害者。
示例：我们研究了运行“精益起步”的概念，因为它是由一些利益相关者提出的。 我们希望明确 MVP 的范围并规划前进的道路。 不幸的是，我们没有强大的用户洞察力。 我们不清楚这个问题是否值得解决，也缺乏真正的跨职能视角。 精益起步是启动“敏捷项目”的“经过验证的”过程，在内部被视为非常进步的举措。 唉，虽然一开始是“伟大的”，但我们最终还是采用了纯 HIPPO 驱动的瀑布模式（具有讽刺意味的是，这从一开始就是研讨会的主要输入）。
从那时起，我与不同行业和公司规模的不同团队合作——既作为内部产品负责人/经理，也作为外部产品教练。 我对如何使产品发现有效的看法发生了巨大变化（而且我相信会变得更好）。
在解释发现和交付如何齐头并进的同时，最流行的双轨敏捷可视化也暗示了一种与团队每天面临的凌乱现实分离的线性。 使发现迭代适应现有的冲刺节奏是有限的。 同样，团队不应该觉得有义务将每个新的发现想法转变为开发冲刺。
我相信这种僵化的存在是因为“舒适区”重复关注冲刺中的输出为利益相关者和团队提供了。 只要新的想法被推到 sprint backlog 中，团队的利用率就会保持很高，这意味着总会有更多的（感知的）价值被创造出来。
在我与团队合作的过程中，我经常观察团队试图通过更详细的计划和清单来解决产品发现固有的不确定性。
有一次，我与一个团队合作，那里的高管要求“大刀阔斧”地真正改变产品的下一个版本。 因此，该团队获得了探索新方向的资源。 同时，从第一天起，就可以看到具体结果的不耐烦。 控制这种不耐烦的一种尝试是概述在接下来的几周内将发生哪些具体的发现活动。 虽然这种方法有助于提前安排用户访谈和跨职能创意研讨会，但它很快就变成了一种“承诺”，几乎没有什么可以纠正的余地。
这让我重新思考如何帮助团队在产品发现“丛林”中找到自己的道路。 我开始相信，没有一条路可以统治他们所有人。 相反，它是关于为团队提供技能、方法和信心来定义和执行他们的个人方法。
显然，这在很大程度上取决于公司文化。 但这是行为上的改变，也可能由个别团队成员引发。 掌握产品发现及其结果的所有权是从功能工厂到授权产品团队的最重要步骤之一。
将重点从交付转向以结果为导向的发现
派遣产品团队执行发现任务需要不同的心态（尤其是如果公司一直专注于输出）。 对交付有用的东西并不能转化为发现工作。 团队必须忘掉一些习惯。
许多公司使用 Scrum 工件和仪式来阐明他们的交付工作——“需要做什么”。 虽然理论上 2 周的 sprint 应该专注于定性的 sprint 目标，但大多数团队成功的最终衡量标准是通过交付“输出”（也就是故事的数量）来定义。 在这个模型中，当团队的速度提高时，团队就会进步。
这种心理模型在产品发现过程中崩溃了。 为什么？ 从鸟瞰的角度来看，产品发现的可能阶段可以这样分解：
这些阶段相互建立，但不是顺序/线性的。 根据上下文，它们甚至可能不是必需的。 通过一个领域工作并不能保证成功（也不能通过所有领域工作）。 从某种意义上说，您必须编写自己的剧本。
示例：我正在为 b2b 企业工具进行 JIRA 集成。 经过一些彻底的发现工作，当我们试图推动 MVP 的采用时，一些困难开始出现。 尽管我们已经将 JIRA 管理员确定为值得关注的演员，但我们并没有直接与他们交谈。
这真的赶上了我们。即使我们有一个我们的实际用户喜欢的产品（并确认它解决了一个问题），JIRA 管理员的观点完全不同。 由于没有直接与他们交谈，我们完全错过了我们需要为他们创建的行为变化。 这种认识让我们回到了绘图板（也就是我们的影响图），重新思考我们需要推动的结果，不仅为我们的主要用户，而且为像 JIRA 管理员这样的次要用户。
发现和理解问题空间具有挑战性。 但挑战并不止于此。 这些见解通常很难与实际业务价值联系起来，这使得它们对于发现团队外部的同行和利益相关者来说不太明显。 团队必须专注于问题和结果空间，而不是通过早期的功能讨论获得伪支持。 虽然您可以更详细地计划下一步的发现，但总体路径通常在下一个实验结束之前仍然不明显。
重申上述观点，这与以交付为中心的产品管理相去甚远。 该团队的任务是在开始头脑风暴解决方案之前揭示真正重要的行为变化。 在此之前，团队必须调整其方法。 您将需要必要的支持。
常见的反模式包括：
- 根据完成的发现活动的速度衡量团队的成功。 这可能会帮助您确定发现方法的多样性，但不会帮助您了解这些方法是否适合挑战。
- 定期将每个新想法转化为原始利益相关者想法的另一个版本。
- 没有新见解的无休止的迭代。 在某个时候，您需要重新考虑您的方法。
- 不提交资源/时间，只做名义上的“发现工作”。
作为第一步，协作就发现任务的固定时间框达成一致。 将此时间框视为启用约束，而不是尽可能多地检查框。 团队应以“尽力而为”的方式解决挑战，并尽可能减少任务的不确定性。
团队选择要关注的阶段和使用自己的方法至关重要。 然而，为了避免对产品发现过程的“黑匣子”认知，它应该与组织的其他成员共享这些决策。
虽然在理论上很容易就产品发现的非线性达成一致，但在现实中很难证明跳跃和循环活动的合理性。 在这种情况下，围绕问题空间对齐的好处是一个重要的锚点。 当一个发现/洞察不能推动团队“前进”，而是需要退后一步或简单地重复时，团队需要有一个基础来支持这一点。
在大多数情况下，这应该是最后的洞察力如何增加或减少团队对实现预期影响的信心。 如果它只是“感觉不对”，团队将很难为非线性提供理由。
我试图鼓励团队建立自己的产品发现工具箱，而不是坚持流行的框架和流程。 这与“通过”下一次发现努力无关。 相反，团队应该努力建立这种力量并增加对未来发现工作的信心。 创建工具箱并增加组织的信任度是团队掌握其产品发现工作的关键步骤。
概括
我认为是时候挑战“正确”产品发现的想法了。 复杂的环境和不断变化的业务挑战需要适应性并挑战线性、僵化的产品发现过程的想法。
重要的是，团队要充分了解哪些方法适合他们所面临的挑战，并知道如何以有效的方式将它们结合起来。 由于特定的预定义产品发现流程，公司不会成功。 他们之所以成功，是因为他们鼓励团队找到自己的道路，并通过培训和心理安全来支持这种发展。
准备好开始了吗？ 这是一个可以帮助您的奖金。
对我来说很重要的是，您可以从本文中分享的故事中获得一些有形的东西。 为了帮助您做到这一点，我为您设置了一个特殊的奖励部分。
免费奖金包括：
- 为期 6 天的免费 Product Discovery Navigator 电子邮件课程，可帮助您在 Product Discovery 期间坚持课程
- 我在产品发现中克服确认偏差的最佳实践
- 当我运行我的第一个 Discoveries 时，我希望我知道什么
您可以在这里注册进入红利区。