| name | build-measure-learn |
| description | 用开发—测量—认知反馈循环驱动产品迭代。当你想知道"做完产品后如何判断对不对"、"要不要坚持当前方向"、"什么时候该转型"时，使用此Skill。 |
Skill: Build-Measure-Learn循环
Metadata
- ID: leanstartup-002
- 类型: framework
- 来源: 《精益创业》引言+第五章
- 验证状态: ✅ 三重验证通过（V1: 全书核心, V2: 每日决策, V3: 非常识）
R — Reading（原文引用）
"新创企业的基本活动是把点子转化为产品，衡量顾客的反馈，然后认识到是应该改弦更张还是坚守不移。所有成功的新创企业的流程步骤都应该以加速这个反馈循环为宗旨。"
I — Interpretation（方法论骨架）
BML循环的核心洞察：创业不是一条直线（计划→执行→评估），而是一个不断加速的循环。
- 开发(Build)：不是"做完产品"，而是"把想法转化为可以测试的形式"
- 测量(Measure)：不是"看数据涨跌"，而是"确认我们获得了关于假设的真实反馈"
- 认知(Learn)：不是"学到了新东西"，而是"证明或证伪了一个关键假设，决定坚持还是转型"
质量标准不是"功能多少"，而是"这个循环转得多快"。
A1 — Past Application（书中案例）
IMVU的教训：作者团队花了6个月开发产品发布后，没有任何用户。但他们没有把"发布"当成终点，而是把"发布"当成循环的起点——每天追踪顾客行为、每周迭代，最终找到正确的产品方向。
Facebook的快速迭代：不是"想好所有功能再发布"，而是每次只发布一个功能，观察数据，立刻决定是坚持还是调整。
A2 — Future Trigger（何时调用）
当你听到以下问题时，就应该调用这个Skill：
- "产品发布后，下一步该做什么？"
- "我怎么知道我们的方向是对的？"
- "我们要不要做一个新功能/进入新市场/改变定价？"
- "团队在争论该不该坚持当前方案，怎么裁决？"
- "产品迭代了很多版本，但不确定是否真的在进步"
E — Execution（可执行步骤）
步骤1：确认当前循环的位置
问自己：这个循环现在卡在哪里？
- 是不知道该开发什么？（想法太多，没有优先级）
- 是开发了但没有测量反馈？（发布了就完事）
- 是测了数据但不知道代表什么？（数据一堆，没有洞察）
- 是知道方向错了但不敢调整？（缺乏转型勇气）
步骤2：为每个活动计时
开发时间：从想法到"能获取用户反馈的产品"要多久？
- 目标：越短越好，目标≤1周
- 如果超过1个月，问："能否拆解成更小的可测试单元？"
测量时间：从发布到"获得有统计意义的数据"要多久？
- 目标：越短越好，目标≤2周
- 如果超过1个月，问："是否有更快的验证方式？"
认知时间：从数据到"知道该坚持还是转型"要多久？
- 目标：当天或次日决策
- 如果超过1周，问："数据是否清晰到可以决策？"
步骤3：问核心问题
"我们把时间投入哪个环节，能最大化加速整个循环？"
把资源集中在拖慢整个循环的那个环节。
步骤4：建立"加速"的定义
不要笼统说"加快迭代"，要具体：
- 从想法到用户反馈：原来X天 → 目标Y天
- 从数据到决策：原来X天 → 目标Y天
- 每月迭代次数：原来X次 → 目标Y次
B — Boundary（何时不适用）
| 不适用场景 | 原因 |
|---|
| 基础研究/长期技术研发 | 这类工作的反馈周期本身就很长，无法按"周"计算 |
| 高度监管的产品（药品/航空） | 合规要求限制了迭代速度 |
| B2B大型复杂销售 | 一个销售周期可能数月，不适合快速BML循环 |
作者盲点提醒：BML循环的"快"是有代价的——它要求团队习惯"不完美"并容忍频繁的方向调整。对于追求完美或权威导向的团队，这个循环会让成员焦虑。
关联Skills
- MVP构建法 — MVP是BML循环中"开发"阶段的最佳实践
- 转型决策树 — "Learn"阶段的产出决定是否需要转型
- 三个"可"衡量指标 — 确保"Measure"阶段的数据是可执行的
