产品经理的核心工作，就是通过产品的设计、开发和优化来解决用户或市场中存在的问题。所以，很多人都会认为他们的主要工作职责就是“解决问题”——找出客户的问题并解决它们。
但是，并不是所有的问题都需要产品经理挨个儿去解决的。解决问题的最终目标是通过产品为用户和企业创造价值、放大价值。所以，产品经理的工作重点应该是“致力于解决值得解决的问题，并以最佳方式为客户提供价值”。那么身为产品经理，如何让自己的工作效能最大化？这里有15个探索性问题，可以帮助你理清思路。
每期监测和精编全球高价值情报，为你提供先人一步洞察机会的新鲜资讯，为你提供升级思维方式的深度内容，是为 [ 红杉汇内参 ]。
用约会来类比，下面这些问题就是用来帮助你确认眼前的“心动对象”是否真的值得投入感情的。
首先，你有必要花点时间通过5-Whys分析法进行追问，确保你找到的是可被解决的根本问题，而不仅仅停留在解决表面的症状上。
举个例子来说：
你的产品准备推出某个新功能。你先放出了申请链接，但反响平平；此时你又发现申请测试使用该新功能的流程有点小问题，你很容易会直接以为“反响平平的原因是流程出了问题”，从而只关注怎么解决流程问题。
事实上，没什么人申请使用，很可能是因为功能本身没有带来足够的价值，或者它没有带来客户需要的价值。因此，在开始解决问题之前，先通过挖掘定性的反思与定量数据来做全面分析就显得非常重要了。
这个问题的答案可能并不像你想象的那么简单。在评估问题的影响时，你需要考虑三个维度：
▨ 覆盖范围（Reach）：受此问题影响的客户数量。这是一个真实的、客观的数字。
▨ 强度（Intensity）：这个问题造成的痛苦有多深。这是一个略微主观的评判，比如“弱-中-强”或用数字划分为1到10个等级。但这一评判也应尽可能地基于真实的用户研究。
▨ 用户权重（User segment）：受此问题影响的是哪些客户。你的某些客户对业务来说比其他客户更有价值。此时应引入一定的权重，更重要的客户使用更大的权重。
以此最终来计算：影响=覆盖范围×强度×用户权重
有些时候，客户的需求和公司的目标并不相同。客户想要解决的难题，有时是对公司的盈利毫无帮助的。所以，面对这类问题不妨多想一想：这个问题如果不解决，长远来看会对公司造成什么伤害？有的问题从短期来看，解决它并没有明显的好处，但时间一长，它可能会侵蚀客户对公司的信任，进而影响公司的长期盈利能力。
即使某个问题对客户有显著影响，并且对公司来说解决它也具有盈利潜力，它仍可能与公司的长远愿景不符。举个简单的例子，如果问题出现在网页端，而公司当前的战略重心是专注于APP，那么解决网页端问题就可能偏离方向。
对不符合公司/产品愿景的重要问题果断说“不”，是保持专注的关键。战略的本质在于选择不做哪些事。
资源是有限的，专注于某个问题时，就无法同时处理其他问题。这就是你的机会成本——会因为错失其他机会而带来的潜在损失。
你需要想想，如果不解决当前这个问题，你接下来会去处理什么事情，并确保你能承受因此而产生的代价。
思考“延迟成本”或“无作为成本”是一个非常有价值的思维练习。你会发现，有些问题就像火灾——要么现在解决，要么等着将来重建；有些问题像漏水的屋顶——情况会逐渐恶化，直到整个屋顶塌下来；还有些问题则像一滩积水——虽然烦人，但只要大家知道绕着走，就不会造成实际伤害。
我们再用约会的例子来打个比方。有人会说：“单身非常好的一点是，你有时间好好思考你到底想要什么样的伴侣！”
同样，当你不被某个具体问题缠住时，你就有更多的时间思考更远大的目标。这也是新手和高手的一大区别。高手懂得识别和界定机会，让产品实现10倍的提升，而不仅仅是10%。
JTBD（Jobs-to-be-done，可理解为“真实需求”）框架鼓励你跳出产品可用性问题，从更广的角度思考。当一个用户从伦敦飞往都柏林时，他们的目的并不是为了坐飞机，而是为了与同事见面。如果你是一家航空公司，你的竞争对手不仅仅是其他航空公司，还包括那些远程会议工具。
理解客户选择你的产品背后的真实需求，可以为产品改进提供明确的方向。例如，Airbnb的用户想要的是一次美好的假期体验，而不仅仅是一个住处——所以他们才会把重点放在打造独有的体验上。
建立护城河最常见的方法之一就是创造“规模效应”：当越来越多的人使用你的产品时，产品对每个用户的价值也会随之增加。
这种规模效应在社交媒体（如果没有朋友或关注对象，社交媒体就毫无意义）和交易平台（如果买家找不到所需的产品/服务，或者卖家找不到买家，平台就失去了价值）等产品中尤为明显。不过，你也可以通过为那些通常独自进行的行为（例如锻炼）加入社交元素，来在其他类型的产品中实现规模效应。
规模效应只是建立护城河的一种方式。你还可以通过让用户对产品产生情感依赖、为技术申请专利等方式来阻止客户流失。
你的公司/产品可能几年前也是怀揣同样的雄心壮志诞生的——你把那些有50年历史的老牌公司视为对手，并把自己的解决方案吹捧为革命性的存在。
但是，如果你停止了创新的脚步，短短几年内，你自己可能就会变成那个曾经被你唾弃的老对手。
如今，社会变化的速度比以往任何时候都快，标准也在持续提升。如果不去自己颠覆自己的产品，迟早有人会替你做这件事。
此外，有时候这种“颠覆”并不来自于具体的某家公司，还有外部的社会因素。而且，这种变化不一定是突如其来的巨变。可再生能源的崛起、电动汽车的普及、植物肉替代品、共享工作模式等缓慢的演变，也可能对你的产品产生影响。要时刻保持警觉，因为未来其实已经悄然到来，只是不同行业受到的影响还不太一样。
对于产品经理，人们总有这样一种刻板印象：“产品经理负责发现问题，工程师负责搞定解决方案”。这种印象有时也会让产品经理不太愿意深入到解决方案的领域。
从某一种角度来说，产品经理的确不该独自拍板解决方案，特别是具体指定解决方案。但产品经理仍然应该主导解决方案的发现过程，集结工程师、设计师、数据科学家以及利益相关方的智慧和力量。
简单来说，你想投入多少资源？又希望设计师和工程师在这上面花多少时间？正如“帕金森定律”所言，一项任务往往会用尽你给它分配的时间和资源。所以，尽早明确好界限，并清楚传达给团队，是非常关键的。
一个好的解决方案应该对用户来说是众望所归的，对企业来说是商业可持续的，并且在现有资源和限制条件下是切实可行的。
假如你把前面的问题都已经过了一遍，基本可以认为你的解决方案已经基本满足“众望所归”和“商业可持续”的条件。而在技术和资源方面是否“切实可行”则是你现在需要弄清楚的，比如参考其他技术职能同事的专业知识。
这一过程的重要性再怎么强调都不为过，各种解决方案之间的差别可以说是天壤之别。举个例子，
你所在的团队正在考虑通过APP为用户提供节能建议。以下是几种可能的方案：
• 直接上线一个banner，链接到包含通用建议的博客文章；
• 分解建议，融入APP的各个细节中，以更“原生”的方式展现；
• 针对不同用户提供个性化建议，只展示适用的内容；
• 通过显示节省金额来提供个性化建议……
第三和第四个方案需要用到可能还没有的用户数据，所以目前来看尚不可行。基于这些信息，你可以决定先实现第二个方案，同时研究一下第三和第四个方案的价值，看看是否值得投入开发。而这就需要参考回报递减的临界点。
最复杂的解决方案几乎肯定是成本最高的选项。不过好消息是，你的客户很可能压根不需要它！一个只需一半开发时间的方案可能就已经能完成80%的任务——这里就体现了回报递减原则。
你可以通过构建一个MVP版本来验证这个想法，将其发布给一小部分用户，然后评估效果。通过小步快速迭代的方式逐步优化方案，而不是耗费数月时间去打造一个“完美”的解决方案。
“红队演练”的核心是让你从友商、最严厉的批评者或竞争对手的角度来审视自己的解决方案。“红队”的任务就是找出方案中的漏洞，提出所有可能出错的地方来挑战你。这一演练非常重要，因为你的实际竞争对手之后很可能也会这么做。
此外，你还需要假设一下“最危险的情况”并思考如何降低这样的风险。解决方案往往建立在一系列假设之上——比如客户想要进行某些操作，或者工程师能够以某种方式构建某个功能等。你的团队可能对这些假设有不同程度的信心水平。而且，每个假设对解决方案的成功与否也具有不同程度的重要性。
你可以尝试将这些假设映射在一个以“信心水平”和“重要程度”为坐标轴的2×2矩阵中，这样就能清楚地识别出哪些假设需要优先降低风险。
尽可能避免花几个月时间开发，然后“惊天动地”地推出一个功能齐全的版本。无论你做了多少研究和测试，产品功能的真正考验是在上线后用户的反应。研究和上线之间的时间差越大，需求、趋势和用户偏好发生变化的风险就越高。
因此，建议你分阶段实施开发计划，专注于发布小而具有价值的功能单元，并不断迭代。
这一点对于“你的功能旨在解决明显的痛点”的情况尤为重要。比起一个一年后能100%解决问题的方案，客户会更喜欢一个现在就能缓解60%问题的方案。
在用了上面十几个问题后，你可能已经确定好了问题与其解决方案，那么你是时候思考这个问题了。
如果你的公司正在快速扩张，而你逐渐成为团队中的资深成员时，更要考虑这个问题。别害怕与同事分享——随着企业成长，你需要适时放手，把自己熟悉和擅长的工作交给新人，自己则转向承担更高层级的职责——这正是你成长的方式。
