很多时候，客户对他们想要解决的问题提出的是一个“假的确定性”需求。他们可能没有定义真正的问题需求，而是经常定义解决方案。
风险在于如果将其误以为需求我们可能构建错误的系统。软件团队希望能够探索问题的不确定性，以便创建一个出色的解决方案。当产品所有者与客户合作定义问题时，然后再与团队合作定义解决方案，每个人才可以获胜。
以下是一位产品经理如何学会接受不确定性并创建实际解决问题的解决方案。新来的产品经理保罗开始没有识别出真正需求，被假需求误导了，后来才发现真正需求是通过捆绑销售更多许可证。
让关键队员在一起
产品经理保罗很沮丧。他之前曾在保险公司工作过，所以他非常清楚他们可能会做些什么来改变他们卖保险的方式以及卖什么样的保险。但他无法让销售副总裁同意。
他与销售副总裁进行了电话会议。销售副总裁无法与保罗就该团队应该解决的问题达成一致。保罗认为他们应该关注那些购买更多保险产品的客户。这意味着改变产品的建议引擎。
老板认为他们都设置好了建议引擎。他想突出他们的产品高于对竞争对手的特点。
老板对页面上的徽标位置感到兴奋。他认为这是一个品牌问题。
培训副总裁希望确保能够在产品上培训内部人员和客户，她怎么能帮助内部人和客户意识到他们有更多选择？
保罗认为老板没有明确说明团队需要解决的实际问题。
首先，保罗自己工作了几天，试图写小故事。但他不明白这项努力的目标。他不再写故事，于是决定再次与大家见面。
分享问题的不确定性
保罗设法让销售副总裁进入会议室，并解决了他对业务成果缺乏了解的问题。最初，销售副总裁似乎对他很恼火：“你不知道你在做什么吗？”他们问道。他依然继续推动，并依次再次询问他们，“业务将如何从建议的变更中获益？”
他听到了下面有关的建议，带着一点点的嗤之以鼻：
- “我们会增加销售额”
- “我们将有一个有吸引力的网页”
- “我们将能够培训我们的客户”
保罗解释说，他想要一种衡量变革成功程度的方法。“我们怎么知道我们提出的建议是否有效？”
这个问题困扰了他们。
他们沉默地坐着，思索着。最后，培训副总裁说：“如果我们能够及早和经常培训客户，他们可能会购买我们想要出售的附加产品。他们可能会鼓励更多人为他们的组织购买许可证。“
销售副总裁同意了。“这就是我们想要出售的产品：通过捆绑销售更多许可证。”
保罗现在了解整体业务问题：能够销售更多许可证，因为更多的人捆绑了更多的保险。
他向小组重复了这个目标。他们都点了点头，暗示了一些协议和理解。
分享定义不确定性
现在保罗理解了他们想要解决的问题，他已经准备好与团队合作来定义和完善这个问题的定义：故事。
他并不喜欢“故事”的概念，尽管他确实喜欢考虑顾客帮助他描述问题的方式。
在过去，保罗已将要求分解为用例。他使用了很多年的用例，并且喜欢他可以创造快乐的路径和替代路径。但他并没有因为不得不像团队所希望的那样将用例分开，而是对那些恶劣的用户故事感到兴奋。
他带着一大杯黑咖啡开始工作。使用VPs对问题的定义，他写了一系列用例。几个小时后，他带着一堆卡片离开了办公室，准备好在早上送给团队。
分享答案不确定性
第二天早上，保罗带着同样大的咖啡坐下来与团队一起向总裁提出问题。
他没有讨论他是如何与团队达成这些答案的。当他解释，他听到了这些担忧：
- “好吧，这永远不会奏效”
- “这是不可能测试的”
- “这不符合我们的架构，所以它不会起作用”
- “这些故事或案例或其他任何你想称之为甚至可以解决问题的方法？”
每个团队成员一直在研究该产品至少两年。然而，保罗只在这个组织工作了六个月。团队成员对产品和客户更加熟悉。
从需求不确定性转向实验
保罗很累，很沮丧。他问团队，“那么，你会做什么呢？”
其中一位资深开发人员表示，“让我们考虑实验，这样我们可以从我们的副总裁那里获得反馈。我认为你已经用你拥有的数据完成了所有工作，但我认为你没有足够的数据。“
其他团队成员插话。他们创建了一个可能的实验列表：
- 纸质原型检查保险包的流程如何运作
- A / B测试验证徽标定位的有效性
- 在最初的纸张原型之后，收集使用数据长达一周，以查看订购保险包的用户界面是否会对销售产生影响
他们又做了几个实验。当团队通过假设时，他们发现了解决问题的更多机会。例如，该团队发现订单有所不同：如果他们以增加的价格显示附加组件，人们更有可能在其捆绑包中添加更多产品。
没有全部的答案
我们经常要求产品经理提供所有答案。他们无法知道一切，PO必须依赖解决问题的人。他们可能不是识别问题的专家，但他们是解决问题的专家。
尊重问题标识符和问题解决者的能力。当每一方都相互尊重时，他们会进行有用的对话并经常做出更好的决定。
提出解决方案既是有功的，但也是创造假的确定性。解决方案一词意味着确定不存在。
当您向客户提供解决方案时，您可以围绕团队如何解决问题创建共享的确定性。您无法保证团队将以这种方式解决问题。当你承诺时，客户相信他们会得到你所承诺的。
当你向团队提出解决方案时，它会更加危险。当你说怎么你想有一个团队来解决一个问题，你妨碍他们的想法和可能性。您可能最终会在团队创建代码时不再需要这样做。
实际上，在您找到解决方案之前，你只会遇到问题 - 解决客户问题的工作成品。在此之前，你所拥有的只是一个假设。围绕假设建立确定性的唯一方法是进行实验和学习。
伟大的团队在实验方面非常出色，这是问题发现的核心。让他们努力解决你带来的问题，并告诉他们你尊重他们的想法。而你最终可能会得到一些辉煌的东西。