And once again, everything is changing
I was very fortunate to have witnessed and helped shape two major turning points in product development.
We’re right in the middle of the second one at the moment.
That is precisely what this article is about: a system that enables product development not only to weather this upheaval, but also to build a successful future.
I started my career at the drawing board. Pencil and ink on tracing paper.
Back then, as a young engineer, I admired my older colleagues.
Lines appeared on the tracing paper. Three side views, an isometric projection, cross-sections. That was all the sheet could accommodate.
They looked at it and saw a part.
They turned it over in their minds, tilted it, cut it open in a place that wasn’t even drawn, and yet they knew what would be there.
To me, they were lines that I had to painstakingly piece together. To them, it was a component you could hold in your hand.
And then came the second part, which impressed me even more.
A colleague placed the pencil at the junction with the rib, tapped the paper twice, and said, “It tears there.”
No calculation. No proof. He had seen it.
People called it “work experience.” These were specific skills that were developed over many years of doing this work.
Then the computer replaced the drawing board.
From that point on, those skills were no longer needed.
Spatial representations were generated and visualized in the 3D design system.
Another cross-section? I’ll have it done in a minute.
Calculation programs indicate where the component will break.
From then on, different skills were needed.
The efficiency gains achieved with the new tools multiplied the output.
A change that used to mean redrawing half a sheet of paper was now just a matter of adjusting a value. What used to take weeks on the drawing board could now be done in an hour on the screen.
Today’s wide variety of options would never have come about with the resources available back then. And certainly not so quickly.
But digitization didn’t just have an impact on efficiency.
At the same time, the number of product features increased. First mechanical, then electrical, then electronic, and finally networked. However, each new feature inevitably interacts with the others.
The complexity of the portfolio’s content skyrocketed.
Now it was a matter of mastering this complexity—of knowing what a change in one place would trigger somewhere else in the system, and in which combination of variants it would become a problem.
Today’s experienced developer looks at a change request and says, “That conflicts with the heavy-duty version.”
No analysis. No evidence. He saw it.
That is the expertise we admire today.
And now we find ourselves at another turning point.
Artificial intelligence and virtual worlds provide the foundation for reaching an entirely new level. Many of yesterday’s skills will no longer be needed.
Still others are needed.
I can’t describe how development will unfold over the next twenty years. I wouldn’t have been able to do that twenty years ago either.
But I can describe the first step toward that future.
NewPDP serves as the bridge between today—when there are still shortcomings to address—and tomorrow, when we will work differently.
Those who fail to address today’s shortcomings will never make it to tomorrow.
After all, one thing is clear even with this technological leap:
This time, too, there will be a massive gain in efficiency. Anyone who fails to achieve this will be a loser in this transformation.
That’s why the NewPDP’s motto is:
Develop more without needing more.
Four years of work went into this model.
Seven elements that address precisely the areas where mechatronic product development today needs the most improvement.
Let’s take a look at them.
Four Approaches, Three Prerequisites
Practices are the areas that need to be transformed and the methods that achieve the desired results.
The order has been chosen so that the first step is the one that lays the foundation for everything that follows.
In doing so, I am already applying a principle that I will return to time and again:
Prioritize the issues that will generate the greatest value right now and those that will result in the greatest loss of value if they aren’t addressed immediately.
Enablers refer to changes in the environment without which the transformation cannot succeed.
There is no specific order here.
Work on leadership, organization, and architecture can and should be done simultaneously.
Curious?
Then let’s briefly go over the key features.
The Four Practices
1. Drum Beat System (DBS)
Pulling together, on one beat
„We’re currently working in QGx.”
I’ve heard that sentence over and over again.
It’s linguistic nonsense. You can’t work inside a gate. A gate is a checkpoint.
People say it anyway. Because our process only names the checkpoints and not the stretches in between. There is no word for the period in which the work actually happens.
That is exactly the gap the Drum Beat System fills.
The Drum Beat gives the in-between a rhythm, a name and points of synchronisation.
- The pomegranate tree model creates effectiveness through goal prioritisation and keeping everyone in sync.
- The universal four-stroke cycle creates efficiency through error avoidance and structured preparation of the work.
Both are part of the Drum Beat System.
And a single rule carries the whole thing:
A Drum Beat is never stretched.
The moment the beat gets extended, we are back where we came from. Then we are negotiating dates again instead of content.
The Drum Beat System is the lubricant for everything else. When it works, the whole machine runs more easily.
That is why we start here.
2. Learning Standard Routines (LSR)
Focus builds mastery.
Perceived complexity and volatility have pushed one insight out of view:
Skill comes from repetition.
Not every activity is complex, and not the whole environment is volatile. Repetitive activities in a stable environment exist, and they always will.
For those, the rule is:
- identify them
- define the way of working
- put the same people on them permanently
- And let those people improve their own way of working continuously.
Now here comes the objection: “But that’s Taylorism.”
Half of it, yes. What stays from Taylor is the fixed assignment. What goes is the separation of doing and improving.
I consider this one of the advantages of the Old Economy.
We actually know how to do this. Where it makes sense, we have to do it without compromise again.
And one more aspect:
Standardised processes are easier to automate and digitise than unstructured ones. That multiplies the efficiency gain.
That is why Learning Standard Routines come second.
3. Hardware Light Development (HLD)
Virtual before physical.
Digitalisation is on everybody’s lips. Everyone talks about AI, about virtualisation, about digital twins.
And rightly so.
Working on real hardware is slow and expensive. So we have to virtualise whatever we can.
No doubt about it.
The challenge sits in that small qualifier: whatever we can.
Even if not everyone will agree with me here: as long as the product is a piece of hardware, a remainder of hardware work stays indispensable.
The decisive change is not to do away with hardware entirely.
It is to develop the same quality and the same functionality with the smallest possible amount of hardware, only far faster and far cheaper.
Now you are asking yourself how that is supposed to work?
That is exactly what we are going to find out.
4. Predictive Technology Readiness (PTR)
Ready when it is needed.
I often hear: we have to bring new technologies to market faster.
My observation is that all too often we only decide to develop a technology once we urgently need it.
That is too late!
But there is also the opposite mistake. Investing too much in innovative technology too early.
A technology that sits finished on the shelf before anyone needs it is inventory. And inventory ages.
The knowledge walks out of the door with the people, and what is left falls behind.
So the challenge is not only speed, it is the right measure.
How do we manage the development of a technology so that it is ready exactly when we need it?
That is precisely what this practice deals with.
The Three Enablers
Leadership (L)
Clear direction, one team.
There are countless models and opinions on leadership.
Only one question interests me:
What does leadership have to deliver so that product development achieves outstanding results quickly and with minimal resources?
One answer up front:
Leading means doing the work. Whoever only decides is not leading.
- What does the team decide for itself, and how is it enabled to live up to that responsibility?
- Which tasks does the boss take on from the team, and how reliably does he deliver them?
This is about trust.
“One team” is not a platitude. It is an attitude, a company culture.
As in team sport, there are different players with different roles, and the way they play together has to be clearly understood and practised.
And there, too, you have set pieces.
And while we have the subject on the table, we will of course also look at leading yourself.
Organisation (O)
Structure follows the system.
For as long as I can remember I have watched the debate over whether a functional or a divisional organisation is the better form.
The pendulum keeps changing direction, and in the end we almost always land at a matrix.
Now the agile enterprise is coming into fashion, and at the same time systems engineering is laying claim to the organisational form of development.
That names the actual problem.
Today the matrix has two dimensions:
- Competence, meaning who can do it.
- And process, meaning how it runs.
Systems engineering brings a third into play, namely product functionality.
Only a matrix does not survive a third dimension. Three memberships, three sets of goals, three people with a claim on the same person.
All three still have to be represented. But there can only be one organisation, and inside it one dimension always leads. That is already the case today, either the functional or the divisional one leads.
So the question is not how we add the third dimension. It is which principle leads from now on. And how the organisation is built around it.
We need an answer to that, because without a suitable organisational form fast and efficient work is not possible.
Architektur (A)
Modular progress.
It is every engineer’s dream to be allowed to develop a completely new product.
I even had that chance several times.
And every time, the organisation swore afterwards never to do such a thing again.
Endlessly expensive and endlessly long.
You are barely finished, and the product is already out of date. The next wishes are on the table.
As a consequence I have spent a lot of time on how to design hardware products modularly enough that improvements and new functionality can be developed incrementally.
Anyone coming from the software world will recognise the increment in that.
Over there it was the same for a long time.
In the days of spaghetti code, almost everything had to be redone with every change.
It was object-oriented programming and the architectural principles that followed it that made the increment possible in the first place. That was decades ago
In hardware, that development is still ahead of us.
Modular architectures have existed on our side for more than twenty years too.
They are simply not well enough understood and not cleanly enough defined.
That is exactly what this element is about. It is meant to close the gaps that stand in the way of incremental product development in mechatronics.
The NewPDP does not define what such an architecture concretely looks like. That would be too specific for a general framework.
The NewPDP defines which properties and which processes it has to have.
Why I leave nothing out
“This is all way too complex; nobody understands it. Take out the drum beat and leave the rest out.”
I hear this objection time and time again. Too complicated, too much, too extensive.
The desire for simplicity is understandable, but is a simple transformation even possible when an entire business system has to be turned upside down?
I don’t think so.
What has to be done must be done.
The seven elements do not stand next to each other, they interlock. Each one creates preconditions for the others, and each one benefits from the others.
That is the nature of a system.
Pick any two of them and ask yourself what one is worth without the other.
And in this shape the NewPDP is already a simplification.
It concentrates exclusively on those elements of the system that carry the greatest need for change in mechatronic product development today.
You can start with one element. In fact you have to. But with one alone you will not get there.
When I write another overview article some time from now, the story will hopefully look a little different.
We will have solved problems we no longer need to talk about, and there will be new challenges instead.
Conclusion
The newPDP is applied to all phases of product development that I described in the previous article.
In the next few articles, I’ll discuss each method and each requirement in detail, so subscribe to my blog so you don’t miss a thing.
Please check out my newsletter or podcast, where you’ll find more content on this topic.
Please feel free to send me an email if you’d like to talk to me about this, and we’ll set up a video call.
I hope you enjoyed the article.
Please let me know what you liked, how I can improve, and suggest topics you’d like to see covered in the future.
Your feedback is essential for improving the blog and providing content that matches your interests. I look forward to hearing from you!
