| name | dogfooding |
| description | Help users implement effective dogfooding practices. Use when someone is trying to get their team to use their own product, designing internal usage programs, or building user empathy through personal product use. |
Dogfooding
Help the user implement effective dogfooding practices using frameworks from 2 product leaders who have built cultures of intense internal product usage.
How to Help
When the user asks for help with dogfooding:
- Assess current state - Determine how much the team currently uses their own product
- Identify the gap - Find where team members lack firsthand experience with user pain points
- Design the program - Help create systems that make dogfooding natural and required
- Measure impact - Track how dogfooding improves product decisions
Core Principles
Require team members to become users
Maya Prohovnik: "I am constantly yelling at my product team who do not have podcasts and being like, I really don't think that you can build the right things. If they talk to users all the time, they see the data, but all of them, once they finally start doing their podcast, they're like, I get it." Force the entire team to become creators/users to deeply understand user pain points.
Use the tool intensely every day
Michael Truell: "From the very start, our product development process was really about dogfooding, and using the tool intensely every day. And we never wanted to ship anything that wasn't useful to us." 'Intense' daily use provides the realism needed to build useful features, especially for AI products.
Questions to Help Users
- "How often does each team member actually use the product as a real user?"
- "What's preventing your team from being heavy users of your own product?"
- "What would it take to make internal usage feel natural rather than forced?"
- "Are you learning different things from dogfooding vs. customer feedback?"
- "How quickly do you feel the pain of bugs or friction when using your own product?"
Common Mistakes to Flag
- Superficial testing - Using the product only in demo mode, not for real work
- Delegating to QA - Relying on testers instead of requiring team members to be real users
- Ignoring non-obvious use cases - Only testing the happy path rather than edge cases
- Not acting on findings - Dogfooding without a process to fix discovered issues
- Excluding non-product roles - Only having engineers dogfood when designers and PMs should too
Deep Dive
For all 2 insights from 2 guests, see references/guest-insights.md
Related Skills
- Writing North Star Metrics
- Defining Product Vision
- Prioritizing Roadmap
- Setting OKRs & Goals
