The hardest part of innovation in a mature industry is often not inventing something new. It is making that invention work reliably inside the systems people already depend on.
A prototype can impress a room. A pilot can generate encouraging results. A presentation can make the future look inevitable. Yet none of those things guarantees that the solution will still work on a busy Monday morning, across different sites, with imperfect data and people who have other priorities.
This is one of the lessons I keep returning to when I think about mobility, logistics and other industries built on physical infrastructure. The distance between a working technology and a working business can be enormous.
A successful pilot is not the same as a successful deployment
A pilot tests whether a solution can work under selected conditions. A deployment proves whether an organisation can operate it repeatedly, at acceptable cost and risk, without extraordinary support.
During a pilot, motivated people make time. Problems get escalated quickly. Data may be cleaned manually. The founder is available to solve every exception. That attention is useful for learning, but it can also hide the true operating cost.
At scale, the product must coexist with shift changes, legacy software, procurement rules, compliance requirements, training needs and the inevitable exception nobody included in the original demonstration.
The right question is not only, “Did the pilot work?” It is, “What would have to remain true for this to work at fifty sites without the founding team in the room?”
Physical industries expose every weak assumption
Software founders can sometimes change a workflow overnight. Physical operations rarely move that way. A transport operator cannot pause deliveries to accommodate a product update. A maintenance team cannot ignore safety procedures because a new dashboard promises efficiency. A manufacturer cannot redesign its supplier network at the speed of a slide deck.
That does not make these industries resistant to progress. It makes the constraints real.
Consider a new digital process for a vehicle fleet. Its value may look obvious at headquarters. But the people who enter information, verify documents, repair vehicles, approve budgets and manage exceptions experience different parts of the process. If the solution saves time for management by adding unpaid work to frontline teams, adoption will suffer.
Innovation becomes credible when it respects the entire workflow, not just the part that looks good in a product demo.
The last mile is made of handoffs
From the product to the people
Who has to change a habit? Who will train the next employee? What happens when someone forgets a step? A workflow that depends on perfect behaviour is not yet a robust workflow.
From one system to another
Data rarely starts clean or lives in one place. The integration that looks minor in a technical specification may determine whether an operator trusts the output. A single missing field can create a manual reconciliation task that destroys the promised time saving.
From the buyer to the user
The person approving the budget may not be the person using the solution. Each needs a clear reason to participate. An executive may want visibility; an operations manager needs fewer exceptions; a frontline user needs a process that is simpler, not merely more measurable.
From innovation budget to operating budget
A pilot may be funded as an experiment. A rollout must compete with ongoing costs. The business case needs to include onboarding, support, integration, change management and the time required to maintain the new process.
Design the pilot to reveal the difficult parts
When founders build for established industries, I believe the best pilot is not the one engineered to produce the prettiest result. It is the one designed to reveal whether the product can survive reality.
Start by choosing a narrow, painful workflow and defining a baseline. How much time does it take today? How often do errors occur? How many handoffs are involved? What does failure cost? Then define a measurable outcome that matters to both the buyer and the user.
Next, include ordinary conditions rather than only ideal ones: a second site, a reluctant user, incomplete records, an unexpected exception and a day when the founder is not available to rescue the process.
Measure more than technical performance. Measure time to onboard, frequency of manual intervention, user adoption, support requests and the cost of operating the system. Those numbers help distinguish a product that works from a product that can scale.
Make the rollout repeatable before making it bigger
Scale is not simply the first pilot multiplied by a hundred. It requires a repeatable way to install, train, support and improve the solution.
Document the decisions that repeatedly cause friction. Reduce the number of custom integrations. Create clear ownership for exceptions. Make the value visible to the people doing the work. Build a feedback loop that reaches the product team before small failures become permanent habits.
This is where systems matter more than motivation. A founder can push a pilot across the finish line through sheer determination. A company needs a process that succeeds without heroic effort every time.
Operational adoption is a competitive advantage
In difficult markets, a feature is rarely the whole advantage. Competitors can reproduce screens, copy a workflow or match a technical specification. It is harder to reproduce the knowledge accumulated by making a solution dependable across real operations.
That knowledge includes understanding where data breaks, which incentives matter, how trust is earned and what must happen when the expected process fails. It becomes part of the product, the service and the company.
This connects to a broader lesson about building in difficult industries: complexity is not automatically a barrier. When you learn to manage it better than others, complexity can become part of your advantage.
The technology opens the door. Execution earns the right to stay.
I am optimistic about what new technology can change in mobility and other established industries. But I am increasingly convinced that the most important question comes after the demonstration.
Can ordinary teams use it? Does it fit the constraints of the real world? Does it create measurable value after implementation costs? Can it work repeatedly without the founder holding every piece together?
The last mile of innovation is not the distance between an idea and a prototype. It is the distance between a prototype and a habit the industry can trust.
Frequently asked questions
Why do promising innovations struggle to scale in traditional industries?
Because technical performance is only one requirement. Adoption also depends on integrations, incentives, training, compliance, support and reliable execution under everyday operating conditions.
What should a startup measure during an industrial pilot?
Measure the customer outcome and the operating burden: time saved, errors reduced, onboarding time, manual interventions, user adoption, support requests and the cost of running the solution.
How can founders move from pilot to rollout?
Build a repeatable implementation process, test less-than-perfect conditions, clarify who owns exceptions and prove that the solution delivers value without constant intervention from the founding team.