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

推荐订阅源

V
V2EX
Y
Y Combinator Blog
博客园_首页
V
Visual Studio Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
阮一峰的网络日志
阮一峰的网络日志
Hugging Face - Blog
Hugging Face - Blog
宝玉的分享
宝玉的分享
B
Blog
博客园 - 三生石上(FineUI控件)
小众软件
小众软件
WordPress大学
WordPress大学
L
LangChain Blog
爱范儿
爱范儿
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
P
Proofpoint News Feed
Blog — PlanetScale
Blog — PlanetScale
C
Check Point Blog
博客园 - 聂微东
云风的 BLOG
云风的 BLOG
Microsoft Security Blog
Microsoft Security Blog
博客园 - 叶小钗
酷 壳 – CoolShell
酷 壳 – CoolShell
H
Help Net Security

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
需求调研的三个坑,你踩过哪个?
AI产品大峡谷 · 2023-04-24 · via 人人都是产品经理

在实际调研中,我们经常会踩很多坑,有些是向上进步的阶梯,有些则是耽误成长效率。这些所谓的“坑”,大部分是认知盲区,本文作者总结了需求调研的三个坑,希望能对你有产品启发和职业参考。

最好的机会,往往存在于认知盲区中。

这两周我一直在招聘高级产品经理,在面试环节我的关注对象实际只有三点:专业能力、学习态度和学习能力,并且,镜同学一直认为这是产品人才快速发展的「铁三角」。

而在关于「专业能力」的面试交流中,我都会问很多关于「业务抽象」的问题,比如,平台的商业模式、盈利模型;用户需求痛点的收集方法与分析策略;竞品的业务价值点与优劣对比;诸如此类,等等。

实事求是地说,如果有人问我,什么是最重要的产品专业能力?我会毫不犹豫地回答:业务抽象

因为,在镜同学看来,高阶产品经理的专业性主要体现在对业务的抽象能力上,我们绝非需求的传声筒,但却是业务的翻译器,也正如《大话软件工程》书中所说:如何从错综复杂的目标需求、业务需求中提炼出产品功能需求,是进行高质量产品设计的关键前提。

前天,有个3年的产品朋友第一次进行出差调研业务需求,他火急火燎地询问我有没有系统性的经验总结,看着他待嫁闺中的样子,我不慌不忙地翻看之前的文章,竟然发现基本所有文章都是正向的建议指导,缺乏有吸引力的「陷阱」,老话说得好:犯错才是快速进步的良药

事实上,在实际调研中,我们经常会踩很多坑,有些坑属实不亏,也是咱们向上进步的阶梯;但有些坑掉进去后才发现坑底写满了「冤枉」与「遗憾」,实在是耽误成长效率。

其实,这些所谓的坑,很多都是认知盲区,有句话老话说的好,你很难挣到认知以外的钱,凭运气挣的钱也会凭实力丢掉。

于是,我决定给大家熬上一副汤药,希望能矫正一些产品认知盲区症,也希望对你有产品启发和职业参考。

01 调研准备不充分,缺乏清单思维

关于准备意识和清单思维这个话题,老读者应该清楚,镜同学分享过很多次,这里也绝非炒冷饭,再次强调是因为我发现很多人并没有这个意识,或者经验并没有系统化,以至于严重低估了这个原本确定性的红利。

对于陌生领域或者重要的工作事项,比如,需求调研或沟通会议,尤其需要提前准备,因为,如果准备不充分很容易手足无措,甚至沟通无法保证基本的同频共振,以至于犯一些基础的常识错误,这会对你的专家效应带来极大伤害

知己知彼、运筹帷幄是决胜千里之外的前提,因此,在需求调研前,产品同学一定要梳理调研相关的问题与标准话术,并将其做成待办清单,甚至反复推演和彩排,只有前期论证越充分,现场调研才越容易成功。

而专家效应对于第一印象又极为重要,我以前公司流传一个故事:

某产品经理第一次参加客户需求调研时,没有提前彩排,结果漏洞百出,最过分的是产品方案里引用的客户图片竟然是客户竞争对手的

当时,客户一脸懵逼,据说对方老板扭头黑着脸就走了,估计一是感觉太浪费时间了,二是觉得我们不够专业,也不够尊重他们。

前两年,我们产品同事去拜访客户、调研业务需求,当时客户提出来想看下系统,结果没有提前准备演示账号/密码/网址等信息,耽误很长时间,也让客户感到失望,体验很不好。

再举个正面例子:上周一我告诉一个产品经理,周四可能安排他去某化工企业做需求调研,让他提前准备下,大概周二下午,他使用Markdown做了一个简单的计划方案。

我一看,计划准备的还挺充分,结构也很清晰,比如,主要包括:需求讨论的功能清单、使用演示系统的账号密码、可能讨论的议题、待办清单(名片、宣传页、U盘)、需要提前内部沟通的问题,等等事项。

