Innovation, continuous development and production of multidisciplinary high-tech products

If you’re in a company “only” developing purely digital products, lucky you. You do not have to manage the added complexity in developing and producing multidisciplinary / mechatronics products.

Should you not be so “lucky” and happen to be with a company doing multidisciplinary product development, this post is for you.

An earlier post scratched the surface on how to approach this type of innovation challenge. Here we’ll go a bit deeper, and let’s start with the holy grail as formulated by Elon Musk:

Pace of innovation is all that matters in the long run

Elon Musk @Twitter, Apr 2020

Spoiler alert: There is no equally simple answer to the simple question – how do we achieve fast-paced innivation?

What does it take to achieve Fast-paced Innovation of multidisciplinary high-tech products?

Fast-paced innovationLet’s assume the availability of a time-machine enabling us to jump to the point in time where we’ve reached the goal of achieving fast-paced innovation of our high-tech products.

Exiting the time-machine we’re especially noting three capabilities, developed to excellence:

    • We’ve managed to reduce the calendar-time introducing new products / upgrades by applying parallel workstreams 
    • We’ve managed to achieve a high and sustainable cadence within each work-stream 
    • We’ve managed to keep all the core product risks under control

Below we’ll unfold each of these to-come capabilities.

Parallel work-streams

Minimal inter-team dependencies

The key unlocking this capability is found in the software community and its object-oriented design practices; especially the notion of encapsulation being the discipline of hiding (encapsulating) complexity behind an interface. In the software world such an “interface” is also called an API (Application Programming Interface).

A widespread practice in software development is called “contract first” with contract meaning a stable interface. Do not start implementing the complexity behind the contract, before the contract is agreed / signed. Jeff Bezos (Amazon) is famous for his clear message on the importance of contracts / interfaces in Amazon:

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn’t matter what technology is used. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn’t do this will be fired.

Internal mail in Amazon from Jeff Bezos

As a side-note it is worth mentioning that Amazon has managed to build an extremely successful API business via AWS (Amazon Web Services).

This notion of encapsulation behind stable contracts / APIs applies directly to the non-software domains. Now the contracts are in the form of mechanical and electrical interfaces.

Importance of stable interfacesWith agreed stable contracts, Product Teams can work (fairly) autonomously thus achieving a high degree of parallelism rendering accelerated product development.

In reality the contracts / interfaces are semi-stable. Given a Product Team sees a need for adjustments to the interface-specifications, this Product Teams is taken the responsibility for the coordination efforts with relevant other Product Teams and stakeholders. Without strong and disciplined Configuration Management this could easily degenerate into chaos. 

But it does not stop here. The product design with stable interfaces enables component flexibility in production.

See Joe Justice’s description below of how this is taken to extremes in Tesla’s production. Components entering a Tesla factory is checked against specifications and interfaces being their DoR (Definition of Ready) to be used in production. Sub-assemblies must in a similar way meet a well-defined DoD (Definition of Done) thereby ensuring that it is Ready for the next production step. In Tesla these DoD / DoR verifications are of course done by robots. All this means that changes in hardware configurations happens all the time (which you’ll definitely not see with any other automotive producer).

In addition to the concept of autonomy / encapsulation, we also need to make sure that the Product Teams work towards the same North Star thus staying aligned.

Shared Product Vision and -Strategy: A shared North Star

Multiple earlier posts have elaborated on the importance of having strong product Visions and –Strategies as the driver to task the Product Teams with (hard) business / customer problems to solve and keep the Product Teams aligned. We’ll not repeat that here, just emphasize its importance.

Strong configuration management

Configuration Management is a very complex, yet vitally important, discipline ensuring that we always have a real-time up-to-date and valid understanding of all the details and dependencies in a product. Without it – forget about fast-paced innovation.

One of the key aspects of a strong Product Culture is the disciplined design and execution of experiments, testing a hypothesis. Understanding exactly what configuration is subjected to such experiments is fundamentally important. Without it a company like Tesla would not be able to have its extreme continuous product development.

Part of this Configuration Management is full production traceability. Two instances of the same product (e.g., a given Tesla model) can have different configurations following that product instance from cradle to grave.

