Hybrid Product Development Is Bigger Than Agile + Stage-Gate

For those of us who have worked with technology and product development for a couple of decades, hybrid development is hardly new.

We were combining different ways of developing products long before we started calling it hybrid.

As software became an increasingly important part of physical products, it became difficult to run everything according to the same development model. Software teams needed shorter learning loops and more frequent integration. Hardware development continued to depend on prototypes, physical builds, testing and longer lead times. Manufacturing had its own readiness requirements. Management still needed control of investments, risks and major product decisions.

The practical answer in many organisations was not Agile or Stage-Gate.

It was some combination.

During the 2010s, this practice gained a much clearer foundation in the product-development literature. Robert Cooper and Anita Friis Sommer’s work on Agile–Stage-Gate showed how Agile practices could operate inside established Stage-Gate systems, including in companies developing physical products. Their later research examined large manufacturing companies experimenting with such hybrids.

That was an important step.

It moved the discussion away from the rather unproductive question of whether organisations should be Agile or traditional.

But I think we now need to move the discussion again.

The development challenge facing technology and engineering organisations today is bigger than finding the right combination of Agile and Stage-Gate.

A modern product may combine mechanical systems, electronics, embedded software, cloud services, data, AI, manufacturing processes, suppliers and regulatory requirements.

Some parts may be developed in weeks. Others take months.

Some involve considerable uncertainty and require experimentation. Others require formal verification before anything can be released.

Software may continue changing for years after the physical product has entered production. Manufacturing and supply-chain decisions may have to be made long before the complete product is known. And increasingly, upgradeability, sustainability and circularity introduce decisions that extend beyond the traditional idea-to-launch process.

There is no reason to expect one methodology to manage all of this.

Which leads me to a different way of thinking about hybrid product development:

Hybrid is not a methodology. It is an architecture.

The question is therefore no longer:

Should we use Agile, Stage-Gate or both?

It is:

Which development and governance mechanisms does this product and organisation actually need, and where?

Different mechanisms solve different problems

Consider a product combining hardware, embedded software, cloud functionality and a new manufacturing process.

The software teams may benefit from short iterations, automated testing and continuous integration.

The system architecture may need controlled interfaces, configuration management and formal verification.

Hardware development may depend on prototype builds that take weeks or months.

Manufacturing may require tooling, process validation, quality controls and supplier readiness before volume production.

Management may periodically need to decide whether the expected value still justifies another significant investment.

Safety-critical or regulated elements may require formal evidence and traceability.

These are not variations of the same problem.

They are different problems.

A development architecture may therefore contain:

• Agile practices and experimentation where uncertainty requires rapid learning

• Stage-Gate principles around major investment, portfolio and strategic decisions

• systems-engineering or V-model principles where requirements, interfaces and verification matter

• DevOps where software needs continuous integration and evolution

• NPI mechanisms where manufacturing and supply-chain readiness become critical

• formal assurance where regulation, safety or reliability require evidence

• lifecycle mechanisms where upgradeability, maintainability, sustainability or circularity influence development decisions

• supplier and ecosystem governance where important parts of development sit outside the organisation

The point is not which mechanism is best.

They solve different problems.

The real management challenge is deciding where each is needed and how they connect.

Execution cadence is not governance cadence

One distinction becomes particularly important when we start thinking this way.

Execution cadence and governance cadence are not the same thing.

A software team may integrate code several times a day.

That does not mean the organisation should reconsider the product business case several times a day.

A hardware team may complete a major prototype build every eight weeks.

That does not mean system-integration issues should wait eight weeks before being addressed.

Manufacturing readiness may follow physical build milestones. Supplier commitments may operate on completely different lead times. The programme itself may have only a small number of major investment decisions during the development cycle.

These cadences can coexist.

In complex product development, they usually have to.

Execution cadence is about how quickly the work can learn and progress.

Governance cadence is about when the organisation needs to make a consequential decision.

Push governance down to every iteration and teams become burdened by unnecessary controls.

Move learning up to the governance cadence and problems are discovered too late.

This is why I increasingly find discussions about whether an organisation or programme is “Agile” unhelpful.

The more useful question is whether each part of the development system operates at the cadence needed for the uncertainty, dependencies and decisions involved.

AI will push this further

AI adds another dimension.

The first visible impact has largely been at individual level.

