Ecosystem innovation: how entities solve shared problems together

Ecosystem innovation is what you do when a problem crosses the boundaries of several organisations and none of them can fix it alone. Instead of each entity improving its own slice, the parties agree one shared problem, map how it really works across them, test a joint solution, and decide in advance who will own it once it works. It is slower to start than solo innovation and much harder to govern, but for problems like a patient moving between hospitals, a shipment moving through a port or a graduate moving into a first job, it is the only approach that reaches the real cause.

This pillar maps the whole topic: how to tell whether you have an ecosystem problem, the different ways organisations work together, the steps of a joint effort, and the governance that keeps it alive. Each form of collaboration has its own deeper article, linked as we go.

What counts as an ecosystem problem

Not every problem with several stakeholders needs an ecosystem effort. Many do not. A useful test has four questions:

1. Does the user's experience break between organisations, not inside one? If the delay, error or frustration happens at a hand-off between two entities, internal fixes will move it, not remove it.
2. Does the data needed to understand the problem sit in more than one place? If no single party can see the whole journey, no single party can diagnose it.
3. Would the fix require changes from at least two organisations? A rule here, a system there, a process somewhere else.
4. Has each party already tried to fix its own part? This one matters more than it looks. Organisations rarely commit to joint work until they have hit the limit of what they can do alone.

If you answer yes to three or four, you probably have an ecosystem problem. If you answer yes to one or two, run it as an internal project and invite the others as contributors. Treating an internal problem as an ecosystem one is a common way to spend a year in coordination meetings.

Draw it before you decide. An ecosystem map shows who touches the user, who holds the data, who sets the rules and who pays. A system map goes further and shows the loops: why fixing one part makes another worse. Most groups discover on the map that the problem is owned by a gap, not by anyone.

The forms ecosystem innovation takes

"Ecosystem innovation" covers several different arrangements. They are not interchangeable. Choose by what you need from the others.

• A convened challenge. A ministry, regulator or sector body brings the players around one problem and sets the conditions for solving it. This is the most demanding form and the one with the widest reach. See How ministries and regulators convene a sector around one challenge.
• An ecosystem hackathon or jam. Several organisations co-own a time-boxed event on a shared challenge. Good for generating options quickly and for building working relationships. See The ecosystem hackathon.
• Working with startups. You bring a problem and a test environment; a startup brings a working technology and speed. See Working with startups without wasting their time or yours.
• Partnering with universities. You bring a real problem and access; the university brings research depth, students and time horizons you cannot afford internally. See Partnering with universities on innovation.
• Open innovation, co-creation and crowdsourcing. Three related ideas about how far you open the door and to whom. They are often confused; Open innovation vs co-creation vs crowdsourcing sets out which to use when.

The term "open innovation" itself comes from Henry Chesbrough, whose 2003 book argued that firms should use ideas from outside as deliberately as ideas from inside, and let unused internal ideas flow out. Ecosystem innovation goes one step further: the problem itself is shared, not just the ideas.

How a joint effort works, step by step

The forms differ, but the underlying sequence is the same. Skipping a step tends to surface later as a stall.

1. Name a convenor. Someone has to hold the pen: call meetings, keep the record, chase commitments. It is usually the party with the most to gain or the most legitimate reason to gather the others, often a public body or sector association. The convenor does not own the solution; it owns the process. In their 2011 Stanford Social Innovation Review article on "collective impact", John Kania and Mark Kramer called this the backbone organisation and listed it as one of five conditions for joint work across organisations to succeed.

2. Recruit the minimum set of owners. From the ecosystem map, pick the organisations without whom no solution can work. Three to five owners is workable. Everyone else becomes a contributor: invited, consulted, kept informed, but not holding a veto.

3. Agree one problem, written from the user's side. Bring a decision-maker from each owner to a half-day session. Build a problem tree on the shared journey, then turn it into one how might we question that names a user and a moment. If you leave with three problems, you have a portfolio, not a project; pick one and park the rest.

4. Make each party's interest explicit. Organisations join joint efforts for different reasons: a regulator wants evidence for a rule, a company wants a market, a university wants research. Hidden interests resurface as obstruction. A stakeholder expectations map puts them on the table early, where they can be accommodated.

5. Write a short agreement. Two to four pages: the problem, each party's contribution, data terms, intellectual property, decision rights, how disputes are settled and how anyone can leave. Use a RACI to show who approves, who does and who is informed. Lawyers will want more; push for a short first version and a review point.

6. Investigate together. Joint research is where trust gets built. Send mixed teams, one person from each owner, to observe the journey and interview users. The finding that "the delay is caused by our forms, not theirs" lands differently when your own colleague discovered it.

