惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Blog — PlanetScale
Blog — PlanetScale
Y
Y Combinator Blog
G
Google Developers Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
L
LangChain Blog
S
SegmentFault 最新的问题
J
Java Code Geeks
V
Visual Studio Blog
H
Help Net Security
Stack Overflow Blog
Stack Overflow Blog
aimingoo的专栏
aimingoo的专栏
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
T
Tailwind CSS Blog
Microsoft Azure Blog
Microsoft Azure Blog
博客园_首页
H
Hackread – Cybersecurity News, Data Breaches, AI and More
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - Franky
B
Blog RSS Feed
The Cloudflare Blog
MyScale Blog
MyScale Blog
月光博客
月光博客
Microsoft Security Blog
Microsoft Security Blog
美团技术团队

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
当你在聊需求时,到底在聊什么?
产品方法论集散地 · 2024-11-25 · via 人人都是产品经理

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

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

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

比如销售同学会跟你说:

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

再比如客成会跟你说:

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

再比如客服主管跟你说:

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

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

不是。

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

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

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

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

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

那位客成同学想说的是:

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

而客服主管想说的是:

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

01 方案 ≠ 需求

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

什么是需求?

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

一般会有两种表现形式:

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

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

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

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

什么是方案?

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

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

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

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

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

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

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

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

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

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

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

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

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

04 总结

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

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

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

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

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

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

专栏作家

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

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

题图来自 Unsplash,基于CC0协议

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