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

推荐订阅源

V
Visual Studio Blog
Y
Y Combinator Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Apple Machine Learning Research
Apple Machine Learning Research
爱范儿
爱范儿
IT之家
IT之家
量子位
小众软件
小众软件
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
罗磊的独立博客
S
SegmentFault 最新的问题
博客园_首页
N
Netflix TechBlog - Medium
月光博客
月光博客
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
aimingoo的专栏
aimingoo的专栏
T
Tailwind CSS Blog
M
MIT News - Artificial intelligence
A
About on SuperTechFans
The Cloudflare Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
腾讯CDC
MyScale Blog
MyScale 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-04-23 · via 人人都是产品经理

在做G端产品的过程中,为了让产品可以符合客户实际需求,我们需要经历客户需求调研的这个环节。那么,需求收集后,我们要从什么维度判断客户的需求是否真的可以产品化呢?

我们做G端产品,新产品的方向几乎100%来自于政策。所以才会有“政策带来产品,产品催生政绩”。

可就算是知道这个思路,一个政策文件出来,光靠我们自己的解读肯定是不够的,还得找客户做专业的产品需求调研,这样做出来的产品才能够即符合政策又符合客户实际需求。

一、新产品需求调研,该找谁?

首先,你得搞清楚,政策文件的宣发路径是什么样的。一般会有两种路径:

第一种是“上头来的”:最高级单位制定了一份政策文件,把文件下发到省级单位。最高级单位的文件制定一般都是方向性的,具体怎么做,就需要各省自行研究。省级单位怎么去研究的,一般就是找一两个在这方面业务做的比较好的市级单位或区县单位,让他们先试试水,看看效果怎么样,然后再总结经验。

第二种则是“下面冒出来的”:某个基层单位突然搞了个创新项目,效果还不错。于是他们就给上级单位打报告,说明工作成效。上级单位一看,哟,这不错嘛!然后就会组织个考察团去实地看看。如果确实靠谱,那就会在全省或全市推广开来。

这两种路径,一个是从上往下,一个是从下往上,虽然方向相反,但落脚点都是一样,都在基层单位。一个是上级指定的基层单位做试点,一个是有想法的基层单位做出了成绩做推广。

这下是不是感觉明朗多了?要做新产品需求的调研,关键得找对人。

如果是上面发下来的政策文件,那就得先去跟省级单位的大佬们聊聊,摸摸底,看看省内有哪些试点单位,然后再直奔这些试点单位去调研。

如果是基层单位搞出了什么新花样,想要推广,那更简单,直接去找这个基层单位,看看他们是怎么玩的,把他们的经验和方法提炼出来,这就是你的产品需求啦。

因此,一个需求是否能产品化?最好就是去找基层单位的客户做验证。他们是属于冲锋在“最前线”的人员,“炮弹”好不好用他们最清楚。

二、注意辨别不同层级客户的需求

做G端产品这事儿,说白了就是围着“领导”的需求转。你说这系统都是基层干部在用吧?没错!但拍板买不买这系统的权力,可都掌握在领导手里。

不过,这里的“领导”也是分层次的,有部门小领导、分管的中层领导,还有上级单位的大领导。

1. 部门领导需求

  • “系统操作得简单点儿,别太复杂了,别让我们手下的兄弟姐妹们累得够呛。最好能智能点儿,别老是要手动去点这个按那个的。”
  • “这系统得实用啊,别只是个摆设或者看上去好看但啥实际作用都没有。”
  • “设计系统功能的时候,得跟具体使用的人员好好对接,听听他们的需求,按他们的要求来定制。”

从部门领导的角度看,他最关心的还是员工的工作量和系统的实际使用效果。他很清楚手下人的工作量,所以不希望新系统给大家带来更多负担。

如果系统真的能帮到大家,提高工作效率,那领导自然乐意推广使用,甚至可能因此受到上级的表扬。但要是系统没啥用,还让大家更忙,最后只能是把锅甩到我们企业头上,以此说服领导,弃用这个产品。

所以,满足部门领导的需求,其实就是确保系统既简单又实用,还得跟用户紧密沟通,确保系统能够真正帮到他们。

2. 分管领导需求

  • “得有个大屏,能让我一眼就看到各种数据分析,数据得真实可靠,还得能深入查看每项业务的具体情况。”
  • “要尽量展示我们的各种工作成果,最好能和其他的业务系统对接,让数据流动起来。”
  • “数据安全问题得重视,绝对不能出现数据泄漏的风险。”

总的来说,分管领导更注重的是工作成绩的直观展示和数据的安全性。他想要一个大屏幕来实时查看各种数据和工作成果,同时也非常关心数据的安全问题。

所以,满足分管领导的需求,就是要提供一个可视化、安全且能全面展示工作成果的系统。

