how to dogfood your own agent product

TL;DR

Use your own agent product for real work every day, log every friction point in the open, and fix the top friction weekly. Dogfooding finds the bugs QA never will because real work has stakes, interruptions, and weird inputs. The rule is simple: if the team is not using it daily, the team does not understand it yet.

how to dogfood your own agent product

Use this when

• You build agent tooling but reach for something else for real tasks
• QA passes but real users hit friction immediately
• You need a steady source of product insights without user interviews
• A founder asks "do we even use this ourselves"
• You are onboarding new team members to the product's reality

Not for this skill when

• You need external beta testers (different program, different skill)
• The product is not yet usable for real work (dogfood when it is barely usable, not before)
• You want formal QA or test plans (complementary, not the same)
• The question is about internal tooling that is not the product

Steps

1. Pick real work, not demo tasks, and do it with your own product daily. The content pipeline, the support triage, the morning briefing; whatever your product claims to do, your team does with it for real. Demo tasks flatter; real work has deadlines and edge cases.

   dogfooded workflows: [list of real workflows run on your own product]

Expected output: named workflows with owners. Success check: the team can point to yesterday's real work done through the product.

1. Log friction in the open, in the moment. Every confusing error, every missing feature, every "I wish it did X" goes into a shared log with a timestamp, not into hallway complaints. Friction unlogged is friction unfixed.

   [time] tried to [task], hit [friction], workaround: [what I did]

Expected output: a growing friction log. Success check: at least five entries per week per active dogfooder.

1. Triage the log weekly and fix the top item. Not the top ten; the top one. Dogfooding generates more findings than any team can fix, so the discipline is picking the highest-friction item and shipping the fix, every week, visibly.

   this week's fix: [friction item] -> [shipped change]

Expected output: a weekly shipped fix traceable to the log. Success check: the log's oldest high-friction items keep getting resolved, not just appended to.

1. Dogfood the unhappy paths deliberately. Kill the network mid-run, feed it garbage input, revoke the credential, restart the VM. Real users will do all of these by accident; you doing them on purpose is how the product survives contact with reality.

   [ ] outage during run: behavior noted
   [ ] garbage input: behavior noted
   [ ] expired credential: behavior noted

Expected output: notes on failure behavior. Success check: at least one real bug found per month this way.

1. Report dogfooding findings like user research, because that is what they are. The weekly fix in step 3 gets announced; patterns get written up; "we hit this ourselves" is the most credible release note a team can write.

   [ ] weekly fix announced with the friction it resolves

Expected output: public credit to the dogfooding loop. Success check: release notes regularly cite internally-found friction.

Variant phrasings

Eating your own dogfood as an AI startup

Startup phrasing. The whole skill: daily real use, open friction log, weekly fix.

Internal testing before launch

Pre-launch phrasing. Steps 1 and 4: real workflows plus deliberate unhappy-path testing before external users arrive.

How to find UX bugs without users

Discovery phrasing. Steps 2 and 3: the friction log is a UX-bug pipeline that needs no recruitment.

Building in public from dogfooding

Public phrasing. Step 5: "we hit this ourselves and fixed it" is build-in-public content that writes itself.

Why it happens

Builders develop blindness: they know the workarounds, they avoid the sharp edges unconsciously, and they test the paths they built rather than the paths users take. Real daily use breaks the blindness because the work has to get done regardless of the product's opinions. The friction log works because writing the annoyance down in the moment captures what memory edits out by the retrospective.

Edge cases / pitfalls

• The team will route around friction instead of logging it. Make logging faster than working around (a one-line command or a chat message), or the log stays empty while everyone suffers quietly.
• Dogfooding finds your team's friction, not necessarily users' friction. Your team is expert and forgiving; pair dogfooding with real user observation, not instead of it.
• Do not let dogfooding become the only QA. It is brilliant at UX and reliability, terrible at systematic coverage; keep the test suite too.
• If the product genuinely cannot do the team's real work yet, say so and dogfood the slice that works. Pretending the whole thing works when it does not corrupts the log.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstW7-Fw77PfjkzgqFU_SaoQ