Most of what we call building is actually imagining. Before a line of code is written, before a prototype ships, before a pitch deck is polished, someone has to sit with a question long enough to let it change them. The product is just the residue of that inquiry.
A framework for new product development suggests starting by describing the world as it will be when the product is done, writing a short science fiction story about that future before anyone builds anything. The exercise is not creative writing; it is a forcing function. If you cannot describe the future state clearly enough to make someone feel it, you are not ready to build. You are still guessing.
This is where most projects die. Not in execution, but in the gap between what the builder imagines and what the future actually wants. Execution is table stakes; imagination is the scarce resource.
We do not treat it that way. We celebrate the launch, the funding round, the million-user milestone. We rarely celebrate the question that survived multiple wrong answers and still held. The person who kept asking it when it would have been easier to switch to a safer, more fashionable query.
A creative director at a major design firm was asked about his own beautiful question. He said it is simply: how do I stay inspired? He considers it part of his job to keep asking it. If the person responsible for the creative output of six hundred people has to treat inspiration as a practice rather than a mood, then the rest of us have no excuse for assuming it arrives unbidden.
Inspiration is not a visitor. It is a habit.
The same discipline applies to failure. Failure stories are the unglamorous infrastructure of any craft that improves over time. They contain the specific details that success stories edit out: the wrong assumption, the misread signal, the moment the builder should have pivoted but did not. Sharing them is not an act of confession; it is an act of calibration. Every failure story is a map of what the future looked like from a particular angle, and why that angle was wrong.
We need those maps.
There is a classic dialogue where a king asks a sage to explain the nature of the self. The sage responds by asking how the king came to the meeting. The question shifts the terrain entirely. The self is not a thing to be explained; it is a process to be traced. Every version of it is built from prior causes, and none of them is permanent.
That is the frame worth bringing to products, companies, and the systems we build. They are not static objects. They are ongoing processes with dependencies we did not choose and effects we did not anticipate. A platform that succeeds by embedding itself in daily habits will one day find those habits migrated elsewhere, leaving the platform to wonder where its users went. A payments rail designed for humans clicking buttons will feel the strain when agents start calling APIs instead. These are not failures; they are the natural motion of systems that never learned to ask the harder question about what they were actually serving.
The harder question is always about dependency. What do we rely on that we have not named? What assumptions are baked into our architecture that we have never tested? Who benefits when this works, and who pays when it does not?
Today the market is sending mixed signals. Some companies are racing to embed invisible watermarks in generated text, shifting the question from whether content is AI-created to who gets to mark it. Selling provenance as trust, but provenance is also a power relationship. The entity that controls the mark controls the record.
At the same time, model costs are falling while the cost of wiring systems together is climbing. The cheap part is generating the output; the expensive part is making it trustworthy, reviewable, and safe to run at scale. Agents are outperforming larger models not because they are smarter but because they review each other, layer by layer. The intelligence is in the process, not the model.
This is the inversion worth sitting with: the thing we thought was valuable, the frontier model, is becoming a commodity. The thing we neglected, the wiring, the trust layer, the review process, is becoming the scarce resource. Every business plan that assumes the model is the moat is now behind the curve. The moat is who can push the code, who can verify the output, who can survive the failure modes no one predicted.
The same pattern shows up in markets. One company’s payments chief built a seven-and-a-half-billion-dollar-a-year engine that keeps users inside the platform; her exit is a reminder that systems outlast the people who designed them, and that the best architectures are the ones that do not depend on a single pair of hands. Another company shipped a tracking device with a rare pairing of technologies, but the real competition is not the device itself; it is which locating standard the world decides to adopt. The winner will be the standard that other builders choose to embed, not the one with the best marketing.
None of this is new. The form changes; the structure does not. The question that outlasts the product is always the same: what problem are we actually solving, and for whom? The builders who stay in the room long enough to hear the real answer are the ones whose work outlasts the hype cycle.
The rest are just writing science fiction about a future they will not live to see.
Leave a Reply