A few years ago I shut down a product its first users loved.
It was an internal venture I owned end to end — a microlearning product, small team, around sixty discovery interviews behind it. People who tried it wanted it; the demand was measured and real. And I folded it back into the company’s portfolio instead of spinning it out, because the thing that made it good couldn’t be produced at scale. The quality came from two people distilling decades of hard-won experience into lessons crisp enough to teach. To turn that into a standalone business we’d have had to produce ten times the content, and there was no way to do that without lowering the bar that was the entire reason anyone liked it. Demand was never the question. The question was whether we could produce the thing, at the quality our edge depended on, at the volume a real business needed. We couldn’t, so we didn’t pretend otherwise.
That decision taught me to distrust the most seductive question in product — does it work? — and to ask the harder one underneath it: can you make it, at rate, to spec? They are not the same question, and confusing them is how good things die.
Lately I keep seeing the same gap in a far higher-stakes arena.
Solving the problem is the easy part
There’s a story the technology industry likes to tell about defense: the bottleneck is invention. Build something clever enough — a better drone, a smarter sensor, an autonomy stack that actually works — and the rest follows. It’s a comfortable story for people who are good at building clever things.
It’s also mostly wrong, and the war in Ukraine has spent over four years proving it. The decisive questions there have not been whether a capability exists. They’ve been whether you can produce it by the tens of thousands, replace it when it’s jammed or shot down next week, and hold quality across a production run when the people assembling unit ten thousand aren’t the engineers who built unit one. The constraint isn’t the demo. It’s the line behind the demo.
This is the part the enthusiasm skips. A prototype that performs brilliantly on a range, in front of the right colonel, has cleared the easy gate. The hard gate is everything the prototype doesn’t show: can it be manufactured at volume, at a unit cost the buyer will actually pay, to a quality bar that holds across the whole production run, through a supply chain that survives contact with reality, fast enough to matter? A capability you can’t actually produce and field reliably is a science project, however well it demos.
People in the field have a name for the place where good systems die between a working prototype and a program of record. They call it the valley of death, and they usually describe it as a funding or acquisition problem. It is partly that. But underneath the paperwork it’s the same problem I hit with a product nobody was shooting at: what decides whether you field it is rarely whether the thing works. It’s whether you can produce it — to the quality your advantage depends on, at the volume your mission needs. A buyer won’t field what you can’t produce to spec, no matter how well it solves the problem on paper. In defense the buyer is a government with soldiers’ lives attached to the answer, which only sharpens it.
Production is a strategy, not an afterthought
The instinct in software is to treat production as a downstream detail — solve the hard intellectual problem, then “scale it later.” Hardware, and defense hardware especially, doesn’t grant you that separation. Producibility is a design constraint from the first sketch, or it’s a wall you hit at the worst possible moment: after you’ve raised on the demo and promised the delivery.
And it cuts across the whole spectrum of what gets built. At one end, attritable mass — systems cheap and producible enough that losing one is a tactic, not a tragedy — lives or dies on rate and unit cost. At the other, a handful of exquisite, expensive platforms lives or dies on yield, reliability, and a secure supply chain for components you can’t simply re-order — because when you only field a few of something, none of them can be the one that wasn’t built right. Different ends of the spectrum, same underlying discipline. The companies I watch most closely are the ones that treat manufacturability and that supply chain as part of the product from the first sketch, not as logistics to sort out once the clever part is done.
What doesn’t scale
There’s a thread connecting the product I killed to all of this, and it’s the part I find most interesting. Some constraints yield to more tooling, and some don’t.
My microlearning product’s bottleneck looked, on the surface, like a content-production problem — and the easy assumption today is that AI would simply solve it now. I don’t think it would. The quality depended on judgment that lived in two people’s decades of experience, formed in rooms where the real conversations were never written down. That knowledge was never in a training set, because it was never documented. You can’t prompt your way to it any more than you could hire your way to it.
Defense has its own versions of the constraint that doesn’t scale on demand: machine tools and the people who can run them, secure supply chains for the components that actually matter, the accumulated process knowledge that only comes from having built the thing, not just designed it. You don’t out-clever these. You out-build them, slowly, by deciding early that production is the hard part and treating it that way. The moat, in the end, is the same one I keep coming back to: the capability that can’t be conjured quickly, only accumulated.
Where I’m pointed
I came to all of this sideways — through products, and through running drone operations in the field, where off-the-shelf hardware has to work at four in the morning on a network you can’t trust. It’s the problem I want to spend the next stretch of my work on. Not because defense is having a moment, but because the gap between it works and it actually ships, to spec is the most consequential gap I know, and I’ve spent my career on the boring, decisive side of it.
The lesson from the product I shut down turned out to be portable. Demand tells you a thing is wanted. It says nothing about whether you can build it for real. In a microlearning startup, getting that wrong costs you a venture. In defense it costs a great deal more — which is exactly why it’s worth getting right.