编者按：如果有人问你，一个人最大的能力是什么？你也许会回答：解决问题的能力。是，解决问题的能力很重要，但是，如果你解决的是错误的问题，这种能力就完全是浪费。作为一名产品经理，你需要提出对的问题。这里有17个问题可以帮助你锐化思维，文章来自编译。
如果几年前有人让我用两个词提炼产品管理这个角色的话，我会说：解决问题。这不就是我们的主要工作吗？找出客户的问题是什么，然后加以解决。 砰，搞定，掌声在哪里？！
热衷于解决问题的问题在于，一旦我看到一个问题，我的本能反应是“我该如何解决？”我太容易被太多的问题所吸引了。这意味着：
往往所有问题我都想自己解决，然后很快就会筋疲力尽。
当我没法获得足够的支持和资源来解决问题时，我也常常感到沮丧。
而且，最糟糕的是，在执行解决方案时，我很容易会感到无聊，因为我已经爱上了另一个问题。
在经历了太多的倦怠和沮丧之后，我吸取了教训。如果你现在问我，我的工作是什么，我会回答：价值倍增。这意味着我只致力于解决值得解决的问题，为客户提供最佳价值。
把注意力放在增加价值而不是解决问题上，这样其实你会成为更好的问题解决者。
以下列举了 17 个探索性问题，可帮助你锐化思维能力，问题共分为 3 个部分。
第 1 部分：评估问题有没有解决的价值
如果问题你已经有了，那么本节就很有用。你可能会在看客户反馈、与支持团队交流，或者在看客户录音的时候遇到这一节的内容。用约会来打比方，这是为了确保对方值得你陷入爱河。
#1：这个问题是不是只是某个更大问题的症状？
花点时间，连续问 5 个为什么，并确保找到可以解决的根本原因，而不只是头痛医头脚痛医脚，这种说法永远都是值得的。
举个简单的例子：如果某个功能的注册率很低，而你发现表单存在一些可用性问题，你很容易就会单刀直入试图修复这些表单问题。（或者更糟糕的是，你先看到了可用性问题，然后你研究起注册号来，想确认这是不是问题。而这就是确认偏差！）
与此同时，注册人数可能很少，因为这一功能其实没太多价值（质量问题），或者没有给客户带来他们需要的价值（产品市场匹配问题）。这就是为什么做定性和定量分析很重要，这样才能全面了解情况。
#2：这个问题对客户有多大影响？
有人会用要么“锦上添花”，要么“必须拥有”来回答这个问题，没那么简单。在评估问题的影响时，你需要考虑三个方面：
覆盖面：这个问题影响到的客户数量。这个数字是真实、客观的。
强度：这个问题的痛点有多痛。衡量可以粗颗粒度一点，用低-中-高划分，或者也可以用 1-10 的尺度，颗粒度由你决定。给出的分值应尽可能基于用户研究。
用户细分：受此问题影响的客户是谁。对企业来说，有些客户比另一些客户更有价值。在这一点上，可以采用系数，比如细分客户 A 和 B 的系数是 1x，但细分客户 C 的系数是 2x 。
影响 = 覆盖率 * 强度 * 用户细分
这三个维度都考虑到可以让你更全面地评估问题的重要性。
#3：解决这个问题对公司有什么好处？
知道吗，客户需要的和公司想要的未必总是一致的。当公司不在乎某件事情，因为这件事情对他们来说无利可图时，我就是那个眼睛明亮、充满理想主义的年轻女性。毕竟，成立公司是干什么的？不就是为了通过满足客户的需求来赚取利润嘛。
我可以告诉你一个能从中受益的技巧：思考一下，看看这个问题从长期来看会如何损害到公司的利益。也许短期内缺乏明确的诱因促使企业解决这个问题，但慢慢地，这个问题会削弱客户对公司的信任，并损害企业长期的盈利能力。
#4：它是否符合公司/产品的长期愿景和战略？
就算问题对客户有影响，而且解决问题对公司来说也有利可图，但仍可能与公司的愿景不一致。举一个简单的例子，如果问题出在 web 端，而公司希望专注于 app。
当某个重要问题与公司/产品的愿景不一致时，对它说“不”对于保持专注就至关重要了。借用迈克尔·波特的话来说，“战略的实质就是选择不做哪些事情。”
#5：为了做这个你需要降低什么事情的优先级？
你的资源有限，一旦处理某个问题，就意味着其他问题没有处理的机会。这就是机会成本：错失机会带来的潜在损失。
如果打算不解决这个问题的话，要思考接下来要干什么，并确保做那件事情的代价你负担得起。
#6：如果什么都不做会发生什么？
思考延迟的成本，或无所作为的成本，这是一项非常强大的思考练习。你还会发现，有的问题就像一场大火——要么现在就破灭，要么就得等以后再重建。有的问题则像漏水的屋顶——会慢慢变得越来越糟，直到整个屋顶都倒塌。还有一些问题就像一滩水——很烦人，但只要每个人都知道绕着走，问题就不会伤害到任何人。
第 2 部分：找到重要的问题
还是拿约会来打比方，知道智者怎么说吗，“单身其实挺好的，因为你可以思考自己真正想要的伴侣是什么样的！”同样地，当你不去想某个特定问题时，就会有更多的空间去思考大局。
初级和高级产品经理之别往往就体现在这里。高级产品经理能发现并确认将产品提高 10 倍的机会，而不是仅仅提高 10%。
#7：客户要完成的工作是什么？
要完成的工作（JTBD）这个思维框架能让你站在更高的角度去思考问题，而不是仅考虑产品的可用性。用户从伦敦飞往都柏林时，他们的目标不是坐飞机，而是与同事见面。如果你是航空公司，你的替代威胁不仅仅是同行的航空公司，还有 Zoom 和 Google Meet。
要了解客户为什么要“雇用”你的产品，这可以明确产品的改进方向。 Airbnb 的用户希望度过一个愉快的假期，而不只是有个住的地方——于是，Airbnb Experience 就诞生了。
#8：如何为产品建立更深的护城河？
护城河是环绕着城堡的深水池——这是保护城堡免受攻击的一种手段。给业务或产品建立护城河，就是让新进入者或竞争对手难以窃取你的客户。
建立护城河最流行的方法之一是创造网络效应：使用产品的人数增加，会增加产品对每一位用户的价值。
社交媒体（如果你没有朋友，或者无人可以关注，那这个社交网络就毫无用处）或交易市场（如果客户找不到自己需要的产品/服务，或者卖家找不到任何买家，交易市场就毫无用处）等产品的网络效应就很明显。找不到任何买家）。但你也可以给一般是自己完成的活动（比方说锻炼或者投资）增加社交元素来给其他产品实现网络效应。
网络效应只是建立护城河的方式之一。你还可以通过对产品建立情感依恋、为技术申请专利等来阻止客户把挖走。
#9：如果某个新的创始人要写份 PPT 来颠覆我的行业的话，他会怎么评价我的公司/产品？
你的公司/产品也许也是几年前成立的，也有着一样的雄心：要颠覆一个已经坏掉的行业。你把有着 50 年历史的公司当作敌人，并将自己的解决方案定位成革命性的救星。
如果你停下创新的脚步，很容易在短短几年之内就沦为那个老朽的敌人。
社会的发展速度日新月异，门槛也在不断提高。如果你不颠覆自己的产品，别人就会来颠覆你。
#10：未来什么样的情况会让我的产品变得无关紧要？
疫情给许多公司都造成了打击。要靠人出游或聚会的产品突然陷入瘫痪，被迫迅速转向在线活动或靠其他方式赚钱。
Covid-19 这种规模的疫情可能每世纪都会发生一次，但这并不意味着就不会有其他情况导致你的产品变得无关紧要了。比如监管发生变化就是可能情况之一。
这未必就是一夜之间发生的革命性变化。可再生能源、电动汽车、植物性肉类替代品、工作共享等的缓慢发展也可能会影响你的产品。要保持警惕，因为未来已来，只是分布不均。
第 3 部分：发现最佳的解决方案
说到产品发现，一般关注的焦点是问题发现。 “产品经理拥有问题，工程师拥有解决方案”这句老话也可能导致产品经理不愿进入解决方案领域。
我完全同意产品经理不应该做决定，或者孤立地指定解决方案更是不可行。但是，产品经理依然应该通过积累工程师、设计师、数据科学家以及利益相关者的专业知识，从而推动解决方案的发现过程。
#11：我们对解决这个问题有多大的兴趣？
简单来说，你想分配多少资源进去？你希望设计师和工程师在这方面花费多长时间？就像帕金森定律的建议那样，任务可以扩展，从而填补被赋予的时间和空间。
要尽早澄清边界，并告诉团队，这一点非常重要。
#12：开发什么才是可行的？
用户需要一个好的解决方案，方案对企业来说需要是可行的，而且可以利用手头的资源，在一定的约束下开发出来。
假设问题 1-11 的作业你已经做完了，并且假设你的解决方案是别人想要而且商业上也可行的。接下来就是工程的可行性了，你得利用自己的工程师（以及其他技术职能，如数据科学家）的专业知识来弄清楚能不能做出来。
这个发现的重要性怎么强调都不为过。不同的解决方案有着天壤之别。比方说，我在 Bulb 的团队正在探索在这款 app 上提供节能建议。解决方案可以是以下几点的组合：
创建一条横幅广告，链接到包含一般建议的博客文章
拆解建议，让建议看起来似乎是 app “原生”的
仅显示适用于用户的建议，提供建议的个性化（比方说，如果房屋是新建的，就不要说“改善房屋的隔热”这样的话）
显示节省下来的金额，提供个性化建议（比方说，这样做的话，你每年可以节省 20 英镑）
第三和第四个解决方案需要有用户数据，但我们未必掌握，因此目前可能不可行。有了这些知识，你就可以做出决定了，比方说现在先做第二个解决方案，同时对第三和第四个的价值做一些研究，看看是否值得去做。而这又让我想到了下一点：收益递减。
#13：收益递减点在什么位置？
最复杂的解决方案几乎肯定是开发成本最高的解决方案。好消息是，你的客户未必需要！花费一半时间开发出来的解决方案也许就能完成 80% 的工作——收益递减原则大概也适用于此。
怎么测试这一点？可以开发解决方案的 MVP 版，发给一小部分用户，然后衡量它的影响。通过小小的迭代不断改进解决方案，而不是花费数月时间开发一个完美的解决方案。
#14：红队对这个解决方案有什么看法？
“红队”是假想敌练习，把你的解决方案当作敌人、最大批评者或竞争对手。红队的工作是寻找解决方案的漏洞，并用所有可能出错的地方来挑战你。这个练习非常有用，因为你的真正的竞争对手到后面可能会做同样的事情。
你也可以想象，自己也许会收到最冷嘲热讽的新闻评论。尤其是如果你的公司受到很多关注的话，这种情况完全是有可能的。 （那篇标题为“Facebook 要求用户提供裸照”的新闻是什么时候发的我还记得……）
#15：最危险的假设是什么？怎么才能降低它的风险？
解决方案基于假设——客户想要执行某些操作，工程师可以用某种方式开发某些东西，等等。你的团队对这些假设的信心水平可能会不一样。而且每个假设对于让你的解决方案行得通来说，其重要性也不一样。
不妨用四象限法来对这些假设进行分类，其中横轴代表置信度，纵轴代表重要性，这样就可以确定需要降低哪些假设的风险了。
#16：我们能提供的价值的最小切块是什么？
我会尽量避免连续开发几个月，然后一次性发布一个成熟的功能。不管你做了多少研究和测试，对于功能的成功来说，真正考验是被发布出去的时候。研究和发布之间的时间差会增加需求、趋势和需求发生变化的机率。
出于这个原因，我一直主张要分阶段制定开发计划。专注于释放小块的价值，然后不断迭代。
如果你的功能解决的是明显的痛点，这一点也很重要。你的客户会喜欢马上就能缓解 60% 问题的解决方案，而不是在一年之内缓解 100% 问题的解决方案。
#17：我是解决这个问题的最佳人选吗？
你一定很困惑吧——什么？！为了细化这个问题并定义解决方案，你问了我 16 个问题，然后还想让我把这个交给其他人干？
是的，尤其是如果你的公司正在迅速扩张，而且你正在成为团队更资深的成员的话。不要害怕放弃你的乐高积木——只有这样你才能真正成长。把问题解决授权给资历浅一点的团队成员，你可以学习新技能（比方说委派、指导的技能）以及腾出时间做更有影响力的工作。
译者：boxi。