产品如何从 0 到 1？

产品“从 0 到 1”常被理解成：从没有代码，到 App 上线。

但一个能打开的产品仍可能没人需要。更准确的终点是：一类真实用户在具体场景中采用产品，并能重复获得你承诺的核心价值。

六阶段分别交付什么证据

阶段	关键问题	最小交付物	继续的证据
洞察	谁在何时遇到什么问题？	用户与场景记录	多个真实经历出现相同模式
定义	我们承诺什么核心价值？	问题陈述与价值主张	用户能理解且认为值得改变
验证	哪个假设最危险？	假设清单与最小实验	用户付出时间、数据、承诺或金钱
构建	最少做什么才能交付价值？	可用 MVP	用户能完成核心任务
发布	第一批用户如何到达并开始？	发布渠道与激活路径	目标用户真实进入并使用
增长	价值能否重复？	核心指标与实验记录	留存、重复使用、转介绍或付费改善

这条路径与 Design Council 的发现、定义、发展、交付有相通之处，也能容纳 Stanford d.school 的理解用户、定义、构思、原型和测试。差别在于，Fullstackinno 把发布和增长单独列出，提醒团队：原型测试通过不等于产品已经形成市场闭环。

为什么不能把六步做成瀑布流程

每一步都会产生新证据。验证发现问题不够重要，就应该回到洞察；原型测试发现价值表达不清，就回到定义；上线后没人激活，可能是渠道错误，也可能是产品没有真正解决问题。

Strategyzer 的测试方法强调先把创意拆成可测试假设、按风险排序，再选择合适实验。这意味着“返工”并不一定是失败；如果它在大规模投入前暴露错误，反而是进展。

MVP 应该最小到什么程度

MVP 不是功能最少的正式产品，而是能测试当前关键假设的最小实现。

• 要验证问题是否重要，可能只需要访谈或人工服务；
• 要验证用户是否愿意行动，可能需要预约页、预售或申请流程；
• 要验证交互是否可理解，可能只需要可点击原型；
• 要验证技术风险，才可能需要一段真实代码或技术样机；
• 要验证重复价值，才需要可供一小批用户持续使用的产品。

每项功能都应该回答：“做完它，我们会知道什么？”如果答案只是“看起来更完整”，它通常不属于当前最小范围。

AI 在每一阶段的合理位置

• 洞察：整理访谈、聚类行为，但不虚构用户证据；
• 定义：生成多种问题表述与反例，由团队选择并验证；
• 验证：辅助设计实验、招募文案与记录模板；
• 构建：生成原型和代码，同时保留测试、安全与人工审查；
• 发布：准备渠道内容和支持材料，不夸大未经验证的结果；
• 增长：分析反馈与实验数据，避免把相关性误当因果。

AI 让小团队更容易跨职能推进，但每一个“继续投入”的决定仍应由现实证据支持。

一个可执行的 30 天版本

第 1 周：洞察与定义。 选择窄人群，完成 5—8 次问题访谈，写出问题陈述和现有替代方案。

第 2 周：验证。 排出最危险假设，运行一个不依赖完整产品的实验，提前写好继续或停止标准。

第 3 周：构建。 只实现交付核心价值的关键路径，邀请少量目标用户完成真实任务。

第 4 周：发布与复盘。 从一个明确渠道获得第一批用户，观察激活、重复使用和阻塞点，决定下一轮返回哪一步。

30 天不是所有项目的承诺工期，而是数字产品早期学习循环的参考节奏。高风险行业和复杂技术项目需要更长周期与额外专业验证。

继续查看从想法到增长的六个阶段，或先完成阶段诊断找到你最早缺失的证据。