Internal Dogfooding Bake-Time Loop
Build internal tools through repeated use, pain, and focused improvement
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 88%
Adopt an imperfect internal tool as part of real daily work, then let recurring friction determine what to build. When an acute problem appears, temporarily pull a small number of developers from the main product to create the smallest useful improvement. Resume normal work and allow several months of bake time so the team can discover whether the change actually solves the problem and what new friction emerges. Repeat the cycle. Because everyone benefits from a better internal tool and no individual wins a political contest by controlling it, decisions can carry less ego than conventional specification debates. Slack emerged through this pattern: its team used IRC, built additions when their own communication became painful, lived with each change, and gradually developed a broadly useful product.
Origin
Stuart Butterfield described how the team behind Slack repeatedly improved its IRC-based internal communication tools while working on another product.
Core principles
- 01Use reveals needs that specifications miss
- 02Acute internal pain creates clear product priorities
- 03Bake time exposes whether a change truly helps
- 04Shared benefit reduces ego-driven decisions
- 05Repeated small improvements can uncover a standalone product
How to run it
- 1
Adopt the rough tool
Use the emerging tool for real internal work rather than evaluating it only in demonstrations.
Pro tip Choose a workflow frequent enough to expose friction quickly.
Watch out Internal use is weak evidence when the team does not resemble the eventual customer.
- 2
Observe acute friction
Wait for repeated, consequential problems to emerge naturally. Document the circumstances and affected users.
Pro tip Prioritize pain that interrupts actual work.
Watch out Do not turn every preference into a feature request.
- 3
Build a focused fix
Pull a small team onto the problem for a limited development cycle. Make the minimum change that could remove the friction.
Pro tip Keep the intervention narrow enough to evaluate independently.
Watch out Avoid letting the internal tool consume the entire primary roadmap.
- 4
Let the change bake
Return to normal work and use the revised tool for an extended period. Observe benefits, workarounds, and newly visible problems.
Pro tip Give the team enough time to move beyond novelty effects.
Watch out Immediate enthusiasm does not prove durable usefulness.
- 5
Repeat from evidence
Re-enter development only when continued use reveals another meaningful need. Accumulate improvements into a coherent workflow.
Pro tip Periodically assess whether the internal tool has become valuable beyond the original team.
Watch out Do not assume an internally successful tool automatically fits a mass market.
In the wild
A game-development team uses IRC for internal communication. When chat creates a concrete obstacle, a few developers improve the tool, then return to product work and use the change for several months before making another adjustment.
→ Repeated pain-driven iterations accumulate into the collaboration product Slack.
A startup's engineers repeatedly struggle to identify failed releases. Two developers add a failure timeline to the team's rough deployment console, then everyone uses it for a month before deciding whether alerts or rollback controls are actually needed.
→ The console evolves around observed operational needs rather than a speculative feature list.
Common mistakes
Building from imagined pain
A speculative feature list forfeits the loop's main advantage: direct evidence from actual use.
Skipping bake time
Rapidly stacking changes prevents the team from learning which improvement produced value.
Mistaking builders for the market
Dogfooding can mislead when external customers have different skills, incentives, or constraints.
Is it for you?
Best for
It is best for software teams that can use an emerging tool in their own daily workflow.
Not ideal for
It is not ideal when builders differ fundamentally from target users or when errors could cause serious harm.
From the transcript
“we should build something to make this chat thing a little better. So they'd pull those developers off of product and they'd you know spend…”
“They they'd use it for like three or four months, and then they'd go in and say, Ah, we actually need to make it a…”
“when we're just trying to solve our own problems and like nobody wins by having our internal tool be better, except that sort of everyone…”
From the episode
NeXT (Live show at the GeekWire Summit)