High cadence

Limit WIP and/or time-boxing

The Agile community has a lot of empirical evidence showing that working in small batches at a time renders a cadence superior to the cadence achieved when working in big batches – at least when it comes to software development. 

Logically the same principle will apply to non-software development as long as due respect is shown to the physical constraints not present in purely digital products.

Limit physical dependencies

As mentioned earlier a number of initiatives can be taken to reduce the impact of these physical dimensions:

    • use simulation models / digital twins
    • use evaluation kits
    • move relevant parts of hardware to software using e.g., Field Programmable Gate Arrays (FPGAs)
    • maintain the fast and disciplined experiment / learn Product Culture as in pure software products
    • learn from the software guys: encapsulate complexity behind stable APIs / interfaces
    • test integration interfaces again and again – experience clearly shows that problems show-up here
    • use the 3D printing technologies that has become both highly advanced and mature

The more we’re able to reduce physical dependencies, the better we’re paving the way for Set-Based Design.

Set-based design (SBD) is a complex design method that enables robust system design by

1) considering a large number of alternatives,

2) establishing feasibility before making decisions, and

3) using experts who design from their own perspectives and use the intersection between their individual sets to optimize a design (Singer, Doerry, and Buckley 2009).

Model-based engineering (MBE)/model-based systems engineering (MBSE) with an integrated framework can enable the use of SBD tradespace exploration, for some situations (i.e. early-design stage with low fidelity models), in near-real time (Specking et al. 2018a). 

Guide to the Systems Engineering Body of Knowledge

Again – strong Configuration Management is essential.


Marty Cagan has listed four key products risks for especially purely digital products. We need to add a risk-area related to the production of physical products:

Balancing these risks and making fact-based decisions is core in a strong Product Culture as highlighted in earlier posts. The point is that we need to understand and balance all five risks. 


The good news is that achieving a high-paced, sustainable innovation and production of high-tech product is both possible and profitable. Tesla (and SpaceX) are examples of living proof.

The bad news is that it is difficult and hard calling for a fundamental reprogramming of the more “traditional” product company with a traditional modus operandi.

Bonus information

If you can spare some of your time, the videos below by Joe Justice provide an insight into how e.g., Tesla thinks and operates with high-tech product innovation. Nothing less than mind-blowing!


This update to the original post will aim at cherry-picking from Joe Justice’s insights provided in the videos.

    • Working with Bill Gates, Bill’s opening question was always “How much of this can we do in parallel?
    •  Joe Justice’s approach has significant similarities to Henrik Kniberg’s “Spotify Model (though Henrik Kniberg emphasizes that is it not a “model”)
    • It is all about speed of feed-back loops
    • If the company is structured around the cross-functional teams … that is your company structure … you don’t need any other hierarchy
    • Making sure that everything fits together from the autonomous teams calls for continuous integration …  “If something is difficult, do it all the time” (done by robots to a high degree)
    •  “Every car has a digital twin (red.: configuration) with a details down to the single bolt and glue used … everything!“. “This is a major IT-project!
    • Tesla is a digital-native from Silicon Valley making it comfortable doing changes in real-time
    • There is no marketing department, there is no competitive analysis department … because everyone has very clear encouragement to approach the law of physics“. “Any product goal less than what is physically possible is vulnerable to competition

If something is physically possible, not only is someone doing it, but there is also an award show

Elon Musk

    • Traditional lean one-piece flow (the Toyota production system is famous for it) makes change very expensive … encourages getting it perfect before deploying to production … resulting in long lead-time for changes … which again delays getting feedback from production to improve design … rendering the slowest possible deployment cycle“. “The traditional lean one-piece flow is completely inappropriate if you want speed of change!” 
    • In contrast, Massively Parallel Concurrent Manufacturing [MPCM] is optimized for change. Here there is no one-piece production line at all
    •  “In MPCM we’re using massively automated unit and integration tests (like with a build-server in a software environment)
    • Knowledge sharing and -development across teams is facilitated using Communities of Practice (CoP)

NB. Getting CoPs to function will probably be a topic for a future post.