当产品团队开始新产品发现任务时，他们的主要工作是减少不确定性。最初的调整和研究可能会让人觉得是可以预测的，返利app可信吗，而且几乎是线性的。但一旦第一个假设被证明是错误的，团队就需要正确的路线。产品发现的复杂性会让人感到难以承受，但试图用其他公司开发的蓝图来克服它却很少是可行的解决方案。发展你自己的方法更重要。在这篇文章中，我想分享为什么我相信你的产品团队的个性是有效产品发现的秘密超级力量。个人故事：速度固定，按数字绘制产品发现，和实现我亲身体验过严格的（和"可预测的"）产品发现方法。我已经在无休止的迭代中创造了我自己的公平份额，却没有创造清晰。当我在2012年拿到CSPO证书时，我确信我对构建优秀的数字产品了如指掌。我确信，作为一名产品经理，我的突破性成功是不可避免的。我所要做的就是确保我的用户情景包含足够的细节并遵循模板。我能够按需背诵敏捷宣言。我主要通过团队的产出和利益相关者对解决方案的满意程度来定义我的角色的成功。我优先考虑提高sprint速度和保持截止日期，而不是不断改进用户行为。这是我所关心的。但有一次，我开始质疑新想法是如何在我们的积压工作中找到的。必须有一个更好的方法，而不是模仿竞争对手，抓住新的设计趋势，等待首席执行官的最新"伟大创意"。在经历了一段时间忙碌的产品经理之路后，我开始了解产品发现和双轨敏捷。我立刻爱上了这两个想法。不幸的是，这段爱情故事结局并不好。我在没完没了的产品发现迭代中迷失了方向，试图一步一步地遵循其他"著名"公司的流程。当我觉得我不能完全跟随他们的方法时。我们没有去探索问题空间，也没有找到新的解决方案，反而成了我们在Twitter和media上找到的模型的牺牲品。示例：我们研究了运行"精益初始"的概念，因为它是由一些涉众建议的。我们希望能明确界定一个最有价值球员的范围，并制定一条前进的道路。不幸的是，我们没有强大的用户洞察力。我们不清楚这个问题是否值得解决，也缺乏真正的跨职能视角。精益初始阶段是启动"敏捷项目"的一个"成熟"过程，在内部被视为一个非常进步的步骤。唉，虽然《盗梦空间》是"伟大的"，但我们最终以纯粹的河马驱动的瀑布模式结束（讽刺的是，这从一开始就是研讨会的主要输入）。从那时起，我与不同行业和公司规模的团队一起工作，既有内部产品负责人/经理，也有外部产品教练。我对如何才能有效地发现产品的看法已经发生了巨大的变化（我相信，会有更好的结果）。在解释发现和交付是如何齐头并进的同时，最流行的双轨敏捷可视化也暗示了一种线性，它与团队每天面对的混乱现实脱节。使发现迭代适应现有的sprint节奏是有限制的。同样，团队不应该感到有义务将每一个新发现的想法转换成一个开发冲刺。我相信这种僵化的存在是因为sprint中对输出的重复关注为涉众和团队提供了"舒适区"。只要新的想法被推到sprint backlog中，团队的利用率就会保持很高，这意味着总会有更多（感知到的）价值被创造出来。在我与团队的工作中，我经常观察团队试图用更详细的计划和检查表来解决产品发现固有的不确定性。有一次，我和一个团队一起工作，那里的高管们要求进行"大幅度的调整"，以真正改变下一个版本的产品。因此，团队获得了探索新方向的资源。与此同时，从第一天开始，人们就迫不及待地想看到具体结果。控制这种不耐烦情绪的一个尝试是概述在未来几周内将发生哪些具体的发现活动。虽然这种方法有助于提前安排用户访谈和跨职能思维研讨会，但它很快就成了一个"承诺"，几乎没有什么空间可以纠正。这让我重新思考如何帮助团队在产品发现"丛林"中找到自己的道路。我开始相信没有一条路可以统治他们。取而代之的是让团队拥有技能、方法和信心，以定义和执行各自的方法。显然，这在很大程度上取决于公司文化。但这是一种行为上的改变，这种改变也可能是由团队成员个人引起的。对产品发现及其结果拥有所有权是从一个功能工厂到一个授权产品团队的最重要步骤之一。将重点从交付转向以结果为导向的发现派遣产品团队执行发现任务需要不同的心态（尤其是如果公司一直专注于产出）。有效的交付并不能转化为发现工作。团队必须改掉一些习惯。许多公司使用Scrum工件和惯例来阐明他们的交付工作"需要做什么"。虽然理论上说，怎么成为淘客，两周的冲刺应该集中在质量上的冲刺目标上，但是大多数团队成功的最终衡量标准是通过交付"输出"（也就是故事的数量）来定义的。在这个模型中，当团队的速度提高时，团队就会改进。这种思维模式在产品发现过程中崩溃了。为什么？从鸟瞰的角度来看，产品发现的可能阶段可以这样分解：这些阶段彼此建立，但不是连续的/线性的。根据上下文的不同，它们甚至可能没有必要。在一个领域工作并不能保证成功（也不能在所有领域工作）。从某种意义上说，你必须自己写剧本。示例：我正在为一个b2b企业工具开发JIRA集成。经过一些彻底的探索工作，当我们试图推动MVP的采用时，一些困难开始出现。尽管我们已经确定JIRA的管理者是值得关注的演员，但我们并没有与他们直接交谈。真的赶上了我们。甚至虽然我们有一个我们的实际用户喜欢的产品（并证实它解决了一个问题），但JIRA管理员有着完全不同的观点。由于没有直接与他们交谈，我们完全错过了我们需要为他们创造的行为改变。这一认识使我们回到绘图板（也称为我们的影响图），重新考虑我们需要驱动的结果，不仅是我们的主要用户，而且是次要用户，如JIRA管理员。揭示和理解问题空间是一项挑战。但挑战不止于此。这些见解通常很难与实际的业务价值联系起来，这使得发现团队之外的同行和利益相关者的洞察力变得不那么具体。团队必须专注于问题和结果空间，而不是通过早期的特性讨论获得伪认可。虽然您可以更详细地计划下一步的发现，但在下一个实验结束之前，总体路径通常是不明显的。重申以上观点，这与以交付为中心的产品管理相去甚远。该团队的任务是在开始头脑风暴解决方案之前揭示真正重要的行为变化。在此之前，团队必须调整其方法。你需要必要的支持。常见的反模式包括：根据完成的发现活动的速度来衡量团队的成功。这可能有助于您确定发现方法的多样性，云购，北京大数据，但不会帮助您了解这些方法是否与挑战相匹配。把每一个新想法变成一个原始利益相关者想法的另一个版本。没有新见解的无休止的迭代。在某种程度上，你需要重新考虑你的方法。不提交资源/时间，只是名义上做"发现工作"。作为第一步，合作商定一个探索任务的固定时间表。将此时间框视为一个启用约束，企业应用中心，而不是一个尽可能多地检查框的竞赛。团队应以"尽力而为"的方法解决挑战，并尽可能减少任务的不确定性。至关重要的是，团队选择要关注的阶段和使用自己的方法。然而，为了避免对产品发现过程的"黑匣子"印象，它应该与组织的其他成员共享这些决策。虽然在理论上很容易就产品发现的非线性达成一致，但在现实中更难证明跳跃和循环的行为是正确的。在这种情况下，围绕问题空间对齐的好处是一个重要的锚定点。当发现/洞察力没有推动团队"向前"，而是需要退后一步或只是重复，团队需要有一个基础来争辩这一点。在大多数情况下，这应该是最后一个洞察是如何增加或降低团队对实现预期效果的信心的。如果只是"感觉不对劲"，团队将很难证明非线性。我试图鼓励团队建立自己的产品发现工具箱，而不是坚持流行的框架和流程。这不是为了"完成"下一次的探索工作。相反，团队应该努力建立这种力量，并为未来的发现努力增加信心。创建工具箱，提高组织的信任度