I’ve noticed something lately — people don’t really dry run things anymore.
Not ideas. Not flows. Not integrations. Not even the obvious edge cases.
Somewhere along the way, thinking became optional.
And the cost of this silent decay shows up everywhere: avoidable delays, circular discussions, “surprise” blockers that shouldn’t have been surprises at all.
The small miss that nearly became a big mess
We were recently working on a third-party integration with our system. Midway through, one of my colleagues reached out and said they were stuck. A key functionality we had planned couldn’t be implemented. If true, the options were ugly: ship compromised functionality, or lose a few more weeks to rework on a project already running late.
When they walked me through it, I did what I often do — went old school. Picked up a pen and paper and started doing a dry run of the entire process with them.
Step by step. As the user. As the system. Down to the API calls.
Halfway through, we hit it.
We’d baked in an invisible assumption: we were treating the system as if it already knew whether to insert a new record or overwrite an existing one. Nothing in the flow actually told it what to do. On paper, during the dry run, that gap was obvious.
That’s all it took to find the small oversight that was about to derail days of work across two teams. In Jira and Figma, it was completely hidden. No tool caught it. No documentation flagged it. No meeting surfaced it. Yet, a simple dry run would have.
And that’s what stayed with me, not the mistake itself, but that no one had walked the flow end to end before committing serious effort to it.
We weren’t blocked by a technical limitation. We weren’t blocked by complexity. We were blocked by a thinking limitation.
Learning to think before we built
Back when I learnt to program, before we even got near a computer, we learnt how to think things through, or as I’m framing it, dry run them. We wrote algorithms in plain English, drew flowcharts, and walked through pseudo-code line by line, tracking variable changes on paper.
We weren’t debugging yet. We were understanding.
Before a single line was typed, the logic had already been tested — slowly, deliberately — in our heads and on the page. We were making sure it was error-free. There was a rhythm to it, a kind of clarity in seeing logic unfold before us.
We didn’t just know what the program did. We knew how. We understood it.
During these dry runs, most of what we caught fell into three buckets: missing steps, wrong assumptions, and conflicting states that only became obvious when we walked the flow end to end.
Those early exercises taught me something that has stayed with me: never trust what you haven’t walked through yourself.
Over the years, it’s helped me in ways far beyond code, in designing products, improving processes, and debugging complex integrations. A 10-minute dry run often reveals what a polished design or well-written PRD can’t — a missing step, a confusing moment, or an assumption that doesn’t hold up in the real world.
This simple process has saved me more time, rework, and embarrassment than any tool ever has.
At that time, dry running wasn’t a step; it was an apprenticeship in learning to think like the system.
Why is it disappearing?
It didn’t die naturally. We choked it out.
It faded for a simple reason: thinking deeply stopped being recognised.
We replaced thinking with doing. We rewarded activity over clarity, quantity over quality. Tools made outputs look finished, even when the thinking behind them was thin, and the details were still missing. Speed replaced comprehension. Fancy FigJam templates replaced rough sketches and sticky notes. Now the artefacts look polished, but the logic underneath stays fuzzy.
Most teams are measured on movement, not understanding. Stand-ups obsess over what shipped, not what was prevented. Dashboards celebrate velocity, tickets closed, and features delivered. No one gets celebrated in an all-hands for the bug that never reached production or the integration issue that never made it to UAT.
Most issues and bugs I’ve encountered aren’t engineering failures. They’re thinking failures. The kind we would have caught if someone had done a simple dry run.
Many teams believe they’re building fast when they’re actually just building blindly.
My take — we didn’t lose the skill. We abandoned it.
How do we bring dry running back?
Dry running isn’t so much a technique as a shift in how you examine work before committing to it.
The goal isn’t to slow the work, it’s to surface the truth early.
1. Visualize.
Outline the flow, mark the key steps, track the variables, trace the moments where something changes. It’s faster and clearer than any diagram when your goal is understanding rather than presentation. Use a pen and paper if you need to.
2. Run it twice.
Once as the user, once as the system. The shift in perspective exposes assumptions you didn’t realize you were making. Most issues hide exactly in that space.
3. Make it a small team ritual.
Give it a name — a “table-top dry run” or “paper walkthrough” — and run it before you start a build or integration. Thirty minutes around a table with a designer, engineer, and QA walking the flow end to end, out loud, almost always surfaces at least one “Wait, what happens if…?” moment. Capture those, adjust the flow, then build.
Dry running won’t make the work slower. It simply makes the thinking clearer before the real cost of mistakes begins.
A discipline worth keeping
This isn’t nostalgia for nostalgia’s sake. Dry running is practical, cheap, and fast. And very effective.
It isn’t outdated. It’s just underpracticed.
At its core, dry running is a product mindset, the discipline to pause before you act, to imagine before you build. Tools can model the steps, but only you can test the assumptions.
The bugs you never ship, and the blockers that never appear, are its real output.
Dry running forces truth early, and early truth is one of the highest-leverage habits in product.
I write about building products without the clutter, and about using AI in the actual work, not just having opinions about it. Most of it comes from more than a decade in product, much of it in health-tech in India.
Subscribe on Substack