Engineers can use AI to support coding, analysis, requirements work and documentation. Project professionals can use it to structure information, analyse risks and prepare decisions.

But AI is increasingly moving beyond personal productivity and into the development process itself.

Requirements analysis, software development, testing, technical search, simulation and evaluation of design alternatives can increasingly be supported or partly automated.

The interesting question is therefore not simply whether AI makes product development faster.

It is:

What happens to the development architecture when parts of the organisation can learn and generate evidence much faster than before?

An engineering team may be able to evaluate far more alternatives in a given period.

That does not automatically mean an architecture decision, safety approval, supplier commitment or production-release decision should happen at the same speed.

AI can accelerate the preparation of a decision.

It does not remove the need to decide who owns that decision, what evidence is sufficient and who remains accountable for the outcome.

AI may therefore increase the difference between the speed at which work can happen and the speed at which governance should happen.

And as AI becomes embedded in workflows rather than simply used by individuals, organisations will need to reconsider where human judgement matters, where assurance is required, and where existing controls may no longer make sense.

We do not yet know exactly what that development system will look like.

But it is another reason why a fixed enterprise methodology is unlikely to be the answer.

The architecture itself will need to evolve.

The research is also moving towards a broader view

The idea of hybrid as architecture is my interpretation of where product development is heading. It is not a conclusion demonstrated by one research study.

But recent research supports parts of the direction.

Sommer and Pisanu’s 2026 study of mission-driven technology maturation examined two multi-partner advanced-manufacturing ecosystems. Rather than treating technology maturation purely as a development process, they considered purpose, strategy, leadership, governance, innovation process, and budgeting and planning together.

Their cases combined iterative learning with more linear maturation and formal governance across organisational boundaries.

It is exploratory research based on two cases, so it should not be treated as a universal development model.

But it illustrates an important point: once development crosses technology and organisational boundaries, process, governance and organisational design become difficult to separate.

Nolte and colleagues approach the problem from another direction. Their 2026 Circular V-Model combines V-model development principles with DevOps and extends the perspective towards upgradeability and circular product lifecycles.

Again, the conclusion is not that everyone should implement a Circular V-Model.

The more interesting point is that increasingly complex products require mechanisms originating from development traditions that were historically treated separately.

That is exactly why I think the discussion about hybrid development needs to become broader.

The enterprise methodology can become part of the problem

There is an irony here.

As product development becomes more complex, many organisations respond by standardising more.

One development model is selected.

Common terminology is introduced.

Standard templates and milestones are created.

Governance forums are established.

Teams are trained.

There are good reasons for some of this.

Common decision criteria are useful. Clear responsibilities are useful. Comparable information is useful. Strong interfaces between functions are useful.

But standardising the entire execution model is something different.

A process designed for exploratory software development is unlikely to be the right model for industrialising a capital-intensive hardware product.

A development model designed around highly regulated systems can unnecessarily constrain an exploratory technology project.

And a team-level Agile method will not solve manufacturing readiness, supplier maturity or system-level trade-offs simply because everybody uses the same terminology.

This can push organisations towards one of two extremes:

governance without sufficient learning and adaptation

or

agility without sufficient decision discipline, integration and accountability.

I think there is a better principle:

Standardise the decisions and interfaces that matter. Allow the execution model to vary where the work differs.

That is a different form of standardisation.

Instead of requiring everyone to work in the same way, define where the organisation genuinely needs consistency.

What evidence is required before another major investment?

When must hardware and software baselines align?

What constitutes manufacturing readiness?

Who owns a system-level trade-off?

When must suppliers commit?

What needs formal verification?

And what information needs to survive from development into manufacturing, operation and future upgrades?

Those interfaces can be highly disciplined even when the work between them is deliberately different.

Start with the product, not the methodology

If hybrid is an architecture, the starting point changes.

Do not begin by deciding whether the programme will be Agile, Stage-Gate, SAFe, V-model or something else.

Start with the product, the uncertainty, the dependencies and the decisions.

I would ask five questions.

1. Which decisions genuinely require governance?

Not every activity needs a gate.

Identify the decisions where the organisation makes a meaningful commitment: funding, architecture, tooling, regulatory exposure, supplier commitment, production release or market launch.

A gate should exist because there is a consequential decision to make — not because the process diagram says it is time for Gate 3.

