There is a standard playbook for building a startup, and it is genuinely good advice — for the kind of company it was written for. Find a narrow problem, ship a minimum viable product fast, obsess over product-market-fit, measure everything, iterate toward the metric. Founders absorb this as gospel, and for a great many companies it's exactly right. The trouble is that the most ambitious technology companies — the ones that end up defining an era — usually didn't look like that early, and judging them by that playbook would have killed them in the crib.
I think we're at one of those moments again, where the genuinely important things being built don't fit the template, and where the conventional wisdom about how to build a company is actively misleading for the people building the things that will matter most. The next platform-defining product — the next thing on the order of the iPhone in its consequence — will not, in its early life, look like a well-run startup. It'll look messy, premature, and strategically confused to anyone applying the standard scorecard. Understanding why is, I think, one of the most important things a founder of frontier technology can internalize.
Great platforms look messy early
The iPhone is the obvious reference, so it's worth remembering how it actually looked at the start, stripped of hindsight. The first one had no app store, no copy and paste, no third-party software, a slow network, and a price that drew real ridicule. By the strict logic of the lean playbook, it was an overbuilt, underfeatured, overpriced product searching for a market. What that critique missed was that Apple wasn't shipping a product. It was laying down a platform — and platforms look incomplete early precisely because their value isn't in what they do on day one but in what becomes possible on top of them later.
This is the pattern with foundational technology generally. The early personal computer looked like a toy for hobbyists. The early web looked like an academic curiosity. The early electrical grid powered a few light bulbs at a cost that made no economic sense against gas. In every case, the thing that became infrastructure looked, in its first form, like a worse and more expensive version of something that already existed — and the people who judged it on that basis were measuring a platform with a product's ruler.
The reason is structural, not incidental. A platform's value compounds as an ecosystem forms on top of it — as the tooling matures, as others build on it, as the use cases that no one could have specified up front are discovered by people the builder never met. None of that exists on day one. So a platform necessarily debuts looking underwhelming relative to a polished point solution, because the polished point solution front-loads its value while the platform back-loads it. If you optimize a platform to look good early, you generally do it by making it less of a platform — narrowing it into a product, trading the compounding curve for the flattering one.
Product-market-fit is the wrong question first
The most sacred metric in the startup canon is product-market-fit, and I want to argue that for frontier technology it's not just insufficient but actively the wrong yardstick at the wrong time.
PMF asks: does this product, as it exists now, satisfy a market that exists now? That's a perfectly good question once both the product and the market are real. But frontier technology, by definition, is building toward a product and a market that don't yet exist — that the technology itself will call into being. Asking for PMF before the platform exists is asking the wrong question of the wrong stage. The iPhone didn't have product-market-fit with the app economy, because the app economy didn't exist; the iPhone created the conditions for it. A neural interface, an embedded-intelligence platform, a new sensing modality — these are building the capability from which markets will form. Demanding evidence of fit with a market that the technology hasn't yet made possible is a category error, and it systematically steers builders away from the most consequential work toward whatever can show traction this quarter.
This is why so much capital and talent pools in incremental products: incremental products can demonstrate PMF, because they serve markets that already exist. Frontier platforms can't, not at first, and so they look unfundable and irresponsible by the standard scorecard right up until the moment they look inevitable. The scorecard isn't wrong about products. It's wrong about the phase before the product, which is exactly the phase where platforms are born.
The better early questions are not about fit with today's market but about the trajectory of the capability. Is the underlying technology on a curve that's improving? Does it open a space of possibility that gets larger, not smaller, as it matures? Are you building the kind of foundation that others will be able to build on? Those are platform questions, and a company can be doing brilliantly on all of them while scoring terribly on near-term PMF. Confuse the two and you'll abandon the platform right before it would have mattered.
Abstraction beats optimization
Here's a third place the conventional playbook misleads, and it's the most technical of the three. The lean instinct is to optimize relentlessly toward the current metric — to make the thing you have measurably better along the dimension you're tracking. For incremental products that's the right reflex. For foundational technology it can be a trap, because the highest-leverage move is often not to optimize the current thing but to find the right abstraction — the reframing that makes a whole class of problems tractable at once.
Optimization improves a point on a curve. Abstraction changes which curve you're on. The companies that have mattered most usually won not by being more optimized than competitors along the obvious axis but by finding a better abstraction — a cleaner platform, a more general primitive, a reframing of the problem — that unlocked everything downstream. The personal computer wasn't a more optimized mainframe; it was a different abstraction of what computing was for. The cloud wasn't an optimized data center; it was a reabstraction of compute as a utility.
The catch is that finding the right abstraction often looks, in the near term, like worse optimization. It means stepping off the curve everyone else is climbing to build the foundation for a different one, and during the transition you'll lose on every near-term metric to the competitors still optimizing the old thing. The discipline of frontier building is the willingness to take that local loss for the structural win — to resist the enormous pull toward optimizing the current metric when the real opportunity is to change the abstraction underneath it. The metric-obsession that serves a product company well is precisely what prevents this move, because the move always shows up as a metric going the wrong way before it pays off.
The honest danger: "platform" as an excuse
I have to address the obvious abuse of everything I've just said, because it's real and it's dangerous. "We're a platform, not a product" and "product-market-fit doesn't apply to us" are exactly the things a failing company tells itself on the way down. The same words that describe the early iPhone also describe a thousand startups that were simply building something nobody wanted and dressing up the lack of traction as visionary patience. If the argument can't distinguish between those two cases, it's worthless — worse than worthless, because it gives every floundering founder a sophisticated story for ignoring reality.
So how do you tell a real platform from an excuse? Not by the absence of near-term traction — both look the same on that axis — but by whether the capability is actually on a trajectory. A genuine frontier platform sits on top of a technology that is observably improving and that opens a possibility space getting larger over time; you can point to the curve even if you can't yet point to revenue. An excuse sits on top of nothing — no improving capability, no expanding possibility space, just a hope that demand will appear if you wait. The tell is whether you're building toward an inevitability that the technology is making more reachable every month, or simply waiting for a market to show up for a thing that isn't getting better.
There's a second tell, which is intellectual honesty about which signals you're allowed to ignore. Permission to ignore near-term PMF is not permission to ignore all feedback. The disciplined frontier builder is ruthless about the questions that are answerable at this stage — is the capability improving, are the hard technical risks actually being retired, is the possibility space real — and humble about the one question that genuinely isn't yet, which is fit with a market the technology hasn't created. The undisciplined one uses "we're early" to wave away every hard question, including the ones they could and should be answering. The difference between conviction and delusion isn't the willingness to look wrong to the crowd. It's whether you're holding yourself accountable to the right scorecard or to no scorecard at all.
This is why taste matters so much in frontier building, and why it can't be reduced to a metric. The judgment about which technology is genuinely on an improving trajectory, which possibility spaces are real, and which conventional signals to weight versus discount — that's the actual skill, and it's the thing the playbook can't give you because the playbook is calibrated for the case where the metrics are trustworthy. When the metrics are misleading, all you have left is judgment, and judgment is exactly what separates the founders who build the next platform from the ones who merely talk like they are.
What this means for how you build
None of this is an argument for sloppiness, for ignoring users, or for indulging technology with no path to mattering. It's an argument for applying the right model of company-building to the right kind of company — and for recognizing that the dominant model is calibrated for incremental products and quietly miscalibrated for foundational platforms.
If you're building frontier technology, a few things follow. Be willing to look unfashionable for longer than is comfortable, because looking finished early and being a platform are usually in tension, and the crowd's scorecard is measuring the wrong curve. Judge yourself on the trajectory of the capability and the size of the possibility space you're opening, not on fit with a market that your own technology hasn't created yet. And protect the willingness to chase the right abstraction even when it costs you on the near-term metrics, because that's the move that actually compounds — and it's the first thing metric-discipline talks you out of.
There's a cost to this, and it's worth naming honestly: building unfashionably means being misunderstood, underestimated, and second-guessed for a long time, including by smart people whose advice is genuinely good for a different kind of company. That's uncomfortable, and it's supposed to be. The companies that end up defining an era are the ones that looked, for a while, like they were doing it wrong — because they were doing something the prevailing playbook had no category for.
The next genuinely important platform is being built right now, and I'd bet it doesn't look like a well-run startup today. It looks messy. It can't point to product-market-fit, because the market it will serve doesn't exist yet. It's optimizing for an abstraction instead of a metric, and losing the near-term comparison to more focused competitors as a result. By every convention, it looks like a mistake. And then one day the platform is finished enough, the ecosystem forms, and in hindsight it looks inevitable — and everyone forgets it ever looked like anything else.