产品|制定“小目标”，了解产品管理中的结构化思维( 二 )

1. 症状对于每个问题或机会，你目前所处的位置（观察）和你想要达到的位置（愿望）之间都存在差距。这些差距代表了有待确定的问题症结。
例如，你目前有 10 万用户，但希望拥有 25 万用户，那么这 15 万的差距就是症结。这是一个简单的例子，但症结可能来自用户访谈、分析、请求等，你只需要明确现状和愿望即可。
识别症结需要注意：
1）某些简单的说明并不是症结
例如，有人可能会说用户界面令人困惑。这不是症结——这是某人对更基础问题的说明。将症结与简单说明区分开来很重要，因为如果你接受了表面的说明，就可能会忽略其他潜在的解释。
2）明确且具体现在需要解决的问题
在大范围内解决模糊问题是不可能的，请确保及时明确症结。如果说现实与愿望之间的距离是一个永恒的问题，比如“我们想赚更多的钱”，那么它是一个过于模糊的症结，无法指导行动。
3）考虑外部 / 环境因素
你不是在真空中运作，重要的是承认环境的变化可能会引起症结或创造机会。
2. 成功如果你不清楚成功是什么样子，就很难解决问题。提出以下问题是一种有用的技巧，可确保你的团队保持一致，以免陷入用解决方案定义问题的陷阱。
这个项目会在何时取得巨大的成功？它的模样会是怎样？
弄清楚如何衡量成功可能很困难。水晶球测试是一种有用的技巧，在了解人们如何使用产品的基础上，继续追问，产品成功的样貌应该是怎样的？
想想人们如何受益，以及某种改进后可以观察到什么？遵循价值。
3. 约束清楚你的项目边界是非常重要的，以便你在探索解决方案时了解各种限制。

你有多少时间？截止日期背后的原因是什么？
有哪些资源可用？
开发解决方案时的风险偏好如何？
成功指标的限制是什么？

对于最后一点，可以借鉴反向护栏地概念。例如，你可以通过将产品成本减半来提高注册转化率，但这现实吗？尽早进行这些讨论将有助于澄清界限，了解哪些权衡是可以接受的。
4. 演员从最终用户到利益相关者，重要的是要明确：

谁正在经历这些症状；
谁负责项目的各个方面；
谁最终对成功负责（提示：很可能是你，PM）；
开发解决方案时应该咨询谁，需要谁批准。

尽可能多地收集信息，并与你的团队一起审查以确保每个人都保持一致。可能会有一些领域你不完全清楚——这是意料之中的。但至少你明确了已知和未知，而不是隐含的假设。
三、构建问题框架 Frame the problem很多时候问题比答案更难。如果你能正确地表达这个问题，那么答案就是简单的部分。
——埃隆·马斯克
构建问题框架，是我们在面临艰巨挑战时所采取的最重要步骤之一，但它常常被忽视。你是否在被人问过一个事后看来非常明显的问题后，极大地改变了你处理问题的方式？也许这一切会让你感到惊讶，但这就是优秀框架的力量。这些 “催化” 问题可以揭示盲点并开辟新的探索途径。
缩小框架以创造焦点与扩大框架以鼓励创造性解决方案之间，存在着一种自然张力。在确定问题范围时，应该通过与更广泛的团队讨论相关限制，找到两者的平衡点。
对于分析选项来说，聚焦更为重要；如果想要扩充更多选项则不宜过早聚焦。一般的经验是：在问题探索的早期阶段保持框架尽可能宽。
以下内容，可以帮助你发现 “催化” 问题。
1. 问题风暴在 Hal Gregersen 的《问题就是答案》一书中，他建议召集一个跨职能的利益相关者小组，并为他们提供问题的高级概述（症状、成功、限制、参与者）。