Development speed is a friction problem, not an effort problem
For ten years my job was to find the friction in a funnel, remove it, and measure the lift. It took me embarrassingly long to point that same method at my own development process — which is, of course, also a funnel: idea in, shipped change out. When I finally did, the bottleneck wasn't where I expected.
"Move faster" almost always gets heard as "build faster" — type quicker, put in more hours. But development speed isn't typing speed. It's the throughput of validated changes per week. And the rate-limiters are almost never the building. They're the gaps around it: the time stuck turning a fuzzy idea into a concrete one, the time waiting to find out whether it worked, the time spent rebuilding the wrong thing. Building is the fast part. The fog around building is the slow part.
So the structure that causes the highest speed is the one that minimises the distance from idea to evidence — and keeps you, at every moment, holding one concrete, shippable, measurable next action. You are never sitting in the fog. I call it the shortest path to evidence.
The single biggest lever is the one most people file under "soft skill": turning general research and a rough idea into a concrete action. That conversion — from a vague "we should improve onboarding" to "build X, expect Y, measure with Z, shippable this week" — is where teams quietly lose most of their time. Make it systematic and everything downstream gets faster. Here's the structure, five moves, each with a test so it stays concrete instead of turning into a poster on the wall:
- Signal in, not opinion. Start from something real — research, data, a support complaint, a rough idea. Test: can you point at the source? If the honest answer is "I think…", go get a signal before you build.
- Compress to the smallest falsifiable action. Rewrite the fuzzy thing as one sentence: build X, expect Y, measure with Z, shippable this week. Test: if you can't write that sentence, it isn't concrete yet — shrink the scope until you can. Speed comes from making the unit small.
- Ship behind guardrails. Reversible and bounded, so moving fast is safe. Test: can you undo it in under a minute? Reversibility is what permits speed — you move fast because mistakes are cheap, not because you're being careful.
- Measure two ways, fast. An A/B or before/after for what worked; one qualitative look for why. Test: the success metric was defined back in move two, before you built — you never invent it afterwards to make the result look good.
- Let the result emit the next action. A win you scale; a loss just handed you the next hypothesis. Test: you exit every loop already holding the next concrete action — you never have to re-enter the fog.
Speed isn't working harder. It's never sitting in ambiguity — always holding one concrete, reversible, measurable next action.
The part that makes it a structure that causes speed, rather than just "trying hard," is that every loop shortens the next one. Your defaults sharpen, your guardrails get reused, your translation from rough idea to concrete action gets faster. The system accelerates itself. It's not theory — it's the loop AcePilot runs unattended across more than forty of my own projects, and the same discipline behind ten years of conversion work: never trust what you can't measure, and never sit still in the fog.
