What an innovation lab is, and why most fail

An innovation lab is a small, protected team with a mandate to take messy problems the organisation cannot solve through business as usual, test new answers cheaply, and hand the ones that work back to the people who will run them. It is a way of working, not a room. Most labs fail for the same few reasons: they have no clear owner for what they produce, they measure activity instead of decisions, and they never plan the handover back to operations.

This guide maps the whole topic: what a lab is and is not, the main types, what a lab actually does week to week, why so many close, and how to build one that lasts. Each section links to a deeper article in this hub.

What an innovation lab is, and what it is not

Strip away the beanbags and the glass walls and a working lab has five parts:

1. A mandate. A written statement of which problems the lab may work on, who sponsors it and what decisions it can take without asking.
2. A small core team. Usually three to eight people who know research, facilitation, prototyping and enough about the business to be credible.
3. A method. A shared, repeatable way to move from a problem to a tested answer: frame the challenge, learn from the people affected, generate options, test the riskiest assumption, decide.
4. A pipeline of challenges. Real problems brought by real owners, chosen deliberately rather than by whoever shouts loudest.
5. A route back to operations. An agreed way for a tested idea to become someone's budget line and job description.

What a lab is not:

• Not a building. A room helps, but it is the last thing you need. Many effective labs started in a borrowed meeting room. We cover this in An innovation lab without a building.
• Not an ideas department. If the lab is where ideas go to be "looked at", the rest of the organisation stops thinking.
• Not an R&D unit. R&D generates new technical knowledge. A lab mostly recombines what exists into new services, processes and policies, and tests whether people will use them.
• Not a showroom. If the lab's main output is visits from delegations, it is a communications asset, and it will be judged and cut as one.

The four kinds of lab you will meet

Labs differ mainly in who they serve and what they are expected to produce. Knowing which kind you are building settles many later arguments.

Public sector labs have the longest track record. Denmark's MindLab, often described as one of the first government innovation labs, was founded in 2002 under the Ministry of Economic and Business Affairs, later became cross-ministerial, and closed on 1 May 2018 when the government replaced it with a smaller Disruption Task Force focused on digital transformation. The UK Cabinet Office opened Policy Lab in 2014 to bring design methods into policy making. The lesson from both is the same: a lab's survival depends less on the quality of its work than on whether its sponsors still see it as the answer to their current problem.

If you are building a lab inside a ministry or authority, read How to set up an innovation lab in a government entity. If you are unsure whether you need a lab at all, or a centre of excellence or innovation unit instead, see Innovation lab vs centre of excellence vs innovation unit.

What a lab actually does, week to week

People imagine labs as places of constant ideation. In practice, the work is mostly framing, research and testing. A healthy rhythm looks like this:

1. Intake. A problem owner brings a challenge. The lab tests whether it is a real, important, unsolved problem with someone willing to own the answer. Many requests are rejected or redirected here, and that is healthy. How to choose your lab's first challenges goes deep on this.
2. Framing. The team rewrites the request as a challenge worth solving, often as a how might we question, and maps who is affected with a stakeholder map.
3. Learning. Interviews, observation and data review with the people who live the problem. This is the step most often skipped and the one that most often changes the answer.
4. Options. Generating several possible responses, not one favoured solution.
5. Testing. Surfacing the riskiest beliefs with assumption mapping and running a cheap hypothesis test before anyone builds anything.
6. Decision. Continue, change or stop, taken by the problem owner with evidence in front of them.
7. Handover. The tested answer moves to the team that will run it, with the people, budget and knowledge it needs. See From lab to operations.

A lab running well might have three to six challenges in flight at once, at different stages, plus a steady line of smaller coaching requests. Labs whose team members sit in different cities or work hybrid can run this same rhythm; Running innovation with distributed and hybrid teams covers how.

Why most innovation labs fail

There is no reliable global statistic on lab survival, and you should be suspicious of anyone who quotes one. What practitioners and published case studies agree on is a set of recurring patterns. The detailed version is in 5 reasons innovation labs get closed in year two. In short:

