dogfooding
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseDogfooding
Dogfooding
Scope
适用范围
Covers
- Designing and running a dogfooding loop where the product team uses the product like a real user would
- Creating “creator commitments” when the product is for creators (e.g., publish a podcast, ship a workflow, run weekly reports)
- Capturing issues as reproducible artifacts (not vibes): logs, severity, decisions, owners, and follow-through
When to use
- “Set up a dogfooding program / dogfooding sprint for our product team.”
- “We’re shipping soon—make sure we’re using the product daily and fixing the biggest pain.”
- “We built this for creators; our team needs to be creators to understand the workflow.”
- “Create an internal beta plan and a weekly dogfooding report template.”
When NOT to use
- You need to validate market demand or solve who is the customer / what is the problem (do discovery first)
- The product team cannot realistically represent the workflow (e.g., regulated roles, hardware constraints) without proxies
- You’re looking for user research replacement (dogfooding complements—not replaces—external user feedback)
- The only goal is “QA everything” (use a QA/test plan; dogfooding is for experience + value + workflow realism)
涵盖内容
- 设计并运行狗食测试循环，让产品团队像真实用户一样使用产品
- 当产品面向创作者时，制定创作者承诺（例如：发布播客、上线工作流、每周生成报告）
- 将问题记录为可复现的具体信息（而非主观感受）：日志、严重程度、决策、负责人及跟进措施
适用场景
- “为我们的产品团队搭建狗食测试项目/狗食测试冲刺。”
- “我们即将发布产品——确保团队日常使用产品并解决最核心的痛点。”
- “我们的产品是为创作者打造的；团队需要亲自作为创作者来理解完整工作流。”
- “制定内部Beta测试计划和每周狗食测试报告模板。”
不适用场景
- 你需要验证市场需求或解决“谁是客户/核心问题是什么”（应先开展探索性研究）
- 产品团队无法真实还原目标用户工作流（例如：受监管的角色、硬件限制）且没有替代方案
- 你想用狗食测试替代用户研究（狗食测试是外部用户反馈的补充，而非替代）
- 唯一目标是“全面QA测试”（应使用QA/测试计划；狗食测试聚焦于体验+价值+工作流真实性）
Inputs
输入要求
Minimum required
- Product summary + target user persona (who it’s for; what job it does)
- 1–3 core workflows to dogfood (end-to-end)
- Time box + cadence (e.g., 1 week sprint; 20 min/day; weekly triage)
- Participants (roles) + any “creator commitments” required
- Environment constraints (prod vs staging; data/privacy constraints; access constraints)
Missing-info strategy
- Ask up to 5 questions from references/INTAKE.md.
- If answers aren’t available, proceed with explicit assumptions and label unknowns. Offer 2 scope options (lean vs thorough).
最低必填项
- 产品概述+目标用户画像（面向谁；解决什么核心需求）
- 1-3个需进行狗食测试的核心端到端工作流
- 时间范围+节奏（例如：1周冲刺；每天20分钟；每周分类梳理）
- 参与人员（角色）+任何要求的“创作者承诺”
- 环境限制（生产环境vs staging环境；数据/隐私限制；访问权限限制）
缺失信息处理策略
- 可从references/INTAKE.md中最多提出5个问题。
- 如果无法获取答案，基于明确假设推进并标注未知信息。提供2种范围选项（精简版vs完整版）。
Outputs (deliverables)
输出交付物
Produce a Dogfooding Pack in Markdown (in-chat; or as files if requested):
- Context snapshot (product, persona, workflows, constraints, time box)
- Dogfooding charter (goals, participants, rules, cadence, definitions)
- Scenario map + routines (daily/weekly tasks + “creator commitments”)
- Dogfooding log + triage board spec (fields, severity scale, decision rules)
- Weekly dogfooding report (insights, decisions, shipped fixes, next experiments)
- Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
生成Markdown格式的狗食测试包（可在对话中展示；若有要求可生成文件）：
- 上下文快照（产品、用户画像、工作流、限制条件、时间范围）
- 狗食测试章程（目标、参与人员、规则、节奏、定义）
- 场景地图+日常流程（每日/每周任务+“创作者承诺”）
- 狗食测试日志+分类看板规范（字段、严重程度等级、决策规则）
- 每周狗食测试报告（洞察、决策、已发布的修复、后续实验计划）
- 风险/待解决问题/下一步计划（必须包含）
模板参考：references/TEMPLATES.md
Workflow (7 steps)
执行流程（7步）
1) Frame the dogfooding goal (experience, not just bugs)
1) 明确狗食测试目标（聚焦体验，而非仅修复Bug）
- Inputs: Product summary; desired outcomes; references/INTAKE.md.
- Actions: Define what “success” means for this cycle (e.g., “team can complete workflow A in <10 min without workarounds”). Set constraints (environment, data, access).
- Outputs: Context snapshot + explicit success criteria.
- Checks: Success criteria are measurable and tied to a real workflow outcome (not “feel better”).
- 输入： 产品概述；预期成果；references/INTAKE.md。
- 行动： 定义本次循环的“成功”标准（例如：“团队可在10分钟内完成工作流A，无需临时变通方案”）。设定环境、数据、访问权限等限制条件。
- 输出： 上下文快照+明确的成功标准。
- 检查项： 成功标准可衡量且与真实工作流成果挂钩（而非“感觉更好”）。
2) Define representative scenarios + “creator commitments”
2) 定义代表性场景+“创作者承诺”
- Inputs: Target persona + workflows.
- Actions: Create 3–8 scenarios that represent real user goals. If the product is for creators, define a publish cadence (e.g., “each PM publishes 1 artifact/week”).
- Outputs: Scenario map + routine plan.
- Checks: At least 1 scenario is “from scratch → shipped/published” end-to-end.
- 输入： 目标用户画像+工作流。
- 行动： 创建3-8个代表真实用户目标的场景。若产品面向创作者，定义发布节奏（例如：“每位PM每周发布1个成果物”）。
- 输出： 场景地图+日常计划。
- 检查项： 至少包含1个“从0到发布/上线”的端到端场景。
3) Set up the capture system (log, severity, triage)
3) 搭建问题捕获系统（日志、严重程度、分类梳理）
- Inputs: Existing tools (Jira/Linear/Notion/Sheets) or “none”.
- Actions: Define the dogfooding log schema, severity scale, and triage rules. Decide labels/tags to link issues to scenarios and workflow steps.
- Outputs: Dogfooding log + triage board spec.
- Checks: Any issue can be reproduced with a clear “steps to reproduce + expected vs actual + evidence”.
- 输入： 现有工具（Jira/Linear/Notion/Sheets）或“无工具”。
- 行动： 定义狗食测试日志结构、严重程度等级和分类规则。确定用于关联问题与场景、工作流步骤的标签/标记。
- 输出： 狗食测试日志+分类看板规范。
- 检查项： 任何问题都可通过清晰的“复现步骤+预期vs实际结果+证据”进行还原。
4) Run daily dogfooding sessions (time-boxed)
4) 开展每日狗食测试会话（限时）
- Inputs: Scenario map + routines.
- Actions: Each participant runs 1–2 scenarios/day, captures friction immediately, and attaches evidence (screens, logs, timestamps). Record “workarounds used”.
- Outputs: Daily log entries + a rolling “top pains” list.
- Checks: Entries are concrete (repro steps) and prioritized by impact on completing the workflow.
- 输入： 场景地图+日常流程。
- 行动： 每位参与者每天完成1-2个场景，立即记录遇到的痛点并附上证据（截图、日志、时间戳）。记录“使用的临时变通方案”。
- 输出： 每日日志条目+滚动更新的“核心痛点”列表。
- 检查项： 日志条目具体（包含复现步骤），并按对工作流完成的影响程度排序。
5) Triage weekly: decide, assign, and protect focus
5) 每周分类梳理：决策、分配任务并聚焦核心
- Inputs: Log + top pains.
- Actions: Run triage: cluster duplicates, classify (bug/UX debt/gap/docs), assign owners, and decide “fix now / schedule / won’t fix (with reason)”. Update scenario map if it was unrealistic.
- Outputs: Prioritized backlog + decision notes.
- Checks: Top 3–5 issues map directly to blocked/slow scenarios and have an owner + next action.
- 输入： 日志+核心痛点列表。
- 行动： 开展分类梳理：合并重复问题，分类（Bug/UX债务/功能缺口/文档问题），分配负责人，决定“立即修复/排期修复/不修复（说明原因）”。若原场景地图不符合实际，进行更新。
- 输出： 优先级排序的待办清单+决策记录。
- 检查项： 前3-5个核心问题直接对应受阻/缓慢的场景，且有明确负责人+下一步行动。
6) Ship loop: verify fixes by dogfooding again (no-ship gate)
6) 发布循环：通过再次狗食测试验证修复成果（发布闸门）
- Inputs: “Fix now” items + release plan.
- Actions: For each fix, re-run the scenario end-to-end. Apply a simple gate: “We can complete the scenario with no hidden workarounds in the chosen environment.”
- Outputs: Verified fixes list + any regressions.
- Checks: The gate is based on completing scenarios, not just closing tickets.
- 输入： “立即修复”项+发布计划。
- 行动： 针对每个修复，重新端到端运行对应场景。应用简单闸门规则：“我们可在指定环境中完成场景，无需隐藏的临时变通方案”。
- 输出： 已验证的修复列表+任何回归问题。
- 检查项： 闸门规则基于场景完成情况，而非仅关闭工单。
7) Report + quality gate + next cycle plan
7) 报告+质量闸门+下一轮计划
- Inputs: Final log + triage outcomes.
- Actions: Produce the weekly report. Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add Risks/Open questions/Next steps and propose the next dogfooding cycle focus.
- Outputs: Final Dogfooding Pack.
- Checks: Report contains decisions (what changed) and shows evidence-backed learning (not just a bug list).
- 输入： 最终日志+分类梳理结果。
- 行动： 生成周报。使用references/CHECKLISTS.md并通过references/RUBRIC.md进行评分。添加风险/待解决问题/下一步计划，并提出下一轮狗食测试的聚焦方向。
- 输出： 最终狗食测试包。
- 检查项： 报告包含决策内容（已变更事项），并展示基于证据的学习成果（而非仅Bug列表）。
Quality gate (required)
质量闸门（必填）
- Use references/CHECKLISTS.md and references/RUBRIC.md.
- Always include: Risks, Open questions, Next steps.
- 使用references/CHECKLISTS.md和references/RUBRIC.md。
- 必须包含：风险、待解决问题、下一步计划。
Examples
示例
Example 1 (Creator product): “We’re building a podcast creation tool. Create a dogfooding program where the whole team publishes 1 short episode/week, and produce a weekly report template.”
Expected: scenarios from “idea → published episode”, creator commitments, log schema, triage cadence, and ship gate tied to publishing.
Expected: scenarios from “idea → published episode”, creator commitments, log schema, triage cadence, and ship gate tied to publishing.
Example 2 (B2B workflow product): “Set up a 2-week dogfooding sprint for our AI meeting notes tool focused on ‘record → summary → share → action items’.”
Expected: scenario map, daily routine, severity scale, triage rules, weekly report, and a verified-fixes list.
Expected: scenario map, daily routine, severity scale, triage rules, weekly report, and a verified-fixes list.
Boundary example: “Dogfood this idea we haven’t built yet.”
Response: dogfooding requires a usable artifact; propose discovery + prototype/usability testing first, then a dogfooding sprint once there’s something to run end-to-end.
Response: dogfooding requires a usable artifact; propose discovery + prototype/usability testing first, then a dogfooding sprint once there’s something to run end-to-end.
示例1（创作者产品）： “我们正在打造一款播客创作工具。创建一个狗食测试项目，要求整个团队每周发布1个短剧集，并生成周报模板。”
预期输出：包含“从想法到发布剧集”的场景、创作者承诺、日志结构、分类梳理节奏，以及与发布挂钩的闸门规则。
预期输出：包含“从想法到发布剧集”的场景、创作者承诺、日志结构、分类梳理节奏，以及与发布挂钩的闸门规则。
示例2（B2B工作流产品）： “为我们的AI会议纪要工具搭建一个2周的狗食测试冲刺，聚焦‘录制→总结→分享→行动项’流程。”
预期输出：场景地图、日常流程、严重程度等级、分类规则、周报，以及已验证的修复列表。
预期输出：场景地图、日常流程、严重程度等级、分类规则、周报，以及已验证的修复列表。
边界示例： “对我们尚未开发的想法进行狗食测试。”
回应：狗食测试需要可用的产品原型；建议先开展探索性研究+原型/可用性测试，待有可端到端运行的产品后再启动狗食测试冲刺。 ",
回应：狗食测试需要可用的产品原型；建议先开展探索性研究+原型/可用性测试，待有可端到端运行的产品后再启动狗食测试冲刺。 ",