Abandon all process
The world is full of process. Most of it exists for one reason: to make sure that when something starts, it gets finished; and that it was the right thing to start.
In organizations, a lot of process exists to make sure that we are working on the right thing. When it comes to writing software, this used to be incredibly important because the most expensive and important thing we have is the time of the programmers.
So whatever the programmers spend time on, that should be the right thing. There cannot be any doubt that whatever they’re working on is the thing that they should be working on, and we want to be sure that we have a good understanding of how much work they can produce. That is the hard constraint or the bottleneck on everything else in the organization.
But we live in a different world now.
Although software is still expensive to produce in absolute terms, because programmers continue to be expensive, and so are tokens of frontier models, the amount of software we can produce and the speed at which we can produce any particular outcome has gone up exponentially, and continues so far in 2026.
This means that all the time programmers or anybody else spends on things that are not building are more costly than ever before, because for each unit of time we can be building, we can create a hundred times or a thousand times more value than we could ever before.
Scrum, Agile, Sprint Planning, long meetings in which deliverables are discussed at length were already incredibly wasteful in most organizations. But today the math is harsh: the output of those meetings matters less than it ever has, while the cost of sitting in them has never been higher.
It’s hard to disagree with the idea that the best way to get feedback on something or to form a deep understanding of a particular subject is to have a product live in front of customers, and so shipping early has always been an axiom that builders could rely on. Ship, talk to customers, iterate.
Today, it’s possible to do this significantly more efficiently. We can ship ten things in parallel, essentially throwing things at the wall and seeing what sticks. Talk to your customers and then iterate on ten things in parallel.
We see this at Remote: our best builders ship tens of changes directly based on their own experience, and hour-by-hour feedback from colleagues and customers. They don’t wait for sign off, discovery, or other abstractions that aren’t directly shipping.
Really, the best way to think about this is that we used to spend a lot of time making sure we don’t do the wrong thing, because we can only do one unit at a time. And so it’s worth spending the time, spending significant time on making sure we’re doing the right thing. But today it is more costly to not spend the time doing things than it is to ship five units of something that doesn’t exactly match what we need. We can throw those five away, because in the same time we shipped five others that worked. Even with a 50% miss rate, we're miles ahead of the old way. We can make greater leaps and correct our mistakes and still be significantly ahead of the old way.
The new discipline isn't deciding what to build. It's building fast enough that the market decides for you.
