The Best Product Rarely Wins

There is a belief that runs quietly through the software industry, rarely stated outright but present in almost every product discussion, every competitive analysis, every post-mortem on a failed product. The belief is that quality wins. Build something genuinely better and the market will eventually recognise it. The best product, given enough time and the right conditions, will find its audience and displace the inferior alternatives.

This belief is comforting. It means the work of building well is connected to the outcome of building successfully. It means technical excellence has a reliable return. It means the chaotic, unpredictable surface of how products get adopted has an underlying order that rewards merit.

It is also, as a description of how software products actually succeed and fail, substantially wrong.

The history of software is littered with technically superior products that lost to inferior ones. The technically inferior product that won often had something the superior one did not: better timing, a more accessible entry point, a distribution advantage, a network that made the product more valuable simply by virtue of other people already using it. The quality gap, if it existed at all, was not the deciding factor.

Understanding why this is true, and what actually does determine which products survive, is more useful than maintaining the comforting fiction that building better is sufficient.

What winning actually looks like

Before examining why quality is insufficient, it is worth being precise about what winning means for a software product, because the word covers several different outcomes that have different causes.

Winning can mean capturing the largest share of a market. It can mean surviving long enough to generate revenue in a sustainable way. It can mean becoming the default choice in a category, the thing people reach for without deliberating. It can mean being the product that defines the category so thoroughly that competitors are described in relation to it.

These are related outcomes but they are not the same. The product that wins market share is not always the one that survives longest. The product that becomes the default is not always the technically strongest. The product that defines the category sometimes does so by arriving early enough to shape what the category means, before the technically superior alternatives that arrive later can change that definition.

The consistent pattern across all of these forms of winning is that they are determined substantially by factors that are independent of the product’s technical quality. Network effects, distribution, timing, pricing, the defaults that other products and platforms set, the inertia of existing habits, the switching costs that accumulate as a product is used and integrated. These forces are more powerful than quality differentials in determining which products succeed, and they are largely outside the control of the team building the product.

The network effect that is not about quality

A network effect exists when a product becomes more valuable as more people use it. Communication tools are the obvious example. A messaging platform that one person uses has no value. A messaging platform that everyone you need to talk to uses has enormous value, regardless of whether it is technically the best messaging platform available.

The network effect creates a specific dynamic that is particularly hard to escape from the outside: the incumbent product becomes entrenched not because it is the best but because it is where the network is. A technically superior competitor can demonstrate that it is faster, more reliable, more private, better designed in every measurable way. If it does not have the network, it does not have the value. The value is the network, not the product.

This is why technically excellent alternative products in network effect categories struggle despite their quality. The product is genuinely better. The experience of using it is genuinely superior. And it remains marginal because the network is elsewhere.

What is less often discussed is that network effects exist in categories that do not look like communication products. Developer tools have network effects: the tool that your colleagues use is the tool you know how to get help with, whose errors you can search for, whose community you can learn from. Databases have network effects: the database with the largest ecosystem of connectors, drivers, tutorials, and experienced engineers is easier to use not because of its technical properties but because of its ecosystem. Programming languages have some of the strongest network effects in all of software: the language that the most people know is the language that the most libraries exist for, which is the language that the most employers want, which is the language that the most people learn.

In each of these cases, the best technical option is frequently not the most widely used one. The most widely used one is the most widely used one, which is its own form of being the best for most practical purposes.

The timing problem

Timing in software products is not a matter of releasing early or late in an abstract sense. It is about releasing in relation to the readiness of the surrounding ecosystem to receive the product.

A product that is technically ahead of its time is a product that cannot be adopted because the infrastructure, the habits, the adjacent tools, and the user understanding required to use it do not yet exist. It demonstrates what is possible. It does not win. A later product that arrives when the ecosystem has caught up to the idea captures the market.

This pattern repeats across the history of the industry with enough regularity to constitute a phenomenon rather than a coincidence. The products that win in any given category are often not the first to have the idea or even the first to execute it well. They are the ones that arrived when the conditions for adoption were right, regardless of whether they were technically superior to what came before.

The uncomfortable implication is that timing involves a significant component of luck that no amount of technical excellence can substitute for. A team can build something genuinely better and release it at the wrong moment, into an ecosystem that is not ready for it, and fail. A team can build something adequate and release it when the moment is right and succeed substantially. The technical contribution to the outcome is real but it is bounded by the contribution of timing, which is largely not within the team’s control.

The default that nobody chose

One of the most powerful forces in software adoption is the default setting. The browser that ships on a new device. The language that a popular framework is built in. The cloud provider that an accelerator’s deal with means all its companies get credits for. The tool that is already installed on the machines of the company you just joined.

Defaults are not chosen by the people who end up using them. They are set by platform owners, employers, educational institutions, and the ecosystem of other products that bundle things together. The user who encounters a default product did not evaluate the alternatives and select the best one. They encountered something that was already there and used it.

This means that an enormous proportion of software adoption is explained not by the quality of the product but by the distribution decision of someone else who set it as a default. The product that wins the default position wins an adoption advantage that is extremely difficult to compete with through quality alone. A dramatically better alternative asking users to actively switch from a default is asking them to do work that the default does not require.

