build-measure-learn

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"阶段的数据是可执行的