第2章 用户场景与需求采集方法:用户访谈、数据分析、竞品分析

需求采集是AI产品版本规划的起点。没有高质量的需求输入,版本规划就会变成“猜拳式”的拍脑袋决策。本章围绕三大核心采集方法——用户访谈、数据分析、竞品分析,讲解如何系统化地获取用户场景与业务问题,并将它们转化为版本规划的依据。

2.1 用户场景与业务问题

在采集需求之前,必须先明确两个基础概念:用户场景描述“用户在哪里、遇到什么障碍、期望什么结果”;业务问题则回答“这个场景对产品KPI(留存、转化、活跃)造成了多大的影响”。

案例对照:
用户场景:用户在地下车库打开语音助手,连续三次唤醒失败。
业务问题:弱网/弱信号场景下的唤醒成功率仅为62%,导致次日留存率下降8个百分点。

一个合格的采集任务,必须同时输出场景描述和业务问题量化数据,否则后续的版本规划将缺乏优先级决策的依据。

2.2 三大需求采集方法

不同阶段、不同目标应选择不同的采集方法。下表从核心目标、适用阶段、典型产出、样本量和时间成本五个维度进行对比:

维度 用户访谈 数据分析 竞品分析
核心目标 挖掘深层需求与情感动机 验证行为假设与使用模式 定位差异化机会与行业基线
适用阶段 探索期 / 需求模糊期 成长期 / 验证期 全周期(尤其规划前)
典型产出 用户画像、痛点清单、JTBD 行为漏斗、功能使用率、留存曲线 功能矩阵、Gap分析、SWOT
样本量 5 – 15 人 全量或大样本(>1000) 3 – 5 款竞品
时间成本 高(1 – 2 周) 中(3 – 5 天) 低(1 – 3 天)

2.2.1 用户访谈

用户访谈适合在0→1或1→N的探索阶段使用。关键操作要点:

  • 采用半结构化提纲:预设6-8个核心问题,留出追问空间。
  • 每位用户访谈时长控制在 45 – 60 分钟,超过容易造成疲劳。
  • 访谈后 24 小时内完成编码和标签化,避免信息衰减。
  • 输出物必须包含原始语录和提炼后的需求陈述两个层次。
避坑提示:不要直接问“你想要什么功能”,用户往往给出方案而非问题。应追问“你现在是怎么做的?那个过程哪里让你最烦躁?”

2.2.2 数据分析

数据分析是用行为事实修正主观判断的关键手段。以AI语音助手产品为例,分析唤醒失败场景的代码示例如下:

import pandas as pd

# 加载用户事件日志
events = pd.read_csv("voice_events.csv")

# 筛选弱网场景下的唤醒事件
weak_net = events[events["network_type"].isin(["2G", "地下停车", "电梯"])]

# 计算各场景唤醒成功率
success_rate = weak_net.groupby("scene")["wake_success"].mean()

print(success_rate)
# 输出示例:
# scene
# 地下停车场    0.62
# 电梯内        0.71
# 楼梯间        0.68

数据分析的关键产出包括:行为漏斗(从触发→唤醒→识别→执行各步流失率)、功能使用热度图(哪些功能被高频/低频使用)、场景渗透率(不同场景下的用户占比和成功率)。

2.2.3 竞品分析

竞品分析不是为了“抄”,而是为了建立差异化的版本规划边界。推荐采用功能矩阵 + 体验基线的双层结构:

  • 功能矩阵:列出竞品在相同场景下的功能覆盖度,标记“已有”“缺失”“领先”。
  • 体验基线:选取3-5个核心场景,逐一对比成功率、响应时长、错误率等量化指标。
  • Gap分析:找出竞品未满足但用户强烈需要的场景,这就是版本规划的“机会窗口”。
需求采集与版本规划流程 需求采集 用户访谈 数据分析 竞品分析 需求池 需求拆解 优先级决策 版本规划方案 指标验证与验收标准 关键决策点 三个方法的输出必须 在需求池中交叉验证

2.3 需求拆解与优先级决策

三大方法采集到的原始需求会汇总到需求池。但“用户想要A功能”这样的描述无法直接进入版本规划,必须经过拆解:

  1. 场景拆解:将需求还原到具体场景,明确触发条件、用户角色、预期结果。
  2. 问题拆解:量化业务影响(如“唤醒失败率每降低5%,次日留存可提升2%”)。
  3. 方案拆解:将用户期望转化为技术假设(如“增加离线唤醒模型”)。

优先级决策推荐使用RICE框架(Reach × Impact × Confidence ÷ Effort),每个维度采用1-5分制:

需求项 Reach Impact Confidence Effort RICE得分 优先级
地下车库离线唤醒 5 4 4 3 26.7 P0
多语种混合识别 2 3 2 5 2.4 P2
唤醒词自定义 3 2 3 2 9.0 P1
注意:Confidence ≤ 2 的需求即使得分高也建议先做验证型实验,不要直接放入正式版本规划。

2.4 版本规划方案

优先级排序完成后,将P0需求归入当前版本,P1需求放入下个版本待定,P2及以后进入产品Backlog。每个版本必须包含三类需求:

  • 关键场景修复:至少解决1个用户访谈中暴露的高频痛点。
  • 数据验证项:包含1-2个可通过A/B测试验证的假设。
  • 差异化功能:来自竞品Gap分析中识别出的机会窗口。

2.5 指标验证与验收标准

版本发布后,通过以下标准检验需求采集和拆解的正确性:

验收维度 指标 达标线 采集方法溯源
场景覆盖率 目标场景中需求被满足的比例 ≥ 90% 用户访谈
行为改善 核心场景任务完成率提升 ≥ 15% 数据分析
竞争差距 与竞品在关键指标上的差距缩小 ≥ 50% 竞品分析
用户满意度 版本满意度评分(1-5分) ≥ 4.0 用户访谈 + 问卷
最佳实践:在版本规划阶段就为每个P0需求写好验收卡,包含“采集来源→原始需求→拆解后需求→验收指标”的完整链路,这样版本发布后可以直接回溯验证采集方法的有效性。