并且还提前约了我的时间,针对他不清楚的问题进行了沟通确认,事实上,我们周四的汇报非常成功,我深知这与我们精心准备密不可分。

正是因为我十分清楚“准备意识”和“清单思维”的巨大作用,我才在团队里“强制”大家必须做清单工作计划,逐步养成这样的习惯。

比如,之前参加很多行业研讨会,虽然有些只是随场交流,我还是做了不少工作,列了问题清单,也读了好几篇行业研报,看了几个B站科普视频,后来在沟通时我明显能感受到对方的认同感。

说到这里,想起上周有个产品同学私信我,询问做好需求调研最重要的方法是什么,我提到的第一点就是“清单思维”,事实上,镜同学认为,不仅是需求调研,日常工作也需要具备“清单思维”。

需求调研的三个坑,你踩过哪个?

02 姿态过低、反而适得其反

先问大家一个问题:你觉得最牛的乙方是什么?

这是前几年我第一次陪同我们总裁出差拜访客户时他问我的问题,最后他告诉我说是医生,还提醒我:我们要做像医生这样的乙方。

这对我启发很大,甚至后来还让我总结出来一句话:持续性的价值互换是建立平等对话的基础

但是在实际工作中,尤其是作为乙方向客户进行需求调研、用户访谈或现场产品汇报沟通时,总是不自觉地「降低身段」,甚至不敢高声语。

于是,很多产品同学在需求调研时本能的向客户妥协,甚至对客户所提出的不合理需求也一味应承,满口没问题,这就导致出现「过度承诺的现象。

这也脱离了产品本位主义,偏离了需求调研的内核,完全被客户需求所绑架,而且,这种情况下,很容易给客户传递错误信号,让他们误以为任何需求都可以被满足,也不利于后续的工作推进。

正常态一旦被错误打破,纠偏的成本就指数上升。

比如,我们前段时间一个产品同学随业务出差,现场调研需求时,就犯了这样的错误,姿态摆的过低,认为自己是乙方,为了协助业务成单有责任改进产品以满足业务需求。

实际上,当时客户只是随口提了一个需求,希望能在他们内部系统上增加我们系统的某功能,该同学不假思索地直接满口应承,但我们回来一讨论,该需求属于典型地伪需求,且ROI极低。

事实上,需求调研也好,用户沟通也罢,大家的出发点都是价值互换、互相成就,如果单方面过于低姿态很难持续合作,也很容易使得真实需求产生较大偏差。

03 情况不明,先“下手”遭殃

很多时候我们总在说「先下手为强,后下手遭殃」,但在和客户进行需求调研分析与业务沟通时,在情况不明确、信息不充分时就过度主观表达,就很容易陷入被动,也难怪古人说「不敢为天下先」。

我想起早些年的一件往事:

当年我和一个产品同学共同陪同业务出差,主要做业务调研和需求收集,我们调研的是客户的生产部门,在办公室会议沟通和演示系统,其中有个客户A走进来询问到我们系统的价值,这个同学表达力很好,就说我们系统的智能化效果,能提高效率、降低成本。

最后该产品同学还“口若悬河”地说道:等我们系统上了之后,计量岗位就可以优化掉,实现无人值守,极大的降低企业经营成本。

后来我们系统推进时总是遇到阻力,最后我们多方打听才找到病症,原来当时的那个客户A就是计量主管,我们完全没有搞清楚情况,细细回想,当时这简直就是在「与虎谋皮」呀。

再举个例子:

我在面试时,在开放性的压力测试时,还经常问大家一个问题:

假设有这样一个场景:客户A部门对你们的产品不熟悉,提出的需求也不是很合理,但拥有决策权;客户的B部门对你们的产品很了解,提出的需求也比较合理,但没有决策权。请问,这种情况下,你会如何处理A/B部门间的需求期望,使得产品需求得到有效落地。

这个问题其实并不复杂,有很多同学的回答都非常优秀,也很结构化,但也有很多同学忽略了一点,那就是「先搞清楚情况」这个关键前提:我们必须先搞清楚客户的内部情况、不同的需求差异度,而后再线下沟通解决。

所以,我们未搞清楚业务的动态时,应该多去了解,多做沟通。

实际上,我经常给大家说,如果我们想把需求调研做的更充分,可以提前先和某一两个客户建立链接,请他们告诉我们一些内部情况,再让他们在开会时支持我们,这样效果往往会非常好。最后,需求调研是产品经理的必修课,同客户沟通交流更是产品基础的能力,我们在调研时需要具备系统的方法论,也需要逐渐扫除认知盲区,只有形成体系认知,才能问题自解。

正如孔夫子所教诲:知者不惑,仁者不忧,勇者不惧

专栏作家

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

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

题图来自 Unsplash,基于CC0协议。

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