2. Where do we need rapid learning?

Some parts of the product are reasonably well understood.

Others remain assumptions.

Where customer needs, technologies, architectures or manufacturing processes remain uncertain, the development system needs short learning loops through experiments, prototypes, simulation or incremental development.

The cadence should reflect how quickly meaningful evidence can be generated.

Not an enterprise-wide definition of a sprint.

3. What must be proven?

There is a difference between demonstrating that something can work and proving that an engineered product will work predictably under defined conditions.

Safety, reliability, system performance, interfaces, regulatory compliance and production capability may require traceability, controlled verification and formal evidence.

These mechanisms need to be designed in from the beginning.

4. Where must the different development systems meet?

Complex programmes rarely fail because one individual team cannot manage its backlog.

Problems emerge at interfaces.

Hardware meets software.

Product development meets manufacturing.

Engineering meets suppliers.

Technology maturity meets programme commitments.

Development meets regulatory approval.

And increasingly, AI-enabled workflows will meet human decision-making and assurance.

These synchronisation points need to be designed deliberately.

What must align?

When?

Based on what evidence?

And who has authority to decide?

5. What continues after launch?

The classic NPD funnel tends to end with product launch.

Increasingly, the product does not.

Software evolves.

Hardware is upgraded.

Products generate field data.

Manufacturing processes improve.

Suppliers change.

AI models may need updating.

Regulatory requirements evolve.

And sustainability and circularity introduce questions around repair, reuse, refurbishment, upgradeability and end-of-life recovery.

Product development therefore increasingly becomes a lifecycle capability rather than an idea-to-launch process alone.

The development architecture needs to reflect that.

Hybrid is an architecture

Agile–Stage-Gate was an important step in the evolution of product development.

It demonstrated that adaptability and governance did not have to be alternatives.

But the landscape has moved further.

Products have become more integrated.

Software has become continuous.

Supply chains and technology ecosystems have become part of the development system.

Manufacturing readiness needs to develop alongside product maturity.

Lifecycle considerations increasingly extend beyond launch.

And AI is beginning to change the speed and nature of the work itself.

The answer should not be another branded methodology.

It should be a better way of designing the development system.

What needs to move quickly?

Where do we need experimentation?

What needs formal evidence?

Where must disciplines synchronise?

Which decisions require governance?

Who remains accountable?

And what must continue throughout the lifecycle?

The answers will differ from product to product.

They should.

Hybrid is not about finding the perfect combination of Agile and Stage-Gate.

It is about deliberately designing a coherent development architecture around the decisions, uncertainty, assurance, dependencies and lifecycle of the product being created.

For me, that is the next evolution of hybrid product development.

And it starts not with choosing a methodology, but with understanding the development system we actually need.

The Escape take

For us, the practical implication is simple:

Do not standardise product development around one methodology.

Standardise the decisions, interfaces and evidence that matter — and allow the execution model to vary where the work is fundamentally different.

That means leadership should be explicit about:

• where fast learning is required

• where formal verification is required

• where major investment decisions are made

• where disciplines and suppliers must synchronise

• where accountability must remain human, even as AI accelerates the work

The objective is not to make every team work in the same way.

It is to create a development system that is coherent across the whole product lifecycle.

That is what hybrid should mean in practice.

References

Cooper, R. G., & Sommer, A. F. (2016). The Agile–Stage-Gate Hybrid Model: A Promising New Approach and a New Research Opportunity. Journal of Product Innovation Management, 33(5), 513–526. DOI: 10.1111/jpim.12314.

Cooper, R. G., & Sommer, A. F. (2018). Agile–Stage-Gate for Manufacturers: Changing the Way New Products Are Developed. Research-Technology Management, 61(2), 17–26. DOI: 10.1080/08956308.2018.1421380.

Cooper, R. G., & Brem, A. (2024). The Adoption of AI in New Product Development: Results of a Multi-Firm Study in the US and Europe. Research-Technology Management.

Sommer, A. F., & Pisanu, A. (2026). Design for Mission-Driven Technology Maturation. Proceedings of the Design Society, 6, 307–316.

Nolte, B., Sander, K., Axmann, J., & Vietor, T. (2026). Towards a Life Cycle-Oriented Development Process Model for Upgradeable and Circular Cyber-Physical Systems. Procedia CIRP, 142, 1010–1015.