在产品管理和客户需求沟通的过程中，我们常常会遇到一个普遍的误区：人们往往将他们认为的解决方案误认为是需求本身。这篇文章深入探讨了需求与方案之间的区别，并提供了实用的策略来识别和处理这一问题。
最近有两个洞察，它们跟需求沟通有关，也跟人有关。
第一个洞察是产品经理日常沟通中，绝大多数人（包括客户、销售、实施、客服、客成等），都不知道什么是需求，他们只是以需求之名，在给你提解决方案，期望让你这个“傀儡”去帮TA实现自己的目标。
比如销售同学会跟你说：
境哥，客户的需求是希望工资报表导出公式，这个如果二开的话，需要多少人天？客户对接人说，如果没有这个支持的话，可能会影响合作（😂😂😂）
再比如客成会跟你说：
咱们薪资设置跟自定义报表页面，希望可以取到员工计薪周期最后一天的工时制类型，否则会影响客户算薪
再比如客服主管跟你说：
咱们工资、考勤的字段计算逻辑比较复杂，客户会有很多客诉问题，导致客服效率比较低，咱们可以结合现有系统，做一个单独的页面，把这些字段的计算的公式、规则都清楚显示给客户吗？
你觉得“工资报表导出公式”、“自定义报表支持工时制类型”、“单独一个页面显示计算公式”是需求吗？
不是。
可他们明明跟你说的是“找你沟通个需求啊”。
想到这里，就让我发现了第二个洞察：绝大多数人都喜欢抽象表达，而不喜欢具象化（哈哈，当我写下这句话的时候，就是对这个洞察最好的印证）。
人们好像觉得抽象化表达，可以隐藏自己的真实想法，避免有一种被人看透的感觉，期望保持对对话的绝对掌控感和主导权，仿佛一旦开口就把自己的问题（或目的）说出来，瞬间就输了一样。
比如那位销售同学，TA其实想说的是：
境哥，我们最近在跟进一家做人力资源外包的A类客户，他们跟多个公司合作，如果采购咱们的系统的话，他们需要每个月导出对应的工资、考勤报表，让每个合作方确认，担心直接给结果会导致对方有疑问时，反复追问，所以最好是可以把对应公式一并导出，她们线下就是这么干的。
那位客成同学想说的是：
客户会有综合工时制、标准工时制等不同工时制员工，如果当月发生过转岗时，希望可以在工资报表中，有效进行筛选与区分，便于最终工资分别核算。
而客服主管想说的是：
咱们系统的工资字段计算逻辑复杂，导致客诉问题较多，最近3个月相关客诉问题有13起，每次客服都需要花10分钟以上才能解释清楚逻辑，你这边有什么好的解决方案吗？
方案不等于需求，就像观点不等于事实一样，可情感脑总会战胜理智脑，让你懒得分辨。
什么是需求？
需求是目的，是回答“为什么”的问题。用一个公式表达就是：需求 = 用户 + 场景 + 问题。
一般会有两种表现形式：
第一种是大白话式。即谁在什么情况下遇到了什么问题，产生了什么样的情绪感受。
比如我最近两天遇到了上述三个案例，每次都需要反复追问（获取有价值信息）和解释（避免对方觉得你是拿鸡毛当令箭），才能获取到所需要的信息，产生了一种心累、不想反复解释的心情。
第二种是用户故事式。即作为一名[角色]，我期望在做[XX]的时候，有一个[XX]功能，以便于实现[XX目的]。
比如作为一名产品经理，我期望客户（或销售/客成等）在提需求时，可以直接去且具体的说问题，以便于我可以快速了解需求本身，寻求不同解决方案。
什么是方案？
方案是手段，是回答“怎么办”的问题。用公式表达的话，就是：方案 = 问题 + 工具/服务。
换句话说，方案是服务于问题本身，不能独立存在，而它的形态可能是一个工具或一项服务。
比如针对上述三个案例，我可以提供一个标准化的解决方案：需求池+提需求模板解决。
如果你有需求，按需求模板（即描述清楚遇到的问题、现在的解决方案、期望解决方案）先提需求池，我基于需求进行回复，避免过多私聊。
第一，如果用户描述“需求”时，完全跟系统/产品相关，那就是方案。比如“导出报表“、“自定义报表新增工时制”等，本身就蕴含了“系统”在里面，基本就可以判断它是方案。
它们之间的关系，就有点像用户问题跟产品之间的关系，用户的目的不是使用产品，而是解决自身问题。
第二，如果用户描述“需求”时，完全没有提到人（或角色）、完全没有提到问题（或困扰），那就是方案。反之，则是需求；
如果是口语沟通的话，可以追问三句话：
如果是书面沟通的话，可以提供一个需求模板：
今天主要跟你分享了两个洞察：
如何有效识别是需求，还是方案？
根据用户提“需求”时，是否隐含了“系统”在内？或是否没有描述遇到的问题？如是，则是方案；
如何有效解决提方案，而不提需求的问题？
请使用关键三问（即遇到什么问题、现在如何解决、期望结果是什么）。
专栏作家
邢小作，微信公众号：产品方法论集散地，人人都是产品经理专栏作家。一枚在线教育的产品，关注互联网教育，喜欢研究用户心理。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。