Less Is More: No User-Driven Software

AI can now turn a requirement into working code in minutes. So the logical next step, surely, is to hook your users up to a ticket system and let them drive. Let the people decide. Ship what they ask for. This is a mistake that leads to bloated, incoherent software built by everyone and owned by no one.

The problem starts with what users actually know. Henry Ford supposedly said that if he’d asked customers what they wanted, they’d have said a faster horse. Whether he said it or not, it’s worth being precise about why that’s true. The user’s real requirement was to travel longer distances in less time. A faster horse wasn’t the requirement — it was their attempt at solving for it, constrained by the only system they understood. Someone who could step back and see the larger picture — combustion engines, road networks, supply chains — could find where the real solution lived. The iPhone follows the same pattern. Nobody asked for a touchscreen computer in their pocket because nobody could imagine it. Jobs didn’t run a poll. He had a conviction about where things were going and he protected it.

But here’s where it gets subtle. Dismissing users entirely is its own kind of arrogance. The signal is genuine. Think about how a physio works. You come in with a sore achilles. Your inclination is to treat the site of pain, massage the muscle nearby. But the achilles is at the end of a long chain. The root cause is often a tight hip flexor, miles upstream. The achilles just hurts because it’s absorbing the slack everything else is creating. Software works the same way. A user reports that a customer is missing from their reports and asks for a button to manually add them back. But why is the customer missing? Probably because something upstream, an import, an integration, a validation rule, is silently dropping records. The button is treating the symptom, not the cause. Users are exceptionally good at telling you where it hurts. They are rarely equipped to tell you why, and that’s not a failing on their part. They don’t have visibility into the whole system. You do.

What if we don’t let them drive the roadmap but at least give them a vote? This is the dreaded design by committee. When the UK’s Natural Environment Research Council opened a public vote to name a new polar research vessel, the internet did what the internet does and “Boaty McBoatface” won by a landslide. The wisdom of crowds is real in certain contexts: prediction markets, triaging bugs, aggregating distributed information. But deciding what to build next is not a forecasting question, it’s a vision question, and vision isn’t democratic. Give users a vote and the product gets shaped by whoever votes loudest. Usually not your best users, but your most vocal ones.

The cumulative effect of user-driven development is a product that is everything and nothing. Every edge case gets a toggle. The surface area grows while the core identity dissolves, and eventually you have a settings page with 47 options and users who can’t work out how to do the one thing they came to do. A product needs an identity, and with that identity comes coherence. Coherence is what makes software feel right. When all the features fit and nothing jars. That only happens when someone, a person not a process, is making the calls.

AI has removed constraints around what you can build — it’s what you choose to build. Saying yes to one thing means saying no to a hundred others. Think of your CV. You don’t list everything you’ve ever done. You curate: here is who I am, here is what I do better than most, here is the bet you are making on me. A product is the same. You pick an identity, commit to it, and trust that the right people will find their way to it.

The users aren’t wrong. They’re telling you where it hurts, and that’s invaluable. Listen hard. Just don’t hand them the wheel.