Moat

Teams that shipped a good feature first and lost the market two years later were never rare. The first mover would lead for half a year, then a company with more money and more engineers would match the feature, cut the price, and watch customers move over. Copying what is visible on the screen usually took about a quarter.

In investor meetings the whole problem hardened into one question: what happens when a large company builds exactly this? Answering that you ship faster, or that your interface is nicer, ended the conversation. Speed and polish are gaps that shrink as soon as the other side spends money, so neither counts as an answer.

That is the gap the word moat fills. The name comes from the ring of water around a castle: a wall can be climbed with a ladder, while water demands a boat and time. Products need the same distinction. Being ahead today and having the gap widen on its own are different claims. Differentiation describes the first; a moat describes the second.

It is also why strategy documents give the question its own line. A strategy that records only what the team is good at empties out the day a rival gets good at the same thing.

A moat doesn't work by blocking competitors. It works by attaching a price to leaving, so that customers stay even after a rival ships the same features. Four mechanisms usually create that price.

1. Network effects — the product gets more valuable as more people use it. Pagedeck with only your own team inside is one more document tool; Pagedeck with ten partner companies commenting in the same files means leaving is no longer your team's decision alone.
2. Switching costs — the labor of moving to another product. Rebuilding three years of meeting notes, per-team permissions, and connections to a dozen other tools takes two people about two weeks. Even at half the monthly price, a customer won't move if those two weeks cost more.
3. Accumulated data — records that only time can produce. If the quality of document recommendations comes out of two years of reading history, a competitor starting today can copy the feature and still has to wait two years to match the result.
4. Brand — being the default name that comes to mind for the job. What counts here isn't affection but the shortcut that brand equity creates. When more customers decide by looking at one option instead of comparing three, a rival has to spend more on advertising to reach the same buyer.

One question separates the four: does this get thicker over time? If it grows harder to cross as users, records, or connections accumulate, it's a moat. If the gap this month looks like the gap last month, it's an advantage and nothing more.

Practitioners test it more bluntly. Could a well-funded company put twenty engineers on it for six months and erase it? If yes, it isn't a moat. The test is useful because it rules out most of what teams like to claim. A faster release cycle, a cleaner design, a cheaper price — all of them fall to twenty engineers and a budget, which is exactly why none of them survive the investor's question.

The word surfaces in three places.

1. Fundraising conversations, where the question above comes up. A list of features doesn't work as an answer, so teams reach for numbers instead — connections per customer went from four to nine over six months, that sort of thing.
2. Roadmap prioritization. When a feature that raises revenue this quarter sits next to a feature that raises the cost of leaving, this is the criterion that decides the order. Pick only one of them every time and you either have no revenue or have the same product as your competitor next year. Teams that wrote the tradeoff into their product principles waver less here.
3. Deciding whether to build or buy. This is the criterion behind build-buy-partner: build the capabilities that belong to the moat even when it's slow, and attach someone else's work for everything else.

There is also a place it shouldn't appear. Debating the moat while 200 people use the product is usually a wasted hour, and the debate tends to produce plans that assume a scale the team doesn't have yet. Making customers who can't leave comes after making customers who arrive.

"This feature adds revenue but doesn't thicken the moat. It shouldn't be first in line this quarter."

It pays now but doesn't create a reason to still be chosen next year.

"If someone asks what our moat is, right now all we have is a feature list."

An honest admission of where the pitch breaks down.

"Push integrations to twenty and the cost of leaving goes up, so that's closer to a moat."

A single feature repriced from the moat's point of view.

Right after Pagedeck's Series A, Grace got the same question from an investor: what happens when a large document company ships these features? The answer she reached for was a number rather than a feature. Half of the paying teams had invited outside partners into their documents, and those teams churned at a third of the rate of the rest.

At the next quarter's roadmap meeting Mia reordered the list on that basis. Work on the flow for inviting outside collaborators moved up; fonts and table formatting moved down. Customers had asked for both, but only one of them widened the water.

The most common misreading is that a long feature list is a moat. It looks like one, since catching up appears to mean building all of it. But a competitor doesn't rebuild everything — they pick the handful customers actually use. If five of your hundred features get used daily, five is what catching up requires. Left uncorrected, this belief has teams adding features nobody opens while believing they're getting safer, and the only things that grow are the screens and code they have to maintain.

Treating a moat as permanent once dug is the other one. The word structure sounds like a fixed object. In practice the world keeps moving toward making departure cheaper: export and import standards turn a two-week migration of three years of records into two days, and tools that reconnect integrations for you mean twenty integrations stop being a wall. Teams that never recheck keep assuming the castle is safe long after the water has dried up.