Key Takeaways
- Agile-Stage-Gate hybrids keep the gates and run the stages in sprints. Case firms report faster time to market, but the model needs dedicated teams and gatekeepers who accept a product definition that firms up over time.
- AI makes gate deliverables cheap to produce. Gates now need provenance rules for numbers and assumptions, or polished documents will pass on weak evidence.
- The EU Digital Product Passport Registry went live in July 2026, and the first mandatory passports apply from 18 February 2027. Compliance data now has to be produced during development, before the launch gate.
- A PIM system turns product data readiness into a measurable gate deliverable. The launch gate can then check completeness per channel instead of collecting verbal assurances.
How The Stage-Gate Process Works
Robert G. Cooper built the model from research into what separated successful launches from failed ones. It splits the path from idea to market into stages. Each stage is a set of parallel activities run by a cross-functional team. Each gate is a decision meeting where senior managers commit or withhold resources for the next stage.
A full configuration for physical products usually looks like this:
- Discovery: ideas come from customers, sales, R&D and technology scouting. The first gate is a light screen against strategy.
- Scoping: a fast desk study of market size, technical feasibility, and competitive position.
- Business case: the main homework stage, with voice-of-customer research, a product definition, a financial model and a project plan. The gate after it is the go-to-development decision and usually the most expensive "yes" in the process.
- Development: product design, prototypes, manufacturing process design, and launch planning.
- Testing and validation: field trials, pilot production runs, certification, and sometimes test markets.
- Launch: commercialization, followed by a post-launch review that compares results with the business case.
Every gate has the same structure. The project team brings deliverables. Gatekeepers apply criteria. The output is a decision (go, kill, hold, or recycle) and an approved plan with resources for the next stage. Criteria typically come in two types. Must-meet criteria work as knockouts. Should-meet criteria are scored and used to rank projects against each other in the portfolio.
Most companies scale the process to project risk. Cooper describes lighter versions, Stage-Gate XPress and Stage-Gate Lite, for moderate-risk projects and minor changes. A line extension may merge scoping with the business case. A platform project built on unproven technology may get an extra technology development stage in front of the main process.
Where Gate Decisions Fail
The most common failure is a gate that never kills anything. Every project passes, the pipeline fills with mediocre work, and resources spread so thin that good projects slow down too. Teams learn that the gate is a formality.
The less visible failure is evidence that nobody can check. A market estimate sits in a slide with no source. Target certifications live in an email thread. A cost model depends on a supplier quote that expired two months ago. Gatekeepers approve what they see, and they have no view of what's missing.
A gate can only judge the evidence that reaches it. Most bad gate decisions start in the stage before the gate.
Both failures get worse under 2026 conditions. Faster cycles put pressure on gatekeepers to approve. AI-generated deliverables look complete whether the underlying data is good or not.
Agile-Stage-Gate Hybrids
Manufacturers started borrowing Agile methods from software teams in the mid-2010s. In the hybrid model, the gates stay. Inside the stages, teams work in time-boxed sprints, hold daily stand-ups, and show results to customers early. A sprint for a physical product rarely ends with something shippable. It ends with something a customer can react to: a virtual model, a rapid prototype, a test result.
Cooper and Anita Friis Sommer studied six major firms running such hybrids. Some reported significant gains in time to market and development productivity, along with faster reactions to changing customer needs and higher team morale. The same firms reported problems with management skepticism, staffing dedicated teams, and handling fluid product definitions (source: Cooper and Sommer, Research-Technology Management).
The fluid definition issue matters most for gate design. Traditional stage-gate locks the product definition at the development gate. In a hybrid, the definition firms up sprint by sprint. So the gate question shifts. It moves away from "is the specification complete" and toward "have the riskiest assumptions been tested with customers or prototypes?" Gatekeepers who still expect a frozen specification will either block the hybrid or approve projects they don't fully understand.
A few adjustments show up repeatedly in working hybrids. The development gate approves a budget envelope and a list of validated assumptions. Teams are dedicated to one project, because a person split across five projects can't work in sprints. And hardware-specific constraints stay in the plan: tooling lead times and certification slots don't shrink because the team holds stand-ups.
AI Inside The Stages
AI tools now draft market summaries, generate concept variants, screen patents, write requirement documents, and assemble first versions of business cases. Early adopters report large gains. Broad adoption has been slower. Cooper reported that only 13 percent of firms used AI in new product development by early 2023, and named low perceived business value, weak management commitment, and trust issues as key barriers (source: Innovation Research Interchange). The percentage is dated now. The barriers are not.
For gates, the main AI risk is a change in what deliverables signal. A forty-page business case used to mean weeks of work. Now it can take an afternoon. Volume and polish stop being evidence of effort or rigor.
A model asked to summarize market reports will produce confident numbers even when its sources disagree or are three years old. A model asked to generate a requirements list will produce a plausible list, including requirements nobody verified with a customer. And AI output inherits the quality of its input. If product attributes, test results, and cost data are scattered across spreadsheets, the AI summary of them is wrong in ways that are hard to spot.
Gate criteria can handle this with simple rules. Every number in a business case links to a source, a dataset, or a named owner who vouches for it. The team states which parts of a deliverable were AI-generated and who verified them. Key assumptions about customer needs and willingness to pay require customer or test evidence as a must-meet criterion, so model output alone can't carry them through a gate.
None of this bans AI. It moves the gatekeeper's attention from the document to the evidence chain behind it.
Regulation Moves Product Data Into Earlier Stages
For manufacturers selling into the EU, the biggest structural change in 2026 is regulatory, and it lands directly on stage-gate timing.
The Ecodesign for Sustainable Products Regulation (EU) 2024/1781 introduced the Digital Product Passport. On 20 July 2026, the European Commission launched the DPP Registry together with a testing environment. Economic operators must register each passport there, via a user interface or an API. The Registry will cover ESPR product groups such as textiles, steel and aluminium, tyres, furniture, ICT products and energy-related products, plus groups under other EU laws, including certain large batteries, construction products, toys and detergents. Six of the harmonised DPP standards are already published, covering unique identifiers, interoperability, data carriers, APIs, data exchange protocols and data storage. The first implementation deadline is 18 February 2027, for certain types of large batteries (source: European Commission).
The passport content comes from development work. Material composition, substances of concern, recycled content, repairability information, and spare part availability are all consequences of design and sourcing decisions. The sequence matters here. A team that picks a material in the development stage has already decided part of the passport. If nobody owns passport data until launch, one of two things happens. The launch slips, or the team reconstructs data from supplier documents under deadline pressure.
So compliance data needs a home in the gates:
The business case gate should identify which delegated acts and passport requirements apply in the target markets, and when. A product approved for development in late 2026 may launch after new delegated acts take effect. The business case has to plan for the rules at the launch date, which are not the rules at the approval date.
The development stage should produce the passport attributes as design outputs, with supplier data agreements in place. Many attributes depend on upstream suppliers, and suppliers need lead time to deliver structured data.
The testing and validation gate should verify that the attributes are complete and correct and that the identifier scheme and data carrier (such as a QR code on the product or packaging) are defined.
Products with digital elements face a parallel timeline under the Cyber Resilience Act. Its vulnerability reporting obligations apply from 11 September 2026, and its main requirements apply from 11 December 2027. A connected product entering development now will likely launch into the full regime. Security requirements, software update policy, and vulnerability handling belong in the product definition at the business case gate. Retrofitting them after design freeze is expensive.
Supply chain volatility adds a quieter problem. Tariff changes and supplier disruptions make landed cost assumptions expire faster than gate cycles. A practical fix: give every cost assumption in the business case a validity date, and require a re-check at each gate after that date passes.
Where Product Information Management Fits
Three system types usually hold product data in a manufacturing company. PLM holds engineering data: CAD models, bills of materials, engineering change management. ERP holds the item master for orders, costs, and inventory. A Product Information Management (PIM) system holds the commercial and channel-facing data: technical attributes in customer-facing classifications such as ETIM or ECLASS, marketing texts, translations, images, data sheets, certificates and channel-specific formats. Compliance attributes for passports increasingly land in PIM too, because PIM already handles structured, multilingual, channel-ready data.
In a classic stage-gate setup, PIM appears only at launch. Marketing receives the product shortly before release and starts writing. The launch gate passes, and the product still isn't sellable through distributors or marketplaces.
If the launch gate can pass while the product is invisible in your sales channels, the gate measures the wrong thing.
Our customers often turn to us with this exact gap. One typical case is a manufacturer of technical components whose distributors require ETIM-classified product data before they list anything. Data creation started after the launch gate. Engineering sent attribute spreadsheets to product management, product management reformatted them, and translations came last. Sales had already announced the product, and distributor listings followed weeks later. The fix had less to do with software than with timing. The product record was created at the business case gate with a draft attribute set. Engineering filled technical attributes during development as design outputs. Channel completeness became a must-meet criterion at the launch gate. Listings then went live with the launch.
Mapping PIM to gates works best when each gate gets a concrete data deliverable:
- Business case gate: a product record exists with classification, target channels, target markets, and the list of required attributes per channel and regulation.
- Development gate: technical and compliance attributes are populated as design decisions are made, with supplier data requested.
- Launch gate: completeness per channel and per market meets a defined threshold, and assets and translations are approved.
There are trade-offs. PIM does not replace PLM, and engineering change management should stay in PLM. Early product records also create clutter, because killed projects leave data behind. A project status attribute and an archiving rule for killed projects keep the PIM clean. And integration matters. If attribute values are typed twice, once in PLM and once in PIM, errors multiply. A sync from PLM for engineering attributes is usually worth the setup effort.
Risks That Sit Between Gates
Some risks don't belong to any single stage, so no gate owns them by default.
Portfolio overload is the oldest one. Gates evaluate projects one at a time, and each project can look fine on its own while the total exceeds capacity. A portfolio review that compares resource demand with available people should run at least quarterly, separate from individual gates.
Sunk cost pressure grows at late gates. Killing a project after the development stage feels wasteful, so gatekeepers approve projects with a deteriorating business case. Re-scoring late-stage projects against the original must-meet criteria makes this visible.
Regulatory dates also fall between gates. A delegated act published during development can change passport requirements for a product already approved. Someone needs to monitor regulatory changes for the active portfolio, and the obvious owner is a compliance or product data role with a seat at gate meetings.
Post-launch reviews get skipped most of the time. Without them, nobody learns whether the business case assumptions held. That includes the AI-generated ones. The review is also the cheapest place to check if product data in channels matches what was approved at launch.