L6-02：CEO战略评审 —— 站在老板角度审视你的技术方案

🎯 学什么：不是"这个设计好不好"，而是"我们该不该做这个"。从野心校准、范围界定、资源分配、风险识别四个维度审视计划，产出战略备忘录和"不做清单"。核心洞察：(1) "不做清单"可能是战略决策里最有价值的产出——每次说"是"都是对其他事情的"否"；(2) Build vs Buy vs Partner 的核心判断标准：核心差异化自己做，非核心但有标准方案就买；(3) 加速器和阻断器必须区分对待——先解决阻断器，再投资加速器。 💡 难易度：⭐⭐⭐⭐ | ⏱️ 预计时间：45 分钟

---

[!quote]- 📖 原Skill精要 技能名称：plan-ceo-review 核心功能：CEO/创始人模式计划评审。重新思考问题、找到10星产品、挑战前提、扩展范围。四种模式：范围扩展（做大梦）、选择性扩展（保持范围+精选扩展）、保持范围（最大严格度）、范围缩减（剥离到本质）。 所属体系：gstack 虚拟工程团队 协作关系：受益于 [[L6-01-创业门诊室|office-hours]] 的前置诊断

---

1. 课程概览

💡 白话小课堂：CEO 评审问的是"做不做"，工程评审问的是"怎么做"。CEO 评审在前，工程评审在后——先确定方向，再确定路径。如果你把顺序搞反了，就会出现"技术方案很完美，但方向完全错了"的悲剧。

---

2. CEO 评审 vs 工程评审

---

3. 评审维度

🔑 核心秘诀："不做清单"（Won't-Do List）可能是战略决策里最有价值的产出。

---

4. 决策框架

💡 白话小课堂：Build vs Buy 是 CEO 最常做的选择题。

---

5. 产出物

---

6. 结构拆解：CEO 战略评审 Skill 模板

---

7. 电商案例：CEO 视角评审电商平台国际化扩张

🛒 实战案例：一家国内电商SaaS公司（服务3万家中小商家），CEO提出战略计划"明年进入东南亚市场，做RCEP区域版电商SaaS"。CTO设计了一个"云端多租户+本地化插件层"的技术方案：在印尼、泰国、越南各部署一套独立集群，通过插件机制适配各国支付（GoPay、PromptPay、MoMo）和物流（JNE、Flash Express、GHN）。

CEO评审对CTO的方案进行了五层穿透：

• 野心校准："东南亚版电商SaaS"包含6个国家、18种支付方式、12家物流公司——这是"需要多步协调"的警示信号。如果只有3个月和一支8人团队，你选哪个市场、哪种支付、哪个核心功能？CTO重新锚定：只做印尼市场、只接GoPay和银行转账、只做订单管理和库存同步两个模块。
• 范围界定：做清单——印尼语后台、GoPay+Bank Transfer支付、商品管理+订单管理+库存同步、JNE物流对接。不做清单——其他5国、信用卡/OVO/Dana、营销工具、数据分析仪表盘、移动App（PWA响应式即可）。
• 资源分配：最大时间陷阱不是代码——是GoPay API的印尼语文档和沙箱申请（需要印尼本地营业执照）。解决方案：通过印尼本地代理商走商务合作通道，2周拿到沙箱权限而非自注册的1个月。
• Build vs Buy vs Partner：支付模块——Partner（用Xendit聚合支付，而不是自己对接每家银行）；物流模块——Buy（对接JNE API是核心竞争力）；AI客服——Build（核心技术差异化在自然语言处理）。
• 加速器与阻断器：加速器——团队有2人会印尼语，CEO在新加坡有商会关系。阻断器——印尼数据合规（PDP Law要求用户数据存储在本土），AWS Jakarta区域刚开，迁移方案需要4周评估。

战略备忘录产出：目标——3个月内印尼MVP上线，服务200个印尼商家。核心假设——印尼中小卖家愿意用SaaS替代WhatsApp群接单。验证标准——50个商家完成首月使用，月均处理订单≥30单。北极星指标——月交易额达Rp 500 juta（约¥22.5万）。

🔑 启示：CEO评审的价值不是在技术方案上比CTO更懂——而是把"野心过大"的信号翻译成"可验证的阶段性目标"。6个国家收缩到1个不是放弃，是把有限子弹打在最精确的目标上。

---

8. 掌握检验

Q1：CEO 评审中"野心太大"的典型信号是什么？

• A) 产品缺乏差异化，很容易被复制
• B) 需要在 2 周内上线 MVP
• C) 需要多步协调、依赖未验证假设
• D) 目标用户群太窄

Q2：在"Build vs Buy vs Partner"决策框架中，什么情况下应该自己 Build？

• A) 有现成的 SaaS 方案可用
• B) 这个能力是产品的核心差异化
• C) 团队人手紧张需要加快上线
• D) 行业已经有成熟的标准方案

Q3：加速器和阻断器的本质区别是什么？假设你在为一个新项目做 CEO 评审，请各举一个具体的例子，并说明为什么必须先解决阻断器。

Q4：在电商国际化案例中，CTO 的原计划是"东南亚版 Shopify"。请用野心校准的框架分析：这个计划为什么是"需要多步协调"的警示信号？如果只做印尼市场 MVP，"不做"清单里至少应该包含哪三项？

Q5：如果"2 周内必须上线"和"给你 6 个月"这两个问题的答案之间的差距非常大，这对 CEO 意味着什么？这个差距说明了什么战略问题？

Q6：你是一个技术团队的 Tech Lead，你要说服 CEO 把 30% 的开发时间投入在"阻断器"（如合规、基础架构）上，而非产品功能上。请用本课的逻辑写一段不超过 3 句话的论证。

---

9. 答案

点击查看答案

Q1：C —— "野心太大"的信号包括：需要改变用户行为、需要多步协调、依赖未验证假设。

Q2：B —— Build vs Buy 的核心判断标准：如果是产品的独特卖点（别人没有），就自己做。

Q3：阻断器 = 不做就无法前进的事（如合规审批、支付牌照、基础架构搭建）。加速器 = 能加速其他一切的事（如自动化测试、CI/CD 流水线）。必须先解决阻断器：因为无论加速器多好，如果连基础条件都不具备，项目根本无法起步。加速器的价值建立在阻断器已解决的前提下。示例：阻断器——支付牌照未获批；加速器——自动化部署管道。

Q4：这是"需要多步协调"的警示信号，因为：本地化支付需要同时接入 5 个国家 12 种支付方式（互相依赖），本地化物流需要对接多家物流公司 API（每家的集成方式不同），本地化合规涉及各国税法（无法并行推进，一个卡住全卡住）。"不做"清单至少包含：泰国/越南市场、信用卡/OVO 等其他支付方式、营销工具和数据分析功能、多仓库/多货币/多税率、移动 App（先用响应式 Web）。

Q5：差距大 = 范围弹性大，说明团队对"什么真正重要"缺乏共识。这暴露出战略模糊——团队可能对所有功能"平等看待"，无法区分 20% 的核心和 80% 的锦上添花。CEO 需要推动团队明确：如果只能做一件事，那件事是什么？

Q6：参考论证："合规审批和基础架构是不可绕过的阻断器——不做完这些，我们写的每一行功能代码都不能上线。花 30% 时间先疏通它们，相当于为剩下的 70% 清除了所有路障，反而是最快的整体交付路径。"

（5/6 通过）

---

10. 延伸阅读

• [[L6-03-工程架构评审|下一课：工程架构评审 —— 在写代码之前先把架子搭对]]