6 Measures for agile, model-based product development

We have been talking about "digital transformation" for years, but unfortunately many companies are lagging behind. What's worse is that product development is often neglected in the digital transformation and anchored as a purely technical discipline. However, products are what companies earn money with. This view is therefore outdated. Product development must be thought through strategicallyas a central element for future viability and competitive differentiation. In the following I deal with:

• Digital transformation overlooks developmentMany transformation initiatives exclude product development.
• Traditional development reaches its limitsLinear, document-based processes can no longer be developed in a meaningful way.
• Own strategy for developmentEfficiency can only be increased slightly without a clear strategic focus.
• Agility needs modelsShort iterations and quick decisions are only possible with integrated models.
• Software is a pioneerCI/CD shows how speed and feedback loops would also be possible in hardware.
• Crisis complicates, but makes change necessaryTransformation is particularly challenging - and necessary - under market pressure.
• Six concrete measuresFrom setting strategic goals to integrating IT & engineering - transformation is possible.
• Conclusion: Now is the timeModel-based agility is overdue - it's better to start late than to procrastinate.

Digital transformation often leaves out product development

When managers talk about digital transformation, product development is often missing, at least explicitly. For example Poppulo describes the following four main areas of digital transformation in this blog article:

• Process optimizationImproving the efficiency and effectiveness of company processes through the use of modern technologies.
• Business model transformationRedesigning traditional business models through digital technologies to open up new growth opportunities.
• Domain transformationOpening up new market areas through the use of digital technologies that were previously not part of the core business.
• Cultural/organizational transformationAdapt the corporate culture and structure to support digital initiatives and create an innovation-friendly environment.

Product development is surprisingly often not directly addressed in the digital transformation.

Of course, some of these also affect product development, such as process optimization. However, most of them are not about development, but:

• Marketing & Sales
• Customer Service & Customer Relations
• Communication (integration of telephone, e-mail, chat, social media, etc.)
• Manufacturing / Production (Smart Factory)
• DevOps / Software development
• Human Resources (HR), Learning & Development
• Finances & Controlling
• Real-time data analysis (business intelligence)
• Supply Chain & Logistics (Supply Chain)

Sometimes the following topic appears on the list Digital twinThis often relates to operations and PLM relates. Nevertheless, it is striking that product development is often forgotten. The reasons are:

• Product development is often interlinked with other domains, e.g. IT, production or marketing.
• In some companies, it is not perceived as "digitalizable" because it seems creative and individual.
• Sometimes it is also perceived as already fully digitized, overlooking the fact that there are breaks in the tool chains or that content cannot be processed by machine.

Why "business as usual" no longer works

Traditional, waterfall-based product development is based on silos, linear processes and extensive communication via texts and tables. Small improvements in this system rarely lead to noticeable progress - it is not a system that can be modernized incrementally. What we need is a paradigm shift: away from document-based work and towards a model-based, networked and agile development approach.

There are many misunderstandings to be resolved:

• If we use an RE tool (DOORS, Jama, Polarion, etc.), we have fine-grained traceability, but no machine-readable artifacts, only text snippets
• Even if we use expensive, specialized tools for CAD, testing, simulation and perhaps even MBSE, tool breakages often persist, leading to long downtimes.
• Even if the tools have collaboration functions to work together in context, communication still takes place via email (or Slack at best)
• Even when agile methods are used, the iterations are many months long.

Product development needs its own strategy for digital transformation

Product development is at the heart of many value creation models, which is why it deserves its own strategy. After all, products are crucial for the speed of innovation, quality and differentiation in the market.

A genuine transformation requires clear objectives, investment in new methods, the development of system expertise and consistent integration into overall digital processes. Those who remain passive or only focus on optimizing existing processes run the risk of losing touch with more agile, networked competitors.

Artificial intelligence, the current hype, should also be used with caution: The easy way would be to use AI to improve existing processes. This would certainly allow us to quickly improve efficiency by 10-20%. But with newly conceived approaches, such as Extreme hardwarecan increase efficiency by orders of magnitude.

Product development needs agility and models

In times when markets change within months and technological cycles are getting shorter and shorter, agility is becoming a survival principle. But agility doesn't just mean daily stand-ups or a few sprints. Agility means quickly gaining insights, evaluating options and implementing decisions. Agility means short iterations, even with hardware.

This only works if teams work with digital, integrated modelsinstead of transporting information via lengthy documents or e-mail ping-pong. Models are comprehensible, verifiable, capable of simulation - and they enable real parallelism in thinking and acting. This in turn breaks down the traditional silos that often still separate development, production and operations.

We have been seeing this for a long time in software development. Continuous Integration and Continuous Delivery (CI/CD) have long been a reality there. This is also possible with hardware, as SpaceX demonstrated with the The development of the Raptor engines shows that with 2-day cycles work.

The timing problem: crisis meets need for change

Ironically, this kind of restructuring requires freedom: a stable market situation, time to learn and resources for transformation. But that's exactly what many companies don't have at the moment. Supply chains are fragile, cost pressure is growing and the shortage of skilled workers is slowing down initiatives. The dilemma: this is precisely the time when transformation is most urgently needed, but it seems the most difficult to achieve.

Difficult, but feasible. Here are my 6 recommendations on how companies can transform product development despite the crisis:

1. Setting strategic goals

The goals of the transformation must be strategically supported by decision-makers. A good strategic driver is, for example, shortening the length of cycles. A good metric for optimization is the idle time, which can be reduced from weeks to minutes through automation.

2. Small initiatives with measurable results

Long-term goals should be implemented in small, self-contained steps. If, for example, the goal is to integrate simulations into development, the simulations must run automatically, but the changes to requirements (e.g. parameters) must also be propagated automatically. These can be two separate initiatives, both of which have added value.

3. Networking models

Models play a role on many levels, from architecture to simulation. Integrating them into workflows and breaking them out of their silos has enormous potential for automation. It is also important not to translate the models manually, but to use them as first-order artifacts. To do this, however, the team must be able to read the models and recognize their benefits.

4. Bridging silos, not fighting them

The difference is subtle but important: silos will not disappear, teams usually know which tools are right for them. For example, software developers will resist using Polarion or Jama instead of Confluence and Jira, even though this would be perfectly possible. That's why we need to work with the teams and bridge the silos as much as possible, but in no way hinder the work. There are often huge problems between departments (and not within departments).

5. Advancing the integration of IT & engineering

In general, the topic of integration is of central importance. This goes far beyond the integration of models. DevOps-like structures help to work together on processes, tools and feedback loops.

6. Making change visible

Change must be visibly worthwhile. That's why we need to measure the effects of change. Good KPIs are faster change cycles, lower error rates or shorter time-to-market, but also soft factors such as satisfaction with the tools and processes. These figures help to create internal acceptance.

Conclusion: Better late than never

The digital transformation must include product development. In particular, this means agile, model-based work. This is a strategic issue if companies are to remain innovative and competitive. Even if the framework conditions today seem anything but ideal: The best moment to start was yesterday. The second best is today.