The Growth Project
Dogfooding: The Difference Between Ideas and Results
Ten minutes. Five real bugs.
That’s what happened the first time we stopped reviewing our own software and started actually using it to do real work.
Not clicking through a demo. Using it. In anger — the way you’d use it on a busy day, with no patience for it being broken. To get something done before lunch.
Ideas Are Free
Every idea sounds good in the room.
The slide is clean. The logic holds. Everyone nods. Someone says “ship it.” The roadmap gets a new line item and the team feels productive.
I’ve watched this play out hundreds of times. The idea survives the meeting because nobody in the meeting has tried to use it. There’s no friction in a sentence. “Users will be able to do X in two clicks” costs nothing to say and feels true.
Then someone builds X. And the two clicks are actually six, and the second one is in a place nobody looks, and the error message it throws when you do it wrong is a stack trace.
The idea was never wrong. It was just untested. Ideas don’t have edge cases. Products do.
Design Review Is Theatre
Here’s the uncomfortable part.
Design review catches the wrong bugs.
It catches the bugs you can see on a screen, in a calm room, with someone narrating the happy path. It does not catch the bug that only shows up when you’re tired, in a hurry, holding a real piece of work in your head and trying to get it out the door.
We run design review. It’s useful. But it is fundamentally a conversation about a thing, not contact with the thing. And a conversation always flatters the design, because the person presenting it knows where the bodies are buried and steers around them. Unconsciously. Every time.
I learned this the hard way. We had features that passed review cleanly, looked correct, demoed beautifully. Then we started using them to run actual work. Dogfooding our own tools surfaced real bugs that no design review ever caught. Not edge cases. The main path. The thing the feature was for, broken in a way that was invisible until a real human with a real task hit it.
Review tells you whether the thing matches the plan. Dogfooding tells you whether the plan was any good.
What “In Anger” Actually Means
There’s a difference between testing a product and using one.
Testing is when you set out to find bugs. You’re in QA mode. You’re patient. You expect things to be a bit broken. You forgive friction because you understand why it’s there.
Using it in anger is when you have somewhere to be. You’re not thinking about the product at all. You’re thinking about the work. The product is just the thing between you and done. The moment it slows you down, you feel it as your problem, not a test result.
That feeling is the entire signal.
| Testing Your Product | Using It in Anger |
|---|---|
| You’re hunting for bugs | You’re trying to finish real work |
| Friction is expected | Friction is infuriating |
| You forgive the rough edges | The rough edges cost you time you don’t have |
| You follow the happy path | You do whatever’s fastest, like a real user |
| Bugs are findings | Bugs are obstacles between you and done |
You cannot fake the right-hand column. You can’t schedule it. You can’t assign it to QA. It only happens when the product is genuinely the tool you depend on to do something you actually need done.
Why Dogfooded Products Are Truer
A product built by a team that uses it daily has a different quality. Not better-looking. Truer.
The friction gets sanded off the paths people actually walk, because the team walks them too and the friction annoys them. The features that look good but feel bad get quietly killed, because the people who built them have to live with them. The defaults are sane, because someone changed them out of frustration on a Tuesday.
This is the same lesson as the 11pm fix: you don’t understand a system until you’ve been on the wrong end of it. Plans built from whiteboards produce whiteboard plans. Products built from demos produce demo products. The scar tissue is the value. It’s the same reason we measured three days of our own usage instead of guessing where the friction was: real use tells the truth the plan can’t.
Teams that don’t dogfood ship products that are optimised for the demo. They feel great for ninety seconds and then quietly fail you on day three, when you hit the thing nobody on the team ever did because nobody on the team uses the product.
Your users live on day three. If you don’t, you’re shipping blind.
The Forcing Function
Most teams agree dogfooding is good. Almost none actually do it.
Because there’s always an escape hatch. The old tool still works. The spreadsheet is right there. “I’ll use it properly once it’s a bit more finished.” And so the team builds the product with one hand and avoids using it with the other, and the gap between idea and result never closes.
The fix isn’t willpower. It’s design. You have to manufacture a forcing function that removes the escape hatch and makes your own product the path of least resistance, not the path of most.
That means committing to use it for a real, load-bearing piece of your own work. Not a side experiment. Something where if it breaks, you feel it. Something with a deadline. The discomfort is the point: discomfort is information, and right now it’s information your users are paying for and you’re not.
When the product is the only way to get your own job done, the bugs stop being abstractions on a backlog. They become the thing standing between you and going home. You will fix them fast. And you’ll fix the right ones.
First Thing Tomorrow
Stop reviewing your product. Start depending on it.
- Pick one real task you do every day. Not a test scenario. A genuine, recurring piece of work you currently do with some other tool. That’s your dogfooding beachhead.
- Move that task onto your own product. Today. Remove the old tool from reach if you can. The escape hatch is the enemy. If escaping is easy, you’ll escape.
- Time the first run and write down every snag. Where did you hesitate? What did you have to look up? What made you swear? Each snag is a bug your users already know about and you didn’t.
- Fix what you hit, in the order you hit it. Friction you felt first is friction your users feel most. Don’t triage by theory. Triage by your own swearing.
- Make it a standing rule, not a sprint. One day of dogfooding is a stunt. Daily dogfooding is a culture. Put it on the calendar and never give yourself the day off.
The goal isn’t to find every bug. It’s to feel what your users feel, before they feel it.
The Bottom Line
Ideas are cheap because they cost nothing to be wrong.
Results are expensive because reality charges full price.
The only way to close the gap is daily use, on real work, until the discomfort makes you fix it.
A meeting can tell you an idea is good.
Only use can tell you a product is.
Want to ship products that survive day three? We build software we use ourselves, daily, in anger. That’s why it works. Let’s talk.