I can still remember it like it was yesterday.

In 2010, we launched the Mercedes Benz Atego Hybrid.

The vehicle was a full-fledged Mercedes with mass production quality. It offered 20% fuel savings in distribution traffic – a value that customers would kiss our feet for.

I was proud as a peacock: The world had never seen a truck like this. No competitor anywhere had anything like it in their lineup.

And then? Nothing. Nobody was interested in the truck.

I don't know how many were sold, but it was negligible. The project was a complete economic failure.

Why?

That's what I want to write about in this article, and of course about what I learned from it.

“I Can Develop It” Projects

Developers are creative people, and they want to develop something new – it's in their nature.

However, it's a fact that this requires an organization, money, and resources.

If a company's processes are organized so that these requirements are only available when a product development project is approved, then this inevitably leads to initiating a full product project for every new technology idea.

Employees find a way to make this happen – believe me.

As I mentioned, developers are creative people, and they also find creative ways to get the project they want.

Alliances are formed, data is gathered, presentations are made, business cases are crafted. In the end, everything looks logical and sensible.

It's not even a lie, really.

The problem is that these products have an extremely high probability of arriving at the market either too early or too late.

For this reason, it doesn't really matter how long the project takes.

Typically, “I Can Develop It” projects have a long project timeline. The technology itself must first be developed before the development of the end product – which is essentially an integration – can take place.

In these cases, the approach proposed by the VDA (German Association of the Automotive Industry) makes sense, which I briefly presented in the last newsletter article.

Not every project set up this way must lead to economic disaster, as it was the case with the Atego Hybrid.

It's not uncommon for these products to find sales.

If the developers' forecast was accurate and the markets develop as expected, it can work.

But one problem is unavoidable.

Due to the long project timeline and the unclear market developments at the start of the project, it's impossible to identify the right specifications at project launch – specifications that might perfectly meet customer needs.

This leads to these specifications being constantly adjusted during the project, which creates additional development loops that either increase project costs and resource requirements or keep pushing the deadline further back.

To make the issue even bigger, competitors who started development later may have the better product on the market.

The predicted profitability cannot be achieved, and the reason often cited is that the market environment has become so volatile. What bad luck!

It's not recognized that the way the product development project was planned is the actual cause of the problem.

“I Need This Urgently” Projects

The opposite of “I Can Develop It” projects are “I Need This Urgently” projects.

Here, the product development project is only initiated when competitors have brought new products or new product features to market that generate high customer interest. This causes customers to no longer want your own product because the competition has better offerings.

The product development time can't be fast enough.

Developers are blamed for always taking too long. With every day that the new product isn't available on the market, the company loses valuable business.

People say:

“In this volatile world, you can only survive if you develop agile, because that's supposedly the only way to deal with volatility, and competitors probably do it that way, otherwise they couldn't be so fast.”

Since it's urgent and must be done quickly, there's no time for technology development and customer use case analysis. It's best to copy the competitor's solutions and not waste time thinking.

Planning these product development projects causes the greatest economic damage.

It doesn't arise from unrealized payback, as with “I Can Develop It” projects, but from declining sales of the existing product, which can be existential.

The Smart Way to Plan Product Projects

With the types of product development project planning just discussed, the problem is that the question is asked:

“What project do we want to start now?”

But the right questions should be:

When is the market ready for the next product update?

What features and requirements are needed then?

When do we know enough to start a product development project?

To find helpful and correct answers and have such a project available on time, several steps are necessary, which I'll now explain:

Recognizing the Right Project Start Time

Unlike the two project approaches presented at the beginning, proper planning doesn't move forward from today, but begins in the future—planning backwards.

However, the problem with the future is that nobody knows it.

That's why we prefer to plan from the present—because it's the point in time we know.

The future can at best be predicted, forecasted, estimated.

And this becomes more accurate the shorter the time period.

The time between the decision for a product project and the time of its market launch must be so short that a reliable forecast of future market demand is possible.

By the way, that's also the time frame that truly matters—not the moment a developer comes up with a technology, nor the moment someone starts thinking about a project, but the point at which project goals can be defined with sufficient certainty.

I see two factors that play an essential role:

* Customers must be able to name their product preferences for the planned point in time when the new product becomes available.

* The time span is so short that competitors also cannot bring a suitable product to market faster.

This time period is certainly different depending on the industry.

In the commercial vehicle sector, I currently consider a period of 3 to 4 years optimal.

Even though pure software features can certainly be brought to market faster, it's still possible to estimate them with good forecast accuracy over a period of 3 to 4 years.

I wouldn't recommend a shorter development time than 2 years for quality assurance reasons. I'll go into this in more detail in another article.

Let's stick with product development projects that also include significant improvements in mechanics and mechatronics.

Then 3 to 4 years of project time is a major challenge.

If it's possible to forecast 3 to 4 years ahead, I wouldn't call that a volatile situation—yet even then, certain precautions are needed to ensure successful product development.

Pre-developing Technologies

How such a project can be structured in practice is something I’ll cover in more detail in an upcoming article.

Let me start by highlighting one essential point:

Technology development must be decoupled from product development.

There needs to be a process that allows technology to be developed in an “I Can Develop It” mode—without having to deliver a market-ready, mass-production product.

This process can fully embrace an agile development approach—while always keeping the question of value creation at its core.

The value in focus is not the revenue or profit, but:

What exactly must be clarified to prepare the technology for safe and efficient integration into a short, customer-focused product development project?

Exploring Future Customer Expectations

The next point aims to help customers improve the prediction quality of their future requirements.

Giving customers early access to prototypes and testing them together in real-life conditions helps sharpen their future requirements.

This form of co-creation was absolutely unthinkable in the past.

New products and especially their prototypes were kept strictly secret.

I predict that in the future it will be common to involve customers very early in the preparation of project decisions.

It’s possible that this is the very lever the European industry needs to stay ahead of Chinese rivals—if it’s recognized and used in time.

This form of collaboration has traditionally been far more established in the U.S. than in Europe.

Planning Incremental Product Improvements

Let's assume I'm right about the 3 to 4 year forecast period.

Then it's not to be expected that no new requirements or market needs will become apparent in the next 3 to 4 years that call for a product update.

Quite the opposite:

After only a year or two, evolving customer needs may already call for the next product initiative—long before the current product is launched.

In the past, this often led to shifting the goals of ongoing product development projects midstream.

The result:

Instability, delayed market launches—and ultimately, no suitable product available when it was actually needed.

That’s exactly what should be avoided.

The right approach is to complete the current product project as planned—while already launching the next project with the necessary time offset, so that the next product improvement is ready precisely when the market is ready for it.

If done right, this will lead to multiple product development projects running in parallel—something that would have been unthinkable in our industry just a few years ago.

Skipping product stages just to save budget—simply because the next step seems obvious—is not financially sound. It ignores the damage caused by the disruptions and delays that typically follow such shortcuts.

At the same time, efficiency still matters. That’s why project targets must be defined with great care—always keeping in mind that the product’s lifespan may be shorter than one would hope.

I think this article contains many thought-provoking ideas that justify deeper consideration.

So please subscribe to my newsletter so you don't miss these articles.

Got questions or feedback? I'd love to hear from you in the comments.

We can also chat about it.

If you found this helpful, don't forget to share it with others who might enjoy it too!

If my newsletter resonates with you, please consider sharing it with others.

Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe