The four principles for more product speed
I now feel like a scratched record: We have a competition problem, we need to develop better products faster. So far, so good. But how do we go about it? In this article, I present four principles that form the basis for this. The principles are not a panacea, but they are universal enough that they can be understood and applied both at management level and by practitioners. At the same time, they are specific enough to give everyone involved a clear direction and common understanding.
These principles are particularly relevant for systems engineering (SE). This is because SE is the place where value flows, architecture, compliance and V&V converge.
What is meant by „principles“ here
In this context, a principle is a fundamental guiding principle that systematically guides decisions. Principles operate at a higher level of abstraction and answer the question: „What is fundamentally important?“.
Principles can work on different levels of fluidity. The principles of Reinertsen, for example, are much more granular, but are just as fundamental and effective. In many cases, they act as patterns or decision heuristics that can be applied in certain situations, especially when flow is the focus.
Formulated in a similar way Industrial DevOps a broader set of principles aimed at lifecycle integration and digital continuity. There is significant overlap, particularly in areas such as feedback loops and system integration. However, the principles presented here summarize the essentials in just four overarching principles that shape the entire development system.
In short, the principles of Product Velocity are systemic commitments. They influence how we define success, how we structure architecture, how we validate work and how we maintain products throughout their lifecycle.
The four principles
Here are the four principles for Product Velocity. I embed concrete case studies that demonstrate the corresponding principle using a real case study:
1. value thinking: define & align
In many organizations, a lack of speed is not only caused by exploding complexity, but also by a lack of clarity about what is really important for success. Teams optimize locally, while customer value is implicit and often falls by the wayside. These disincentives lead to rework, delay and loss of accountability.
Value Thinking begins with a simple but demanding commitment: we define measurable results and consistently align all relevant players with them. To do this, we continuously sharpen stakeholder needs and make transparent how each activity contributes to the value flow.
Value Thinking strengthens the business perspective by translating stakeholder intentions into common, measurable targets and consistently reflecting these in architecture and engineering decisions. It is less about prioritization in the narrow sense and more about coherence in the overall system.
The Ameru Smart Bin case study provides a practical example. From the outset, the team defined success not as „better accuracy“, but as measurable stakeholder outcomes: Disposal had to be as convenient for users as with traditional garbage cans, operators had to lose significantly fewer recyclables in residual waste, and the recycling rate had to increase enough to make the investment worthwhile. These clear KPIs shaped the design, AI classification thresholds and service decisions. Because the team optimized for stakeholder value rather than isolated technical performance, improvements led directly to economic impact and a resilient return on investment.
2. architect for flow: structuring & scaling
Architecting for Flow shows that speed does not come from improvisation, but from deliberate structure. We build a modular, scalable backbone that brings results to the user quickly without having to discuss the same questions over and over again.
In cyber-physical systems, architecture determines how quickly changes can be implemented, how safely we can experiment and how knowledge is built up across product generations. Interfaces, platform strategies and integrated models are effective economic mechanisms. Unclear boundaries create coordination effort and fragile integrations. Clear modularization allows teams to work largely independently and still ensure system coherence.
This principle primarily strengthens the architecture perspective, but affects the entire system. If the structure is explicit and interfaces remain stable, we accelerate engineering and reduce the risk in implementation.
Wagner's long-term modeling strategy for safety-critical fire protection systems provides an illustrative example. Instead of a one-off transformation, Wagner gradually raised abstraction levels, strengthened encapsulation and established contract-based design as a deliberate architectural direction. Many small steps resulted in a consistent development platform with automation, regression tests and scalable reuse. This significantly shortened certification cycles. The architectural discipline anchored flow directly in the structure of the system.
3. shift left: build & validate
Shift Left addresses one of the most persistent causes of lost speed: late findings. When we postpone integration, verification and validation, uncertainties build up unnoticed until we suddenly find ourselves in a crisis.
Shift Left means systematically moving learning forward. This includes continuous integration of software and hardware, early interface simulations, model-based verification and increasingly AI-supported analyses of requirements and test artifacts. We not only automate existing steps, but also structurally shorten the distance between intention and feedback.
This principle streamlines the engineering perspective by transforming the unknown into validated knowledge as early as possible. This reduces change costs and shortens iteration cycles.
ZF provides an example of this in the development of high-performance electronics. Validation used to dominate as a bottleneck and took up to twelve months due to extensive physical tests and computationally intensive simulations. ZF consistently shifted verification and validation to the front and established model-based digital twins. Structured modeling and AI-supported model reduction, which keeps runtimes manageable, created a repeatable, confidence-building validation capability in the development flow. This reduced the validation time from twelve to two months while maintaining the same safety and compliance standards.
4. accelerate: operate & further develop
The last principle makes it clear: we only ensure speed if development does not end with the market launch. Accelerate sees product development as an ongoing evolutionary process in which operation, feedback and iteration are closely interlinked.
In traditional models, we develop and deliver products and then freeze them until the next major revision. In a product velocity environment, the release marks the transition to a new learning phase. Operating data, digital twins and update mechanisms allow us to further develop the product together with user behavior and environmental conditions.
This principle strengthens the delivery perspective and reconnects it with business and architecture. Feedback from deployment influences backlog prioritization, architecture decisions and even platform strategies.
For Saab, Accelerate means institutionalizing rapid decision-making as an operational capability. Saab established a daily escalation rhythm in which blockers become visible and reach the management level the same morning if necessary. Management sets aside time each day to resolve blockers, making decision delays an actively managed variable rather than an administrative side effect. Problems that would otherwise take weeks to resolve are solved by teams in a matter of hours, protecting the design flow.
What do these principles mean in concrete terms for systems engineering?
In our role as systems engineers, we can use the principles very specifically as a compass in our work:
Value Thinking in SE: We ensure that all aspects of our work can be traced back to a measurable stakeholder value and are ideally linked to it. We ask questions systematically:
- Which problem is solved economically or functionally?
- Which target value changes?
- How do we recognize success?
SE is thus transformed from a documentation provider to a value broker. Requirements are not only managed, but also justified.
Architect for Flow in SE: This is the classic strength of systems engineering, but it is often not used consistently enough. Determine architecture decisions:
- How strongly teams depend on each other
- How complex changes become
- How well models can be integrated
- How much reuse is possible
Architect for Flow requires conscious management of interfaces, abstraction levels and model coherence. MBSE is critically scrutinized and becomes a means of reducing coordination costs.
Shift Left in the SE: SE is traditionally closely linked to verification and validation. But in many organizations, V&V remains organized sequentially. Shift Left in Systems Engineering means:
- Early model validation
- Continuous consistency checks
- Simulation before hardware
- Requirements quality analysis before implementation
- End-to-end traceability that is actually used
This reduces change efforts exponentially and makes uncertainties visible at an early stage.
Accelerate in the SE: For systems engineering, Accelerate means that the system definition does not end with the delivery. We do not think in terms of projects, but in terms of products, and later even platforms.
Feedback from operations must flow back into models, requirements and architecture in a structured manner. Digital twins, OTA updates and data-driven further development are fundamentally changing the role of the SE.
SE becomes a continuous system responsibility over the entire life cycle.
The book: Product Velocity
In my upcoming book Product Velocity I show how organizations systematically implement these four principles.
The book combines systems engineering, architecture, economics and organizational design into a coherent overall picture. It is not about individual tools or methods, but about structural levers with which companies can build sustainable speed.
Many of the case studies described there come from real industrial projects and show how these principles can be applied in practice.
Conclusion
Competitiveness in the 21st century is not achieved by improving the gap, but by creating value for stakeholders. The four principles provide a foundation on which systems engineering can unfold its full effect:
- Make value explicit
- Understanding architecture as an instrument of flow
- Enforce learning at an early stage
- Linking development and operation
Those who take these principles seriously do not just change processes. They change the system in which development takes place.
