The Screwdriver or the Swiss Army Knife

For twenty years, the bottleneck in software was building. Every tool and ritual in modern Agile was built on that assumption.

Story points. Sprints. Pull requests. Code review. QA gates. Every ritual exists because writing code was slow, expensive, and error-prone. Pointing sessions were about effort. PRs were checkpoints because getting it wrong was costly. Thirty years of engineering wisdom, all resting on one idea: implementation is the hard part.

That assumption just broke.

A founder can prompt a feature into existence in an afternoon. When the cost of building collapses, the process stack should topple too and we haven’t figured that out. The line between “writing the ticket” and “building the feature” is thin to the point of vanishing. It’s generally less work to just prompt the thing than to describe it for someone else to prompt.

Building is cheap. Building is fun. We’re shipping faster than ever, so what’s the problem?

Ferris Bueller had the answer: “Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.”

The constraint didn’t disappear. It moved.

When Pixar made Toy Story, they did something counter-intuitive. The industry expected fast turnarounds. Pixar slowed down and spent years on story. The visual effects were the spectacle, but it was the story that made people cry. They bet on the thing that couldn’t be automated.

We’re in the discovery phase of a similar truth in software. People don’t buy software for a feature, they buy it for a benefit. Now the slow thing is deciding what to build, and building too much of the wrong thing can actually erode the benefit you’re trying to provide.

That’s a much harder problem. And most teams are structurally unprepared for it.

Engineering capacity used to enforce prioritization for free. That’s less true today and will be less true tomorrow.

Two tools

Picture a screwdriver. It does one thing. It’s the right tool for the job in front of you.

Now picture a Swiss army knife. It contains that same screwdriver, plus a thousand other blades, picks, and gadgets. Most of which you’ll never use. All of which make the thing heavier, more confusing, and harder to use for the one job you actually need done.

Most products start as the screwdriver. That simplicity is the competitive advantage. Then, feature by feature, they become the Swiss army knife.

It’s ironic that the core vision of most products is to be simple and easy to use. And the new economics of building push relentlessly in the opposite direction. More surface area, more complexity, more for the user to wade through. Cheap building is in direct tension with great product.

What actually changes tomorrow

Some of the old process survives. But its center of gravity shifts toward what matters to the customer.

Code review doesn’t go away. It gets harder. You’re no longer checking whether the code is syntactically correct. You’re checking whether the product still makes sense.

We should be doing prompt reviews, not just code reviews. The context we feed the machine determines what we get out.

I’ve started writing the vision document for a product before I write a single feature. Before there’s anything to prompt. Not as bureaucracy. As a forcing function. The vision is what lets you validate a feature request against what the product is for, instead of just against whether you can.

Without it, you’re just building another multi-tool and hoping you have the discipline not to open every blade.

Anyone can ship fast now. The whole game is knowing what not to build.