Services

Innovation strategy and management

An innovation capability that produces adopted outcomes, not innovation theater. The systems, governance, and pipeline that get new ideas past the lab and into the operating core.

Who it is for

Institutions and governments that need innovation to actually reach production, not sit in a showcase.

What you get

• An innovation operating model and governance
• Chief Design or Innovation function design, of the kind adopted as a government-wide standard
• A portfolio and pipeline that ships
• Futures-driven research and development

How it works

1. Fix what innovation is actually for here
2. Design the operating model and governance
3. Build the pipeline
4. Drive ideas through to adoption

Questions

Common questions

Every proposal we see now has AI on it. How do we tell what is real?

Ask what the system does when it fails, and ask to see it work on your data rather than on a prepared example. Real capability has boundaries the builder can describe precisely. Marketing does not. Then check the substance underneath: what is proprietary, what is a thin layer over something anyone can buy, what data they genuinely hold, and what it costs to run at your volume. I published Crucible for this, a structured adversarial review that tries to break a claim before you fund it.

Should we build an internal AI capability or partner outside every time?

Build the part that sits close to your advantage and buy the rest. If AI will touch your core product or your proprietary data, you want people inside who understand it, even a small number. If it supports a back office function, partnering is faster and cheaper and you should not be maintaining infrastructure. The failure mode I see most often is hiring one engineer with no strategy around them, then concluding from that experience that the technology does not work.

How do we run a pilot that actually tells us something instead of a demo that impresses nobody?

Decide in advance what result would make you stop. A pilot without a stopping condition is a demonstration, and demonstrations always succeed. Define the metric, run on real volume rather than a curated sample, include the awkward cases, and set a date to decide. Then give someone the job of arguing against the result before it reaches a board. That is the discipline in Crucible, and it saves far more money than it costs to run.

How do we verify a vendor's claims about their model or data when nobody on our team is technical?

You do not need to read code to test a claim. Ask what data they built on and whether they have the right to use it. Ask what happens on inputs they did not anticipate. Ask for performance on your material, not their benchmark. Ask who owns the outputs, and what your exit looks like. Where the money is material, bring in an independent technical review before signature rather than after. That is a defined piece of work and it is quick.

Related: Strategic foresight · Selected work · All services