规模化阶段系统与增长团队

前提：0→1 和 1→100 是两种完全不同的游戏。0→1 在找 PMF；1→100 要尽快达到 hyperscale，打法是两个支柱：

支柱一：提前规划棋步，建系统，"go slow to go fast"。

• 花时间想清楚核心抽象和信息架构，系统才能长期不返工。案例：
  • Facebook Newsfeed：仔细设计了完整的分享循环（顶部发布 → 出现在 feed → 点赞 → 红色通知 → 循环），12 年基本没变过。
  • Uber pickup/dropoff 团队：找到"venue"这个正确抽象，机场/无路牌地区的接送变成可配置问题，支撑全球扩张——听起来无聊但对规模化至关重要。
  • Messenger：在推送通知等基础设施上下重注，约 2.5 年从 0 做到每天 47 亿条消息。
• 何时切换到这种模式：不是二元开关，是 ramp rate。用 portfolio approach 分配（Google 式 70-20-10 适合成熟公司，创业公司可能 50/50），按阶段调整。

支柱二：1→10 阶段就 measure everything，方式是先建 growth team。

• 类比：不会不看仪表就开飞机，为什么不装仪表就运营产品？
• 建 growth team 而不是 analytics/data science team 的原因：分析团队的洞察可能没人听；而 growth leader 被增长结果绑定，会主动追问"为什么会这样？把 XYZ 的数据拿来"→ 暴露出没打点的地方 → 打点后又引出新问题 → 迫使全团队进入假设-实验的严谨循环。一个招聘决定改变整个团队的 DNA。
• 作者在 Instagram、Uber、Airtable、ChatGPT 每次接手都先建 growth 团队；走进 Instagram 时问"我们有多少用户"，得到的答案是"不知道，反正很多"——这是常态，不是例外。