7. Pilot small, in one place, with one owner per change. Ecosystem pilots fail when everything has to change at once. Find the smallest version that tests the joint idea: one district, one product line, one cohort. Each change in the pilot has a named owner in one organisation.

8. Measure one shared outcome. Each party will have its own KPIs. Agree one outcome you all track, measured the same way, from the user's side: time to clearance, days from referral to treatment. A KPI tree can connect it to each party's own measures so nobody has to abandon theirs.

9. Decide who owns the scale before the pilot ends. This is the step most ecosystem efforts miss. A working pilot with no permanent owner quietly dies when the project team disbands. Agree in advance: if it works, who runs it, who funds it, and which rule or system changes it needs.

Governance: what keeps it alive past the first year

Joint efforts rarely fail on ideas. They fail on governance. Four arrangements make the difference.

A steering group with real decision-makers, meeting rarely. Quarterly is enough. Its job is to unblock, not to review slides. If the people around the table cannot commit their organisation, you have a consultation forum, not a steering group.

A working group that meets weekly. The people doing the work, one from each owner, with the convenor in the chair. This is where the joint effort lives day to day.

A written record of decisions. In single-owner projects, people remember. Across organisations, people rotate, and the new person was not in the room. Keep a decision log every owner can read.

A communication rhythm. Each owner reports back into its own organisation differently, and messages drift. A stakeholder communication plan agrees what goes out, when, and in whose name.

Run a premortem at the start: "It is eighteen months from now and this effort has collapsed. Why?" The answers are usually specific and political: a minister changed, a budget moved, one partner felt used. Name them early and design against them.

Do's and don'ts

Do

• Test whether it is really an ecosystem problem before convening anyone.
• Keep the number of owners small and the number of contributors generous.
• Put each party's interest in writing, including the convenor's.
• Send mixed teams into the field together.
• Agree one shared outcome measure from the user's side.
• Name the long-term owner before the pilot starts.

Don't

• Don't start with a signing ceremony. A memorandum with no work behind it sets a pattern of announcement over delivery.
• Don't let every partner add its priority to the brief. One problem per effort.
• Don't confuse the convenor with the owner. The body that gathers the group is often not the right one to run the solution.
• Don't wait for perfect data sharing. Start with what each party can open now and improve as trust grows.
• Don't measure success by the number of partners. A short list of committed owners beats a long list of logos.
• Don't let the effort live only in the project team. If no owner has changed anything inside its own organisation by month six, the effort is in trouble.

Illustrative example

Illustrative. In a mid-sized Canadian city, young people leaving the care system at eighteen were falling through gaps between housing, employment services, health and education. Each agency had its own programme for this group. None could see the whole picture.

The city's social services department took the convenor role. An ecosystem mapping session with the housing authority, the provincial employment service, a community college and two charities showed that the critical moment was the three months before the eighteenth birthday, when every agency's responsibility either started or stopped, and nobody was coordinating.

The five owners agreed one question: "How might we make sure every young person leaving care has a home, an income and a named adult before their eighteenth birthday?" Mixed teams interviewed young people and caseworkers. They found that most failures came from paperwork that could only begin after the birthday.

The pilot covered one district and twenty young people. Each agency changed one thing: housing allowed applications at seventeen and a half; the employment service let a caseworker start registration early; the college held places open. The shared measure was simple: the share of young people with all three in place on the day they turned eighteen. Before the pilot ended, the steering group agreed that the housing authority would host the coordinating role permanently, with a cost shared between three partners.

Questions people ask

What is the difference between an innovation ecosystem and ecosystem innovation? An innovation ecosystem is the set of organisations in a place or sector that create and spread innovation: companies, universities, funders, government. Ecosystem innovation is a way of working: several of those organisations solving one shared problem together. You can have a rich innovation ecosystem where nobody ever does ecosystem innovation.

Who should lead an ecosystem innovation effort? The convenor is usually the party with the most legitimate reason to gather the others, often a public body or sector association. Leading the process is not the same as owning the solution. Decide separately who will run the solution once it works.

How long does an ecosystem innovation effort take? Longer than an internal project. Expect two to three months to agree the problem and terms, three to six months to investigate and pilot, and a further period to embed. Efforts that promise results in weeks usually skip the agreement on ownership and stall later.

Where to go next

Start with an ecosystem map and a system map to test whether your problem really crosses organisations. Use a stakeholder expectations map to bring hidden interests into the open, and a RACI to agree who does what. Then go deeper into the form that fits you: convening a sector, working with startups, partnering with universities or choosing between open innovation, co-creation and crowdsourcing.