灰色小熊过去一年，我把团队的产品分析与规划流程，从一堆零散的用户访谈纪要和Excel需求池，收敛到了 BMAD 这套可复用的方法论架构上。说“收敛”其实并不准确，准确说是被逼出来的：每个版本评审会都像开盲盒，开发问“这个需求到底解决什么问题”，老板问“凭什么先做这个不做那个”，客户成功团队又甩过来一堆互相矛盾的反馈。直到我把 Phase 1（产品分析）和 Phase 2（产品规划）当成两个独立又强耦合的阶段来执行，整个讨论才从“互相说服”变成了“共同解题”。
这篇文章不打算讲什么玄乎的理论，而是把我在真实业务里用 BMAD 做产品分析与规划的全过程拆开，包含每个阶段的输入、输出、工具模板，还有那些只有实际踩过坑才会注意到的细节。如果你正在带产品项目、做产品决策，或者刚转行做产品经理觉得需求分析永远没有章法，这篇文章应该能直接拿去用。
1. 先给BMAD“验明正身”：方法论架构为何把产品工作切成两个阶段
1.1 一次评审会把我的思路撞碎之后
先说一个让我彻底反思的场景。当时我们做一个企业内部知识管理工具，版本评审会上产品经理花了二十分钟讲新增的“智能推荐”功能，开发负责人问了一句很朴素的话：“这个功能和上个月上线的内容订阅有什么关系？”全场安静了。
我后来复盘发现，问题不在“智能推荐”这个方案好不好，而在于我们直接从“用户想要更聪明的内容获取方式”跳到了“做一个推荐功能”。中间漏掉了一整段推理：用户为什么觉得内容获取低效？是搜索入口太深？还是内容本身质量不高？用户的核心使用场景是哪几类？如果把这一段推理补齐，有可能会得出完全不同的结论。
BMAD 就是补这段推理用的。它逼着团队先回答“我们在哪个业务目标下做判断”，再去聊用户、场景和问题。这件事做在前面，后面开会才会变成解题，而不是辩论。
1.2 BMAD四个字母在表达一条思考主链
BMAD 在不同团队里可以被赋予不同的展开方式，但整套方法的内核是一条思考主链：先锁定业务目标（Business），再把业务抽象成可讨论的模型（Model），接着用证据做分析验证（Analysis），最后才进入决策与规划（Decision）。这条链最容易被跳过的环节是中间的“建模”和“分析”，大部分团队都习惯从业务目标直接跳到解决方案，等于把后面两个动作全部外包给了直觉。
用知识管理工具的例子来说：业务目标是“提升内容的利用率”，可讨论的模型是“内容生产过程：生产-入库-分发-消费”，分析动作是在每个环节找数据、找用户反馈、确认瓶颈到底在哪一段。等这四步走完，产品方案要解决什么问题已经不言自明。
所以 BMAD 不是又一个需求文档模板，它是一种阻止你过早提出解决方案的思维刹车。Phase 1 覆盖这条主链的前半段，也就是业务目标、建模和分析；Phase 2 覆盖后半段，也就是基于分析结果做决策、排优先级、定路线图。两段分开，是为了避免“还没分析清楚就开始规划”这个几乎人人都犯的错。
1.3 Phase 1 和 Phase 2：不是流程分工，而是两种心智模式
很多团队把产品工作分成“调研”和“规划”，看起来已经是两段式，实际执行中还是混着来。原因在于两张阶段的产出物完全不同，对思考的要求也完全不同，人如果坐在同一场会议里，很容易滑向那个更轻松的方向——赶紧列方案。
Phase 1 是发散与收束交替的分析阶段，适合用工作坊、访谈、数据看板去推敲“问题本身是什么”。对它最准确的心智模式是“做侦探”：不看结论，看证据链。
Phase 2 则是一个计划和取舍阶段，适合用优先级矩阵、依赖分析、里程碑切片去回答“我们接下来做什么、按什么顺序做”。它的心智模式是“做调度员”：不纠结永恒的正确，只看有限资源下最好的下一步。
把这两种心智放在同一个会议里，结果通常是分析会开成需求评审会，规划会开成头脑风暴会。这也是我认为 BMAD 方法论架构最有价值的地方：它用明确的阶段定义和输出物，把两件事从组织层面分开，再通过固定节奏把它串起来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Phase 1拆解：产品分析要交付的是判断，不是调研报告
2.1 业务目标解构：穿透“我们要增长”这类模糊表述
Phase 1 的第一步不是去访谈用户，而是先跟需求发起方对齐“业务目标具体指什么”。大多数需求之所以后面走形，是因为开始的业务目标就没说清楚。
“我们要提升知识库月活”“我们希望用户分享次数变多”“我们要提高付费转化”——这些目标听上去都对，但不能直接指导分析。它们至少缺了三个要素：数值、期限、目标对象。
我当时梳理业务目标时会用一张“目标澄清清单”：
- 这个目标在什么时间范围内达成？是季度目标还是年度目标？
- “提升”的基线是多少？从 10% 提到 15% 和从 30% 提到 35%，解题路径完全不同。
- 最希望看到行为变化的人群是哪一个细分？是新用户还是低频老用户？
- 如果这个目标达成了，业务上哪个环节会因此受益？
有一次业务方拍过一句“让知识库更活跃”，我追着问了一个小时才把目标拆成：季度末，新注册团队中第 7 天活跃率从 22% 提升到 35%。目标一旦变成这句话，产品分析的方向立刻清楚：不是去优化高级搜索或智能推荐，而是要先解决“新团队第一周如何快速把内容填起来”的问题。这就是目标解构的意义：把方向性的口号翻译成可分析的行为命题。
2.2 用户与场景矩阵：把目标人群摊开来看
目标清楚之后，就要建模。这里的“模型”不需要很高深，但一定要让团队对用户形成统一的描述。我喜欢用的工具是“用户与场景矩阵”，它把用户分层和场景频率放在一个二维表里。
实际建模时，我先列清谁在用产品，粗略分为“内容生产者”“内容消费管理者”“内容消费者”三类。接下来要区分用户在什么场景下进入产品：比如“入职第一天查阅制度文档”“项目中期找历史决策记录”“项目结束后沉淀复盘文档”。把人群和场景做交叉，就能得到若干“人群-场景-核心任务”的组合。
矩阵的价值在于，它会暴露团队之前忽略的组合。比如我们从前只关注内容消费者如何搜资料，矩阵却显示“内容生产者”在项目结束后的归档场景里流失非常严重，大量项目复盘文档没有被结构化管理，导致后续内容消费者无论用多聪明的搜索都找不到东西。这个洞察后来直接改变了产品方向。如果一上来就只访谈“爱用搜索的那批用户”，这个更上游的问题根本不会被发现。
2.3 真伪需求判定：三类“需求证据”的可靠性排序
有了用户场景和初步访谈信息，Phase 1 里最考验功力的动作来了：判断哪些需求值得进入下一步规划。我把常见需求证据按可靠性做了一个排序，这个排序帮团队挡掉过不少伪需求。
| 证据类型 | 表现形式 | 可靠性 | 典型陷阱 |
|---|---|---|---|
| 行为数据 | 漏斗流失率、功能点击热力、搜索无结果率 | 高 | 数据只能说明现象，不能自动给出原因 |
| 场景化访谈 | 用户在真实任务中的操作过程与卡点 | 中高 | 用户容易把结果归因于表层因素 |
| 观点与投票 | “如果能做XX功能就好了”的评价 | 低 | 用户描述的是解决方案，不是需求 |
典型陷阱我专门展开说一次。知识库产品里，有一个大客户提出“希望有 AI 自动生成摘要”，理由是“文档太长，大家不看”。表面需求是加一个摘要能力。把场景化访谈做深之后却发现，真实原因是部门文档缺乏统一的模板和开头结论，大部分文档需要翻到第三页才知道结论。客户描述的“摘要”其实是在补内容结构缺陷，而不是真的需要生成式 AI。我们把 Phase 1 的结论定为“先做内容模板和结论前置规范”，成本低、见效快，而且直接解决了“太长不看”的问题。
因此我在团队里立了一条规矩：所有出现在规划文档里的需求，必须至少同时有“用户原话摘录”和“行为或场景证据”，两者缺一不可。只有观点、没有场景证据的需求，只进观察清单，不进需求池。
2.4 Phase 1的交付物：《分析结论卡》长什么样
Phase 1 当然有文档产出，但我的经验是绝不要写冗长的分析报告。报告越长，被认真读完的概率越低。我们内部把 Phase 1 的固定交付物叫“一页纸分析结论卡”，结构非常固定：
- 业务目标（含数值、期限、目标用户）
- 关键模型/场景图（可用一段文字或简单表格表达）
- 主要发现列表：按“证据-判断”成对出现
- 待验证假设：暂时无法100%确认，但已经比较可信的假设
- 被排除的方向：明确不做什么，并写清原因
- 建议进入 Phase 2 的机会点清单
分析结论卡的精髓是“判断明确”。很多团队的产品分析文档写得像新闻综述：什么问题都说了一点，但没有一个问题是拍板定论的。BMAD 要求每一张分析卡都必须能回答“所以我们要做什么、不做什么、为什么”，如果写不出来，说明 Phase 1 还没有完成。
3. Phase 2拆解：产品规划要交付的是节奏，不是功能清单
3.1 从需求池到候选清单：过滤器的三层结构
进了 Phase 2，第一步是把 Phase 1 留下的机会点跟现有需求池合并，然后过一个三层过滤器。
第一层过滤器是“目标相关性”：这个需求是否直接服务于当时季度锁定的业务目标？如果不直接相关，哪怕听起来再酷，也只能放入“探索队列”而不是提上日程。
第二层过滤器是“证据强度”：需求是否来自 Phase 1 识别到的痛点场景，有没有用户原话与行为数据双重支持？如果只有孤立的用户反馈，就继续保留在观察清单。
第三层过滤器是“能力匹配”：团队当前的技术储备和数据基础设施是否支持？这里最常出现的问题是“技术上能做”和“技术上能做好”的混淆。智能推荐算法可以接进来，但如果用户行为数据量连最小推荐模型都喂不饱，硬做就等于上线的第一天就在积累技术债。
三层过滤器全部通过的需求会进入候选清单，用三维度进行排序。我把评估维度定为：价值贡献、实施成本、确定性。价值贡献看它对核心指标的影响幅度和范围；实施成本包括开发工时、跨团队协作、后续维护成本；确定性指的是我们对用户反应和上线效果的把握程度。
三个维度做完，我会给每一个需求算一个“行动分数”，用通俗公式表达是：行动分数 = 价值贡献 × 确定性 / 实施成本。高风险高回报项目有时候也会故意保留，但团队心里清楚这是在主动选择不确定性，而不是因为漏算了风险。
3.2 版本切片：识别依赖、锁定最小可行范围
优先级排完，接着面对的是老生长谈的版本规划问题。传统做法是列一个功能清单，开发说“这些功能大概两到三个月”，产品说“那把上线时间定在X月”。BMAD 的 Phase 2 在版本规划上强调的是做“切片（slicing）”，而不是做“整块”。
切片之前先做两个动作：找依赖，找收益闭环。所谓找依赖，是看候选功能之间有没有数据依赖、UI 依赖或行为依赖。比如“推荐内容流”依赖“内容标签完善”，“内容标签完善”又依赖“入库模板改版”。如果依赖不识别，排期会不断被打断。
找收益闭环的意思是，每个版本切片都应该能用一句话描述“用户做了什么动作，产品数据会发生什么变化”。如果切出来的版本只是功能堆积，没有形成行为链条，我基本会打回重排。
知识库项目一个比较成功的切片案例：我们第一版不做全量智能搜索升级，而是先做“搜索结果页面中增加‘最近编辑过的文档’字段”，把用户从搜索行为引导到近期活跃内容上。这个切片体量很小，但它能验证一个关键假设：用户找不到内容的原因是不是因为不知道哪些文档是最新的。如果假设成立，第二步再做“活跃内容自动置顶”，第三步才考虑更重的“基于团队的个性化排序”。整个切片序列形成一个完整的学习闭环，而不是一锤子买卖。
3.3 指标树：让每条规划都有一条可以被证伪的结果
Phase 2 还有一个许多产品经理容易忽略的交付物：指标树。没有指标树，规划里所有“希望提升体验”“希望增加活跃”都是一句空话。
我在做规划时会在产品方案旁挂一棵三层指标树：北极星指标、过程指标、反向指标。
仍拿知识库产品说明。北极星指标是“周活跃内容消费数”。过程指标包括“入库模板完成率”“搜索结果点击率”“文档更新频率”。反向指标则是“内容误删率”“用户搜索跳出率”等。上线一个版本前，每项规划都必须写明预期会影响哪一层指标，并给出一个可以事后校验的数字方向。
比如做“最近编辑过的文档”字段时，预期提升的是搜索结果点击率，从 30% 提高到 36%。如果上线两周后数据没有变化，我们就要回头质疑切片假设，而不是自我安慰“还需要时间”。这种证伪机制让每一次版本规划都变成实验设定，而不是领导要的“交付物”。
3.4 规划文档怎么写才不被开发骂
Phase 2 的规划文档我也有一套轻量模板，不铺长文，围绕四个维度组织：为什么现在做、解决什么问题、预期如何验证、与其他功能的关系。很多开发抱怨产品文档不清，本质是产品经理没把原因写明白，只写了要做什么。
我的路线图文档里，每个版本会带一张四栏表格：
| 版本目标 | 关键切片 | 预期行为变化 | 验证时间点 |
|---|---|---|---|
| 提高新团队内容入库率 | 入库模板改版 | 入库完成率从 45% 提到 65% | 上线后第7天 |
| 提高内容消费效率 | 活跃内容优先展示 | 搜索结果点击率从 30% 提到 36% | 上线后第14天 |
开发在看到这张表的时候，能理解自己做的功能是为了哪个数据服务；测试也能根据预期行为变化编写验收用例；运营则能提前准备数据看板。规划文档如果只写功能和排期，那就只是一张施工图，不是产品规划。
4. 从入门到精通：BMAD落地时最容易变形的三个环节
4.1 变形一：分析堆材料，不产出结论
第一次带团队用 BMAD 的时候，产品经理交上来的 Phase 1 文档有三十页：竞品截图、用户访谈时间轴、数据报表全贴进去了，但我找不到任何“所以呢”的句子。这是所有方法论落地时最常见的变形：大家把分析当成了收集材料，而不是形成判断。
修正方法是我后来强制的“一句话结论训练”。每一份 Phase 1 结论卡只能保留三句话以内的核心判断，如果判断和判断之间互相冲突，就必须回到证据里重新辨析，而不是同时保留。比如你既写了“内容入库阻碍大”又写了“内容搜索体验差”，那必须确认到底哪一个才是当前阶段的主要瓶颈。分析可以有多个发现，但必须分清主次。
这个要求并不是为了简化，而是为了让 Phase 1 真正能支撑 Phase 2。如果分析端没有一个最强判断，规划端就会陷入平均用力，最后每个需求都做一点，哪个都没做透。
4.2 变形二：规划和现实开发脱节，排期被频繁击穿
另一个容易变形的环节是 Phase 2 的排期估算。产品经理把路线图画得漂漂亮亮，开发一做发现工作量比预期大两倍，规划立刻失效。这个问题的根源通常不在开发估算不准，而在规划阶段没有把“缓冲区”和“返工区”设计进去。
我后来给 Phase 2 加了三类时间区：开发时间、测试时间、验证修正时间。很多排期只算了前两类，导致功能上线后一旦数据不达预期，团队没有时间做迭代修正，只能把问题带进下一版本。
BMAD 的 Phase 2 是把“验证假设”当作工作内容的一部分来排期的。每个关键切片默认预留一个修正周期，如果验证顺利，周期可以用来优化细节；如果验证不达预期，时间用来做二次调整。这样的排期才更接近开发真实节奏，而不是一份自欺欺人的甘特图。
4.3 变形三：方法只有自己会用，团队协同断层
第三个坑比较隐蔽：一个产品经理学会了 BMAD，但设计师、开发、运营都没学过，评审会照样回到老路。每个人都有自己的表达习惯，你提问的方式如果没有被团队理解和接受，对话依然会散。
我在团队里推动的方式不是先讲方法论，而是先统一“提问模板”。评审每个需求时固定问五个问题：
- 我们正在解决的业务目标是什么？
- 这是谁在什么场景下的问题？
- 有没有证据说明这个问题值得被解决？
- 这个版本切片完成后，什么数据会改变？
- 如果数据不变，我们的备选动作是什么？
这五个问题拆开看都很朴素，合在一起其实就是 BMAD 的主链。几个月后，团队开发在需求评审会上也能自己用这套话术提问，产品经理节省了大量解释时间。方法论的“团队化”从来不是靠让大家背概念，而是靠把概念变成会议的默认议程。
4.4 我目前在用的落地检查表与常见模板
最后分享一套我现在每次启动新项目都会跑的轻量检查表，你直接复制到自己文档里就能用：
业务目标是否已包含“数值、期限、目标用户”三要素？
- 是 / 否，原因：
Phase 1 阶段：
- 用户分层与场景矩阵是否完成？
- 每个核心判断是否都有至少两类证据支撑？
- 有没有明确“不做什么”的排除项？
- 分析结论卡是否控制在三句话核心判断以内？
Phase 2 阶段：
- 需求是否通过三层过滤器？
- 版本切片是否识别了依赖，并能形成行为闭环？
- 指标树是否包含北极星、过程、反向三层？
- 排期是否预留学生验证与修正时间？
这个检查表不是束缚，它是防止团队退化成“方案驱动型组织”的护栏。产品分析的本质是把资源投向确定性更高、价值更大的问题；产品规划的本质是让团队在未知中依然保持稳定的交付节奏。两件事看着简单，真正做扎实需要每一个迭代都坚持使用这套动作。
我个人的体会是，BMAD 最有价值的不是某个阶段的技巧，而是它逼着团队把“分析和规划”从性格和直觉中剥离出来，变成一套可以讨论、可以修改、可以传承的流程。如果这套逻辑对你有启发，不妨从下一次最不起眼的需求评审开始，先试着多问一句“我们正在解决的业务目标是什么”，接下来的事情会自然发生改变。