The Distance Between R&D and Revenue

By Alejandro Di Tolla

Some R&D cycles take years because the technology is genuinely difficult. Others take years because the operating model around the technology makes them difficult.

In one business, development cycles for major new solutions had historically taken more than two years. We eventually took new solutions from concept to commercial deployment in months, at a fraction of the expected development cost. Shortly thereafter, we were deploying successfully and generating revenue in the new market.

The technology mattered. But technology wasn’t what changed the timeline from years to months.

The way we operated did.

When development is taking too long, it is tempting to assume that the answer sits inside R&D: more engineers, a larger budget, better tools, a different development methodology, or simply more pressure to deliver.

Sometimes it does.

But before adding resources, I think there is a more important question to answer:

Where, exactly, is the time going?

We didn’t start by trying to make R&D faster

We started by becoming much more disciplined about the problem we were trying to solve.

Instead of asking what we could build, we worked backward from the customer need. Was the problem important enough? Would solving it create sufficient value? What assumptions were we making about the customer, the technology, deployment, and the economics? Which of those assumptions could we test before making a significant commitment?

We also looked hard at what we already had.

There is an important difference between entering a new market and starting from zero. Existing technology, knowledge, operating capabilities, customer experience, or processes can provide substantial leverage—but only if they transfer to the problem being solved.

That sounds obvious. In practice, it is remarkably easy to confuse we can enter this market with we have an advantage entering this market.

The distinction matters because R&D decisions are also capital-allocation decisions.

McKinsey examined 770 large advanced-industry companies over a 15-year period and found that companies successfully expanding into what it calls “natural adjacencies”—areas where existing capabilities gave them a genuine “right to win”—generated stronger shareholder returns than their peers. Two-thirds of those adjacency growers outperformed their industries. 

But I would be careful about the conclusion we draw from that research.

It does not mean adjacent expansion is inherently a good strategy. Other research cited in my review puts the failure rate for adjacency initiatives much higher, particularly when companies move too far from the core, underestimate what capabilities actually transfer, or underestimate incumbent advantages. 

That is precisely the point.

“Adjacent” is not a strategy. It is a hypothesis.

You still have to prove that the customer problem matters, that your capabilities transfer, and that the economics justify the investment.

Validation changed when we committed capital

One of the biggest changes we made was not eliminating risk. That would have been impossible.

We changed when we took the risk.

Rather than making the large development commitment first and using the development process to discover whether our assumptions were right, we tried to invalidate the most important assumptions as early and inexpensively as we reasonably could.

Customer need came first. Then whether our existing capabilities could credibly solve it. Then field evidence. Each step gave us more information before the next commitment.

Only after we had sufficient evidence did the larger R&D investment make sense.

This is why I increasingly think about customer validation not simply as a product-development practice, but as capital discipline.

Every assumption you can test inexpensively before making a major commitment reduces the capital exposed while uncertainty is still high.

Of course, there is a limit to this. You can research and validate indefinitely and never build anything. At some point, leadership has to decide with incomplete information.

The objective isn’t certainty.

It is to understand which uncertainties could kill the economics of the investment and resolve enough of them before putting significant resources behind it.

Then the constraint moved

Once we had enough evidence to proceed, the problem changed.

Now we had to execute.

And this was where simply telling R&D to move faster would have accomplished very little.

R&D couldn’t operate as a silo, develop something, declare it complete, and then hand it downstream to the functions responsible for validating, deploying, supporting, and commercializing it. If those teams discovered requirements or constraints late in the process, the work came back upstream. Time was lost, priorities changed, and rework accumulated.

So, working closely with our technical leadership, we changed the model.

The functions required to develop, validate, deploy, and ultimately commercialize the solution became part of the same operating process. That reduced sequential handoffs and, just as importantly, allowed problems that would normally have appeared downstream to surface much earlier.

Research on R&D organization supports the mechanism. McKinsey has argued for clearer end-to-end responsibility in R&D and fewer organizational interfaces, while academic work on concurrent engineering has found reductions in development time and cost when appropriate activities move from sequential handoffs toward more parallel, multidisciplinary execution. 

But this is where I would add another qualification.

Cross-functional does not mean everyone has the same priorities.

Nor should they.

Good operating models don’t eliminate functional tension

Technical leadership has to protect technical integrity. Finance has to care about economics and capital exposure. Operations has to determine whether something can actually be deployed and supported. Commercial teams have to understand whether customers will buy it.

Those responsibilities create tension.

That’s healthy.

The objective isn’t to eliminate the tension by forcing everyone into artificial agreement. It is to keep legitimate functional differences from becoming organizational friction that unnecessarily slows the company.

For us, that meant creating enough alignment around the outcome that each team could protect what mattered within its function without letting competing priorities, unresolved decisions, or handoffs dictate the development timeline.

That required more than putting people from different departments into meetings.

