"We need this feature."
"Yes, let me build it."
Four weeks later: "That's not what I meant."
Nobody was careless here. The requester wasn't vague, the developer wasn't sloppy. The collision happened because building new software is learning. The only way to fully specify what you want is to write it down in unambiguous, executable terms, which is just programming. You can't plan your way out of the loop, because you can't define what you don't yet know.
That's the argument Thorsten Ball made to his team at Amp in a Slack message he later posted publicly, unedited. It's blunt and it's right. If you ship software for a living, the part worth internalizing isn't the loop itself. It's the one variable inside it you actually control.
The loop you can't skip, only shorten
Ball walks through three versions of the same story. The builder finishes and the requester says that's not what I meant. Or the builder gets halfway in and realizes there are three valid approaches with no obvious winner. Or it ships and the requester just doesn't like it.
person a: "we need this feature"
person b: "yes, let me build it"
[...]
person b: "done."
person a: "hmm, actually, that's not what I meant."
Same root cause every time: neither person understood the thing until the thing existed in some form.
The error was never that the loop happened. The error is letting that [...] run for four weeks before reality gets a vote. You will bump into "that's not what I meant" when you build something genuinely new. Guaranteed. The only question is how long it takes you to get there.
Front-load the collision
Ball's prescription is concrete, and most of it costs less than a coffee break. Instead of vanishing for a month to build the "right" thing, you engineer an early collision with reality.
- Build a prototype in an hour. Show it. Let them say "no, not that." Sixty minutes spent, not sixty hours.
- Write a spec in 30 minutes. A written description of your approach surfaces misalignment as well as working code does, and it's almost free to revise.
- Ship one slice every day. Each daily release is a feedback event. By day two someone says "you know what, we should change..." before the wrong direction has compounded.
- Cut scope down to the unknowns. Skip what you already know works. The learning lives at the edges. Don't build five login methods when the real question is whether the concept holds at all.
- Fake a demo video. Quinn on Ball's team has done this repeatedly. A recorded walkthrough pulls real reactions with zero production code.
- Write the announcement post. If you can't capture the idea in three paragraphs, you don't understand it well enough to build it. If you can, those paragraphs might surface the flaw first.
- Write the README example. Show people the API as it would read in the docs. Nobody needs a working SDK to tell you the interface feels wrong.
These aren't mutually exclusive. For anything big you'd run several in sequence or parallel. The specific tactic matters far less than the question underneath all of them: how do I get feedback on this as soon as possible?
Speed without signal is just faster noise
Shipping fast for its own sake doesn't close the loop. Here Ball gets precise.
You won't learn anything from an MVP so visibly broken that every response is a bug report. The signal drowns in the defect list. You won't learn anything if testers have to clear eight hurdles before they can touch the thing. And you won't learn anything if you sit on 27 commits in a branch for three weeks. When CI blows up on merge, you've got 27 suspects instead of one.
His skateboard analogy cuts through the usual MVP hand-waving. Want feedback on the deck's design? Show the deck, no wheels needed. Want feedback on how it rides? You can't skip the wheels. The shape of your prototype has to match the question you're actually asking.
Feedback also arrives from more directions than most teams track. CI catches regressions on main. Colleagues catch logic errors in review. Users catch missing cases in production. You catch the rest the moment you actually use the thing. All of it counts. So the question worth asking on a loop isn't "did I ship?" It's "when did I last get valuable feedback, and why is that frequency so low?"
Why this lands harder right now
Ball ends on a wider frame. Software itself is changing fast, fast enough that confident predictions about what to build carry less weight than they did a few years back. In that environment, the teams that learn quickly through tight feedback loops hold a structural edge over the ones that plan carefully and ship rarely.
So drop the goal of building the right thing on the first pass. Arrange the work so reality corrects you early and often: through CI, through production, through teammates, through users. Ship things people can react to. Make reacting easy. Then act on it and ship again.
Building software is learning. You learn faster by getting your assumptions in front of reality more often. That's the whole game.
