第二章 MVP验收标准设定的前置条件:明确产品愿景、用户画像、核心假设
MVP验收标准不是凭空产生的,它必须建立在三个前置条件之上:产品愿景决定了验收的方向边界,用户画像决定了验收的评判视角,核心假设决定了验收的关键维度。本章将拆解这三个前置条件的具体内涵与操作方法,为后续设定验收标准打下根基。
2.1 适用场景
本章内容适用于以下具体场景——当团队处于产品定义早期或即将进入MVP开发阶段时,必须先完成三项前置条件梳理。如果在验收标准设定过程中出现方向分歧、优先级争议、指标无法落地等情况,通常意味着前置条件未充分对齐。
| 场景类型 | 典型表现 | 适用程度 |
|---|---|---|
| 新产品启动 | 从0到1构建产品,尚未形成清晰的用户与价值认知 | 必须执行 |
| 现有产品新增模块 | 在成熟产品中开辟新功能线,需重新定义目标用户与假设 | 强烈建议 |
| 方向 pivoting | 因数据或市场反馈需要调整产品方向 | 必须重新执行 |
| 验收标准反复返工 | 验收标准频繁变更,团队对"什么是好"无法达成一致 | 需回溯至前置条件 |
2.2 前置条件
执行本章内容之前,团队需要先确认以下基础条件已就位:
- 已确定产品立项决策(获得资源支持或管理层确认)
- 至少完成一轮目标用户访谈或二手调研(非必须但强烈推荐)
- 团队核心角色(产品经理、技术负责人、业务方代表)已到位
- 具备基本的用户研究或需求分析工具(如用户访谈提纲、调研问卷模板)
提示: 如果团队尚处于"想法阶段"且没有接触过任何真实用户,建议先开展最少3~5组用户访谈再进入本章操作。纯粹的内部讨论容易产生"伪用户画像"和"虚假假设"。
2.3 操作步骤
本步骤按照“愿景 → 画像 → 假设”的递进关系展开,共分为8个详细步骤。每个步骤都包含具体的操作要领与产出要求。
| 步骤 | 操作内容 | 关键要领 | 产出物 |
|---|---|---|---|
| 1 | 提炼产品愿景声明 | 用一句话回答"我们为什么做这个产品,它解决了谁的根本问题";避免功能列表式描述 | 产品愿景卡片(1张) |
| 2 | 界定愿景的边界条件 | 明确"做什么"和"不做什么";用in/out list区分范围 |
边界条件清单 |
| 3 | 识别目标用户群体 | 从愿景出发,列出可能使用产品的2~3类用户角色 | 用户角色初选列表 |
| 4 | 构建用户画像 | 为每类角色填充:人口属性、行为特征、痛点/目标、决策因素 | 用户画像卡片(每类1张) |
| 5 | 绘制用户场景地图 | 选取核心用户,画出3~5个关键场景触点 | 场景触点清单 |
| 6 | 推导核心假设 | 针对每个场景,提出"如果我们做A,用户会B"的因果假设 | 核心假设列表 |
| 7 | 假设优先级排序 | 按"风险程度"和"影响范围"对假设排序,筛选出前3~5条 | 优先级排序矩阵 |
| 8 | 输出验收候选维度 | 将高优先级假设转化为可观察/可衡量的验收维度 | 验收标准候选列表(初稿) |
操作要点: 步骤1~2由产品经理主导,步骤3~5需要用户研究人员参与(如有),步骤6~8需要产品经理+技术负责人+业务方三方共同完成。每个步骤完成后需由团队其他成员"反向复述"确认理解一致。
2.4 输入输出物
| 类型 | 名称 | 说明 |
|---|---|---|
| 输入物 | 产品立项文档 / 产品brief | 描述产品背景、目标、初步范围;至少包含1~2段产品初衷说明 |
| 输入物 | 用户调研原始记录(如有) | 访谈录音、笔记、问卷原始数据;用于支撑用户画像真实性 |
| 输出物 | 产品愿景卡片 | 包含愿景声明(一句话) + 边界条件(in/out list) |
| 输出物 | 用户画像卡片 | 每类角色1张,包含属性、行为、痛点、目标、使用场景 |
| 输出物 | 核心假设列表(含优先级) | 至少5条假设,标注优先级和风险等级 |
| 输出物 | 验收标准候选列表(初稿) | 从高优先级假设转化而来,每条对应1~2个候选标准 |
常见误区: 很多团队跳过"边界条件"直接写愿景,导致后续验收范围失控。务必在愿景卡片中明确写出"我们不做什么",这比"做什么"更能帮助验收标准聚焦。
2.5 责任边界
| 角色 | 职责 | 决策权限 |
|---|---|---|
| 产品经理 | 主导愿景提炼、画像结构设计、假设推导与排序 | 有权确认愿景声明最终版本;有权否决不符合用户画像的假设 |
| 用户研究员(如有) | 提供用户数据支撑,验证画像真实性,修正偏差 | 有权要求产品经理修改与实际数据不符的用户描述 |
| 技术负责人 | 从技术可行性角度评估假设的可验证性 | 有权对"当前技术无法验证"的假设提出降级或拆分建议 |
| 业务方代表 | 提供业务视角,确认愿景与真实业务需求的一致性 | 有权否决偏离核心业务目标的愿景描述 |
2.6 记录材料
本章操作过程中需要留存的记录材料包括以下3份核心文档,建议使用统一模板归档:
- 产品愿景卡片(模板示例)
产品愿景卡片 版本:V1.0 日期:2025-XX-XX 愿景声明:_________________________________ (一句话:为谁解决什么问题,带来什么价值) 边界条件: In(范围内): · _________________________ · _________________________ Out(范围外): · _________________________ · _________________________ - 用户画像卡片(模板示例)
用户画像卡片 角色名称:__________ 人口属性:_________________________ 行为特征:_________________________ 核心痛点:_________________________ 使用目标:_________________________ 典型场景:_________________________ - 核心假设列表(模板示例)
核心假设列表 编号 | 假设内容 | 来源场景 | 风险等级 | 优先级 ----|----------|----------|----------|------ H1 | 如果___ | 场景A | 高 | P0 H2 | 如果___ | 场景B | 中 | P1
归档建议: 建议将上述3份记录材料存入团队共享文档库(如Confluence、飞书文档、Notion),并@相关成员确认。每次迭代更新时需保留历史版本,便于回溯验收标准变更原因。
2.7 异常处理
| 异常情况 | 处理方法 | 升级路径 |
|---|---|---|
| 愿景描述出现分歧 | 组织"愿景对齐工作坊",使用电梯演讲结构化模板强制收敛;每人写一版,然后合并共性内容 | 仍无法达成一致时,由产品总监/业务负责人做最终裁决 |
| 用户画像缺乏数据支撑 | 标记为"待验证画像",先用内部专家经验补充,同时启动快速调研(3天内完成5组访谈) | 若时间不允许调研,需在验收标准中增加"用户验证"环节 |
| 核心假设数量过多(超过10条) | 强制使用风险-影响矩阵筛选,只保留前5条;其余放入"实验候补清单" | 产品经理与业务方共同裁定优先级 |
| 团队对"假设"概念理解不一致 | 使用"如果…那么…"句型统一表达;现场举例示范 | 邀请有经验的产品教练或内训师介入辅导 |
| 业务方频繁修改愿景边界 | 要求业务方以书面形式提交变更申请,并评估对验收标准的影响 | 触发需求变更流程,重新评审前置条件 |
注意: "用户画像缺乏数据支撑"是最常见的异常。如果团队为了赶进度而编造画像,后续所有验收标准都会建立在错误的用户认知之上,导致MVP验收时发现方向根本不对。这种情况下,宁可延迟1周做调研,也不要用虚假画像。
2.8 验收标准
本章操作完成后,团队应使用以下检查项进行自我验收,确保前置条件已充分建立:
| 序号 | 检查项 | 验证方式 | 合格标准 |
|---|---|---|---|
| 1 | 产品愿景声明是否简洁明确,且团队核心成员能复述一致 | 随机提问3人 | 3人复述内容偏差 ≤ 20% |
| 2 | 边界条件是否同时包含"in"和"out"两部分 | 文档审查 | 必须同时存在,且各 ≥ 3条 |
| 3 | 用户画像是否覆盖至少2类角色,且每类包含5个维度以上 | 文档审查 | 角色数 ≥ 2,维度数 ≥ 5/类 |
| 4 | 核心假设是否使用"如果…那么…"格式表达 | 逐条审查 | 100%使用统一格式 |
| 5 | 核心假设是否已完成优先级排序,且前5条可追溯到具体用户场景 | 回溯验证 | 每条假设均有场景来源标识 |
| 6 | 验收标准候选列表是否已从高优先级假设中导出 | 对比检查 | 候选标准覆盖前5条假设 |
| 7 | 所有记录材料(愿景卡片、画像卡片、假设列表)是否已归档并通知相关方 | 系统检查 | 归档完成且已发送通知 |
验收通过条件: 上述7项检查项全部为"合格"时,本章前置条件工作方可视为完成,团队可进入第3章「MVP范围界定与功能拆解」。若存在 ≥ 2项不合格,需返回对应步骤重新操作。