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

推荐订阅源

奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Blog — PlanetScale
Blog — PlanetScale
小众软件
小众软件
F
Fortinet All Blogs
博客园 - 叶小钗
博客园_首页
D
DataBreaches.Net
Apple Machine Learning Research
Apple Machine Learning Research
U
Unit 42
爱范儿
爱范儿
aimingoo的专栏
aimingoo的专栏
博客园 - Franky
Martin Fowler
Martin Fowler
酷 壳 – CoolShell
酷 壳 – CoolShell
The Cloudflare Blog
A
About on SuperTechFans
Google DeepMind News
Google DeepMind News
Microsoft Security Blog
Microsoft Security Blog
IT之家
IT之家
M
MIT News - Artificial intelligence
有赞技术团队
有赞技术团队
博客园 - 【当耐特】
S
SegmentFault 最新的问题
Hugging Face - Blog
Hugging Face - 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-10-29 · via 人人都是产品经理

在做市场调研、需求挖掘时,我们会经常需要进行用户调研。这篇文章,作者以B端业务调研为例,为我们分析了调研的整个过程,供大家参考。

用户调研是一切项目的开端。

以B端业务调研举例,进行全过程剖析。

案例:小红集团是一家经营了十几年的新能源项目规划设计、工程咨询、工程施工、运营管理等为一体的综合性工程管理公司。

由于近几年工程业务发展较迅速,工程施工所需流程/标准多且复杂,若干流程、管理、风险问题越来越突出,企业难以及时掌握项目开展情况等。

诉求:企业希望通过配套软件对整体施工情况进行有效把控,提升业务效率,控制施工风险。

业务调研主流程:

明确调研目的→确定调研方法→调研样本选择→执行调研计划→总结归纳

一、调研前准备

1)明确调研目的

梳理业务现状、总结业务问题,梳理业务相关法律法规(若有)

回到前文案例中,我们确定的调研目标如下:

  • 了解施工进度管控在整个小红集团的战略定位、战略目标
  • 了解该业务的经营策略、管控模式
  • 了解该业务的线下运作模式与细节、含组织架构、业务流程、使用场景及用户等
  • 梳理该业务的问题与痛点,确定优先级

2)确定调研方法

本篇主要以用户访谈方法举例

访谈要素:访谈大纲、从高级别人员到中层再到一线人员分别访谈、提前研究访谈对象、和访谈对象保持联系

访谈方法之一 :提出假设、通过访谈、验证假设,也可通过直接问问题的方式进行

调研大纲:问问题前,对客户业务需要做一些初步了解,明确本次访谈的对象是谁、通过调研想了解到什么,准备调研大纲可参考如下结构:

3)调研样本选择

客户分层分析选择、关键用户画像梳理。

  • 针对前文案例(B端业务调研),调研对象一般为业务高管、业务经理、一线业务人员等
  • 针对高管,可以了解战略层面信息;针对经理/部门负责人,可了解业务的管控模式、运营思路等;对于一线业务人员,可了解实际作业过程、操作细节等信息。
  • 针对小红集团,计划调研对象为:集团信息化负责人1人,集团工程部负责人1人、集团工程部业务人员1人、2家分公司与1个项目生产部负责人、业务人员各1人。

二、执行调研计划

怎么围绕核心业务流程进行询问,怎么抓住重点进行提问,不像无头苍蝇一样。

1)破冰

先确认核心诉求

方法:用户故事法

用户故事三要素:

  1. who:谁要使用
  2. what:要完成什么事情
  3. value:为什么这么做,能带来什么价值

2)沟通需求细节

如何梳理业务情况呢?可采用如下框架进行分析:

流程管理举例:客户已有一部分业务在线上化系统流转,但未形成业务闭环

调研了解到的手工业务流程如下:

从流程图中可看出:

  1. 创建计划:每次计划制定好后,都需打印出来拿给上层领导进行签字确认,才能继续往下执行,过程中要等领导有空进行当面沟通,各层级领导签完字后再将文件拿回到项目部进行施工指导,中间耗时较久,文件易丢失;
  2. 进度上报:每次周会才将进度同步到领导层,中间若出现异常情况,领导层只能等到周会的时候才知道,再下发整改要求,中间可能错失了最佳整改时间、或措施办法,在时效性和方案准确性上都可能存在问题,且对最终的整改结果也缺少及时的反馈;
  3. 修改计划:每次编辑计划,推测由于创建计划时,人工审批流程较耗时且环节多,导致在修改计划时,去掉了中间的审批流程,那每次修改其实是缺少管控的,业务人员可以随意变更计划,施工人员按照没有监管情况下修改的计划施工,极大概率会出现计划不合理导致的项目延期交付。

在以上三个环节都需要进行业务流程的优化。

若对业务不熟悉,或业务过于复杂,无法对沟通结果快速判断是否合理,可先问自己几个为什么?

  • 需求方提出的需求到底能不能根本解决问题?
  • 需求落地后的预期效果是否值得调用现有资源支持?
  • 需不需要提前跑些相关数据来验证需求背景?

一些调研问题预设:

  • “咱们今年或近2年针对业务信息化发展规划是怎么样的?”
  • “集团信息化这块主要负责人或决策人是什么部门的、平时主要负责哪些事项?”
  • “咱们对已有的上百个工程项目的运营模式和管控策略大概是什么样的?”
  • “针对施工进度管控业务有什么集团方针或政策要求吗?”
  • “施工进度管控业务的主要工作流程是?参与的角色除了生产部门还有其他部门涉及吗?”
  • “我了解到咱们线下管理的流程大概是xxxxx,那这个过程中是碰到什么问题了吗?”

…………

仅简单列举了一些方向性问题,避免诱导性问题。一般会从大到小、从浅到深依次与客户探讨,不要一下子钻到细节问题中,很容易会有某一方面的调研遗漏。

这也是我之前扎扎实实踩购过的坑,不得不进行二次调研,导致客户很抵触,得到的答案也不如第一次明确。

一般相同原因重复性调研时,客户的配合度、情绪和得到的答案都存在一定的问题,尽量在调研前,将可能的方向/问题想的较全面一些,当然会存在一些我们确实想不到的事项,不过调研过程中客户如果提到其他未预设到的方向,可以重点记录,会上和客户明确说出自己对这块想再深入了解下或自己确实没梳理到,会后希望还能找他详细沟通一下,给客户一个心理预期,二次调研时,就会更顺畅。

注意事项:用户说的和实际做的不一样,如果有条件可以看看客户实际工作中到底是怎么操作的,使用习惯是怎么样的,从实际行为中寻找需求、问题。

三、调研结论

1)关键业务问题梳理

经调研分析,工程进度管理业务存在如下问题:

  • 创建计划审批耗时长且文件易丢失,效率低
  • 修改计划缺少规范的工作流程、及监管,计划随意变更,出现问题,无法追溯
  • 采用较传统方式进行进度汇报,实时进度无法及时掌握,无法知晓业务最新情况
  • 进度汇报的过程中,经常通过经验判断关键工作是哪些,缺少科学依据,准确性存在问题
  • 施工过程中出现风险,无法实时预测/捕捉,知道结果与采取补救动作较后置

2)问题解决思路

  • 审批配置与规则线上化,且支持自定义配置环节与审批人员(P0)
  • 提供首页实时面板,项目关键指标进展实时更新(P1)
  • 系统嵌入智能计算模型,自动计算修改后计划是否影响交付时间、及关键工作(P2)
  • 支持风险规则配置、系统自动预测风险,实时通知到责任人(P0)

经过探讨和业务人员达成一致,将业务主监管流程与影响作业的主要风险预判线上化确定为高优先级,将数据看板与关键工作定位方式的优化列为中低优先级。

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

题图来自Unsplash,基于CC0协议

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