Moats for People Who Don't Own a Castle Yet
A field bestiary of the advantages that actually protect a product from being quietly eaten by a smarter, cheaper, faster competitor. Which one does yours have? Be honest.
Every startup pitch deck claims a moat. Most of them have the moat of "the founders really want this to work," which, in moat terms, is about the depth of a puddle.
For a new PM, understanding what a real moat looks like is genuinely important, because the strategy you execute against depends on which moat your company is actually building. A team trying to win on network effects should be doing wildly different work than a team trying to win on switching costs. Mix them up and you will ship features that make nobody's life better except the competitor you're subsidising by accident.
Here is a working taxonomy — the six advantages that stand up under pressure — written as a bestiary, because most strategy language pretends these things are noble when in practice they are survival instincts.
You serve a customer that the dominant player structurally cannot — because serving them would cannibalise a bigger part of their business. A free tier that the market leader can't offer without destroying their enterprise revenue. A self-serve flow that a sales-led competitor can't match without firing half their sales team.
This is the most common moat for early-stage products. It is also the most fragile — it disappears the moment the incumbent decides the new market is big enough to risk the cannibalisation.
The classic network effect. Each new user makes the product more valuable to the existing ones. Marketplaces, social platforms, collaboration tools all try to build this. Most don't.
The critical nuance: not every product with users is a network. If the 10,000th user adds nothing to the experience of the 500th, you have scale, not a network. Scale is useful. It is not a moat.
Switching costs. The customer would technically prefer a competitor, but moving their data, retraining their team, rewiring their integrations, re-doing their reporting — is so expensive they stay. This is why enterprise software is such a good business and such a tragic user experience.
The uncomfortable truth: switching costs are often indistinguishable from customer frustration. A moat made of "it would be too painful to leave" is a moat made of resentment, which competitors can dissolve by offering to handle the migration for free.
Scale economies. The per-unit cost of serving a customer falls as you grow, so you can price below what any smaller entrant can sustainably match. Cloud infrastructure is the textbook case. Same with logistics networks, data labelling operations, and — increasingly — AI training runs.
Scale economies are enormous for the companies that have them and almost impossible to build if you don't start with them. A new PM at a big company is usually inside one of these moats. A new PM at a startup is usually trying to avoid bumping into one.
Customers pick you, over a technically identical product, because trusting the brand is cheaper than evaluating the alternative. This is the slowest moat to build — years, sometimes decades — and the one most often claimed falsely. A logo isn't a brand moat. A marketing budget isn't a brand moat. A brand moat is a customer paying a premium because the search for something comparable feels risky.
Worth noting: brand is real in consumer, medium-real in SMB, and vanishingly real in technical B2B, where every buyer thinks they are above being influenced by brand and exactly half of them are correct.
Proprietary data plus the learning loops to use it. Recommender systems, fraud detection, routing algorithms — all depend on accumulated user interactions that latecomers can't manufacture. This is the moat most talked about in the AI era and most exaggerated.
Two caveats. First, raw data is rarely the asset; the pipelines and feedback loops around it are. A competitor can buy a dataset; they cannot buy three years of shipping, learning, and re-training around it. Second, a lot of what gets called a data moat is actually "we got there first," which is not a moat, it's a head start.
What to do with this list as a new PM
You cannot build a moat yourself in your first year. What you can do is stop shipping work that accidentally sabotages the one your company is building.
Pick the moat your company's strategy is actually betting on. (If nobody can tell you, that is also useful information — see the wish-list-in-a-blazer piece.) Then, for every project on your roadmap, ask the single most useful strategy question you can ask as a new PM:
"Does this make our moat deeper, or does it just make our quarter look better?"
Work that makes the quarter look better is not bad — teams need wins, bonuses need to pay out, executives need numbers. But if your entire roadmap is quarterly wins, and none of it is deepening the moat, you are not executing strategy. You are running a very stressful treadmill that happens to produce dashboards.
The honest conversation
Most products you will work on in your career will not have a serious moat. That is fine. Most software businesses survive on a combination of a lead, some switching cost, and a customer base that is too busy to shop around. Pretending you have a castle when you actually have a nice office with a moderately sticky lease is how you end up surprised when a competitor overtakes you.
The new-PM superpower here is simple: name the moat out loud. "We're a switching-cost business with a brand overlay." "We're relying on scale economies that won't kick in for two years." The moment the moat is named, roadmap conversations stop being about features and start being about whether each feature is actually pulling its weight against the thing that protects the company.
Which is to say — strategy.
← Back to Product Strategy