mvp-architect

MVP 架构师 - 最小可行产品范围界定

概述

运用 Hexa 的方法论，帮助独立创始人将产品范围缩减到最小，以验证核心假设。在 3 个月或更短时间内推向市场。

Hexa 的核心原则：“在 3 个月内推出包含关键高价值功能的 MVP。即使功能还未发挥全部效用，也最好先推出清晰、易于理解的功能。”

适用场景

• “我的 MVP 应该包含什么”
• “帮我界定 MVP 的范围”
• “我需要哪些功能”
• “先构建什么”
• “已经开发了好几个月，但还没发布”

Hexa 的 7 项原则

1. 深入挖掘用户需求 — 关注根本需求，而非表面诉求
2. 对抗确认偏误 — 挑战各种假设
3. 尽早与设计合作伙伴协作 — 与真实用户共同构建
4. 优先设定灵活的里程碑 — 设定 6 个月目标，采用 2 周冲刺
5. 先绘制草图，再进行设计 — 在验证之前，保持粗糙即可
6. 围绕稳定要素构建 — 只纳入稳定的功能
7. 对架构进行压力测试 — 数据库设计会影响一切

快速工作流

第 1 步：明确问题

• 是否进行了 10 次以上的客户访谈？
• 能否用一句话描述问题？
• 是否有 3-5 位设计合作伙伴？

第 2 步：核心假设

We believe that [customer] has a problem with [pain point].
We believe that [solution] will solve this.
We will know we're right when [success metric].

第 3 步：功能优先级排序

针对每项功能，询问：

• 能否验证核心假设？→ 保留
• 用户是否明确提出过？→ 可能保留
• 是否属于关键路径？→ 保留
• 能否手动完成？→ 不要构建

目标：最多 3-5 项功能。

第 4 步：稳定要素测试

只构建在所有设计合作伙伴反馈中都保持稳定的功能。

第 5 步：用户旅程（3-4 个屏幕）

• 用户如何注册？
• 第一个操作是什么？
• 如何交付核心价值？
• 如何确认成功？

防止范围蔓延检查清单

添加任何功能前：

1. 这能验证我们的核心假设吗？→ 如果不能，就删掉
2. 是否有 3 位以上的设计合作伙伴提出过？→ 如果没有，就推迟
3. 没有这项功能，我们能发布吗？→ 如果能，就推迟
4. 我们能先手动完成吗？→ 如果能，就不要构建
5. 这会让发布延迟超过 3 天吗？→ 如果会，就删掉

“两周内发布”测试

如果你必须在 2 周内发布，会删掉什么？ 无论你会删掉什么……现在就删掉。 那才是你真正的 MVP。

集成

• idea-validator - 界定范围前先进行验证
• startup-icp-definer - 明确你的目标用户
• fullstack-workspace-init - 设置代码库
• brand-architect - 为产品命名并定位

---

完整的假设框架、功能优先级矩阵、稳定要素识别、屏幕映射、技术架构检查清单、时间线模板和输出格式，请参阅： references/full-guide.md