The User-Centric Fallacy

There is a piece of advice that gets recycled endlessly in startup culture: build something simple that anyone can use. Ship the minimum viable product. Talk to your users. Remove friction. Design for the person who has never heard of you and never wants to think about your product for more than thirty seconds. Go for the large user base.

This advice is not entirely wrong. But it has been repeated so many times, and applied so broadly, that it has become a dogma — and like most dogmas, it causes damage precisely where it should not be applied.

Here’s a counterfactual: the biggest technology companies in the world were not built this way.

The founding myth

Google was built by two Stanford computer science PhD students who wanted a better way to navigate academic research papers. The original algorithm, PageRank, was essentially a formalization of citation analysis: a concept borrowed from academic publishing. Larry Page and Sergey Brin were not thinking about the average internet user. They were thinking about the problem in front of them, the problem that bothered them personally, because they lived and breathed it.

Linux was not built for anyone in particular. Linus Torvalds wrote the first version because he wanted a Unix-like operating system for his own Intel 386 machine and the existing options were either too expensive or insufficiently free. He famously described it as “just a hobby, won’t be big and professional like GNU.” Today it runs the majority of the world’s servers, virtually all Android phones, and the infrastructure underpinning most of the internet.

Apple was born in a garage out of the Homebrew Computer Club, a group of electronics hobbyists who read technical manuals for fun. The early Apple computers were kits for people who could already solder. Wozniak designed the Apple I primarily to show off to his fellow enthusiasts. The idea of selling to a mass consumer market came later.

Amazon started as a bookstore optimized for people who wanted to find obscure titles that did not exist in any physical shop nearby. Bezos built the infrastructure to serve a niche that mainstream retail had written off: readers who wanted every book, not just the popular ones.

These companies were not founded by people doing market research on general consumers. Nor were they concerned about becoming trillion dollar companies. They were founded by people who were deeply embedded in a technical or intellectual community, building something they urgently wanted to exist, because they understood the problem better than anyone else. And they were just passionate about building.

Why passion beats user research

The standard pitch for user-centricity is that it reduces the risk of building the wrong thing. Talk to customers early. Validate your assumptions. Don’t fall in love with your solution.

This is sensible advice when you are trying to fit a known product into a known market. It is poor advice when you are trying to build something that does not yet exist, for a need that users have not yet articulated. Something truly transformative. This is because users cannot articulate needs for things they have never seen.

Henry Ford did not discover the automobile by asking people what they wanted and hearing “a faster horse.” The quote may be apocryphal, but the underlying observation is not. Truly new categories of products require a founder who has a vision of what should exist, not a survey of what people currently wish for. And, more often than not, a founder who is having fun building out this vision.

Vision of that kind requires depth. You cannot have a strong intuition about what a fundamentally better search engine should feel like unless you have spent years reading and thinking about information retrieval. You cannot design a genuinely better programming environment unless you have spent thousands of hours frustrated with existing ones. The technical expert who has been living with the problem is the person most likely to see the solution. Not because expertise confers creativity, but because it confers the right kind of impatience.

Passion and expertise combine to produce a specific cognitive state: you know the problem intimately enough to be genuinely offended by inadequate solutions, and you care enough to keep working when the conventional wisdom says the thing is impossible. That state is extremely difficult to manufacture through user interviews.

The complexity reversal

There is also something structurally backwards about the “start simple for the masses” advice when applied to technical products.

The products that eventually reached the masses did not start simple and then become more sophisticated. They started sophisticated — designed for experts — and then became simpler over time as they were refined, commoditized, and ported to cheaper hardware.

The early internet was for academics and defense researchers. The command line was for systems programmers. Spreadsheets were first adopted by accountants and financial analysts. Smartphones were first a business tool for executives.

In each case, the technology matured in a demanding, expert environment that pushed it to become genuinely good. When it finally reached a mass audience, it worked — not despite the complexity of its origins, but partly because of it. The decades of refinement under expert scrutiny produced something robust enough to withstand casual use.

If you build for the masses from the beginning, you risk optimizing for ease of comprehension at the cost of genuine capability. You end up with a product that anyone can pick up and that few power users will ever trust with anything important. You will also find it hard to have any sort of moat. You get the form without the function.

What this means for founders

None of this is an argument for ignoring users or building incomprehensible products. The lesson is more specific than that.

If you are a technical expert building something for other technical experts, trust that instinct. The fact that your early users require sophisticated knowledge to benefit from your product is not a bug to be designed away in version one. If layman friends criticize your idea because they don’t understand it, that need not be a deal breaker. It may be the filter that keeps the feedback loop honest. Expert users give you harder, more precise feedback. They can describe not just that something is broken but why, and what they would need instead.

If you find yourself filing down the complexity of your product because investors have told you that ordinary users need to be able to use it on their first try, ask yourself whether ordinary users are actually the right target market for what you are building, right now.

The path to mass adoption does not always run through mass accessibility from day one. Sometimes it runs through a small community of people who are obsessed enough to use a rough, hard, demanding tool — because it is the only tool that does what they need.

That obsession, mirrored in the founders themselves, is what makes the thing worth building. The simplicity, the polish, the mainstream appeal — those come later, after the core is proven.

The danger of premature simplification

There is a failure mode that the user-centric doctrine produces in abundance: products that are easy to explain and impossible to love.

A product designed primarily for accessibility to non-experts tends to have smooth edges everywhere. Nothing is hard. Nothing requires investment. This means nothing builds commitment, either. The same frictionlessness that makes the product easy to pick up makes it easy to set down.

Compare this to the tools that technical communities build and use obsessively — Vim, Git, LaTeX, R, Emacs. These are products that impose real learning costs. They are difficult for beginners and unforgiving of carelessness. And yet they have survived for decades, with passionate users who would not trade them for simpler alternatives, because the depth of the tool rewards the depth of investment.

That loyalty, grounded in genuine capability rather than pleasant onboarding, is the kind of foundation on which durable companies are built.

It cannot be achieved by starting from the question: what is the simplest thing a casual user can do in thirty seconds? It can only be achieved by starting from the question: what would a person who cared deeply about this problem actually want to exist?

The founders of the great technology companies asked the second question. They asked it because it was the question they themselves needed answered. That personal urgency — not superior user research — is why they built what they built.