3. 产品方向与用户画像界定：目标用户、核心需求、问题域边界
在产品 MVP 阶段，方向选择错误是最大的浪费。本章聚焦于如何通过结构化框架界定目标用户、提炼核心需求，并严格划定问题域边界，确保交付资源投入在最具验证价值的环节。
3.1 用户画像的三维界定框架
用户画像是产品方向的锚点。针对架构方案型课程，我们采用 业务边界 × 用户分层 × 技术边界 的三维界定方法，避免模糊的“泛用户”描述。
| 维度 | 定义 | MVP 阶段核心要求 |
|---|---|---|
| 业务边界 | 用户在组织/生态中的角色与职责范围 | 只覆盖 1～2 个典型业务场景，不追求全角色 |
| 用户分层 | 按决策权、使用频次、技术成熟度分层 | 优先选取“高痛点、低迁移成本”的种子层 |
| 技术边界 | 用户对集成方式、数据密级、接口标准的限制 | 明确数据流向与信任链路，锁定最小可行集成 |
案例提示： 某企业内部数据分析平台 MVP，目标用户不是“所有部门”，而是“电商运营组中 3 名月报编写者”。业务边界限定为“月销售趋势分析”，用户分层为“高频写报表但无技术背景的运营”，技术边界限定为“只读离线数仓表，不涉及写回”。
3.2 核心需求的四象限分类
需求分类是 MVP 优先级决策的关键。采用 频率 × 价值 四象限法，将用户需求划分为 4 类：
- 高频高价值（P0）：MVP 必须包含，缺少即无法验证产品价值。
- 高频低价值（P1）：可做自动化或减配版，降低用户操作成本。
- 低频高价值（P1）：通过灰度或手动辅助临时满足，暂不纳入 MVP。
- 低频低价值（P2）：明确放入“不做清单”，直到数据积累证明其必要性。
选型权衡： 如果高频高价值需求的技术复杂度超出 MVP 交付能力（例如需要跨多个异构系统），优先寻找“最小可行替代路径”，而非直接砍掉。例如用人工辅助 + 半自动脚本临时支撑，待架构解耦后再升级。
3.3 问题域边界确认：责任链与“不做什么”清单
问题域边界是防止 MVP 膨胀的护栏。我们需要从 责任链视角 审视每个需求在系统中的流动路径，并明确“不做什么”。
| 边界类型 | 确认方法 | 输出物 |
|---|---|---|
| 数据边界 | 列出 MVP 所需的数据实体与外部数据源接入点 | 数据流图（仅画到第 2 层） |
| 功能边界 | 按“用户故事 × 验收标准”逐条判断是否纳入迭代 | MVP 产品待办列表（含“排除列表”） |
| 集成边界 | 标记外部系统的信任链路与接口合约版本 | API 契约文档（草稿） |
常见风险点： 团队在界定问题域时容易犯“乐观估算”的错误：认为某个需求“后期很容易加上”，从而在 MVP 阶段就引入过于宽松的边界。此做法会导致架构腐蚀，后续渐进式交付时大量返工。正确的做法是：对于 P1/P2 需求，设计预留点（如空接口、配置占位符），但不做实现。
3.4 落地步骤与验收标准
为保障上述框架可执行，以下是本阶段的落地步骤：
- 步骤一：种子用户访谈与场景还原（产出：5 份以内的人物原型卡片）
- 步骤二：四象限需求分类工作坊（产出：按 P0/P1/P2 标记的用户故事）
- 步骤三：责任链推演（产出：数据流与控制流草图，标注信任链路）
- 步骤四：输出“不做什么清单”（产出：明确排除的功能与集成点）
| 验收标准 | 通过条件 |
|---|---|
| 用户画像清晰度 | 团队可用一段话描述种子用户的业务角色、技术背景与痛点 |
| 核心需求清单 | 所有 P0 需求已有对应的用户故事与验收条件 |
| 问题域边界 | “不做什么清单”获得产品负责人与架构师双方签字确认 |