那些令人迷惑的产品，为什么还会被推向市场

前段时间，罗技公司CEO在播客中提出订阅制“永久鼠标”的概念引起了不少人讨论。很多网友直言：“鼠标坏了换个新的不就行了，搞订阅制是在干嘛？”

尽管后来罗技的公关部表示目前并不会生产这样的产品。但日常中我们却不少见到各种令人迷惑的产品以及匪夷所思的功能。那些产品与功能，为什么还会被推向市场？

今天的内容，编译自Pavel Samsonov的文章。他就职于AWS，负责解决客户问题。在他看来，低效的团队总在解决他们自己想要解决的产品问题，而不是基于客户的真实需求。希望可以带给你一些跳脱出现有框架的解法。

以下为正文内容：

有人说，优秀的设计师总是喜欢创造问题，而不是提出解决方案。某种程度上，我是赞同这一说法的。所以我在见新客户的时候，总是会让他们先描述下他们所遇到的问题。

记得几年前，曾经有位合作伙伴向我提出了一个需求。起源是他们的CEO试着购买他们的新产品，但交易没有成功，也无法查看交易状态。因此，他要求把“让所有用户能够追踪他们的交易情况”列在最需要解决的问题上。

看到这儿，你可能会察觉出不对劲的地方——他们在阐述需求的时候的说法是“用户缺这个”。换句话说，他们偷换概念地把CEO的个人需求当作了广泛用户的需求。

但我们一时无法说服合作方的CEO做出改变，他执着地认为“不能追踪交易情况”是个重要的待解决问题。直到他们在这个问题上付出了两年的不懈努力，依旧没有取得什么实际效果后，他们才意识到我们在初次沟通时就点出的关键：他们一味地陷在产品本身的问题上，而忽视了客户的真实需求到底是什么。 

过度纠结于产品问题可能会通向陷阱

在产品经理经典书目《Escaping the Build Trap》中，作者提出了“构建陷阱（Build Trap）”这一概念，是指关注开发新的功能超过了这些功能实际产生的价值。

前面说的情形经常在我跟客户对话的过程中出现。大多数情况下，他们对于问题的描述都归根于“我们想要添加这个功能，你能帮我们实现吗？”

我倒是能够理解这样的原因，因为这些团队通常并非真正意义的“产品团队”，而是“项目团队”——被下定一个需求方向，并围绕这个需求做出行动。而由于这些需求往往是由高管团队下的，如果他们不深入业务实战，就有可能在一些实际中非重要的问题上过度执着。

下面两张图说明了两种思路的区别：左侧为输出驱动（output-driven）团队的计划图，可以看到前期确定性较高，而后期确定性则较低；右侧为结果驱动（outcome-driven）团队的计划图，虽然当下确定性较低，但未来确定性较高。

图源：Medium

输出驱动的团队围绕具体几个功能制定计划，在短期内造成更具确定性的假象。但从长远来看，这样的风险可能要大得多，因为这些被设定的输出与最终的结果之间，并没有实质性的联系。

在开头的案例里，由于CEO要求开发这个追踪功能，这个需求就成为了团队两年努力背后的驱动原则。在平时的生活中，我们也经常会在新闻里看到例如“用户需要一个陪聊机器人”“用户需要一个订阅制鼠标”的类似说法。

归根结底，这些团队的出发点都不是在问“我们的客户到底需要产品解决什么问题？”，而是“这个产品还缺少什么功能？”从而一直在产品层面打转。

而一旦团队的工作方向被指引为是产品问题，纠正这种框架就变得极其困难。无论你做多少努力验证你的想法，都很难不会发现自己开始就走错了路。

当你问出“用户希望仪表盘上有哪些功能”时，很难直接听到“用户不需要仪表盘”的反馈，除非你能够从别人话中揣摩出他们真正的想法。

在绝对的产品问题导向下，产品或者项目经理提出想法，然后工程师来将其实现。这种工作通常会变成“用户体验剧场（UX Theatre，描述一些项目表面上看似采用以用户为中心的设计方法）”，但实际上并没有真正地考虑到用户参与其中的情况。

