Berk Bayri
Innovation systems4 min read·

A pilot is a decision instrument

A pilot should reduce uncertainty around a real decision. If it cannot do that, it is probably a demonstration.

The word pilot is used for many different things. Sometimes it means a prototype. Sometimes it means a short trial with a vendor. Sometimes it means a project that has been given a small budget because nobody is ready to make a larger commitment.

Those uses are understandable, but they blur the point of a pilot.

A pilot is useful when it helps an organization make a decision it could not make with confidence before. It may confirm that an opportunity is worth scaling. It may show that a workflow needs redesign before technology will help. It may prove that the conditions are not there yet. All three outcomes can be valuable.

Start with the decision

Before discussing scope, ask what decision the pilot needs to inform.

It might be a decision to invest in a product direction, change a workflow, expand a capability, choose an operating model or stop pursuing an idea. The answer gives the pilot a job. Without it, teams tend to collect activity rather than evidence.

A vague question produces a vague pilot. "Can we use this technology?" invites a demo. "Can a small group complete this recurring task with fewer handoffs while preserving the quality standard our customers expect?" gives the team something testable.

The second question also makes it clear that the technology is only one part of the work. The people involved, the current process, the quality threshold and the decision owner all matter.

Keep the claim narrow enough to test

A pilot does not need to represent the entire future state. In fact, it should not try to. The more situations it attempts to include, the more likely it is to become a miniature implementation programme with none of the discipline of one.

Choose a slice of work that is real, bounded and consequential enough to matter. Give the team a clear starting condition and a clear way to observe the result. The pilot should create a contrast: before and after, current and proposed, assumption and evidence.

This is where small multidisciplinary teams are often more effective than large committees. A compact group can bring the necessary perspectives into the room, make a decision and observe what changes. It can also identify when a problem has surfaced in another part of the system.

Define what counts as evidence

A pilot needs success criteria before the result is known. Otherwise, enthusiasm will interpret any movement as proof.

The criteria do not need to be elaborate. They can include the reliability of an output, the time required for a task, the ability of users to complete a workflow, the quality of a decision, the burden introduced for reviewers or the willingness of the responsible team to continue using the new approach.

The important thing is that the criteria fit the context. A model that produces faster output but creates a difficult review process may not improve the work. A new experience that is well received in a controlled session may still fail in a live operational environment.

Evidence should be broad enough to catch these differences. Analytics are useful. So are interviews, workflow observation and support signals. A pilot is not an isolated technical test. It is a temporary window into the system that will have to carry the result.

End with a decision report

The final deliverable is not the prototype. It is a clear account of what was learned and what should happen next.

That report should say what the pilot tested, what evidence it produced, where the limits were and which decision is now recommended: scale, iterate, change the framing or stop. It should make the trade-offs visible rather than smoothing them away.

A pilot that succeeds still leaves work to do. What should happen after an innovation pilot succeeds is often the more difficult question. The pilot has earned the right to move from curiosity to ownership. It has not made that transition automatic.

The most useful pilots are modest in scale and demanding in thought. They let an organization learn enough to act without pretending that a small experiment has answered every question.

Berk Bayri

Creative Technology & Innovation Leader

Designing and building for digital environments since 1998, across strategy, product, design, technology and organizational innovation.

About Berk →

Get new essays in your inbox.

New essays by email, when they are published.