Recently, in a LinkedIn post of mine on the composition of innovation ecosystems, Bror Salmelin made a comment that I have kept turning over since. “Just look at OI2 and Living Labs combined,” he wrote. Bror is one of the people who actually shaped how the European Commission has thought about open innovation and Living Labs for the past two decades, and he was a guest at a research event on open innovation I organized in Uppsala back in 2012. So when he points in a direction, I tend to look. He was, as usual, right — but in a way that took me a few days to articulate properly. So here it goes.
For most of my consulting life I have talked about innovation as if it moves in phases. Discover. Develop. Validate. Build. Launch. Five phases, more or less, depending on which framework you happen to be holding that day. Every methodology I have produced — and at this point I have produced a few — treats the phase as the operational unit. That is where projects get stuck, we say. That is where the death valley sits. We then design interventions at the phase level. A fund for the death valley. A validation lab for the validation phase. A growth program for the growth phase. Tidy.
The trouble is that almost nothing actually gets stuck at the phase level. Projects get stuck several layers deeper, inside the phase, at a specific point where the kind of resource the team needs has shifted from what was needed five minutes ago.
I should have known this. In my Living Labs years in the late 2000s, when I led the Airport Living Lab and we were inside ENoLL, the whole methodology was built on this insight, even if we did not always call it that. Early in a project you needed users who could articulate latent needs you had not thought to ask about. In the middle you needed users with the patience to live with a half-working prototype for weeks. Toward the end you needed users who could carry the solution into other parts of their organization through their own networks. Three quite different kinds of user involvement, all sitting under the same label, and you got nowhere if you confused which one you needed when. Somewhere between 2012 and writing maturity models for clients a decade later, I let that insight quietly slip away. The phase model is so tidy that it is easy to forget the phase is not where the work actually happens.
What the catalog has shown me, and what Living Labs methodology had figured out long before any of us was talking about innovation ecosystems, is that the kind of resource a project needs rotates within every single phase. Early in a phase, the dominant need is strategic knowledge — frameworks, foresight, problem framing. In the middle, the need shifts to relations — access to users, to industry partners, to pilot customers, to specific competencies nobody on the team has. Toward the end, the need shifts again, this time toward decision authority and capital. Three quite different resource types, in a fairly predictable sequence, inside every phase. The names change as the project matures. The rotation does not.
Once you start looking for it, you see where projects actually get stuck.
It is almost never at the phase boundary. It is at the rotation point inside the phase. A team strong on strategic knowledge but thin on user relations will fly through the first half of validation and grind to a halt the moment they need actual customers in the room. A team well connected to customers but allergic to escalating decisions will reach the gate at the end of the phase and stall there for three quarters waiting for someone to either approve or kill the project. Both teams will be reported as “stuck in validation”. They are not stuck in validation. They are stuck at two completely different points within validation, and they need two completely different things to get unstuck. This is also, more or less, what the valley of death turns out to be. It is not a phase. It is a rotation point — the moment in validation where a project pivots from needing strategic knowledge to needing access to real customers and real testing environments. Teams that have spent a year sharpening a concept arrive at that rotation, look around, and find that the ecosystem has plenty of foresight consultants and plenty of growth-stage capital, with not much in between. The valley is not a failure of the phase. It is a failure of the rotation, repeated thousands of times.
Bror was making, I think, a deeper version of this point. Living Labs and open innovation taught us, fifteen years ago, that you do not design for a phase. You design for the sequence of engagements inside it. Innovation ecosystem management is now slowly catching up to that, except it is being framed as a new discovery rather than as the application of something a generation of researchers and practitioners has already done the hard thinking on. We have an opportunity to skip a few of the obvious mistakes if we go back and read what they wrote. I am still working through what this means for the framework. The shortest version is that the orchestrator’s job is considerably harder than the phase model suggested. You cannot fix a phase. You can only design the rotation inside it, substep by substep, and watch where it breaks. Which, on reflection, is what the better regional ecosystems have been doing all along — without quite naming it that way. The rest of us have been busy funding phase-level instruments and wondering why the projects keep getting stuck.
Tidy frameworks are seductive that way.
Second in a series drawing on the Innovation Ecosystem Architecture framework, the conceptual base of a book in progress. The first post — on why I have been wrong about innovation ecosystems for twenty years — is on this blog.
Be the first to comment