Skip to content
All articles
Research7 min read
InfrastructureTimingSystemsStrategy

Timing Is a Systems Problem

In 1995, a company called General Magic shipped a handheld device with a touchscreen, wireless connectivity, downloadable applications, and an online marketplace. It was, in most functional respects, a smartphone—a decade before the iPhone. The engineering worked. The product did what it claimed to do. General Magic went bankrupt in 2002.

The technology was viable. The market was not ready. Wireless infrastructure was too slow, carrier partnerships were too fragile, and consumers did not yet have the mental model for a "pocket computer" that would make the value proposition legible. When Apple shipped the iPhone in 2007, the core concepts were nearly identical, but the surrounding conditions—3G networks, capacitive touch maturity, an established iTunes ecosystem, cultural familiarity with always-on connectivity—had caught up.

There is a particular kind of work that is technically viable but socially premature, and the gap between those two states is a systems condition that can be observed, measured, and adapted to.

Three Kinds of Readiness

Technical readiness is the easiest to measure because the feedback loop is tight: the system either works or it does not, it either performs as specified or it fails, and you can test, iterate, and verify on a timeline of days to weeks. Measurable signals include passing test suites, reproducible benchmarks, and stable performance under load. General Magic's device was technically ready—the engineering was sound.

Market readiness is harder to measure because it depends on what people believe they need. A market exists when enough decision-makers recognize a problem, believe it is solvable, and are willing to allocate budget to solve it. Measurable signals include: inbound inquiries that reference the problem you solve rather than requiring you to explain it, competitor activity in the same space, analyst reports that name the category, and procurement processes that have line items for the kind of work you do. When your sales conversations end with education rather than negotiation, market readiness has not arrived. General Magic had none of these signals—the category did not yet exist.

Institutional readiness is harder still, because institutions move slowly by design and require consensus, process, and precedent before they can adopt something new. Measurable signals include: published standards or frameworks that reference your problem domain, regulatory guidance that creates compliance obligations your solution addresses, executive-level champions who can create internal budget authority, and at least one reference deployment that other institutions can point to as precedent. A technology can be technically and market-ready but institutionally premature if it challenges existing power structures, requires new governance frameworks, or depends on trust that has not been established.

These three forms of readiness operate on different timelines, and they are almost never synchronized.

The Go-to-Market Gap

When you build infrastructure ahead of market readiness, you enter a peculiar space. The problems you are solving are real. The solutions you are building are functional. But when you try to explain what you have built, you encounter a vocabulary gap.

The listener does not have the conceptual hooks to place your work. They do not yet have the problem category you are addressing. They are not yet asking the questions your system answers. This is a go-to-market problem: the product works, but the pitch requires teaching the buyer a new problem before you can sell them the solution. That ordering is expensive and slow.

Staying Honest About Being Early

The obvious risk when you are early is convincing yourself the market is wrong and you are right. Sometimes that is true. More often, "early" means you haven't found the right framing, the right buyer, or the right entry point. I-Corps forced this reckoning for work I was doing in this category.

The conversations we had with enterprises were clear: they cared about AI capability, not AI governance. That did not mean governance was unimportant—it meant we were selling to the wrong urgency at the wrong time. The productive response was to stop pushing and start listening for the signal that the timing had shifted.


Timing as a Systems Problem

Timing is often framed as a personal challenge—you were too early, you should have waited, you should have entered the market at the right moment. But markets are complex adaptive systems. They respond to external shocks, regulatory changes, technological breakthroughs, and cultural shifts. The moment when a market becomes ready for a particular solution is determined by forces largely outside any individual's control.

You can position yourself to take advantage of timing. You can monitor signals that suggest readiness is approaching. But you cannot manufacture market readiness through willpower. Treating timing as a systems problem removes the personal dimension and replaces frustration with analysis.

What Early Looks Like

When you are early, certain patterns become recognizable. You spend more time in sales conversations explaining the problem than proposing the solution; by the time you reach the proposal, the listener is fatigued. You get compared to things that are not quite right—"So it's like X?"—because there is no existing category that fits and the listener reaches for the nearest approximation. People find the idea interesting but not urgent, and interest without urgency does not produce purchase orders. The few people who understand what you are building are often ahead of their own organizations; they see the value but cannot create internal consensus.

These are signals, not failures. They tell you where the market is in its readiness cycle and how far you are from the conversion point.


Adaptation Strategies

If you find yourself early, the options are straightforward, and none of them involve pretending you are not early.

First, reduce burn. If the market is not ready, you cannot force it. The goal becomes survival until conditions change—reducing expenses, extending runway, and avoiding commitments that assume near-term revenue.

Second, reframe as research. Work that is valuable but ahead of its market may be better framed as research than as a product. Research does not require market validation. It requires intellectual coherence and eventual applicability.

Third, build for the adjacent. Sometimes the work you have done is applicable to a related problem that has already achieved market readiness. Pivoting to the adjacent is positioning, not abandonment.

Fourth, document relentlessly. If you are building infrastructure ahead of its time, the documentation becomes crucial. Future developers, including your future self, will need to understand what was built and why. The context that seems obvious now will be forgotten.

Finally, maintain conviction without rigidity. Being early does not mean being wrong. But it requires openness to the possibility that your timing assumptions were off, that the market may evolve differently than expected, or that the problem may be solved by a different approach.

The Long Game

Some infrastructure takes decades to mature. The internet was technically functional long before it was commercially viable. Containerization existed for years before Kubernetes made it mainstream. Version control concepts preceded Git by decades.

The history of technology is full of ideas that were right but early. The ones that eventually succeeded often did so because they persisted until adoption caught up. Persistence is necessary but not sufficient—being early does not guarantee eventual success. But giving up guarantees failure.

A Systems View

Viewing timing as a systems problem changes how you interpret your position. You are not ahead of "them." You are in a different phase of a larger cycle, and the cycle will continue to evolve.

The useful question is not "Why doesn't the world understand what I'm building?" but "What phase is the market in, and how should I adapt my approach to that phase?"

Building systems before the world has language for them is disorienting. The conversations are hard because the shared vocabulary does not yet exist. But timing problems are systems problems, and systems problems respond to positioning and patience. When your sales conversations end with education rather than negotiation, that is diagnostic information. Use it to decide whether to reduce burn, reframe as research, build for the adjacent, or keep waiting—and know which one you are choosing and why.

James KC AuchterlonieCo-founder, MLNavigator