尽管看起来那些产品经理在孜孜不倦地与客户交流，收集对于产品本身的反馈和功能想法，并根据这些想法制定方案，排出待办事项优先级。但基于这样打磨出来产品有可能会使用户体验变得更差，因为它们是建立在“解决产品缺少的功能”的前提之上，而不是在“解决客户刚需问题”。 

看似功能完美的产品，客户真的需要吗？

产品团队之所以经常意识不到他们犯了这个错误，因为它已经融入了产品经理被规训的惯性工作方法中。

甚至连硅谷产品大师Marty Cagan也没有把“是否解决了用户的问题”列入产品开发过程的四大风险中，反而把UX设计（用户体验设计）归入“可用性风险”类别，许多产品经理都学习了这种理念。

结果，产品团队花费的大部分时间都用于解决“工具问题”而不是“目标问题”——如何使某个功能更易用，或者如何添加更多选项和设置。鉴于每个工具层面的问题都是被团队自己定义甚至是臆想出来的，解决这些问题对于客户的整体影响非常低。

当然了，产品设计师在过度重视设计、忽视客户体验方面同样负有责任。因为这个行业的现状似乎鼓励设计师为了卷设计而设计，以拿更多产品奖项，设计师也能凭借花哨效果的作品集得到更多的工作机会。

在软件开发领域，也有类似的现象：当他们尝试通过发布MVP（Minimum Viable Product，最小可行产品）来了解客户需求，很快就会演变成不断在解决各种各样的编程问题，而牺牲了对用户体验进行可衡量的改进。

就像配备有各种附件、看似功能无比齐全的瑞士军刀。在制造这把瑞士刀的过程中肯定需要解决大量的产品、设计和工程问题。但很难想象，客户究竟是有什么样的需求，才要使用如此复杂的一个工具来实现。

于是，产品部门中的三方（产品经理、设计师、开发者）为了实现他们各自设定的目标争吵不休。创造和优化产品的过程变成了割裂的各自讨论——将要解决哪些产品问题、哪些设计问题、哪些开发问题。

而当每个人都在为自己负责的部分讨价还价时，还有谁去站在客户角度思考问题呢？ 

跳脱出产品本身，回归客户的真实需求

杰夫·贝索斯曾说，“从客户真实需求出发工作是一项艰巨的任务，但这将为你后续节省更多的工作。”

关于产品定义的问题由来已久。努力打造客户“可能想要的”产品，影响了产品导向思维二十多年。

事实上，对于客户来说，他们不知道想要什么产品，但知道他们想要产品解决什么问题。如果在早期阶段过分执着于从产品角度出发抠细节，等资金快耗尽的时候才意识到寻找PMF（产品市场契合度），是一个效率非常低且危险的做法。

产品团队不应该根据团队中决策者的要求来预测趋势，而应该从客户实际想要实现的目标出发，根据这些结果反推，规划出可能的实现路径。

无需给各个功能来回排优先级，不如问自己一个简单的问题：下一步做什么，可以帮助我们更接近达成结果目标？这样做出来的产品，可能不是世界上最酷炫的，但确实能够帮助客户解决刚需问题。

回到开头的案例中，我们的团队最终说服了这位固执的合作伙伴，根本就不需要在改造网页上大费周章——因为他们的用户根本就不想要浏览网页，更不会关注网页是否具备追踪支付情况这一功能。对于他们来说，直接通过短信的形式向用户发送所需的信息，不仅搭建速度快、测试成本低。更重要的是，比网页上线一个追踪系统更能够让客户清楚了解到进度情况。

如果此刻的你也在为让产品实现某个功能而焦头烂额，不妨暂时地跳脱出来，回归客户的真实需求再思考下：对于客户来说，这真的是最好的解决方案吗？

原文标题：Stop inventing product problems; start solving customer problems

本文来自微信公众号：零一创投，作者：Pavel Samsonov，编译：零一创投