3. 上级单位领导需求

  • “系统得能让我随时查看所有单位的业务办理进度,数据得多角度分析,还得是实时更新的。”
  • “系统得能预警数据异常,自动生成分析报告,让我能一眼就发现普遍存在的问题。”
  • “系统得体现出我们工作的规范性,所有流程都得在数据里有所反映,而且必须让大家都用起来,该填的数据都得填。”

总的来说,上级单位领导更关心系统的指挥决策作用。他们希望通过系统的运用,能够轻松地发现共性问题,推广优秀的工作经验,从而更好地管理和指导下属单位。

所以,满足上级单位领导的需求,就是要提供一个全面、实时、智能且能确保工作规范性的系统。

你看,不同层级的客户对系统的需求真是各有各的想法呢!所以呀,一个新产品的机会,关键得看是谁在牵头。不同的客户牵头,那产品功能设计上可就会有所区别了。

部门领导更注重系统的易用性和实用性,关心系统是否会增加员工工作量以及是否能带来实际工作成效。分管领导则更加关注数据的可视化和安全性,以及系统能否全面展示工作成果和与其他系统的数据互通。而上级单位领导则重视系统的指挥决策作用,希望通过系统发现共性问题并推广工作规范。

总得来说,领导提出来的需求都比较宏观和具体,不够落地,需要进一步甄别和证伪。

三、如何判断客户的需求能否产品化?

话说我们收集客户需求,很多时候真的就像是逛街时顺便捡到的一样。

这些需求啊,东一个、西一个,有时候真的像是天上掉下来的馅饼,但又怕是陷阱!

说实话,我们心里也没底。这系统做出来,客户真的会掏钱吗?就算这个客户愿意买单,那其他客户呢?会不会觉得这东西就是个鸡肋,食之无味、弃之可惜?

说实话,我们也不是神仙,没法飞到全国各地,找到每个客户问个明白。所以啊,有时候客户说得天花乱坠,我们一激动就给做了,结果后来发现,哎呦,怎么就这一个客户买单呢?

那么,当我们在有限的客户调研资源的情况下,应该从哪些方面来判断这个需求是不适合做成产品呢?

我认为,关键要搞清楚这四个问题:

  1. 有没有政策,或者有没有可能出台相关的政策?
  2. 有没有效果,对业务办理能不能带来实质性的作用?
  3. 有没有标准,能不能输出标准化的东西满足全国客户?
  4. 有没有预算,是否愿意花钱来共同建设或采购这个产品?

第一,有没有政策

说到某个需求嘛,如果它只是某个客户的“脑洞大开”或者某个小地方的“土政策”,那这种需求啊,基本上就是“地域限定版”,很难推广到全国。

你想啊,如果没有全国统一的“政策要求”这种大招牌,哪个客户会闲得蛋疼,给自己增加工作量,去搞一个不知所谓的系统呢?

第二,有没有效果

政策固然重要,但效果才是硬道理!

如果这个系统真的能让业务部门如虎添翼,提升效率,还能晒出实实在在的成果,那就算没有政策撑腰,也会有识货的客户愿意为它买单。说白了,好用才是王道!

第三,有没有标准

有些产品做出来确实会好用,也有政策要求,但要标准化很难。没有统一的标准,前期投入就得拼命砸钱,产品定价也水涨船高,这时候就得看客户愿不愿意掏腰包了。

比如,做个视频合规性审查产品,大家都说需要,政策也有规定,但标准呢?全国都没有一个准确的审查标准,谁来确定这个标准都成了问题。有些客户看视频时,一眼就能看出问题在哪,但让他们用文字描述出来,那就像是挤牙膏一样难!

第四,有没有预算

需求嘛,像天上的星星,多得数不清。但说实话,不是所有需求都得靠信息化手段去解决。

想想以前没互联网的时候,大家不也照样过日子、干工作嘛。所以,咱不能“一刀切”的思维,认为客户有某方面的问题,就给客户提供软件系统的解决方案。有些问题或许下线去处理解决,成本还更低。

不过话说回来,如果客户真的有某个强烈的需求,那我们就得看看他们愿意为这个需求掏多少钱了。别想着“白嫖”我们,或者从别的地方找钱来“曲线救国”。这钱,得是针对这个产品,实打实地花。一谈钱,很多所谓的需求立马就会露出原形:不做也可以。

最后的话

一个客户的需求能不能做出来产品?

  1. 得看这个需求是谁提出来的,基层单位提出来的会靠谱的多。
  2. 得辨别不同层级客户的需求,领导提出的需求偏宏观和抽象,需要甄别和证伪。
  3. 得针对具体的需求进行四个“有没有”分析,基本上能够判断出来这个需求能不能做成产品。

作者:武林,To G企业产品总监

本文由@武林 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

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