跨职能全员 Dogfooding
解决什么问题
判断一个新功能/新工具在对外发布前,内部试用应该覆盖到什么范围,才能真正验证它是否可用。
核心内容
GitHub 的原则不只是工程团队 dogfood 自己的产品,而是公司里所有职能部门都被要求用 GitHub 运行 GitHub(GitHub is running on GitHub):财务团队用 discussions/PR 沟通 AR 数字,法务、HR 团队也在用(不论他们喜不喜欢)。她给出的硬性原则:"如果我们自己都用不了这个工具,客户肯定也用不了"(if we cannot use them, our customers cannot use them for sure)——任何功能在对外发布前,都要在内部"煨"足够长的时间("months of cooking"),先由产品团队作为最早期用户之一去验证:结果是不是我要的?摘要是不是按我想要的方式生成的?
这与只让工程团队内测的常见做法不同:把非技术职能(财务、法务、HR)也纳入 dogfooding 范围,是为了验证产品在真实、多样、非理想化使用场景下(而不仅是工程师视角)是否真的好用。
适用边界
前提是产品本身定位为"通用型平台"(面向多种角色),如果产品本身只服务单一职能,跨部门 dogfooding 的必要性会降低。
关键引述 · 原话
"we are the first to try every feature... GitHub is running on GitHub" — Inbal Shani
"if we cannot use them, our customers cannot use them for sure" — Inbal Shani
关联卡片
与 single-dri-parallel-tasks-dogfood-gate--johnny-ho 都把"内部先充分使用"设为发布前置门槛,可对比不同公司对 dogfooding 硬度的具体做法。
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2