• The sponsor leaves. The lab was one leader's idea. When that leader moves on, nobody else feels it is theirs.
• Nobody owns the output. The lab produces tested concepts, but no department is obliged to adopt them. Good work piles up unused.
• Activity is mistaken for value. Reports count workshops held, ideas generated and visitors received. When budgets tighten, none of these numbers explain why the lab should exist.
• The lab drifts from real problems. Challenges are chosen because they are interesting or photogenic, not because they matter to the people who fund the lab.
• The handover is never designed. A pilot succeeds, then sits in limbo because no one budgeted for scaling it.

Notice that none of these is about creativity or method. Labs rarely die because their ideas are poor. They die because the organisation around them was never set up to receive what they make.

How to build a lab that lasts

The practices below come from what tends to separate labs that are still running after five years from those that are not.

1. Write the mandate before you hire. One page: which problems, which sponsor, what decision rights, what the lab will not do.
2. Have two sponsors, not one. A senior executive for authority and an operational leader for adoption. If one leaves, the other carries the lab.
3. Choose challenges with owners. Never take a challenge without a named person who will decide on the result and run it if it works.
4. Report decisions, not activity. Each quarter, list the decisions taken because of the lab's work: services changed, projects stopped, money saved or redirected. Use portfolio mapping to show the balance of work across stages.
5. Plan the handover at intake. Ask on day one who will run this if it works and what they will need. Use a rollout checklist so nothing is improvised at the end.
6. Build capability as you go. Bring staff from the problem owner's team into every challenge. Over time, they become your strongest advocates and the lab stops being a black box.
7. Keep the room modest. Spend first on people and testing budget. If the physical space later earns its keep, expand it. Some work genuinely benefits from canvases printed and pinned to a wall, as Printed and physical: when the canvas belongs on the wall explains, but that does not need a showpiece building.

Do's and don'ts

Do

• Agree in writing what the lab is for and what success looks like after one year.
• Reject or redirect challenges that have no owner or no real stakes.
• Show stopped projects as wins: a cheap "no" saves the organisation money.
• Keep the core team small and borrow specialists per challenge.
• Make every result traceable: who brought the problem, who contributed, what was decided.

Don't

• Open with a launch event and a branded room before the first challenge is chosen.
• Measure the lab by number of ideas or workshops.
• Let the lab become the place other departments send problems they want to avoid.
• Run pilots with no agreed path to budget and operations.
• Treat the lab as permanent by right. Earn renewal every year with evidence.

An illustrative example

Illustrative: an invented organisation, described to show the pattern.

A regional water utility in northern Europe set up a lab after a run of customer complaints about billing. The chief executive sponsored it; the head of customer operations was named co-sponsor from the start. The lab had four people and a borrowed meeting room.

Its first challenge was not "innovate billing" but a narrower question from the operations head: how might we cut the number of customers who call twice about the same bill? The team spent two weeks listening to calls and visiting customers at home. They found the main cause was a confusing estimated-reading notice, not the bill itself.

They tested three rewritten notices with a few hundred customers before changing any system. One version clearly reduced repeat calls in the test group. Because the operations head owned the challenge from the start, the new notice went into the standard process within the quarter, with her team running it.

The lab's first quarterly report listed one decision taken, one process changed and two ideas stopped after testing. That report, not the room, is why its budget was renewed.

Questions people ask

What is the difference between an innovation lab and an R&D department? R&D creates new technical knowledge, often over years. An innovation lab mostly works with what already exists, recombining it into new services, processes or policies, and tests quickly whether people will use them. Many organisations need both, but they should not be confused.

How many people does an innovation lab need? A core of three to eight is common. What matters more is that the core can research, facilitate, prototype and speak the language of the business, and that it borrows specialists and staff from problem-owning teams for each challenge.

How long before an innovation lab shows results? Expect the first decisions from tested work within three to six months if challenges are well chosen. Larger outcomes, such as a redesigned service running at scale, usually take a year or more because they depend on the handover to operations.

Where to go next

Start with the methods that matter most in a lab's first months: how might we to frame challenges, assumption mapping to find what could sink an idea, hypothesis test to check it cheaply, and a rollout checklist for the handover. Every article in this hub goes deeper on one part of the picture: setting up a lab in government, labs without a building, why labs close, lab vs centre of excellence vs innovation unit, lab to operations, choosing challenges, distributed teams and printed canvases. All 75 method guides are at tiremesu.com/guides.