The round closes on the demo. The company dies on the second product.
I have watched this happen enough times, from enough seats, that I no longer think of it as bad luck. A team spends four or six or nine years getting a genuinely hard technical result to work. They raise on the strength of it — correctly, because the result is real and rare. And then, somewhere between the first paying pilot and the fiftieth unit, the company stops making progress in a way that nobody can quite point at. Revenue does not compound. The roadmap grows. Hiring accelerates and output does not. Eighteen months later the story is that the market was early.
The market was usually not early. What happened was that the company crossed from a domain where the founders were the best people in the world at the problem into one where they were beginners, and nobody told them the domain had changed.
This is not the valley of death
The phrase “valley of death” already exists in deep tech, and it means something else: the funding gap between a grant-supported research result and a venture-fundable company. That gap is real, it is about capital, and a lot of thoughtful people work on it.
The valley I mean sits later and is not about capital at all. It opens after the company is funded, sometimes well funded. It is the distance between a thing that works and a thing that ships repeatedly, at a cost someone will pay, to buyers who will keep paying. Money does not close it. I have seen companies raise straight through it twice and arrive at the far side smaller than when they started.
It is an operating problem. Which means it is made of decisions, and the decisions are more legible than they look.
Four of them account for most of what I have seen go wrong.
One — what you build second
The first product in a deep-tech company is usually not chosen. It is whatever the technology could do first, aimed at whoever was willing to try it. That is fine. Nobody has enough information at that stage for the choice to be better than that.
The second product is chosen, and it is the most consequential decision the company will make in its first five years.
The instinct is almost always to widen. The first product worked in one setting, the technology clearly generalizes, and the pitch that raised the round described a platform. So the second product serves a second market, or exposes the capability as something more general, or becomes an SDK. This feels like leverage. It is the single most reliable way I know to enter the valley and not come out.
Widening costs more than it looks like it costs. Two markets means two sets of requirements, two support burdens, two qualification cycles, two sales motions, two versions of the truth in every roadmap meeting — carried by an engineering team that was sized for one. The technology does generalize. The company does not.
The second product should narrow. It should go deeper into the wedge that produced the first paying customer: the adjacent workflow, the missing piece those same buyers had to build themselves, the thing that turns a compelling component into something a procurement department can approve. Boring, and it compounds. Every unit of engineering spent there makes the first product harder to displace and the next sale shorter.
At Ixia the business unit I ran more than doubled revenue, and very little of that came from new categories. It came from going deeper with buyers who had already said yes — plus acquisitions to fill gaps we had decided not to build. Which is the other half of this decision: narrowing does not mean never adding capability. It means being honest that the fastest path to a capability is often to buy it, and that the decision to build it yourself is a decision to spend eighteen months.
The test I would apply: if the second product succeeds wildly, does it make the first product more defensible, or does it create a second company inside the first one?
Two — who the first ten customers actually are
Every deep-tech company has early adopters who are a pleasure to work with, technically sophisticated, genuinely excited, and completely unrepresentative of the market.
They are usually a research group, an innovation team, a skunkworks, or a single unusually motivated engineer with a discretionary budget. They will give you extraordinary feedback. They will co-develop with you. They will say yes quickly, which after years of no is intoxicating. And a meaningful number of them are structurally incapable of ever becoming a real customer, because the budget they are spending is not the budget that would buy this at scale, and the person spending it does not have to justify a repeat purchase.
The failure mode is not that these customers are bad. It is that the company reads them as a market and builds the second product for them. You end up with a product exquisitely tuned to buyers who will never place a second order, and a two-year track record that a sceptical enterprise buyer discounts entirely.
The question I would ask about each of the first ten is narrow and unromantic: when this contract renews, who signs it, and what happens to them if it fails? If the answer is “the same enthusiast, and not much,” that is a design partner. Valuable, but not evidence. If the answer names an operating budget and a person with something at stake, that is a customer, and their requirements should outrank everyone else’s.
A company should know, explicitly, which of its logos are which. Most cannot tell you.
Three — when you hire commercially
Founder-led sales works far longer in deep tech than in software, because in the early market the buyer wants to talk to the person who invented the thing, and no salesperson can substitute for that. This is true, and it becomes a trap, because it means the ceiling arrives silently.
Hire too early and you get a competent commercial leader trying to sell a product whose value proposition has not stabilized, into a market that does not have a name yet. They will fail, and the failure will read as a hiring mistake rather than a timing mistake, and the company will conclude it needs a different profile. It does not. It needed six more months.
Hire too late and something worse happens. The founder’s own network gets exhausted, but slowly enough that nobody notices — pipeline just gradually gets harder to fill. Because the founder is still closing deals, the dashboard looks fine. By the time it is obvious, the company needs a commercial organization immediately, which is exactly when hiring one is hardest and most expensive.
The signal I trust is not revenue. It is repeatability: can someone who is not a founder run the same conversation and reach the same outcome? Once two or three deals have closed where the technical explanation was the same each time and the objections rhymed, the motion is teachable and you should hire. Before that, you are asking someone to sell something that has not been characterized yet.
And when you hire, hire for the buyer you have, not the buyer you want. A brilliant enterprise software seller will drown in a procurement cycle that runs through a plant manager, a safety officer, and a capital budget committee.
Four — how much you raise, and against what
The last decision is the one founders most often get advice on and most often get wrong, because the advice optimizes for the wrong variable.
Rounds are usually raised against time: how much do we need for eighteen or twenty-four months. That framing is comfortable and nearly meaningless, because it treats the next round as the goal. The better framing is to raise against the next thing that stops being a question. What is the single largest uncertainty in this company right now — is it that the process yields at volume, that the second customer segment exists, that the unit cost curve bends? Fund the elimination of that, plus enough margin to be wrong once.
This matters more in deep tech than elsewhere because the uncertainties are sequential and expensive. You cannot de-risk manufacturing and go-to-market simultaneously on the same money. Trying to is how a company arrives at its next round having spent a great deal and resolved nothing cleanly.
The related error is over-raising. A large round is not free optionality; it sets a price, and the price sets the bar for everything after it. I have watched more than one good company become unfundable not because it stopped executing but because it raised at a number its realistic outcome could no longer justify, and then had to spend two years growing into a valuation instead of building. If the round is larger than the milestone requires, the excess is not a cushion. It is a constraint you have agreed to in advance.
None of this is an argument for raising less. It is an argument for knowing what the money is buying.
What the ones that made it had in common
Not brilliance — the ones that failed were brilliant too. Three things, consistently:
They knew what they were, at any moment. Whether the company was still characterizing a technology or had begun manufacturing a product. These require different organizations, different metrics, and different people, and the transition is a decision rather than a drift. The companies that struggled were usually running a research organization while telling investors they were running a product company.
They wrote things down. Not decks — documents. The strategy, the segment, the reasons for the second product, the assumptions underneath the model. A document can be argued with and can be found to be wrong. A deck cannot, which is why it is more comfortable and less useful.
They said no publicly. To customers who were not the segment, to features that widened, to acquirers who were early, to money on the wrong terms. Every no cost something visible and saved something invisible, and the founders who made a habit of it had more room than the ones who did not.
The valley is not mysterious and it is not about the science. It is four or five decisions, made in a period when the company is least equipped to make them, by people who have never made them before. That is a knowable problem — which is the entire reason this practice exists.
If any of this is the decision in front of you right now, I would rather talk about your specifics than have you extrapolate from mine.