Innovation should survive contact with reality.

Innovation is easy when it is still a presentation. In a workshop, almost every idea can look transformational. The architecture is clean. The customer understands immediately. Integration is assumed. Adoption is effortless. And the business case fits nicely onto one slide.

Reality is less cooperative.

Users have existing habits. Systems have dependencies. Security has constraints. Procurement has timelines. Data is incomplete. Teams have limited capacity. A concept that looked obvious in a meeting suddenly has to compete with everything that already works well enough.

That moment is not where innovation fails. It is where innovation starts becoming useful.

A good idea is still only a hypothesis

One of the most expensive mistakes in innovation is treating enthusiasm as evidence. A team likes an idea, a prototype looks impressive, stakeholders react positively — and very quickly the organization starts behaving as if the underlying assumptions have already been proven.

They have not.

Every innovation contains assumptions: that a problem matters enough, that users will change behavior, that the solution fits the workflow, that the technology can operate reliably and that the resulting value justifies the complexity introduced.

Innovation becomes a discipline when an idea is treated as something to learn from — not something to defend.

The goal of an early experiment is therefore not to prove that the idea was right. It is to reduce uncertainty.

Start with the problem, not the technology

New technology naturally attracts attention. Generative AI, agents, automation platforms, new security architectures and cloud services all create new possibilities. The temptation is to start with the capability and search for somewhere to use it.

That can be useful for exploration. It is a weak foundation for investment.

A stronger starting point is a concrete friction: a decision that takes too long, repetitive work that consumes scarce expertise, a security process users constantly work around, information that exists but is difficult to turn into action, or a customer journey that creates unnecessary effort.

Once the problem is specific, technology can compete to solve it. Before that, technology tends to become the objective itself.

Small experiments create disproportionately useful learning

Organizations often associate serious innovation with large programs: dedicated workstreams, broad roadmaps, substantial budgets and long timelines.

But the earliest questions usually do not require that scale. They need evidence.

A small experiment is not the same as a superficial demo. A demo shows a capability. An experiment tests an assumption.

That distinction is essential.

Real users are part of the architecture

A technically elegant solution can fail because it ignores how people actually work. If a new process adds friction, requires constant context switching or solves a problem that users do not perceive as important, adoption will expose that quickly.

This is why user feedback cannot be reserved for the end of implementation. By then, too many decisions have already hardened.

Putting a rough prototype in front of real users early creates uncomfortable but valuable information. They use it differently than expected. They ignore features the team thought were essential. They ask for something that seemed minor. They reveal the workaround that actually defines the problem.

That feedback is not noise around the innovation process. It is the innovation process.

Constraints improve ideas when they arrive early

Security, compliance, integration, operations and economics are sometimes treated as obstacles that appear after the creative phase. That separation creates fragile innovation.

A better approach brings constraints into the experiment early enough to shape the idea.

Can the required data legally and technically be used? Can identities and permissions be scoped correctly? Can the solution integrate with the systems that matter? Who will operate it? What happens when it fails? What will it cost when usage increases by a factor of ten?

An idea that survives these questions becomes more credible. An idea that changes because of them becomes better.

Do not scale uncertainty

Scaling too early is one of the easiest ways to turn a small unknown into an expensive unknown.

When an experiment shows promise, the instinct is often to add more users, more use cases, more integrations and more features. But scale should follow confidence, not excitement.

Before expanding, it helps to ask which uncertainty has actually been removed and which uncertainty is merely being carried forward.

• Problem: Is the problem frequent, important and specific enough to justify change?
• User: Have real users demonstrated that the proposed solution improves their work?
• Technical fit: Has the idea been tested against real systems, data and integration constraints?
• Risk: Are security, compliance and operational failure modes understood?
• Value: Is there observable improvement compared with the current way of working?
• Scale: What new uncertainty appears when the solution moves from ten users to one thousand?

Stopping can be a successful outcome

Innovation programs often make stopping psychologically difficult. Once a project has a name, a sponsor and a roadmap, ending it can feel like failure.

That creates a dangerous incentive: experiments become ceremonies designed to justify continuation.

A healthy innovation system treats a well-supported decision to stop as valuable. If a two-week experiment shows that users do not care enough about the problem, that the operational cost is disproportionate or that another approach is clearly better, the experiment has saved time and money.

The failure would have been learning the same thing after twelve months.

Innovation needs a path into normal work

There is another failure mode at the opposite end: experiments that remain permanently experimental.

A prototype proves value, people like it, presentations are made — but nobody answers the next questions. Who owns it? Who supports it? How is it secured? How is it funded? What process changes because it exists?

For an experiment to become innovation, it eventually needs an operating model.

This transition should be part of the design from the beginning. The experiment does not need production-grade everything, but the team should understand what would have to become true for the idea to graduate.

Progress is better measured in reduced uncertainty than in activity

Innovation teams can be very busy without learning very much. Workshops completed, prototypes produced, technologies evaluated and roadmaps written all create visible activity.

A more useful measure is what the organization knows now that it did not know before.

Do we know that the problem is worth solving? Do we know that users will adopt the new behavior? Do we know that the technology can operate within the required constraints? Do we know which outcome will justify further investment?

Each good experiment should make at least one important decision easier.

Reality is not the enemy of innovation

The strongest ideas are not those protected from criticism, constraints and messy implementation details. They are the ideas that improve because of them.

Innovation should therefore move quickly toward reality: real problems, real users, real systems and real measurement.

Start smaller than feels impressive. Learn sooner than feels comfortable. Scale only what the evidence supports.

Because an idea that survives contact with reality is no longer just an idea.

It is something worth building.