JR

Innovation Reactor

An engine for turning knowledge into value

A four to six month programme that puts researchers, companies and decision-makers to work together on real problems, until those problems stop being a hunch and become something you can build.

It is a programme of my own design: I design it, coordinate it and teach it in every edition. Academic direction always sits with the host university.

Try the chain of seven agents that walks through the method ↓


What a Reactor is

A Reactor is not a doctoral programme, nor a consultancy, nor an incubator. But it has elements of all three. It is a temporary device installed inside an organisation to do something that organisation, on its own, almost never manages: to take a hunch as far as the point where somebody can decide about it.

Most organisations that do research have the same difficulties. They produce knowledge efficiently (papers, patents, theses, reports) and then wait for that knowledge to turn into impact by itself. It doesn't. Doing research and developing technology does not guarantee innovation: R&D produces knowledge; innovating is what turns that knowledge into value. They are two different processes, with different logics, and almost nobody organises the second one.

The Reactor organises the second one. For a few months it brings together a small group of people with deliberately different profiles, gives them a method, a problem and a rhythm, and puts them under useful pressure: having to prove, over and over, that what they are doing matters.

The starting point

The Reactor starts from an uncomfortable and very productive premise: you don't start with an idea, you start with a hunch.

This inverts the usual order. Almost every innovation programme asks for a brilliant idea and then looks for someone to sell it to. The Reactor does the opposite: it starts from an imperfect hunch about a problem and spends the effort on understanding that problem until it becomes manageable. It is what I call reverse entrepreneurship: the problem first, the solution afterwards, if it ever arrives.

The practical consequence is that the first thing you prototype is not the solution: it is the problem. A problem is workable when it meets three conditions: that it is solvable, that it is recognisable (you can describe what would make the solution possible) and that it is verifiable, that is, that there is some way of knowing whether it has really been solved. A problem that doesn't meet all three is not a problem: it is a complaint.

How the work runs

Four modules, teams of three to five people from different disciplines and an assessment at the end of each one. Between sessions, fieldwork and mentoring.

  1. The problem and the hunchesYou start from a hunch and put it through the structure of a problem. The team goes out to talk to experts made available to them (through the programme or by their own means), to front-line operators and to the people affected, not to confirm their hypothesis but to try to destroy it. What they are listening for is "you are wrong", and why.
  2. Parts and scaleThis is the least intuitive logic in the method: bringing the scale of the problem down until it fits the resources you already have. And building with existing parts (technologies, data, knowledge, capabilities) reused and re-proposed for something else. Innovating is not necessarily expensive; it almost never starts out that way.
  3. The opportunity spaceWith the problem now manageable, you mark out where there is real opportunity to create value and you manage the risks that come with it. It is not about choosing the best idea, but about turning an idea into something a decision can be taken on: carry on, vary it, scale it up, invest or stop.
  4. Final report and scaling logicEach team hands in the problem reframed with what they have learnt, the inventory of what is still unresolved and the logic of how it grows. It is a document you can pass to somebody else and that somebody else can pick up.

What makes it different

The panel that tries to knock it down

A panel that assesses every milestone with an explicit mandate: find out why this is not going to work. It is not a friendly tribunal but a mechanism that stops a team spending six months on an elegant solution to a problem nobody feels.

The problem gets prototyped

Before building anything you have to make the problem tangible: simulate it, mock it up or define how you would know it had been solved. That is what separates this method from an ideation workshop.

Deliberately uncomfortable teams

A core team of 10 to 25 people, organised into working groups of three to five, from disciplines that don't usually meet. Whoever generates ideas is rarely the person who scales them, and neither of them is the expert who knows how to discard them. The method needs all three profiles at the same table.

Expert mentoring in research and knowledge transfer

Researchers from the organisation itself and players from the ecosystem work alongside the teams. Knowledge doesn't come in from outside to explain: the knowledge already inside is activated and connected to what is missing.

Seven in-house AI agents and a specific mapping of resources

A chain of assistants designed specifically for the method, which accompanies the teams between sessions. It doesn't replace the fieldwork: it puts it in order and subjects it to criticism.

It leaves capability behind

When it finishes, the organisation isn't left with a report: it is left with a group of people who have done the whole route and know how to repeat it. That is the result being sought.

What comes out of a Reactor

The third edition at the Universidad Pública de Navarra closed in June 2026 with four proposals, all of them born from a hunch and taken to the point where a decision could be made about them.

The four proposals and the closing ceremony, in the Universidad Pública de Navarra press release.

Tool

Seven agents that walk through the method with you

A chain of assistants built on the Reactor method. Each one receives only what it needs from the previous one, and you can refine and regenerate any stage. It doesn't replace the fieldwork or the sessions: it puts in order what you bring and subjects it to criticism.

01ProblemPuts the hunch through the structure of a problem: solvable, recognisable and verifiable.
02PartsTakes stock of which existing technologies, data and capabilities can be reused and re-proposed.
03PeopleWho knows, who operates and who suffers it. How to find them and what to ask them so that they prove you wrong.
04ScaleCuts the problem down until it fits the available resources without ceasing to be the same problem.
05ImpactWhat changes if this works, for whom, and with what metric you check it.
06CriticLooks for why this is not going to work. It is the assessment panel in assistant form.
07OrchestratorIntegrates the previous outputs into a kit somebody else can carry on with.
Try the chain of agents

Write a complex problem or a hunch. Don't think about solutions yet. Answers are recorded anonymously to improve the tool.

Innovation Reactor

Problem → Parts → People → Scale → Impact → Critic → Orchestrator

Who it works for

Where it has been deployed

And in design with other universities and industrial corporations.

Every deployment is adapted to the problem and to the organisation, but the structure (four modules, mixed teams, milestone assessment and a scalable deliverable) stays the same.

How it is commissioned

The Reactor is not sold by the hour or by the deliverable: it is commissioned by edition. What changes from one deployment to the next is not the method — four modules, mixed teams, milestone assessment and a scalable deliverable — but the way it fits inside the organisation.

What shape it takes

What your organisation puts in

How it is closed

The scope and the terms are set in a prior conversation, starting from the problem, the number of teams and the depth of the support between sessions. Each edition is quoted on that basis.

Let's talk about a Reactor in your organisation