The Product Overhang Doctrine
In any product cycle, there are two curves to follow. The first is what your underlying technology can do. The second is what your users can actually do with it. They are not the same curve, and the gap between them — what the platform makes possible versus what the product surfaces — has a name.
Overhang.
For most of software’s history, the overhang was small. Your stack moved approximately as fast as your team could ship features against it. The two curves stayed close. Product roadmaps were exercises in execution, not in temporal arbitrage. You built for the capability you had; the capability you would have next quarter looked roughly like the capability you had this quarter, plus integrations.
Frontier AI broke this symmetry. Model capability now compounds on a six-to-twelve-month doubling cycle. Per METR’s 2026 benchmark, the time horizon a model can autonomously execute against has expanded roughly 41× in 16 months — from approximately 21 minutes on Sonnet 3.5 to approximately 12 hours on Opus 4.6. Inference price per equivalent unit of work has collapsed by a similar order of magnitude over the same window. The product capability built around those models has not, and structurally cannot, move at the same pace.
Most product organizations are built to ship for the curve they can see today. The frontier moves while they ship. The result is a permanent, widening gap, and that gap is now the most important strategic surface in software.
The Product Overhang Doctrine is the bet that you can build into the gap before it closes — shipping features for capability that doesn’t yet exist, knowing the capability will arrive on the next model release, and absorbing the pre-PMF months because the alternative is shipping into a frontier that has already moved past you.
This piece is the doctrine at depth. How it works. Who is executing it and who isn’t. The four ways it fails. The eight operating practices that make it survivable. The organizational form required to run it inside a company. And the structural choice every org now faces about which curve it’s competing on.
Join Yearly Premium Membership To Get The Builder-PM
The architecture of the overhang
The two-curve mechanic
Plot two curves on the same axes. The horizontal is time. The vertical is capability.
The first curve is model capability — what the frontier model can actually do, measured along whatever axis matters for your product (context length, reasoning depth, code generation, multi-turn coherence, agentic task horizon, multimodal fluency, tool-use reliability).
This curve compounds. New architectures, new training data, and new post-training techniques each push it upward, and the cycle now repeats every few months rather than every few years.
The underlying mechanism is scaling laws — empirical relationships among compute, data, parameters, and capability that have held with surprising stability since 2020 and for which no one has yet found a clean ceiling.
The second curve is product capability — what users of your specific product can actually do, end-to-end, in production. This curve does not compound. It moves at the rate of your release cadence, gated by PRDs, design reviews, engineering sprints, QA, and rollout. In an exceptionally well-run org, it inflects two or three times a year. In most orgs, it influences annual planning cycles.
The result is structural. Model capability is exponential; product capability is approximately linear. Once an exponential and a linear function are plotted on the same axes, the gap between them widens monotonically. There is no execution speed at which a linearly improving product can keep pace with an exponentially improving substrate. The gap is not a problem to be solved through better engineering; it is a structural feature of the era.
Three properties of overhang
Directionality. The gap is asymmetric in direction. Models leave products behind, not the other way around. There is no scenario in which product capability outruns model capability over the long term, because every product is built on top of the model. The arrow points one way, and any roadmap that assumes otherwise is mispriced.
Dimensional asymmetry. The compounding is not uniform across capability dimensions. A model release might extend the agentic task horizon by 10× while only modestly improving multilingual reasoning. Your overhang is dimension-specific. Building into a dimension that doesn’t compound on your horizon is the silent failure mode every builder underestimates. Picking the right axis matters more than executing well against the wrong one.
Decay. Any individual overhang bet decays. The gap you saw six months ago is partially closed by the next model release, partially closed by competing product teams, and partially closed by the user’s evolving expectations. The bet has a half-life. You ship into the gap, you capture the arbitrage, then the gap closes, and you need the next bet ready. Operators who run the doctrine well are not running one bet; they are running a pipeline of bets with staggered horizons.