It required clarity about the outcome, who owned which decisions, what information needed to move between teams, when to escalate disagreements, and what evidence was sufficient to move forward.

The research also offers useful caution. Cross-functional integration is not universally beneficial. Some evidence suggests its value is greater when technological and market uncertainty are high; in lower-uncertainty environments, coordination cost can offset some of the benefit. 

That makes intuitive sense to me.

The lesson isn’t “make everything cross-functional.”

It is design the level of integration around the uncertainty and interdependence of the work.

Be careful what you optimize

This may be the most important lesson I took from the experience.

If leadership asks:

How do we make R&D faster?

The organization will naturally optimize R&D.

Add engineering capacity. Improve development processes. Introduce new tools. Change methodologies. Measure development velocity.

Any of those may be appropriate.

But they optimize one part of the system.

The question I find more useful is:

How do we reduce the distance between an identified customer problem and commercial revenue?

Now the boundary of the problem changes.

Customer discovery matters. Validation matters. Capital allocation matters. R&D matters. Operations matters. Deployment matters. Commercial readiness matters. And the decisions connecting all of them matter.

A product completed quickly but difficult to deploy hasn’t necessarily created speed.

A solution deployed quickly that customers won’t buy hasn’t either.

And an R&D organization hitting every internal milestone while downstream teams wait—or discover requirements too late—is locally efficient but systemically slow.

This is why I think the meaningful clock starts much earlier than the formal R&D cycle and stops much later.

It starts when the company identifies a problem worth solving.

It stops when the solution creates commercial value.

Speed is part of the economics

That broader definition also changes how I think about time-to-market.

Speed is not valuable simply because faster sounds better.

Time has an economic cost.

Every unnecessary development cycle consumes technical capacity and management attention. Every avoidable handoff creates coordination cost. Every important requirement discovered late creates the possibility of rework. And every month spent developing against an assumption that could have been tested earlier exposes additional capital to uncertainty.

Opportunity cost matters, too. Capital and technical talent committed to one development path cannot be deployed elsewhere.

That is why I see R&D speed as an economic variable, not simply an execution metric.

In our case, changing the operating conditions helped turn development cycles measured in years into months, at a fraction of the expected cost. Commercial deployment followed, and so did revenue.

But the metric is not the part I find most transferable.

The operating logic behind it is.

Before adding resources, diagnose the constraint

When R&D takes too long, I don't automatically conclude the company needs more engineers or a larger budget.

I would first want to understand:

• Are we solving a sufficiently valuable customer problem?

• Which assumptions are we treating as facts?

• Which of those can be validated before committing significant capital?

• What capabilities can we credibly reuse rather than rebuild?

• Where are handoffs creating delay, information loss, or rework?

• Which decisions repeatedly stall between functions?

• Who owns the outcome end to end?

• Are development, deployment, and commercialization working toward the same definition of success?

• And what are we actually optimizing: completion of R&D, or creation of commercial value?

The answers may still lead to more engineers, more capital, or more time.

If they do, good.

At least leadership now understands what constraint that additional investment is intended to remove.

That is very different from putting more resources into an operating model that may itself be creating the delay.

Sometimes the technology really is the constraint

I don’t want to overstate the argument.

Some technologies genuinely take years to develop. Some technical problems cannot be parallelized. Some validation can only happen after substantial investment. And additional cross-functional coordination can itself become bureaucracy if the work doesn’t require it.

The objective should never be speed for its own sake.

It should be to remove avoidable time, capital, and organizational friction from the path between a problem worth solving and a solution customers are willing to pay for.

That experience changed the question I ask when development seems too slow.

I don’t start with:

How do we make R&D faster?

I start with:

Where is the time actually going—and why?

Sometimes the answer will be the technology.

But sometimes it's an assumption nobody tested early enough, a decision nobody clearly owns, a functional handoff that creates repeated rework, or an organization optimizing one part of the system while the real constraint sits elsewhere.

The objective isn’t to make R&D faster.

It is to make the company better at converting validated customer problems into commercial value—without wasting time, capital, or organizational capacity along the way.



—

Sources & Further Reading

McKinsey & Company. “How to Reignite Growth Through Adjacencies.” 2023.
⁠https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/how-to-reignite-growth-through-adjacencies

McKinsey & Company. “The Present-Focused, Future-Ready R&D Organization.” 2020.
⁠https://www.mckinsey.com/capabilities/operations/our-insights/the-present-focused-future-ready-rd-organization

McKinsey & Company. “Achieving Success in Large, Complex Software Projects.” 2014.
⁠https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/achieving-success-in-large-complex-software-projects

Rihar, Lidija; Žužek, Tomaž; and Kušar, Janez. “How to Successfully Introduce Concurrent Engineering into New Product Development?” Concurrent Engineering: Research and Applications, 2021.
⁠https://journals.sagepub.com/doi/10.1177/1063293X20967929