Your real competitor is "do nothing"

Ask a team who they’re up against and you’ll get a slide: the two funded startups, the incumbent suite, maybe an open-source project. It’s a comforting list because it’s a list of products — things you can feature-compare and out-build. It’s also, most of the time, the wrong list. The competitor that actually beats early products isn’t on it, because it isn’t a product. It’s the user continuing to do exactly what they do now.

“Do nothing” — the spreadsheet, the group chat, the thing they hacked together, the just-living-with-it — is the incumbent with the largest market share in almost every category. And it has advantages no competitor can match: it’s already learned, already trusted, already paid for, already integrated into everyone’s day. Switching away from it costs your user something real before they get anything from you. That asymmetry is the whole game, and most roadmaps ignore it.

The clearest way I know to think about this comes out of the jobs-to-be-done tradition: a switch happens only when the forces pushing toward change beat the forces holding a person in place. On the “go” side: the push of their current situation being annoying enough, and the pull of your new thing looking better. On the “stay” side: the habit of what they do now, and the anxiety about your new thing — the learning, the risk, the what-if-it’s-worse. New solutions obsess over pull (“look how much better!”) and quietly lose to the two forces they never addressed.

What changes if you take “do nothing” seriously as the thing to beat:

You stop only adding pull, and start cutting anxiety and habit. More features is a pull move, and pull is the force teams are already best at. The neglected wins are on the other pan: a migration that imports their existing mess so they don’t start from zero, a way to run you alongside the old thing instead of betting everything at once, a reversible first step, proof that switching won’t lose the work they’ve already done. Anxiety, not capability, is often what’s actually stopping them.

You measure against the workaround, not the feature matrix. The honest question in a user conversation isn’t “would you use this?” — it’s “walk me through how you handle this today,” and then, “what would have to be true for you to stop doing it that way?” You’re not looking for feature gaps against a rival. You’re sizing the gravitational pull of their current habit, because that’s the number you actually have to overcome. (This is the flip side of an earlier idea here — that the best feature request is a workaround: the workaround reveals both the job and the incumbent you’re really fighting.)

You respect that “good enough” is a real answer. Sometimes the status quo genuinely wins — the pain isn’t big enough, the switch isn’t worth it, and no feature you ship will change that math. Recognizing those cases early is not defeatism; it’s how you avoid pouring a year into out-building a competitor your user was never choosing between in the first place. The best builders aim their energy at jobs where inertia is beatable, and walk away from the ones where it isn’t.

Note this is a different failure from the one where your own team’s comfort kills a product. This is about the user’s comfort — the quiet, undramatic pull of the thing they already do — and it’s undefeated far more often than any named competitor. Put it on the slide. Then build against it.

The science, to look up: the jobs-to-be-done framing and the “four forces of progress” (Clayton Christensen; Bob Moesta and Chris Spiek’s Re-Wired Group; the “hiring and firing a product” lens); status-quo bias (Samuelson & Zeckhauser, 1988) and the endowment effect as the psychology underneath why “stay” starts ahead.