The tools got fast. Not incrementally fast. Genuinely, dramatically fast. Code generation, design iteration, data synthesis. Things that used to take days take hours. Hours take minutes. The throughput is real.
So is the problem it creates.
There’s a particular confidence that comes from watching output pile up. Tickets close. Features ship. The velocity chart goes up and to the right. From a distance, it looks like progress. Inside it, if you’re honest, it sometimes doesn’t feel that way. You’re moving. You’re not always sure toward what.
I’ve spent the last two years doing zero-to-one product work at Henderson Engineers. A professional services firm, technically excellent, built for client delivery and domain expertise. Not product thinking. No product culture, no product vocabulary, no pre-existing model for what a product organization even looks like. Building a platform from scratch inside a firm that wasn’t designed for it. The tools made a lot of things faster. They didn’t touch the hard part.
The hard part is knowing what to build.
Speed is genuinely useful. This isn’t an argument against velocity. It’s an argument against velocity as a primary virtue, which is what it’s quietly become. The current conversation around AI-assisted development treats throughput as the thing you optimize for. Move fast, ship often, iterate quickly. The frameworks — Agile, lean, shape-up — are all built to reduce friction between idea and execution.
That framing works when you know what you’re pointed at. In iteration mode, with a validated product direction, real users, and established feedback loops, speed is what separates good teams from great ones. Tighten the loop. Compress the cycle time. Ship more.
But zero-to-one isn’t iteration mode. It’s discovery mode. You don’t have a validated direction. You have hypotheses, and if you’re lucky, some early signal. The thing you’re optimizing for isn’t throughput. It’s learning. And learning has a different shape than shipping.
The most productive days in a zero-to-one build are often the slowest ones. A conversation with a user that doesn’t produce any deliverable. A whiteboard session that ends with two things deleted and one question added. Someone saying “wait, are we sure about this?” and the honest answer being no. Nothing registers on the velocity chart. But those days do more work than a sprint full of closed tickets pointed in the wrong direction.
Visible output feels like progress. It’s legible. Sitting with uncertainty, holding hypotheses open, resisting the urge to commit before you’ve learned enough — that’s illegible. It looks like slowness. It’s often wisdom.
Process frameworks don’t help here. They can make it worse.
Agile, properly applied, is excellent. It assumes you’re building software for users whose needs are somewhat understood, and that you should reduce waste by working in short cycles and correcting continuously. That assumption is load-bearing. Strip it out and you have ceremony around uncertainty masquerading as rigor.
I’ve watched sprints where the team was technically productive and the direction was wrong. Not obviously wrong. Subtly wrong, in the way that only becomes clear after several iterations. Planning, standups, reviews, retros — all of it continued. Velocity was measurable. The product that came out was polished and pointed at the wrong problem.
More process wasn’t the answer. More discovery was. Slower, more deliberate conversations with the people who were supposed to use the thing. More time in the question before committing to the answer. That work doesn’t have a ceremony. It doesn’t produce a burndown chart. It’s harder to justify to stakeholders. And it’s the thing zero-to-one product work most depends on.
The tools are genuinely useful. I want to say that clearly.
AI-assisted development has made execution faster in ways that matter. When I know what to build, I build it faster. When I have a clear problem, I explore solutions more quickly. Synthesizing research, drafting a spec, working through edge cases in a design — the tools compress that work substantially. That’s real. It changes what’s possible for a small team.
But they hit a wall exactly where the hard work begins.
They accelerate execution of figured-out things. The figuring-out is still slow, still human, still irreducible. You can’t prompt your way to knowing whether you’re solving the right problem. You can’t generate your way to judgment about what “good” means for this specific user in this specific context. You can’t automate taste. You can’t fine-tune your way to understanding.
Zero-to-one product work requires developing that judgment before you have the feedback loops that would normally develop it. Making calls before the data that would normally make them obvious. Building the instrument while you’re trying to take the measurement.
No tool changes that.
Here’s what I’ve learned to watch for.
Teams in velocity mode talk about output: what shipped, what’s in progress, what’s blocked. Teams doing discovery right talk about questions: what we don’t know yet, what signal we need, what would change our minds. Those aren’t two styles of the same conversation. They’re two different theories of what progress is.
Speed is a feature. It amplifies whatever direction you’re already going. Pointed right, it’s a significant advantage. Pointed wrong, it’s a faster path to somewhere bad — with more confidence.
The question isn’t how fast you’re moving. It’s whether you know what you’re moving toward. In zero-to-one work, you often don’t yet. Which means the first job isn’t to accelerate. It’s to protect the figuring-out from the pressure to ship something visible before you’re ready.
Harder than it sounds. The pressure is real. The tools are fast. The velocity chart is right there.
The teams that get zero-to-one right aren’t the fastest ones. They’re the ones who knew when to slow down.
Part 1 of Building From Zero — a series on what it actually takes to go from nothing to something, in a market that isn’t ready, inside an organization that wasn’t designed for it.