🎯 学什么：不是"这个想法好不好"，而是"你的需求假设对不对"。6 个强迫性问题暴露需求真相——从需求现实到未来适配，逐层剥开创业假设，产出可执行的设计文档。核心洞察：(1) 付费行为 > 使用行为 > 口头承诺 > 调查回答——需求验证的金字塔；(2) "最窄楔子"是 6 个问题中最值钱的一个——版本 1 只做一件事；(3) office-hours 必须是 gstack 工作流的第一步——没有需求验证的战略是空中楼阁。 💡 难易度：⭐⭐⭐⭐ | ⏱️ 预计时间：45 分钟
1. 课程概览
💡 白话小课堂：Startup Mode 是"动真格的"——你的项目要找真实用户收钱。Builder Mode 是"练习场"——副业、黑客松、学习项目的设计思维脑暴。两种模式都会产出设计文档，但 Startup Mode 的 6 个问题会像 YC 合伙人一样追问到你怀疑人生。
来源：gstack 虚拟工程团队 / YC Startup School Office Hours 形式
2. 两种模式
Two Modes
Startup Mode（创业模式）
针对真实创业项目的严格诊断。 6 个强迫性问题，层层剥开需求真相。 适合：正在创业、验证想法、寻找 PMF 的创始人。
Builder Mode（构建者模式）
针对副业、黑客松、学习项目的设计思维脑暴。 更创意导向，更自由发散。 适合：side project、open source、学习探索。
两种模式都会产出设计文档。
3. 6 个强迫性诊断问题
The Six Forcing Questions
1. 需求现实（Demand Reality）
"你怎么知道有人真的需要这个？" → 不是"我觉得"或"很多人在抱怨" → 是需要已经有人在付费解决的证据
2. 现状锁定（Status Quo）
"用户现在是怎么解决这个问题的？" → 替代品不是"什么都不做" → 竞争对手往往是 Excel、Email、人工流程
3. 绝望的特异性（Desperate Specificity）
"谁对这个需求最绝望？" → 不是"所有人" → 是具体的、可识别的一个人群 → 他们的痛苦有多具体？
4. 最窄楔子（Narrowest Wedge）
"你能切的最窄的入口是什么？" → 不是"我们最终要做 X" → 是"版本 1 只做这一件事"
5. 观察（Observation）
"你亲自观察过用户吗？" → 不是"我们做了调研" → 是你亲眼看到用户挣扎的那一刻
6. 未来适配（Future-Fit）
"5 年后，这个产品是更相关还是更不相关？" → 趋势是你的朋友还是敌人？ → AI 会让这个更有价值还是更没价值？
⚠️ 避坑指南：前5个问题考察"现在有没有需求"，第6个问题考察"未来需求会不会消失"。很多创始人只关注第1个问题（"我觉得有人需要"），但忽视了2-6——这才是创业失败的主因。
🔑 核心秘诀："最窄楔子"可能是这6个问题里最值钱的一个。
4. 需求验证框架
Demand Validation
三个信号级别，从弱到强：
弱信号（要警惕）
→ "很多人说他们会用" → 调查问卷中的正面反馈 → "这个领域很大"（TAM 大不代表你的产品有需求）
中等信号（可继续探索）
→ 用户已经在用非最优方案 → 有人为类似方案付费 → 有可测量的痛点（时间/金钱损失）
强信号（值得投入）
→ 用户正在为不完美的替代品付费 → 有人在用你的产品之前就已经在付费解决这个问题 → 用户主动来找你（不是你去问他们）
核心原则： 付费行为 > 使用行为 > 口头承诺 > 调查回答
💡 白话小课堂：需求验证的本质就是一个问题——"用户用钱包投票了吗？"口头说"我会用"不值钱，但有人已经在为不完美的替代品付钱了，这才是真实的刚需信号。
5. 设计文档产出
Design Doc Output
每次 office-hours 会话产出设计文档：
→ 核心假设：我们相信什么？ → 目标用户：谁最需要这个？ → 版本 1 范围：最小可行版本是什么？ → 关键风险：什么可能让我们失败？ → 下一步：接下来验证什么？
设计文档保存到： ~/.gstack/projects/{repo_slug}/-design-.md
📝 术语：gstack 用
repo_slug（仓库标识符）来组织项目文件。它是从 git remote URL 中提取的项目名——比如github.com/user/mega-shop的 slug 就是mega-shop。写在路径里时用{repo_slug}表示"这里替换成你的项目名"。
成为后续 /plan-ceo-review 和 /plan-eng-review 的输入。
6. 与其他 Skill 的关系
Workflow Position
office-hours → plan-ceo-review → plan-eng-review → autoplan
office-hours 是 gstack 工作流的起点： → 先验证需求（office-hours） → 再制定战略（plan-ceo-review） → 再设计架构（plan-eng-review） → 最后全流程评审（autoplan）
不要跳过 office-hours 直接进入 plan-ceo-review。 没有需求验证的战略是空中楼阁。
⚠️ 避坑指南：很多工程师的直觉是"我有 idea → 直接开始写代码"。但 gstack 的设计哲学是：验证需求 → 确定战略 → 设计架构 → 才开始写代码。
7. 结构拆解：创业门诊 Skill 模板
创业诊断型 Skill 模板
核心特征
→ 管理对象 = 创业 idea 的需求假设验证 → 核心原则 = 6 个强迫性问题 + 3 级需求信号金字塔 → 关键设计 = Startup/Builder 双模式 + 设计文档产出
通用结构
Two Modes（双模式）
- Startup Mode：真实创业严格诊断（6 个强迫性问题）
- Builder Mode：副业/黑客松/学习项目（创意脑暴）
Six Forcing Questions（6 个诊断问题）
- Demand Reality：付费证据
- Status Quo：现有替代方案
- Desperate Specificity：最绝望的用户画像
- Narrowest Wedge：版本 1 的最小切口
- Observation：亲眼观察用户
- Future-Fit：5 年后的相关性
Demand Validation（需求验证）
- 弱信号：口头承诺、调查回答
- 中等信号：使用非最优方案、可测量痛点
- 强信号：为不完美替代品付费、用户主动找你
- 金字塔：付费行为 > 使用行为 > 口头承诺 > 调查回答
Design Doc Output（设计文档）
- 核心假设 / 目标用户 / 版本 1 范围 / 关键风险 / 下一步
- 存储路径：~/.gstack/projects/{repo_slug}/-design-.md
8. 电商案例：用 Office Hours 验证一个电商创业 idea
🛒 实战案例：一个新锐美妆品牌创业团队，手握配方和供应链资源，准备在抖音和小红书做DTC护肤品牌。创始人的原始计划：半年内上线50个SKU，覆盖洁面、水、乳、精华、面霜五个品类，同时铺抖音店+小红书店+微信小程序三渠道。团队6人（2研发 + 1运营 + 1内容 + 1供应链 + 1创始人兼CEO），预算300万。
Office Hours通过6个强迫性问题层层剥开假设：
- 需求现实：创始人拿出20个种子用户在小红书的私信截图——她们在问"有没有XX成分的平价替代"且已经在为国外品牌的海淘运费买单。付费信号成立。
- 现状锁定：用户现在的替代方案是什么？"海淘+等清关"或"线下专柜正价"。平均多花30%的钱或等15-20天。痛点可量化。
- 绝望的特异性：最绝望的用户画像——25-30岁成分党女性，敏感肌，已尝试过5+个品牌但找不到"成分干净+价格300以内"的精华液。她们在小红书写成分分析长文，主动@品牌问何时上新。
- 最窄楔子：不要50个SKU、不要三个渠道、不要五个品类。版本1只做一件事——一瓶30ml的5%烟酰胺精华液，定价¥269，只在抖音一个直播间卖。用一瓶超级单品验证"成分透明+价格击穿"的定位。
- 观察：创始人亲自去了5个成分党用户的家里，看她们梳妆台上的瓶瓶罐罐，听她们对着成分表逐行分析——发现她们对"烟酰胺浓度5%以上"有执念，但对"复配成分"完全不关心。这个观察直接影响了产品配方优先级。
- 未来适配：5年后成分党会更多还是更少？趋势是加速——越来越多用户从"看品牌"转向"看成分表"。赛道在扩大。
诊断总结：从"50个SKU铺三渠道"收缩到"一瓶精华液一个直播间"，开发周期从6个月缩短到3个月，首月种子验证预算从300万降到15万。验证标准：第一场直播卖出200瓶（GMV ¥53,800），复购率≥15%。达成则验证了"成分透明+价格击穿"定位。
🔑 启示：创业诊断不是告诉你"这个idea好不好"，而是帮你找到那个最小的、可验证的切口。从300万到15万的收缩不是退缩——是把子弹留到真正值得All-in的时刻。
9. 掌握检验
Q1：在 6 个强迫性诊断问题中，"最窄楔子"（Narrowest Wedge）问的是什么？
- A) 你的产品 5 年后是否还存在
- B) 版本 1 只做哪一件最小的事
- C) 你的目标市场总规模有多大
- D) 用户现在用什么替代方案
Q2：以下哪个是需求验证的"强信号"？
- A) 调查问卷中 80% 的人说"我会用"
- B) 用户正在为不完美的替代品付费
- C) 一个很大的 TAM（总可触达市场）
- D) 很多人抱怨现有方案的不足
Q3：6 个问题中，"现状锁定"和"观察"的核心区别是什么？为何两个问题缺一不可？
Q4：在电商 SaaS 案例中，创始人最初的想法是"AI 卖家运营工具"，但经过诊断后版本 1 变成了"选品推荐工具"。请分析：如果把 office-hours 工作流颠倒——即先做工程评审再验证需求——会产生什么后果？
Q5：一个创业者告诉你"我的目标用户是所有人"，你作为 AI 诊断师要指出这个回答对应 6 个问题中的哪一个，并给出修正后的具体用户画像要求。
Q6：在 gstack 工作流中，为什么 office-hours 必须是第一步？如果跳过它直接进入 plan-ceo-review，可能造成什么类型的浪费？请结合电商案例说明。
10. 答案
点击查看答案
Q1：B —— "最窄楔子"问的是版本 1 只做一件什么事。
Q2：B —— 付费行为是最强的需求信号。
Q3："现状锁定"问的是用户现在怎么做（替代方案是什么），这证明需求是否真实存在——用户即使没有你也在想办法解决。"观察"问的是你亲眼见过用户挣扎吗，这证明你的理解不是二手信息，而是具有"现场感"的洞察。两者缺一不可：前者验证需求的客观存在，后者确保你对需求有足够深入的理解来做出正确的解决方案。
Q4：如果跳过需求验证直接进入工程评审，工程上完全可以做一个多功能的运营工具，技术上没有阻塞点——但核心假设（"卖家需要优化标题"）是错的。结果是：投入 3 个月开发了一个"技术上完美但没人愿意付费"的产品，浪费了 3 个月 + 团队带宽。而先做 office-hours 在 1 小时内就发现了真正的需求是"选品"而非"标题优化"。
Q5：这对应第 3 问"绝望的特异性"。"所有人"不是答案——它说明创始人还没认真想过谁最需要这个产品。修正要求：锁定一个具体的、可识别的人群，描述他们当前的具体痛苦（量化更好），证明他们的绝望程度足以驱使他们付费。
Q6：office-hours 是需求验证层，plan-ceo-review 是战略决策层。跳过 office-hours → 做战略决策时基于"我认为有人需要"而非"已证实的有人需要"。在电商案例中，如果没有 office-hours 发现"选品才是真痛点"，CEO 评审会在"AI 运营工具"这个错误前提上讨论野心、范围、资源分配——整个战略建立在沙滩上。造成的浪费：整个产品方向可能错误，而不仅仅是一些功能的浪费。
（5/6 通过）
11. 延伸阅读
- [[L6-02-CEO战略评审|下一课：CEO战略评审 —— 站在老板角度审视你的技术方案]]
评论区
共 0 条评论