当需要设计 MVP、验证商业假设…

适用于创业或新产品探索：用最小可行实验、可执行指标和创新会计快速验证或推翻关键假设，并据此决定坚持或转型。

适用场景

解决思路

1. 把创业或新业务当作管理过程：把每份计划视为一组待证伪假设，不执行固定 roadmap，投入消除浪费并加速 validated learning。
2. 用 Quick Diagnostic 五行给计划、实验或指标集评分：每行答案为 yes 得 1 分，若还有 Validation Ladder Level 3+ 证据再得 2 分；9-10 分要求所有 leap-of-faith assumption 已命名并按风险排序、最风险假设由真实 MVP 测试、已定义 actionable metric、构建前已设 pivot criteria；5-6 分表示有假设和 MVP 但指标虚荣或 pivot criteria 未定义；≤3 分表示 waterfall 思维；报告当前分数和最低分行作为下一步修复点。
3. 反向规划 Build-Measure-Learn 循环：按 IDEAS → BUILD（product）→ MEASURE（data）→ LEARN（knowledge）→ 回到 IDEAS；先问要学什么 hypothesis，再问如何知道已学到 metrics，最后问最小能建什么 MVP；目标是最大化减少通过循环的总时间。
4. 规划实验时查看 references/build-measure-learn.md：使用反向规划序列、实验设计模板、按产品类型的循环示例，并避开 build loop 与 vanity-metric loop 陷阱。
5. 用真实行为做 validated learning：衡量客户 do 而不是 say；不要依赖 feature requests、surveys 或 focus groups；运行能否证伪假设的实验；拒绝下载量、无 engagement 注册等虚荣胜利。
6. 用 Validation Ladder 定位证据强度：Level 1「我认为客户想要」= 最弱（观点）；Level 2「客户说想要」= 弱（stated preference）；Level 3「客户注册 early access」= 中（low commitment）；Level 4「客户付定金」= 强（real commitment）；Level 5「客户正在积极使用」= 最强（revealed preference）；规模化构建前目标 Level 4-5。
7. 把 MVP 设计为学习载体：提供最大 validated learning 和最少努力；不是 prototype（技术可行性）、不是 beta（质量）、不是 minimum marketable product；通常小得令人尴尬、质量低，且比你想的小。
8. 选择 MVP 类型：Concierge（手动服务假装自动化，测试解决方案是否有价值，例 Food on the Table）；Wizard of Oz（假自动化、手动后台，测试是否需要自动化，例 Zappos）；Smoke test（landing page + signup、无产品，测试需求，例 Dropbox 视频）；Single feature（只做一个核心功能，测试哪个功能最有价值，例 Twitter）；Piecemeal（组合现有工具，测试工作流再定制开发，例 Groupon 用 WordPress + email）。
9. 设计 MVP 时回答：最风险假设是什么？测试它的最小版本是什么？如何测量它是否被验证？选择或定尺寸时查看 references/mvp-design.md 的七类 MVP、类型选择矩阵、上下界和 MVP Design Canvas。
10. 识别 Leap-of-Faith Assumptions：找出若错则业务失败的假设；按风险排序（哪个失败致命），先测最风险假设，绝不按容易度排序。
11. 按假设类型测试：Value hypothesis 问客户是否在意问题，用 smoke test、concierge MVP；Growth hypothesis 问客户如何发现我们，用 channel tests、referral experiments；Retention hypothesis 问客户是否会回来，用 cohort analysis、engagement metrics；Monetization hypothesis 问客户是否会付费，用 pre-orders、pricing tests。Dropbox 案例：leap of faith 是「人们会下载并使用文件同步工具」，先用 explainer video 测试，beta list 从 5,000 一夜增至 75,000。
12. 映射和排序假设时查看 references/assumptions.md：使用 Impact-Uncertainty matrix、优先级评分模板、按假设类型的测试方法和行业假设列表。
13. 建立 innovation accounting 基线：精确测量当前现实，即使为零或尴尬；测 conversion funnel（signup → active → retained → paying）、engagement（DAU/MAU、session length、features used）、economics（CAC、LTV、churn）。
14. 调整增长引擎：运行实验改善基线指标，例如 A/B test pricing（$9 vs. $19/mo）、onboarding completion rates、acquisition channels（SEO vs. paid vs. referral）；每个实验目标是通过 validated learning 获得可测量改进。
15. 当调优停滞时执行 pivot-or-persevere 决定；构建基线仪表板时查看 references/innovation-accounting.md 的 funnel、cohort、economics 指标框架。
16. 用 actionable metrics 替代 vanity metrics：Total signups → % signup→active；Page views → time on page、bounce rate；Total users → active users（DAU、WAU、MAU）；Downloads → DAU/downloads（activation rate）；Revenue → revenue per cohort、LTV/CAC。Actionable metrics 三特征：actionable（清晰因果、可复现）、accessible（简单、人人理解）、auditable（底层数据可检查）。
17. 做 cohort analysis：按注册日期分组用户并随时间跟踪行为；这是看出产品是否真正改进的唯一方式。构建 cohort table 或选择跟踪指标时查看 references/metrics.md 的五步 cohort 和 AARRR（Pirate Metrics）。
18. 决定 pivot 或 persevere：pivot when 实验反复失败验证假设、指标迭代后仍平、客户反馈与愿景矛盾、进展太慢于 runway；persevere when 指标改善（即使慢）、有明确学习、调整方向正确。Pivot 是结构化纠偏，测试关于产品、策略或增长引擎的新假设。
19. 选择 pivot 类型：Zoom-in（单一功能变成整个产品，例 Instagram 从 Burbn 的 photo filters）；Zoom-out（产品变成单一功能，例 Flickr 从 Game Neverending 的 photo-sharing）；Customer segment（同问题不同客户，例 Groupon 从 activism platform 到 local deals）；Customer need（同客户不同问题，例 Potbelly 从 antique store 到 sandwiches）；Platform（app ↔ platform，例 YouTube 从 dating site 到 video platform）；Business architecture（高毛利低量 ↔ 低毛利高量，例 Salesforce 从 software 到 SaaS）；Value capture（变现模式改变，例 Android 从 paid 到 free + app revenue）；Engine of growth（viral、sticky 或 paid，例 Facebook 从 college viral 到 paid advertising）；Channel（触达客户方式，例 Salesforce 从 direct sales 到 self-service）；Technology（不同技术同方案，例 Apple 从 Intel 到 ARM chips）。
20. 采用 pivot 节奏：成功 startup 通常在 product-market fit 前 pivot 1-5 次；反模式是未验证新方向能解决核心问题就「pivoting」；数据建议 pivot 时查看 references/pivots.md 的数据信号、pivot 会议议程、领先指标和 Instagram/Slack/YouTube 故事。
21. 选择并优化一个 growth engine：只选 sticky、viral 或 paid 之一，先优化再考虑加其他；同时运行多个引擎会稀释焦点和学习。
22. Sticky engine：用 growth rate = new customer acquisition rate − churn rate；跟踪 churn rate、retention cohorts（30/60/90 days）、DAU/MAU；适合 SaaS、subscriptions、social networks；策略是改进产品，直到自然增长超过 churn。
23. Viral engine：用 viral coefficient = (% who invite) × (invites sent) × (% who join)；系数高于 1.0 表示指数、自维持增长；跟踪 coefficient、viral cycle time、referral attribution；适合 Dropbox、Hotmail、WhatsApp；策略是把病毒性建进产品本身。
24. Paid engine：要求 LTV > CAC，目标 LTV/CAC > 3x；跟踪 CAC、LTV、payback period；适合 e-commerce 和传统业务；策略是优化到每个客户利润能资助获取更多客户。选择或调优引擎时查看 references/growth-engines.md 的 churn 降低战术、K-factor 和 viral-loop 设计、LTV/CAC 优化、渠道经济学表和产品到引擎匹配框架。
25. 用 Five Whys 做根因分析：问题发生时连续问 why? 五次，然后在每一层按比例投资，不只治症状。示例：website down → server ran out of memory → memory leak in new feature → code wasn't reviewed for memory management → no code review process for infrastructure changes → team moving too fast to create processes。比例投资：fix bug（第1层）、add memory monitoring（第2层）、implement code review（第3-4层）、slow down to build quality processes（第5层）；反模式是停在 level 1。主持 session 时查看 references/five-whys.md 的三个示例和处理分叉链、责备蔓延、不可控根因。
26. 使用 small batches：小批量工作以更快反馈、更容易 pivot、少浪费、更快上市。大 batch → 小 batch：先建整个产品再发布 → 先 landing page 再 build；quarterly release → weekly 或 daily release；12-month roadmap → 6-week cycles；big bang rewrite → incremental refactoring。
27. 实施 continuous deployment 作为终极小批量：每次 commit 部署，立即 catch bugs，持续学习，减少每次发布风险。设置更快发布节奏时查看 references/small-batches.md 的 continuous-deployment pipeline 和 prerequisites、feature-flag types、progressive-rollout checklist、work-decomposition techniques。
28. 按阶段应用：Phase 1 Problem/Solution Fit：通过 customer discovery、smoke tests、concierge MVPs 验证问题存在且客户在意；指标是客户愿意付费或承诺。Phase 2 Product/Market Fit：构建 MVP 并根据 usage data 迭代；指标是高 retention、organic growth、strong engagement。Phase 3 Scale：优化 growth engine 和 unit economics；指标是可持续、盈利增长；反模式是跳过 Phase 1-2 直接 scale。
29. 按上下文应用：SaaS startup：smoke test（landing page + email list）→ concierge MVP with 10 customers → single-feature MVP → 测 retention、NPS、feature usage → 用 cohort data 决定 pivot 或 scale。Corporate innovation：把 innovation accounting 与核心业务指标分开，保护团队免受季度收入压力，按 validated-learning milestones 解锁 metered funding。Product features：部署在 feature flag 后 → A/B test against core metrics → 根据数据 kill、iterate 或 scale。查看 references/applications.md 和 references/case-studies.md（Dropbox、IMVU、Zappos、Groupon，含失败）。
30. 避免常见错误并按 fix 操作：Building too much → 先用 smoke test 或 concierge 测试；Asking customers → 观察行为而非意见；Vanity metrics → 跟踪 cohorts、conversion、retention；No hypothesis → 每个实验前写 hypothesis；Pivot too slow → 提前设清晰 pivot criteria；Skip innovation accounting → 建立 baseline、测量 tuning efforts；Premature scale optimization → 先验证学习，质量跟随证据。
31. 用 Quick Diagnostic 审计任何产品开发计划：问最风险假设是什么？若无 → map leap-of-faith assumptions；如何测试？若无 → design MVP to test assumption；什么指标会验证或推翻？若无 → define actionable metrics；能否用比这更少的资源测试？若无 → shrink MVP further；实验失败怎么办？若无 → define pivot triggers upfront。
32. 需要完整框架、研究和案例时阅读《The Lean Startup》和《The Startup Way》（Eric Ries）。

适用边界 · 注意事项

• 当需求明确、技术路径确定且主要挑战是执行效率时，不必完整运行探索式 Build-Measure-Learn 循环。
• 当处于强监管、安全关键或高风险领域，不能以低质量 MVP 面向真实用户测试时，需改用合规的模拟、受控实验或缩小范围。
• 当产品已达到 product/market fit，重点是规模化执行和运营优化时，方法重心应转向增长引擎与单位经济优化，而非反复探索假设。