The products that have understood this have invested in becoming defaults rather than in being better. They have made deals with platform owners. They have built integrations that make them the natural next step in an existing workflow. They have made the cost of not using them visible and the cost of switching away from them high. None of this is technical work. It is distribution work, and it produces outcomes that technical work cannot reliably produce.

Why switching costs determine markets

Switching costs are the friction that accumulates as a product is used over time. Data stored in a proprietary format. Integrations built against a specific API. Muscle memory developed around a specific interface. Team knowledge that is specific to a particular tool. Workflows that have been designed around the assumptions of a particular product.

These costs do not require the product to be technically superior to accumulate. They accumulate simply through use. A product that has been used for three years by a team of engineers who know it well has switching costs that are independent of whether it is the best available option. Replacing it requires not just evaluating the new product but migrating the data, rebuilding the integrations, retraining the team, and redesigning the workflows. The new product must be better enough to justify all of that, which is a much higher bar than simply being better.

This creates a specific dynamic that benefits incumbents regardless of their technical quality: the longer a product has been in use, the harder it becomes to displace, independent of whether something better arrives. The incumbent does not need to match the quality of the challenger. It only needs to be good enough that the cost of switching exceeds the value of switching.

Most incumbent products that hold their market position despite the arrival of technically superior alternatives are holding it because of switching costs rather than technical merit. The users who choose to stay are not making a wrong choice. They are making a correct calculation that switching is not worth the cost, which is true even when the alternative is genuinely better.

What this means for building

If quality is necessary but insufficient, if timing and network effects and defaults and switching costs determine outcomes as much or more than technical excellence, what should the people building products do with this information?

The first thing is to stop mistaking technical quality for a complete strategy. Building well is important and worth doing for its own reasons: good products are more maintainable, more reliable, more adaptable, and more satisfying to work on. But building well is not a substitute for understanding distribution, timing, and the dynamics of the specific market being entered.

The teams that build excellent products and then wonder why adoption is slow have often not thought carefully about why a potential user would switch from what they currently have, how the product will find its first users, what network effects if any are available to them, and what the default landscape looks like in their category. These are not marketing questions that can be deferred until the product is ready. They are product questions that shape what should be built and how.

The second thing is to take switching costs seriously as both a threat and a tool. As a threat: the product that is displacing an incumbent needs to reduce the switching cost to the point where the quality advantage justifies the effort. As a tool: the product that is trying to build a durable position should be accumulating switching costs deliberately, making itself harder to leave not through lock-in in the manipulative sense but through genuine integration, through becoming embedded in workflows, through building the kind of muscle memory and institutional knowledge that makes the product feel essential rather than interchangeable.

The third thing is to be honest about the role of luck in timing. The teams that succeed are not always the most capable ones. They are often the ones that happened to be in the right place when the conditions for adoption materialised. This is uncomfortable to acknowledge because it reduces the sense of control over outcomes, but it is accurate, and accurate maps are more useful than comfortable fictions. The practical response is not to wait for perfect timing, which cannot be predicted, but to stay close enough to the problem and the users that when timing becomes favourable, the product is ready to move.

The products that do win on quality

Having argued that quality is insufficient, it is worth being honest about the cases where it is a significant factor.

In markets where the cost of failure is high, quality differentials matter more. Infrastructure software, security tools, financial systems: the user in these categories is making a decision where getting it wrong is expensive, so they evaluate carefully and quality plays a larger role than in markets where the switching cost of getting it wrong is low.

In markets without strong network effects, quality differentials can drive switching. If the value of a tool is entirely in what it does rather than in who else uses it, a substantially better tool can pull users away from an incumbent. The key word is substantially. Incrementally better is usually insufficient to overcome switching costs. Order-of-magnitude better can overcome them.

In markets that are early enough that no incumbent has established switching costs, quality is a more reliable differentiator. The product that is clearly better in a category where everything is new and habits have not formed yet can win on technical merit. This window closes as incumbents accumulate switching costs and networks, which is why the companies that build in the early days of a category have an advantage that is worth more than later quality improvements.

The story the industry tells itself

The belief that quality wins is not just a misreading of history. It is a story that the people building products want to believe because it connects the quality of their work to the outcomes they care about. It makes technical excellence feel like a complete strategy rather than a necessary but insufficient one.

The story is also told by the winners, who tend to attribute their success to the quality of their product rather than to the timing, the distribution advantage, or the network effect that was more causally important. Success stories told by successful products are not reliable guides to what produced the success.

The more accurate and more useful story is that building well matters and building well is not enough. The teams that understand both parts of that sentence make better decisions than the teams that only understand the first part.

They build with as much technical care as the teams that believe quality is sufficient. They also think carefully about distribution, about timing, about how their product will accumulate the kind of value that makes switching away from it feel costly.

They are not cynical about quality. They are realistic about what quality can and cannot accomplish on its own.

That realism does not make the building less worthwhile. It makes the building more likely to produce something that lasts.