正确的提示信息

扫码打开虎嗅APP

从思考到创造
打开APP
搜索历史
删除
完成
全部删除
热搜词
2024-08-23 16:04

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

本文来自微信公众号:零一创投,作者:Pavel Samsonov,编译:零一创投,头图来自:视觉中国

文章摘要
团队应关注客户需求而非产品功能。

• 💡 避免陷入“构建陷阱”,聚焦实际价值

• 📊 从结果驱动而非输出驱动出发规划产品

• 🛠️ 问自己如何更接近解决客户需求

前段时间,罗技公司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,编译:零一创投

本内容为作者独立观点,不代表虎嗅立场。未经允许不得转载,授权事宜请联系 hezuo@huxiu.com
如对本稿件有异议或投诉,请联系tougao@huxiu.com
打开虎嗅APP,查看全文

大 家 都 在 看

大 家 都 在 搜

好的内容,值得赞赏

您的赞赏金额会直接进入作者的虎嗅账号

    自定义
    支付: