当你在聊需求时,到底在聊什么?

8 评论 4875 浏览 54 收藏 9 分钟
大厂导师团亲自授课,超过200小时的精品课程,从0到1为你构建“产品+业务”的复合型知识体系,让你在职场竞争中脱颖而出。

在产品管理和客户需求沟通的过程中,我们常常会遇到一个普遍的误区:人们往往将他们认为的解决方案误认为是需求本身。这篇文章深入探讨了需求与方案之间的区别,并提供了实用的策略来识别和处理这一问题。

最近有两个洞察,它们跟需求沟通有关,也跟人有关。

第一个洞察是产品经理日常沟通中,绝大多数人(包括客户、销售、实施、客服、客成等),都不知道什么是需求,他们只是以需求之名,在给你提解决方案,期望让你这个“傀儡”去帮TA实现自己的目标

比如销售同学会跟你说:

境哥,客户的需求是希望工资报表导出公式,这个如果二开的话,需要多少人天?客户对接人说,如果没有这个支持的话,可能会影响合作(😂😂😂

再比如客成会跟你说:

咱们薪资设置跟自定义报表页面,希望可以取到员工计薪周期最后一天的工时制类型,否则会影响客户算薪

再比如客服主管跟你说:

咱们工资、考勤的字段计算逻辑比较复杂,客户会有很多客诉问题,导致客服效率比较低,咱们可以结合现有系统,做一个单独的页面,把这些字段的计算的公式、规则都清楚显示给客户吗?

你觉得“工资报表导出公式”、“自定义报表支持工时制类型”、“单独一个页面显示计算公式”是需求吗?

不是。

可他们明明跟你说的是“找你沟通个需求啊”。

想到这里,就让我发现了第二个洞察:绝大多数人都喜欢抽象表达,而不喜欢具象化(哈哈,当我写下这句话的时候,就是对这个洞察最好的印证)。

人们好像觉得抽象化表达,可以隐藏自己的真实想法,避免有一种被人看透的感觉,期望保持对对话的绝对掌控感和主导权,仿佛一旦开口就把自己的问题(或目的)说出来,瞬间就输了一样。

比如那位销售同学,TA其实想说的是:

境哥,我们最近在跟进一家做人力资源外包的A类客户,他们跟多个公司合作,如果采购咱们的系统的话,他们需要每个月导出对应的工资、考勤报表,让每个合作方确认,担心直接给结果会导致对方有疑问时,反复追问,所以最好是可以把对应公式一并导出,她们线下就是这么干的。

那位客成同学想说的是:

客户会有综合工时制、标准工时制等不同工时制员工,如果当月发生过转岗时,希望可以在工资报表中,有效进行筛选与区分,便于最终工资分别核算。

而客服主管想说的是:

咱们系统的工资字段计算逻辑复杂,导致客诉问题较多,最近3个月相关客诉问题有13起,每次客服都需要花10分钟以上才能解释清楚逻辑,你这边有什么好的解决方案吗?

01 方案 ≠ 需求

方案不等于需求,就像观点不等于事实一样,可情感脑总会战胜理智脑,让你懒得分辨。

什么是需求?

需求是目的,是回答“为什么”的问题。用一个公式表达就是:需求 = 用户 + 场景 + 问题

一般会有两种表现形式:

第一种是大白话式。即谁在什么情况下遇到了什么问题,产生了什么样的情绪感受。

比如我最近两天遇到了上述三个案例,每次都需要反复追问(获取有价值信息)和解释(避免对方觉得你是拿鸡毛当令箭),才能获取到所需要的信息,产生了一种心累、不想反复解释的心情。

第二种是用户故事式。即作为一名[角色],我期望在做[XX]的时候,有一个[XX]功能,以便于实现[XX目的]。

比如作为一名产品经理,我期望客户(或销售/客成等)在提需求时,可以直接去且具体的说问题,以便于我可以快速了解需求本身,寻求不同解决方案。

什么是方案?

方案是手段,是回答“怎么办”的问题。用公式表达的话,就是:方案 = 问题 + 工具/服务

换句话说,方案是服务于问题本身,不能独立存在,而它的形态可能是一个工具或一项服务。

比如针对上述三个案例,我可以提供一个标准化的解决方案:需求池+提需求模板解决。

如果你有需求,按需求模板(即描述清楚遇到的问题、现在的解决方案、期望解决方案)先提需求池,我基于需求进行回复,避免过多私聊。

02 如何判断是需求,还是方案?

第一,如果用户描述“需求”时,完全跟系统/产品相关,那就是方案。比如“导出报表“、“自定义报表新增工时制”等,本身就蕴含了“系统”在里面,基本就可以判断它是方案。

它们之间的关系,就有点像用户问题跟产品之间的关系,用户的目的不是使用产品,而是解决自身问题。

第二,如果用户描述“需求”时,完全没有提到人(或角色)、完全没有提到问题(或困扰),那就是方案。反之,则是需求;

03 如何解决用户总是提方案,而不提需求的问题?

如果是口语沟通的话,可以追问三句话:

  • 第一句:“咱们现在是遇到了什么问题?”
  • 第二句:“咱们现在是怎么解决的?”
  • 第三句:“咱们期望的结果是什么?”

如果是书面沟通的话,可以提供一个需求模板:

  • 请描述你当前遇到了什么问题?
  • 请描述当前你是怎么解决的?
  • 请描述你期望的理想结果是什么?

04 总结

今天主要跟你分享了两个洞察:

  • 绝大多数人(包括客户、销售、实施、客服、客成等),都不知道什么是需求,他们只是以需求之名,在给你提解决方案;
  • 绝大多数人都喜欢抽象表达,而不喜欢具象化。

如何有效识别是需求,还是方案?

根据用户提“需求”时,是否隐含了“系统”在内?或是否没有描述遇到的问题?如是,则是方案;

如何有效解决提方案,而不提需求的问题?

请使用关键三问(即遇到什么问题、现在如何解决、期望结果是什么)。

专栏作家

邢小作,微信公众号:产品方法论集散地,人人都是产品经理专栏作家。一枚在线教育的产品,关注互联网教育,喜欢研究用户心理。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 也有例外的情况,就是专业性很强的需求,你不及业务部门的人员专业,就算明确需求也无法为他们提供需求方案,还是要依赖专业业务人员的方案执行

    来自山东 回复
    1. 嗯,是的,但产品经理对需求的洞察以及提出有效解决方案,跟最终落地执行是自身,还是依赖业务人员,并不冲突

      来自北京 回复
  2. 对方直接将方案是较快实现对方需求的一种方式,但有可能不是最佳方式。
    聊清楚需求仅是第一步,后续还需要积累需求实现方式,以保证功能真正满足需求,不容易啊

    来自浙江 回复
    1. 对,所以我会推荐“需求是1,方案是0”的方法论,前提就是需要先区分什么是需求,什么是方案

      来自北京 回复
  3. 这个其实很考验产品经理对需求的判断力,要判断这个是真实的市场需求还是看似真实其实没办法通过市场检验

    来自广东 回复
    1. 对,这是需要经验,以及刻意练习的结果

      来自北京 回复
  4. 聊需求就是在找问题和答案嘛,搞清楚要啥,怎么实现,感觉像是在做侦探游戏。🕵️‍♀️🔍💭

    来自辽宁 回复
    1. 哈哈,我喜欢你的这个类比,确实有相似之处

      来自北京 回复
专题
17963人已学习14篇文章
批量导入是用户在工作中经常需要用到的功能。本专题的文章分享了批量导入的设计思路和优化思路。
专题
15450人已学习13篇文章
作为一种软件开发工具,低代码平台一定程度上提升了企业的软件开发效率,适应了整体的数字化发展趋势。本专题的文章分享了关于低代码的讲解。
专题
19118人已学习15篇文章
表单是我们比较常见的一个信息录入工具。本专题的文章提供了表单设计指南。
专题
53352人已学习18篇文章
做了好多年的产品经理,该不会连注册登录功能设计都没整明白吧?
专题
66792人已学习25篇文章
做好微信运营比做好APP运营还重要,因为用户把时间都给了微信。
专题
13088人已学习11篇文章
需求评审会议对整个项目想影响至关重要,作为产品经理,应该如何完成需求评审呢?本专题的文章分享了如何高效完成需求评审。