A moat has two parts
In my August 13, 2026 First 1000 essay “The moat paradox,” I used Hamilton Helmer’s 7 Powers as the frame. A real power needs a benefit that improves cash flow and a barrier that makes the benefit hard to copy or arbitrage away.
The seven Powers are scale economies, network economies, counter-positioning, switching costs, branding, a cornered resource, and process power.
The categories describe a destination. At this stage, the seven Powers are usually lagging indicators. A founder can choose a difficult customer problem and measure whether the team is getting better at solving it.
What the hard problem looks like on day one
The examples share a shape: taking on the taxi industry, getting strangers to sleep in each other’s homes, making design software run in a browser, getting code to run on a graphics card, or scaling transformers.
The work was hard, risky, slow, and connected to the core value the user wanted. That difficulty created the possibility of a future barrier because other teams had reasons to avoid it.
Which hard problem, if solved, would make the product materially more valuable and harder to replace? Hard work by itself is not a moat. A painful internal process, a bespoke integration nobody wants, or a feature customers barely notice can consume years without improving defensibility.
The avoidance pattern
Uncertainty makes long-horizon work uncomfortable. A smaller task gives an answer today. A hard core problem may take two years before the answer is clear.
That is why founders can spend a week redoing a landing page while the critical product problem waits. The landing page gives immediate feedback. The hard problem gives ambiguity.
I am not arguing against small improvements. I am proposing a prioritization test. If a task creates a clean artifact but does not move the core problem, do not count it as moat progress merely because it shipped.
A weekly hard-problem review
Write down one hard problem and review it every week.
| Question | Evidence to bring |
|---|---|
| What user outcome does the problem control? | A specific workflow, failure, or promised result. |
| What makes it difficult? | Missing data, reliability, distribution, trust, latency, regulation, or a physical constraint. |
| What did the team learn this week? | A test result, failed approach, user correction, or narrower boundary. |
| Did the product get harder to replace? | A retained artifact, workflow integration, learned preference, trust signal, or unique access. |
| What did we avoid because the answer was uncertain? | The decision you postponed and the reason. |
AI makes the distinction sharper
I wrote the essay while building with AI agents. AI makes output cheaper and faster. That changes what customers can assume every competitor can do.
My rule is to use AI against the hard problem while keeping the failure-mode and tradeoff calls human. Those choices are where differentiation starts.
Faster code is useful only when it helps the team solve the problem competitors still avoid. Name the hard problem, connect it to user value, and bring evidence that the team moved it.
The weekly operating practice
- Name the hard problem.
- Connect it to a user outcome.
- Record what the team learned.
- Separate shipped output from hard-problem progress.
- Review what uncertainty caused you to avoid.
The takeaway
A moat is a destination. The useful measure today is whether you are solving the hard problem competitors still avoid.
Sources and original research
Historical facts are attributed to these sources. An observed product change does not establish conversion lift.
Updated September 20, 2026. Based on original First 1000 reporting and the sources listed above.