神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：好的设计师爱上的应该是问题，而不是解决方案，但事实往往相反。在研究解决方案前，值得多下工夫琢磨真正的问题是什么。文章来自编译。
有人说，好的设计师会爱上问题，而不是解决方案。我大抵同意这一观点，对于新客户，我让他们做的第一件事总是描述自己所面临的问题。
几年前，一位客户向我提出了一个请求：“我们的首席执行官试过用我们的产品。结果交易没成功，但又没法查看交易状态。所以，让客户能够跟踪他们的交易是我们需要优先解决的问题。”
我确信你已经发现了问题所在：他们声明的问题是“用户没有这个工具”。
换句话说，这是一份变相的解决方案声明。
但我们没法说服客户的 CEO 做出改变。他“爱上了”没有跟踪工具的问题。经过两年的努力，客户团队没有改变指标，他们终于意识到我们在第一周就告诉他们的事情：他们试图解决的是产品问题，而不是客户问题。
通往开发陷阱的道路上布满了产品问题
开发陷阱（build trap）是指组织更关注功能的交付与开发，而不是这些功能产生的实际价值。—— Melissa Perri，《逃离开发陷阱》
问题陈述最后定义成了产品问题，这绝不是客户的唯一一次。事实上，我看到的大多数问题陈述一开始都是“我们想添加这项功能，你能帮我们定义它吗？”
这是说得过去的，因为这些团队一般是用项目团队的形式组织起来，不是真正的产品团队。他们会被赋予一个产出目标，并且只做出产出范围内的决策。由于关于形态因子的决策通常是由高管曾的利益相关者（如客户的首席执行官）为他们做出的，于是他们就直接跳到了形态因子。
产出驱动规划与结果驱动规划之别：产出驱动规划围绕着功能展开，这会让人在近期产生确定性的幻觉，但却会导致长期的不确定。
由于利益相关者要求团队“开发一个跟踪工具”，因此“用户想要一个跟踪工具”成为了团队努力背后的驱动原则。你可能已经在新闻当中看到过 “用户想要一个聊天机器人”、“用户想要一个仪表板”或“用户想要订阅鼠标”这样的东西。
就根本而言，所有这些团队提出的问题不是“我们的客户有什么需求？”而是“这个产品缺少了什么功能？”
他们在解决的是产品问题。
当成熟度较低的产品团队确实掺和到结果性目标时，情况很少会变好很多额度。虚荣指标（比方说查询次数或电子邮件发送率）会占主导地位，将产品团队锁定在他们最为工具化的形态因子上，而不是让他们选择最合适的渠道来接触客户。
一旦团队的工作被定义为产品问题，纠正这种定性就变得极其困难。不管你怎么验证你的想法，你都不会发现自己走错了路。
当你问“用户希望仪表板具备哪些功能”时，你永远不会听到“用户不需要仪表板”，除非你确实非常擅长读懂字里行间的意思。
产品经理提出想法（问题），开发者开发实现（解决方案）：这种方法论虽没双钻方法论那么出名，但实践上用得更多
这种工作通常被鄙视成走过场——没错——但对于没有经验的从业者来说，这肯定感觉像是在做研究。毕竟，产品经理跟客户交谈了，也去收集反馈及对功能的想法，并根据这些想法制定路线图，然后列出优先待办事项了。你还想怎样？
但根据这些积压事项做出来的功能都会导致用户体验的恶化，因为它们建立在解决“缺少功能”的产品问题的前提上，而不是解决客户没法达成目标的问题。
客户问题成就团队；产品问题毁掉团队
当工作组建立了共同的目标，并制定了实现这些目标的方法，它就变成了一支团队。——《对真正的团队合作与可持续质量文化的更深入理解》
产品团队没有意识到自己犯了这个错误，因为团队把焦点放在定义用户故事与实现功能上（产品经理受训就是按照这种方式解决问题的）。甚至 Marty Cagan 也没有把“它是否解决了用户的问题”列入四大风险之一（“被人会买吗”最接近，但完全不是一回事）。
相反，Cagan 将 UX 设计（最适合捕捉这种风险的职能）归入“可用性”类别，很多产品经理也纷纷效仿。
所以说，产品团队设计师花费的大部分时间都用在解决工具问题，而不是目标问题上——琢磨的是如何让某个功能更易用，或者如何添加更多选项与设置。而且，鉴于每个工具问题从定义上来说都是团队自己制造出了的问题，解决这些问题的总体影响极低。
当然，设计师在解决设计问题和解决客户问题方面同样负有责任。或者甚至负有更大的责任，因为我们这个行业的设计理念是激励其他设计师为其他设计师而设计 — — 用奖项给同行留下深刻印象，用令人惊叹的作品集视觉效果让招聘经理眼花缭乱。
而对于这种现象，软件开发者也有自己的版本；比如想靠发布 MVP 来了解客户需求，很快就会演变成逐步解决有趣的编码问题，但代价是没法对用户体验做出可衡量的改进。
做出瑞士军刀需要解决一大堆产品、设计和工程问题，但这玩意儿能解决什么客户问题呢？
结果呢？产品三角的三条“腿”最终设定了自己的目标，并为此打个不停。确定优先级的过程变成了讨价还价：我们要解决这么多的产品问题、这么多的设计问题、这么多开发者问题。
当每个人都在为自己讨价还价时，就没有时间去体谅顾客了。
其结果是形成了一整个由各种为了替员工以及像他们一样的人解决问题的产品构成的行业。
关注客户，忘掉产品
从客户需求出发逆向而行任务艰巨。但它能为你节省更多工作。——杰夫·贝佐斯
这个问题根深蒂固。这是我们谈论产品的根本原因：客户“渴望”产品的思维模式影响了产品思维 20 多年。
事实上，客户不渴望任何产品。客户有自己想要的结果，而产品可以帮助他们实现这些结果。虽然任何成功的产品策略最终都必须选择从什么层面展开，但选择在小工具的层面上展开，然后在资金耗尽之前努力实现产品市场匹配却是最没效率的一种。
产品团队不应该根据利益相关者的要求来预测产出，而应该从利益相关者希望实现的目标开始，然后根据这些结果进行反向预测，从而规划出可能的前进道路。
然后，你就不需要确定功能的优先级，而是可以在不会损害灵活性的情况下选择一个赌注：接下来的哪一步能帮助我们尽量了解到可行的前进道路是什么样的？
结果可能不是全世界最吸引人的应用。我的团队最终说服了这位固执的客户接受的解决方案根本就没有web的存在——因为用户其实并不想访问网站。我们直接用短信向用户发送需要的信息。这种开发速度快，测试成本低，而且——最重要的是——相对于大多数人永远都不会看到的网站上的跟踪工具，这种方式能让客户更了解情况。
译者：boxi。
