---
name: "dogfooding"
description: "Run an internal dogfooding program: scenario map, routines, triage spec, ship/no-ship gate."
---

# 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**)
- You need structured usability testing with real external users, task completion metrics, and think-aloud protocols (use `usability-testing`)
- You’re planning the actual product launch/release rollout (use `shipping-products`)
- You need a design critique session to evaluate visual/interaction quality (use `running-design-reviews`)
- You want to build a framework for developing product taste and quality intuition (use `product-taste-intuition`)

## 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](references/INTAKE.md).
- If answers aren’t available, proceed with explicit assumptions and label unknowns. Offer 2 scope options (lean vs thorough).

## Outputs (deliverables)

Produce a **Dogfooding Pack** in Markdown (in-chat; or as files if requested):

1) **Context snapshot** (product, persona, workflows, constraints, time box)
2) **Dogfooding charter** (goals, participants, rules, cadence, definitions)
3) **Scenario map + routines** (daily/weekly tasks + "creator commitments")
4) **Dogfooding log + triage board spec** (fields, severity scale, decision rules)
5) **Weekly dogfooding report** (insights, decisions, shipped fixes, next experiments)
6) **Risks / Open questions / Next steps** (always included)

Templates: [references/TEMPLATES.md](references/TEMPLATES.md)

## Workflow (7 steps)

### 1) Frame the dogfooding goal (experience, not just bugs)
- **Inputs:** Product summary; desired outcomes; [references/INTAKE.md](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").

### 2) Define representative scenarios + "creator commitments"
- **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) Set up the capture system (log, severity, triage)
- **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".

### 4) Run daily dogfooding sessions (time-boxed)
- **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.

### 5) Triage weekly: decide, assign, and protect focus
- **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.

### 6) Ship loop: verify fixes by dogfooding again (no-ship gate)
- **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
- **Inputs:** Final log + triage outcomes.
- **Actions:** Produce the weekly report. Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](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).

## Anti-patterns (common failure modes)

1. **Bug-list-only dogfooding.** Treating the dogfooding program as a QA bug bash instead of an experience evaluation. The team files cosmetic bugs but never evaluates whether the core workflow is coherent and valuable.
2. **Tourist mode.** Participants click around casually instead of committing to real end-to-end scenarios. The feedback is shallow ("looks fine") because nobody completed a meaningful task.
3. **Internal-user bias blindness.** Assuming internal team members represent real users without acknowledging their expert knowledge, muscle memory, and workaround tolerance. Findings don’t transfer to actual users.
4. **Log without triage.** Capturing hundreds of issues in a spreadsheet but never running a triage session. Issues pile up, owners are never assigned, and the dogfooding program loses credibility.
5. **One-and-done sprint.** Running a single dogfooding sprint before launch and never repeating. The program produces a snapshot but no continuous improvement loop.

## Quality gate (required)
- Use [references/CHECKLISTS.md](references/CHECKLISTS.md) and [references/RUBRIC.md](references/RUBRIC.md).
- Always include: **Risks**, **Open questions**, **Next steps**.

## 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 to 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 to summary to share to action items’."
Expected: scenario map, daily routine, severity scale, triage rules, weekly report, and a verified-fixes list.

**Boundary example (usability testing):** "Run a usability study with 5 external users to measure task completion rates."
Response: use `usability-testing` for structured external user research; dogfooding is for internal team experience evaluation.

**Boundary example (launch planning):** "We finished dogfooding; now plan the rollout to real users."
Response: use `shipping-products` to plan the launch; dogfooding validates internal readiness, not external release execution.

**Boundary example (no artifact):** "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.