Eat-Your-Own-Dogfood Requirement¶

Participatory-exposure practice — instantiates Skin-in-the-Game Alignment

Requires the people who design, build, or mandate a system to live under it themselves, so the burdens they impose land first on them.

An Eat-Your-Own-Dogfood Requirement makes the actor experience the thing they create or impose from the inside — using the product they ship, carrying the pager for the service they built, living under the rule they wrote, filling in the form they designed. Its distinctive move among its siblings is that the stake it puts at risk is not money but lived consequence: the friction, defect, and burden the actor would otherwise impose on others now lands on the actor directly. This is the right tool exactly where financial exposure is uninformative — where the problem is not that the actor might profit from harm but that they simply don't feel the downside of what they hand off, and so design it carelessly. By collapsing the distance between maker and user, it makes the exposure gap perceptual rather than contractual.

Example¶

A team builds an internal deployment tool that every other engineering team is required to use. Left there, the builders enjoy a quiet asymmetry: they ship the tool, move on, and never suffer its rough edges — the confusing errors, the 2 a.m. failures, the missing rollback — because other teams absorb them. A dogfooding requirement rewrites that. The team must run their own services through the exact tool they ship, and they must take the on-call pager for it.^[1] Now the cryptic error message wakes the person who wrote it; the missing rollback blocks the team's own release. Nothing about their pay changes — the discipline comes from lived experience, not a stake. The burdens they were exporting to every other team now land on them first, which is precisely the information a distant maker lacks and cannot get from a spec.

How it works¶

Map the imposed burden. Identify the specific downstream consequences — defects, toil, friction, maintenance — that the actor's work pushes onto others.
Route those consequences back. Require the actor to use, run, or live under the system so the mapped burdens land on them, not only on downstream users.
Make participation real, not token. Ensure the actor's exposure is genuine — production use, actual on-call, the same constraints — rather than a staged demo.
Keep the loop live. Sustain the requirement over time so the actor keeps feeling the consequences of each change they make.

Tuning parameters¶

Fidelity of exposure — how closely the actor's experience matches a real user's. A sanitized internal version blunts the signal; production-identical use sharpens it but costs the actor real time.
Coverage — whether every maker dogfoods or only some. Broad coverage spreads the felt consequence; partial coverage can leave the decisive designers insulated.
Representativeness — how well the actor's own use resembles the hardest-hit users'. A power user who dogfoods may never feel what a novice or edge-case user suffers.
Duration — one-off trial versus permanent ownership; standing exposure disciplines far more than a launch-week sampling.
Escape hatches — whether the actor can quietly opt out or route around their own system, which silently reopens the gap.

When it helps, and when it misleads¶

Its strength is supplying information a stake cannot: the tacit, hard-to-specify friction of a system is exactly what a distant maker misses and a user feels, and dogfooding hands that felt knowledge to the person who can fix it. It suits design and reliability problems where the failure is neglect born of distance rather than greed.

Its failure modes are unrepresentativeness and theater. The maker who dogfoods is rarely a typical user — they know the workarounds, hold the wrong hardware, never hit the novice's wall — so their lived experience can systematically miss the worst-affected. And the requirement is easily reduced to a ritual demo that satisfies the letter while the real exposure is quietly routed around. Its blind spot is any harm the maker's own use never triggers: dogfooding aligns the maker to their experience of the system, not necessarily to the most vulnerable user's. The discipline is to match the actor's exposure to the hardest-hit users' conditions, keep it genuine and standing, and pair it with a channel that surfaces the harms the maker will never personally meet.

How it implements the components¶

Dogfooding realizes the lived-exposure side of the archetype:

participation_in_outcome_requirement — its core: the actor must use, run, or live under the system they impose, so its outcomes are experienced firsthand.
downstream_consequence_map — identifying the burdens the actor's work pushes onto others is what tells the requirement which consequences to route back.
exposure_gap — it closes the mismatch between decision power and downside by making the maker feel what they would otherwise export.

It stakes lived experience rather than money, so it does not post capital — that is Co-Investment Requirement and Equity Stake with Retention Period — nor allocate financial loss, which is Deductible or First-Loss Share and Shared-Loss Contract.

Instantiates: Skin-in-the-Game Alignment — it puts the maker's own experience at stake so the burdens they design land on them first.
Sibling mechanisms: Co-Investment Requirement · Reputation-at-Risk Registry · Deductible or First-Loss Share · Deferred Compensation with Forfeiture · Equity Stake with Retention Period · Shared-Loss Contract · Clawback Clause · Collateral Requirement · Malpractice or Professional Liability · Performance Bond

References¶

[1] Eating your own dog food (or dogfooding) is the established industry practice of a company using its own product in real work before or as it ships it to customers. It is a genuine, widely-used term for participatory exposure — the maker experiencing the thing they make rather than only building it. ↩