第二章 需求分析与产品定义：用户场景挖掘、功能优先级排序、技术可行性评估、MVP定义

说实话，很多做语音产品的团队，一上来就急着写代码、调算法。我见过太多这样的案例——花了三个月做出一个“完美”的原型，结果用户根本不买账。为什么？因为从一开始就没想清楚：这东西到底给谁用？在什么场景下用？哪些功能是必须的？

这一章，我们就来聊聊产品定义阶段的核心工作。我个人习惯把这个阶段叫做“想清楚再动手”。你想想看，盖房子之前还得画图纸呢，做语音产品也一样。

2.1 用户场景挖掘：别坐在办公室里猜

用户场景挖掘，说白了就是搞清楚你的产品会在什么时间、什么地点、被什么人、用来干什么。我早期做过一个智能音箱项目，团队觉得“语音控制家电”是刚需，结果用户调研发现——大多数人回家第一件事是掏出手机，而不是对着空气喊。

场景挖掘有几个关键维度：

• 物理环境：安静还是嘈杂？室内还是室外？距离多远？
• 用户状态：双手是否被占用？注意力是否集中？
• 任务类型：是信息查询、设备控制，还是娱乐互动？
• 使用频率：每天用几次？还是偶尔用一次？

常用的场景挖掘方法：

• 用户访谈：找5-8个目标用户，聊他们的日常习惯
• 实地观察：去用户实际使用环境里看他们怎么操作
• 日志分析：如果有竞品，分析它们的用户行为数据
• 场景卡片：把典型场景写在卡片上，让用户排序

2.2 功能优先级排序：别什么都想要

场景挖掘完了，你手上可能有一堆功能需求。这时候最忌讳的就是“全都要”。我见过一个团队，给智能闹钟加了30多个功能——播新闻、查天气、讲故事、背单词、甚至还能做数学题。结果呢？用户连“设置闹钟”这个核心功能都找不到。

功能优先级排序，我推荐用 MoSCoW 方法：

优先级	含义	举例（语音闹钟）
Must have	没有这个功能，产品没法用	语音设置闹钟、取消闹钟
Should have	重要，但可以稍后实现	语音查询天气、播报时间
Could have	有更好，没有也行	语音讲故事、播放音乐
Won't have	这次不做，以后再说	语音控制智能家居、语音购物

排序时还要考虑两个维度：

• 用户价值：这个功能解决了用户什么痛点？
• 实现成本：开发这个功能需要多少资源？

画一个四象限图，把功能放进去。右上角（高价值、低成本）的先做，左下角（低价值、高成本）的直接放弃。

2.3 技术可行性评估：别被PPT忽悠了

功能优先级排好了，接下来要问一个问题：这些功能，以我们现在的技术能力，能做出来吗？

语音交互系统的技术可行性评估，我一般从这几个方面入手：

1. 语音识别（ASR）：在目标场景下，识别率能达到多少？远场、噪声环境下的表现如何？
2. 自然语言理解（NLU）：用户可能用多少种不同的说法表达同一个意图？我们的模型能覆盖多少？
3. 语音合成（TTS）：需要什么音色？响应速度要求多快？
4. 硬件资源：MCU算力够不够？内存够不够？功耗能不能接受？
5. 网络依赖：是纯离线方案，还是需要云端支持？离线方案的词库大小、唤醒率如何？

技术可行性评估的输出，应该是一份 技术风险清单：

• 哪些功能是成熟技术，可以直接用？
• 哪些功能需要做技术攻关？
• 哪些功能目前根本做不了，需要调整产品定义？

2.4 MVP定义：最小可行，不是最小功能

很多人对MVP有误解，觉得MVP就是功能最少的版本。其实不是。MVP的核心是：用最小的成本，验证最大的风险。

举个例子。你要做一个语音控制的台灯。MVP应该是什么？

• ❌ 做一个完整的APP，支持语音、手势、手机控制
• ✅ 只做一个语音开关灯的功能，用开发板+麦克风+继电器实现

为什么？因为最大的风险是“用户愿不愿意用语音控制台灯”。如果这个验证不通过，其他功能做得再好也没用。

MVP的定义文档，一般包含以下内容：

• 核心用户场景：1-2个最典型的场景
• 功能列表：只包含“Must have”功能
• 验收标准：什么样的表现算“可用”？比如唤醒率>90%，响应时间<2秒
• 排除项：明确哪些功能这次不做
• 时间计划：MVP的开发周期，一般建议4-8周

嗯，这里要注意一点：MVP不是最终产品，它只是一个学习工具。它的目的是让你快速知道“这条路对不对”。如果对了，继续投入；如果错了，赶紧掉头。别把MVP当成“缩水版”的正式产品，那样你会陷入无休止的加功能循环。

最后，分享一个我自己的小习惯。每次定义完MVP，我都会在团队里问一个问题：“如果我们只有两周时间，只能做三个功能，你会选哪三个？” 这个问题能帮你快速找到真正的核心。试试看，你会发现很多你以为“必须”的功能，其实没那么重要。