Innovation — Subirachs Ventures —
Why exploration stalls
Interest in a technology usually arrives as a question without an owner. Someone senior has seen enough to believe it matters, but nobody has been asked to produce a decision, and no one has defined what a decision would even require.
What follows is familiar. Workshops are held. Vendors present. A slide deck circulates. A year later the organisation knows more about the technology in the abstract and no more about what it should do. The work was real; it simply was not pointed at anything.
Structured experimentation fixes this by starting at the other end. Before anything is explored, the team writes down the decision the work is meant to inform, and the evidence that would settle it.
Start from the decision, not the technology
A useful innovation brief is not 'explore AI agents'. It is closer to: 'decide, within two quarters, whether we should route tier-one support enquiries through an assisted workflow, and on what conditions.'
That framing does three things at once. It makes the work finite. It identifies who has to be convinced. And it makes it obvious what evidence counts, which in turn tells you what kind of experiment you need.
- The decision the work must inform, and who owns it
- The conditions under which the answer would be yes
- The conditions under which the answer would be no
- The evidence required to distinguish between them
- The date by which the decision is made either way
Design pilots that can fail
A pilot that cannot fail is not a pilot; it is a demonstration. Demonstrations are useful for building internal support, but they produce no information, because the outcome was decided before the work began.
A well-designed pilot has a scope small enough to run inside a real operating environment, a defined comparison against how the work is done today, and a stated threshold that determines what happens next. It runs with real users, real data and real constraints, because those are precisely the things that determine whether a technology survives contact with an organisation.
The most common design error is scoping a pilot to be impressive rather than informative. The second most common is running it in a sandbox so isolated that nothing it reveals transfers to production.
Bring the outside in deliberately
Most emerging technology capability sits outside the organisation, in startups, research groups and specialist operators. Scouting is how that capability is brought in, but scouting only works when it is anchored to a defined problem.
A scouting brief built from a real internal problem produces a shortlist that operating teams recognise as relevant. A scouting brief built from a technology category produces a long list that nobody knows what to do with.
The difference shows up later: problem-anchored scouting ends in pilots, category-anchored scouting ends in a market map.
Plan the path to adoption before you need it
The hardest part of corporate innovation is not the pilot. It is the transition from a successful pilot to something the organisation actually runs, with a budget line, an owner, a support model and a place in existing processes.
Teams that plan this transition at the start ask different questions during the pilot: who would operate this, what would it replace, what has to be true for procurement, risk and compliance to approve it. Teams that leave it until the end discover that a successful pilot has no route into the business.
Adoption is a design constraint, not a phase. Treating it as one is the single biggest determinant of whether innovation work compounds or resets each year.
What good looks like
An organisation running this well has a small number of live experiments at any time, each attached to a decision with a date. It can say what it learned from the ones it stopped. It has a repeatable way of bringing external teams into contact with internal problems. And it can point to at least one thing that moved from experiment to operation.
None of that requires a large innovation function. It requires clarity about what the work is for.