Most product frameworks assume the hard part is already solved. You know the thing can be built. The remaining questions are about execution: which market, which features, how fast to scale.
Deep tech is different. In many cases, you don’t yet know if the end product can be built at the level required to be useful. That’s not a minor distinction. It changes what product management is actually for.
Value works differently here
In most software, a partial product can still be valuable. Ship something, get users, improve it. Value accumulates incrementally.
In deep tech, value often doesn’t work that way. It’s discontinuous. There’s a threshold, and the relationship to value isn’t a gradual slope, it’s a cliff. Below the threshold, you don’t have a product in any real sense. Above it, things unlock all at once: a clinical workflow accepts your output, a regulator signs off, a procurement team has justification to buy. The threshold isn’t just a scientific milestone. More often, it’s the later point where the people downstream of your technology can actually act on it.
That changes everything about how you should run the company.
Two different games
In a conventional startup, multiple teams could probably solve the same problem. What separates winners is speed, differentiation, and go-to-market execution. The MVP is the smallest version of the product that already delivers value.
Deep tech is a different game. Feasibility is genuinely uncertain. A working prototype or a strong benchmark result might show real progress and still not meet the feasibility threshold for a product. The question isn’t “what’s the smallest useful thing we can ship?” It’s “are we actually getting close to the minimum level of capability that makes this real?”
So product work in deep tech can’t be organized primarily around shipping features. It has to be organized around evidence. And that distinction matters more than it sounds, because progress in deep tech can be deceptive. Experiments run, benchmarks improve, demos get more compelling. That can all look like momentum without actually being convergence. The team is moving, but it isn’t clear it is going to reach its destination.
Product management exists to make that distinction.
What product actually means when feasibility is unsettled
If you don’t know whether the thing will work, product management exists to answer three questions:
Are we making real progress toward the threshold that matters? Is the pattern of improvement consistent with eventually getting there? And if we do get there, is the value large enough to justify the journey?
That third question, the product-market fit question, is still critical. Arguably it’s the most important commercial question of all. But it only has operational meaning if the first two questions have a credible answer. PMF doesn’t become irrelevant in deep tech; it becomes conditional. A compelling market story doesn’t rescue a product that may never exist. But a technically credible path without a clear value endpoint is equally stranded.
This is where a lot of deep-tech teams get into trouble. They generate output continuously: experiments, pilot results, demos, benchmark gains. None of that is sufficient on its own. The real job is distinguishing output from evidence. Is the progress informative? Does it scale? Is it converging on something that actually matters?
What MVP means in this context
The MVP concept still applies in deep tech, but the definition shifts. It’s not the smallest usable version of the finished product. It’s the earliest point at which the path to a viable product becomes legible, technically and commercially. And that requires two things in equal measure.
First, the technical trajectory has to be coherent. Improvement can’t look random or localized. It has to suggest that more data, more engineering effort, or better methods will systematically close the remaining gap. Not just that things are getting better, but that the pattern of improvement points at the right destination.
Second, you need a signal from the world. The system may still be below the threshold for real deployment, but the relevant stakeholders need to be able to see what crossing that threshold would unlock, and start behaving accordingly. That might mean a partner is willing to share data, co-develop, allocate budget, or support a validation study. The question is: at what point does partial progress start changing what other people do? That behavioral shift is the value probe. Without it, technical progress is necessary but not sufficient.
A concrete example: suppose your model needs 85% balanced accuracy before it can support clinical decisions. Early versions hit 60%, then 65%, then 70% as you scale up training data. Seventy percent isn’t enough. It doesn’t unlock the value. But the trajectory still matters if the pattern of model improvement suggests it will reach 85% balanced accuracy, and if clinical stakeholders treat 85% as meaningful enough to invest in closing the gap. At that point, you might have reached an MVP in the deep-tech sense. Not a finished product, but a legible path with both components present: a coherent technical trajectory and a real signal from the people who would use it.
AI makes this even more important
AI is genuinely useful here. It compresses experimental cycles, surfaces patterns earlier, and reduces the cost of testing hypotheses. But it doesn’t remove threshold dynamics. If anything, it makes them more challenging to reason about and determine you’re actually making progress, because it dramatically increases the volume of things you can produce and test. More models, more experiments, more demos. That can look like momentum without actually being convergence.
Faster iteration doesn’t mean you’re getting closer to the threshold that matters. But it does impact the dynamics of developing products in deep-tech companies, and I plan to elaborate on it in a separate note
The so what
In deep tech, value might not exist until a threshold is crossed. But knowing whether you’re moving toward that threshold is work you can do right now. So is understanding what value would actually unlock if you got there, and for whom.
That’s what product management is for in this context: separating real progress from motion. It’s harder than prioritizing features or optimizing growth. And it’s the difference between companies that eventually matter and those that disappear without ever knowing how close they were.
