The Valley of Death: From Technology to Operating Reality

In 2014, I wrote about the Valley of Death: the uncomfortable space between having a promising idea or technology and turning it into something real. At the time, my argument was simple. You need internal resources — motivation, resilience, passion — and you need a map: a clear sense of where you want to go and enough knowledge of the dangers along the way.

I still believe that. But after another decade of building, scaling, selling, integrating and transforming businesses, I would draw the map differently.

The Valley of Death is not one gap. It is a sequence of translation gaps.

A good technology can still be a bad business

The first gap is between technical possibility and a problem worth solving. Engineers naturally ask whether something can be built. Markets ask a different question: whether someone cares enough to change behaviour, take risk and pay for it.

That sounds obvious. It rarely is. In complex technology businesses, the buyer, user, economic beneficiary and operational owner may all be different people. A technology can be impressive, strategically relevant and still fail because the organisation never translated capability into a proposition the customer could understand, trust and adopt.

Commercialisation is therefore not the final step after invention. It is a translation layer between technology, customer value, economics and operational reality.

A pilot is not an operating model

The second gap appears after the first success. A pilot works. A customer says yes. The technology performs. Everyone celebrates — correctly.

But a successful demonstration does not prove that a company can deliver the same outcome repeatedly, economically and at scale.

That requires something much less glamorous: ownership, processes, decision rights, data, resource planning, quality controls, commercial discipline, support models and management rhythms. In other words, it requires an operating system for the business.

This is where many promising ventures discover that what looked like a product problem was actually an organisational one.

The map must change while you are walking

My 2014 version of the story emphasised having a map. I would now add an important qualification: the map cannot be treated as a fixed plan.

Strategy is not certainty. It is a disciplined way of making choices while reality keeps changing.

A useful map should tell you three things: the destination you are trying to reach, the assumptions behind the route, and the signals that tell you when the route is no longer working. The point is not to eliminate uncertainty. It is to make adaptation intelligent rather than accidental.

Scale creates a second Valley of Death

There is another valley that gets less attention. It appears when the company has already proven that something works.

Growth adds customers, people, products, systems, geographies, acquisitions and exceptions. The organisation accumulates complexity faster than its operating model evolves. Decisions slow down. Ownership becomes unclear. Data fragments. Senior leaders become human APIs connecting parts of the company that should be able to connect themselves.

The business is no longer trying to prove that the idea can survive. It is trying to prove that the organisation can survive the idea's success.

This is the heart of what I now think of as scaling without breaking.

The future rarely replaces the present overnight

Transformation adds another complication: the new world usually has to coexist with the old one.

A company may be introducing automation while still depending on manual operations for revenue. It may be moving toward a new technology platform while legacy systems continue to support customers. It may be integrating an acquisition while the acquired team still needs enough autonomy to preserve the capability that made it valuable.

Leaders cannot build the future by pretending the present has disappeared.

The operating model has to support both exploitation and exploration: today's performance and tomorrow's capability. That tension is not a temporary inconvenience. It is often the transformation itself.

So what gets you through the valley?

I would keep some of the advice I wrote in 2014: build competence, learn from those who walked before you, protect your internal resources, and know where you are trying to go.

But I would add five questions:

• What customer or operational problem are we actually solving?
• What has to become repeatable for this to scale?
• Which assumptions are carrying the strategy — and how will we know when they stop being true?
• What part of the current operating model will prevent the future model from working?
• Who owns the interfaces between strategy, technology, people, process and execution?

The Valley of Death is still real. But I no longer see it mainly as the distance between invention and funding.

I see it as the distance between possibility and operating reality.

Crossing it requires more than a good idea and more than determination. It requires the ability to turn ambition into a system that can deliver — repeatedly.