Building Innovation Labs

A company's innovation center opening usually goes the same way: colorful walls, whiteboards, a hackathon, a press release. A year later the center runs three pilots, and nobody is authorized to move even one into the core business. The lab exists. The output does not.

Google X and Amazon's Lab126 are attractive examples because the outputs are impressive. Waymo came out of Google X, and Lab126 is where products like the Kindle and the Echo were developed. But it is worth remembering that the same Lab126 also built the Fire Phone. Working in isolation does not guarantee success; it only permits trying. This piece is about how to turn that permission into a result.

When you need it

Your core business has become a structure that grows at its own pace but cannot try anything new. Every new idea collides with current revenue targets and processes and gets the answer “not now.” Competitors or new entrants are testing a method that could erode your core, and nobody on your side is positioned to test it.

It is too early if your main product is still searching for product-market fit; in that case your lab is your core business. Also, if the budget you would set aside is large enough to slow the core's growth and there is no clear thesis, this is not an innovation investment but a luxury.

What most teams miss

The lab idea usually rests on two things: freedom and isolation. True, the speed of the core business can smother a new idea. But isolation alone is not the solution; it creates a new problem. The further the lab drifts, the harder it is to return to the core.

A common pattern in failing labs goes like this. The team builds a beautiful prototype. The head of the relevant business unit treats it as a side project. Sales is not rewarded for selling it. Operations builds no process to support it. The product works technically and is an orphan organizationally.

A lab's success is not measured by how much innovation it produces, but by how much of what it produces enters the company's core business.

So the most important question in lab design is not “what will they discover?” but “who will take over what they discover, and under what conditions?” Any structure that does not answer this up front turns into expensive R&D theater.

The second point: a lab does not have to be a building or a department. In a mid-sized company it can be a team of three or four with a defined budget and a defined mandate. The authority definition matters, not the architecture.

The playbook

1. Set a thesis and a boundary

“We will do innovation” is not a thesis. A thesis sounds like this: “Over the next five years our customers may take this job from us to somewhere else; to test that, we will try these three hypotheses.” Limit the scope to two or three themes. A lab without boundaries chases everything that looks interesting and finishes nothing.

2. Clarify mandate, budget and sponsor

The lab needs a senior executive sponsor, someone who decides at the points where the lab clashes with the business units. Give the budget as a fixed annual box rather than per project; rebudgeting every project eats time. But release the box in stages: the next tranche depends on the previous one reaching its learning goal.

3. Set stage gates and kill criteria

Every idea passes through gates written in advance: is the problem validated, is a customer ready to pay for this, is the technical risk manageable, do the economics work at scale? The question at each gate should be “do we continue?”, and the criteria should be written before anyone is emotionally attached to the project. Celebrate killing an idea as a success, because an idea that dies early frees resources for the next one.

4. Build the link to the core

On every project, someone from the receiving business unit should be on board from day one: coming to the weekly demo, judging the prototype. If that person does not like the project, a later handover will not work, and learning that early is good news. Write the handover terms up front too: at what revenue threshold the project moves into a business unit, how the team splits, whose P&L it lands in.

5. Share what you learn

Failed projects also produce something: learning. Write a one-page note at every closure: what was the hypothesis, what did we learn, which knowledge now belongs to the company. These notes are the only evidence that earns the business units' trust in the lab.

What to measure

• Learning velocity per stage (leading): the time for a hypothesis to be tested and decided. If the lab slows down, it is turning into theater.
• Handover rate (lagging): the share of projects that leave the lab and move into a business unit. This is the real output.
• Business unit involvement (leading): the number of receiving sponsors who attend demos and are ready to take over.
• Number of closed projects and their average age (leading): if no project ever closes, that is a warning; the criteria are missing or not enforced.

Pitfalls

The showcase lab. A structure visible outside and disconnected inside is a branding exercise, not innovation. The yardstick is revenue entering the core.

Loading all the risk onto the lab. If the core's leaders say “that's the lab's job” and walk away from responsibility for renewal, nothing the lab does will be adopted.

Funding without criteria. A project with a budget and no kill criteria becomes a fixed cost of its own and lives for years.

Pulling the core's best people. Good labs attract talent but must not hollow out the core. Work with rotation: people from the core spend a stint in the lab and return, so knowledge flows both ways.

Start this week

1. List the ideas your company shelved in the last three years with “interesting, but not now,” and mark which of them rest on a real customer problem.
2. Sit with a senior executive for twenty minutes and ask one question: “On what topic could you give decision authority to a small team testing a new idea?”
3. For your strongest idea, write a one-page handover agreement: under what condition it continues, under what condition it closes, and who from the receiving business unit takes it over.