Crawl, Walk, Run?
Sometimes Product Teams Trip Somewhere in the Middle
Everyone loves a good maturity model.
Crawl → Walk → Run.
It sounds clean. Linear. Comforting.
It’s also mostly fiction.
Here’s what usually happens at time:
- You crawl slowly, painfully, while going close to the problem. You feel every bump.
- Then you get confident and decide it’s time to run.
- You skip the “walk” part entirely. Because walking is boring. Walking means building things properly, documenting them, setting up feedback loops, and—god forbid—maintenance.
So you start running with duct tape still hanging off your shoes. And then you trip.
Hard. Very Hard.
The "real" run isn't speed. It's stability at speed.
In product, running isn’t just velocity — it’s repeatable velocity without chaos.
It’s:
- Shipping fast and fixing fast.
- Debugging without detective work.
- Testing without bottlenecks.
- Monitoring that doesn’t surprise you at 3AM.
If you’re running fast but can’t explain why things work, you’re not running. You’re sprinting blindfolded.
What Crawl → Walk → Run Really Looks Like
Let’s not pretend it’s linear. It’s messy. Here’s how it usually plays out:
| Phase | Reality Check |
|---|---|
| Crawl | You’re scrappy. Everything is manual. You learn a lot because the pain is loud and obvious. |
| Walk | You try to add structure. But now there are too many cooks. Half-processes. Testing gets introduced but no one trusts it yet. |
| Trip | Something breaks. Customers complain. The thing you skipped in “walk” comes back to bite you. |
| Run (maybe) | If you survive the trip, and still care about quality, you build real systems. You monitor, you test, you learn in loops. Not sprints. |
So What?
Next time someone says “we’re in the run phase,” ask them:
- What did we learn in crawl?
- What did we intentionally design in walk?
- What are we still faking?
Because most teams aren’t running.
They’re sprinting on stilts. Are you too?
