There is a conversation I have been having with experienced innovation leaders for about as long as I have been in this profession. It usually starts with someone observing that the valley of death is still where most of their projects die. We then agree, more or less in unison, that the various funds and programs designed to bridge it have not really moved the needle. And then we proceed to discuss the matter as if “the valley of death” were a single phenomenon.
I no longer think it is.
This has crept up on me over the last year, as part of the research that underpins the framework I am currently developing — an Innovation Ecosystem Architecture, which will form the conceptual base of the book I am writing. The work involves cataloging the operational supply in innovation ecosystems in some detail: I have so far grouped roughly 570 services, programs, and methods into a typed catalog, and as the typing has progressed something interesting has separated out in the data. The cluster of activities labeled “death valley support” is not one cluster. It is at least three, each addressing a different breakdown, each requiring a different orchestrator response, and each currently mis-served by the funding instruments we tend to throw at “the death valley” generically.
If you have been around the field long enough to have personally co-authored a few “death valley fund” recommendations, as I have, the typology may feel familiar before I name it. Naming it, I think, is most of the work. So here it goes.
The first one is what I am calling the research-to-market valley. It is the valley that deep-tech and life science projects fall into when the underlying research is sound but the commercialization route is still unclear. Nobody quite knows who the first customer is supposed to be, what the regulatory path looks like in operational detail, or how the science translates into a clinical or industrial deployment that someone is willing to pay for. The orchestrator instruments that work here are not funds. They are technology transfer offices that actually function, co-development contracts with anchor customers, regulatory navigation services, and patient pilot programs with institutions that can absorb early risk. A generic fund applied here pays for the wrong thing.
The second one is the pre-revenue valley. It is the valley that startups fall into between completing initial validation and being able to credibly raise Series A. They have shown that customers want what they are building. They have not yet shown that customers will pay enough, often enough, and with enough velocity for a venture investor to underwrite. The instruments that work here are bridge financing, convertible structures, and validation-stage capital provided by investors who understand that the evidence for Series A is, almost by definition, evidence that does not yet exist. A generic death valley fund tends to either pay too early on terms that protect nobody, or too late after the team has already given up.
The third one is a bit different; it is what I am calling the B2B cycle-mismatch valley. It is the valley that hits founders who are selling to large enterprise organizations. They have done their Lean Startup correctly. They have run their hypothesis tests at startup velocity. And then they collide with the eighteen-month procurement cycles, security reviews, and steering committees of the customers they thought they had validated against. The instruments that work here have almost nothing in common with the previous two. They are enterprise pilot programs run with budget separation from the main procurement process, patient capital that understands the calendar, and anchor customer relationships that someone has spent years building. A generic death valley fund here is, to put it carefully, mostly useless.
I keep going back to the same point. Each of these three breakdowns is real, and each one is well known in the parts of the field where it predominates. What is curious is that we have continued, in policy documents and program designs and consulting decks alike, to treat them as variants of a single condition. Once you separate them out — and the catalog of operational supply makes the separation almost impossible to avoid — the implications for orchestrator design become uncomfortable. Three different problems require three different instruments.
To be honest, my view of these three valleys comes from more than one side of the table, and that is part of why I now think the distinction matters as much as it does. I have walked into the valley as an entrepreneur in projects of my own — most painfully the classic case, where a project with real potential ran out of development capital in exactly the textbook way. I have looked at the same phenomenon from the evaluator’s side, assessing innovation applications at Stockholm Municipality, at CSC, and as a Vinnova reviewer during my time at RISE. I have, on a few occasions, helped fund crossings of the valley myself. And I have studied the matter academically as part of my research on innovation ecosystems. Each vantage shows something the others miss. What I am proposing — that we are looking at three different problems, not one — and I am willing to commit to it now. From whichever side I have looked, the generic death valley fund has performed about as you would expect from a hammer applied to three different problems.
The deeper move the Innovation Ecosystem Architecture framework now needs to make is to name these three breakdowns as separate substeps in the architecture itself, rather than letting them sit invisibly inside a single “validation phase”. I am working on that as the framework develops. Whether it ends up as three distinct substeps or as a single substep with a typological overlay is still open. The naming is the easy part. Working out where, in each of the three, the orchestrator’s leverage actually sits — that takes longer.
For now, the smallest useful next move is to stop pretending we are talking about one thing. Three different problems. Three different instruments. One conversation we should probably start having differently.
Third in a series drawing on the Innovation Ecosystem Architecture framework, a conceptual base of a book in progress. Earlier posts on the composition of innovation ecosystems and on where projects actually stall are on this blog.
Be the first to comment