Stage-Gate-Prozess für Produktentwicklung: Was sich 2026 ändert

Kernpunkte

• Agile-Stage-Gate-Hybride behalten die Gates und durchlaufen die Phasen in Sprints. Fallstudien zeigen schnellere Time-to-Market, erfordern aber dedizierte Teams und Gatekeeper, die eine Produktdefinition akzeptieren, die sich im Laufe der Zeit verfestigt.
• KI macht Gate-Deliverables kostengünstig zu produzieren. Gates benötigen nun Nachverfolgungsregeln für Zahlen und Annahmen, sonst passieren polierte Dokumente mit schwachen Belegen.
• Das EU-Register für die Digital Product Passport ging im Juli 2026 live, erste verbindliche Pässe gelten ab 18. Februar 2027. Compliance-Daten müssen nun während der Entwicklung vor dem Launch-Gate produziert werden.
• Ein PIM-System macht die Produktdaten-Bereitschaft zu einem messbaren Gate-Deliverable. Das Launch-Gate kann dann Vollständigkeit pro Kanal prüfen, statt sich auf mündliche Zusicherungen zu verlassen.

Wie der Stage-Gate-Prozess funktioniert

Robert G. Cooper entwickelte das Modell aus Forschungen darüber, was erfolgreiche Markteinführungen von gescheiterten unterschied. Es teilt den Weg von der Idee zum Markt in Phasen auf. Jede Phase besteht aus parallelen Aktivitäten eines funktionsübergreifenden Teams. Jedes Gate ist ein Entscheidungstreffen, in dem leitende Manager Ressourcen für die nächste Phase freigeben oder einbehalten.

Eine vollständige Konfiguration für physische Produkte sieht normalerweise so aus:

• Discovery: Ideen kommen von Kunden, Vertrieb, F&E und Technologie-Scouting. Das erste Gate ist ein leichtes Screening gegen die Strategie.
• Scoping: eine schnelle Schreibtisch-Studie zu Marktgröße, technischer Machbarkeit und Wettbewerbsposition.
• Business Case: die Haupthausaufgaben-Phase mit Customer-Research, Produktdefinition, Finanzmodell und Projektplan. Das folgende Gate ist die Entscheidung zur Entwicklung und meist das teuerste „Ja" im Prozess.
• Entwicklung: Produktdesign, Prototypen, Fertigungsprozessdesign und Launch-Planung.
• Testing und Validierung: Feldversuche, Pilotproduktionen, Zertifizierung und teilweise Testmärkte.
• Launch: Kommerzialisierung, gefolgt von einer Post-Launch-Überprüfung, die Ergebnisse mit dem Business Case vergleicht.

Jedes Gate hat die gleiche Struktur. Das Projektteam bringt Deliverables. Gatekeeper wenden Kriterien an. Das Ergebnis ist eine Entscheidung (Go, Kill, Hold oder Recycle) und ein genehmigter Plan mit Ressourcen für die nächste Phase. Kriterien gibt es typischerweise in zwei Arten. Must-Meet-Kriterien wirken als Ausschlusskriterien. Should-Meet-Kriterien werden bewertet und verwendet, um Projekte im Portfolio gegeneinander zu bewerten.

Die meisten Unternehmen skalieren den Prozess nach Projektrisiko. Cooper beschreibt leichtere Versionen, Stage-Gate XPress und Stage-Gate Lite, für Projekte mit moderatem Risiko und kleinere Änderungen. Eine Linienergänzung kann Scoping mit dem Business Case zusammenfassen. Ein Plattform-Projekt, das auf unbewährter Technologie aufbaut, kann eine zusätzliche Technologie-Entwicklungsphase vor dem Hauptprozess erhalten.

Wo Gate-Entscheidungen scheitern

Der häufigste Fehler ist ein Gate, das nie etwas eliminiert. Jedes Projekt passiert, die Pipeline füllt sich mit mittelmäßiger Arbeit, und Ressourcen werden so dünn verteilt, dass gute Projekte verlangsamen. Teams lernen, dass das Gate eine Formalität ist.

Der weniger sichtbare Fehler ist Evidenz, die niemand überprüfen kann. Eine Marktschätzung sitzt auf einer Folie ohne Quelle. Zielzertifizierungen leben in einem E-Mail-Thread. Ein Kostenmodell hängt von einem Lieferantenzitat ab, das vor zwei Monaten abgelaufen ist. Gatekeeper genehmigen, was sie sehen, und haben keinen Überblick über das Fehlende.

Ein Gate kann nur über die Evidenz urteilen, die es erreicht. Die meisten schlechten Gate-Entscheidungen beginnen in der Phase vor dem Gate.

Beide Fehler verschärfen sich unter den Bedingungen von 2026. Schnellere Zyklen üben Druck auf Gatekeeper aus, zu genehmigen. KI-generierte Deliverables sehen vollständig aus, unabhängig davon, ob die zugrunde liegenden Daten gut sind oder nicht.

Agile-Stage-Gate-Hybride

Hersteller begannen Mitte der 2010er Jahre, Agile-Methoden von Software-Teams zu übernehmen. Im Hybrid-Modell bleiben die Gates erhalten. Innerhalb der Phasen arbeiten Teams in zeitlich begrenzten Sprints, halten tägliche Standups und zeigen Ergebnisse früh den Kunden. Ein Sprint für ein physisches Produkt endet selten mit etwas Auslieferbarem. Es endet mit etwas, worauf ein Kunde reagieren kann: ein virtuelles Modell, ein schneller Prototyp, ein Testergebnis.

Cooper und Anita Friis Sommer untersuchten sechs große Firmen, die solche Hybride durchführten. Einige berichteten von erheblichen Gewinnen bei Time-to-Market und Entwicklungsproduktivität sowie schnelleren Reaktionen auf sich ändernde Kundenbedürfnisse und höherer Teamzufriedenheit. Dieselben Firmen berichteten von Problemen mit Management-Skepsis, dedizierten Teams und Umgang mit fließenden Produktdefinitionen (Quelle: Cooper und Sommer, Research-Technology Management).

Das Problem der fließenden Definition ist am wichtigsten für das Gate-Design. Traditional Stage-Gate sperrt die Produktdefinition beim Development-Gate ein. In einem Hybrid verfestigt sich die Definition Sprint um Sprint. Die Gate-Frage verschiebt sich also. Sie bewegt sich weg von „ist die Spezifikation vollständig" hin zu „wurden die riskantesten Annahmen mit Kunden oder Prototypen getestet?" Gatekeeper, die immer noch eine eingefrorene Spezifikation erwarten, werden entweder den Hybrid blockieren oder Projekte genehmigen, die sie nicht vollständig verstehen.

Einige Anpassungen zeigen sich wiederholt in funktionierenden Hybriden. Das Development-Gate genehmigt ein Budget-Envelope und eine Liste validierter Annahmen. Teams sind einem Projekt gewidmet, da eine Person, die auf fünf Projekte verteilt ist, nicht in Sprints arbeiten kann. Und hardware-spezifische Constraints bleiben im Plan: Tooling-Lieferzeiten und Zertifizierungsplätze schrumpfen nicht, weil das Team Stand-ups abhält.

KI innerhalb der Phasen

KI-Tools entwerfen jetzt Marktzusammenfassungen, generieren Konzeptvarianten, durchsuchen Patente, schreiben Anforderungsdokumente und stellen erste Versionen von Business Cases zusammen. Early Adopter berichten von großen Gewinnen. Die breite Einführung war langsamer. Cooper berichtete, dass nur 13 Prozent der Unternehmen KI in der Produktentwicklung bis Anfang 2023 nutzten, und nannte geringen wahrgenommenen Geschäftswert, schwache Management-Verpflichtung und Vertrauensprobleme als Schlüsselbarrieren (Quelle: Innovation Research Interchange). Der Prozentsatz ist jetzt veraltet. Die Barrieren sind es nicht.

Für Gates ist das Hauptrisiko der KI eine Änderung in dem, was Deliverables signalisieren. Ein vierzehnseitiger Business Case bedeutete früher wochen lange Arbeit. Jetzt kann es einen Nachmittag dauern. Volumen und Politur hören auf, Beweis für Anstrengung oder Strenge zu sein.

Ein Modell, das aufgefordert wird, Marktberichte zusammenzufassen, erzeugt selbstbewusste Zahlen, auch wenn seine Quellen nicht übereinstimmen oder drei Jahre alt sind. Ein Modell, das aufgefordert wird, eine Anforderungsliste zu generieren, erzeugt eine plausible Liste, einschließlich Anforderungen, die niemand mit einem Kunden verifiziert hat. Und KI-Ausgabe erbt die Qualität ihrer Eingabe. Wenn Produktattribute, Testergebnisse und Kostendaten über Tabellenkalkulationen verstreut sind, ist die KI-Zusammenfassung davon auf schwer zu erkennende Weise falsch.

Gate-Kriterien können damit umgehen mit einfachen Regeln. Jede Zahl in einem Business Case verlinkt auf eine Quelle, einen Datensatz oder einen benannten Besitzer, der sich dafür verbürgt. Das Team erklärt, welche Teile eines Deliverables KI-generiert waren und wer sie verifizierte. Schlüsselannahmen über Kundenbedarf und Zahlungsbereitschaft erfordern Kunden- oder Testevidenz als Must-Meet-Kriterium, sodass Model-Output allein sie nicht durch ein Gate tragen kann.

Das verbietet KI nicht. Es verschiebt die Aufmerksamkeit des Gatekeepers vom Dokument zur Evidenzkette dahinter.

Regulierung verschiebt Produktdaten in frühere Phasen

Für Hersteller, die auf dem EU-Markt verkaufen, ist die größte Strukturänderung in 2026 regulatorisch und trifft direkt auf Stage-Gate-Timing.

Die Verordnung (EU) 2024/1781 zur Ecodesign für nachhaltige Produkte führte den Digital Product Passport ein. Am 20. Juli 2026 startete die Europäische Kommission das DPP-Register zusammen mit einer Testumgebung. Wirtschaftsakteure müssen jeden Passport dort über eine Benutzeroberfläche oder eine API registrieren. Das Register wird ESPR-Produktgruppen wie Textilien, Stahl und Aluminium, Reifen, Möbel, IKT-Produkte und energiebezogene Produkte abdecken, plus Gruppen unter anderen EU-Gesetzen, einschließlich bestimmter großer Batterien, Bauprodukten, Spielzeugen und Waschmitteln. Sechs der harmonisierten DPP-Standards sind bereits veröffentlicht, die eindeutige Kennungen, Interoperabilität, Datenträger, APIs, Datenaustauschprotokolle und Datenspeicherung abdecken. Der erste Implementierungstermin ist 18. Februar 2027 für bestimmte Arten großer Batterien (Quelle: Europäische Kommission).

Der Passport-Inhalt kommt aus Entwicklungsarbeit. Materialzusammensetzung, bedenkliche Stoffe, recycelter Gehalt, Reparierbarketsinformationen und Ersatzteilzuverfügbarkeit sind alle Folgen von Design- und Beschaffungsentscheidungen. Die Reihenfolge ist wichtig hier. Ein Team, das ein Material in der Entwicklungsphase auswählt, hat bereits einen Teil des Passports entschieden. Wenn niemand den Passport-Daten bis zur Markteinführung gehört, passiert eines von zwei Dingen. Der Launch verzögert sich, oder das Team rekonstruiert Daten aus Lieferantendokumenten unter Deadline-Druck.

Compliance-Daten brauchen also einen Platz in den Gates:

Das Business Case-Gate sollte ermitteln, welche delegierten Rechtsakte und Passport-Anforderungen in den Zielmärkten gelten, und wann. Ein Produkt, das Ende 2026 zur Entwicklung genehmigt wird, kann nach neuen delegierten Rechtsakten starten. Der Business Case muss für die Regeln zum Launch-Datum planen, nicht für die Regeln zum Genehmigungsdatum.

Die Entwicklungsphase sollte die Passport-Attribute als Design-Outputs erzeugen, mit Lieferantendatenschutzvereinbarungen an Ort und Stelle. Viele Attribute hängen von vorgelagerten Lieferanten ab, und Lieferanten brauchen Vorlaufzeit, um strukturierte Daten zu liefern.

Das Testing- und Validierungs-Gate sollte verifizieren, dass die Attribute vollständig und korrekt sind und dass das Identifikatorsystem und Datenträger (wie ein QR-Code auf dem Produkt oder der Verpackung) definiert sind.

Produkte mit digitalen Elementen sehen eine parallele Timeline unter der Cyber Resilience Act. Ihre Schwachstellen-Meldungsverpflichtungen gelten ab 11. September 2026, und ihre Hauptanforderungen gelten ab 11. Dezember 2027. Ein verbundenes Produkt, das jetzt in die Entwicklung geht, wird wahrscheinlich in das vollständige Regime starten. Sicherheitsanforderungen, Software-Update-Politik und Schwachstellen-Handling gehören in die Produktdefinition beim Business Case-Gate. Sie später nach Design-Einfrierung anzubringen ist teuer.

Supply-Chain-Volatilität fügt ein ruhigeres Problem hinzu. Tarifänderungen und Lieferantenstörungen lassen Grenzkosten-Annahmen schneller ablaufen als Gate-Zyklen. Eine praktische Lösung: Geben Sie jeder Kostenannahme im Business Case ein Gültigkeitsdatum, und verlangen Sie eine Neu-Überprüfung bei jedem Gate nach diesem Datum.

Wo Product Information Management passt

Drei Systemtypen halten normalerweise Produktdaten in einem Herstellerunternehmen. PLM hält Engineering-Daten: CAD-Modelle, Stücklistenmanagement, Engineering-Change-Verwaltung. ERP hält den Item Master für Bestellungen, Kosten und Bestand. Ein Product Information Management (PIM)-System hält die kommerziellen und kanalorientierten Daten: technische Attribute in kundenorientierten Klassifizierungen wie ETIM oder ECLASS, Marketing-Texte, Übersetzungen, Bilder, Datenblätter, Zertifikate und kanalspezifische Formate. Compliance-Attribute für Passports landen zunehmend auch in PIM, da PIM bereits strukturierte, mehrsprachige, kanalfertige Daten handhabt.

In einem klassischen Stage-Gate-Setup erscheint PIM nur beim Launch. Marketing erhält das Produkt kurz vor der Freigabe und beginnt zu schreiben. Das Launch-Gate wird bestanden, und das Produkt ist immer noch nicht über Distributoren oder Marktplätze verkäuflich.

Wenn das Launch-Gate bestanden werden kann, während das Produkt in Ihren Vertriebskanälen unsichtbar ist, misst das Gate die falsche Sache.

Unsere Kunden wenden sich oft mit genau dieser Lücke an uns. Ein typischer Fall ist ein Hersteller von Technischen Komponenten, dessen Distributoren ETIM-klassifizierte Produktdaten verlangen, bevor sie etwas auflisten. Die Datenerstellung begann nach dem Launch-Gate. Engineering schickte Attribut-Tabellenkalkulationen an das Produktmanagement, Produktmanagement reformatierte sie, und Übersetzungen kamen zuletzt. Sales hatte das Produkt bereits angekündigt, und Distributor-Listings folgten Wochen später. Die Lösung hatte weniger mit Software als mit Timing zu tun. Der Produktdatensatz wurde beim Business Case-Gate mit einem Entwurfs-Attributsatz erstellt. Engineering füllte technische Attribute während der Entwicklung als Design-Outputs. Kanal-Vollständigkeit wurde ein Must-Meet-Kriterium beim Launch-Gate. Listings gingen dann mit dem Launch live.

Die Zuordnung von PIM zu Gates funktioniert am besten, wenn jedes Gate ein konkretes Datadeliverable erhält:

• Business Case-Gate: Ein Produktdatensatz existiert mit Klassifizierung, Zielkanäle, Zielmärkte und die Liste erforderlicher Attribute pro Kanal und Regulierung.
• Development-Gate: Technische und Compliance-Attribute werden gefüllt, wenn Design-Entscheidungen getroffen werden, mit angeforderten Lieferantendaten.
• Launch-Gate: Die Vollständigkeit pro Kanal und pro Markt erfüllt einen definierten Schwellenwert, und Assets und Übersetzungen sind genehmigt.

Es gibt Kompromisse. PIM ersetzt PLM nicht, und Engineering-Change-Management sollte in PLM bleiben. Frühe Produktdatensätze erzeugen auch Unordnung, da gelöschte Projekte Daten hinterlassen. Ein Projekt-Status-Attribut und eine Archivierungsregel für gelöschte Projekte halten das PIM sauber. Und Integration ist wichtig. Wenn Attributwerte zweimal eingegeben werden, einmal in PLM und einmal in PIM, multiplizieren sich Fehler. Eine Synchronisierung von PLM für Engineering-Attribute ist normalerweise die Setup-Anstrengung wert.

Risiken, die zwischen Gates sitzen

Einige Risiken gehören zu keiner einzelnen Phase, daher besitzt standardmäßig kein Gate sie.

Portfolio-Überlastung ist das älteste. Gates evaluieren Projekte einzeln, und jedes Projekt kann auf sich selbst in Ordnung aussehen, während das Total die Kapazität übersteigt. Ein Portfolio-Review, das Ressourcen-Nachfrage mit verfügbaren Personen vergleicht, sollte mindestens vierteljährlich, getrennt von einzelnen Gates, durchgeführt werden.

Versunkene-Kosten-Druck wächst bei späten Gates. Ein Projekt nach der Entwicklungsphase zu töten fühlt sich verschwenderisch an, daher genehmigen Gatekeeper Projekte mit sich verschlechterndem Business Case. Die Neubetrachtung von Late-Stage-Projekten gegen die ursprünglichen Must-Meet-Kriterien macht das sichtbar.

Regulatorische Termine fallen auch zwischen Gates. Ein delegierter Rechtsakt, der während der Entwicklung veröffentlicht wird, kann Passport-Anforderungen für ein bereits genehmigtes Produkt ändern. Jemand muss Regulierungsänderungen für das aktive Portfolio überwachen, und der offensichtliche Besitzer ist eine Compliance- oder Produktdaten-Rolle mit Sitz bei Gate-Treffen.

Post-Launch-Reviews werden meistens übersprungen. Ohne sie lernt niemand, ob die Business Case-Annahmen hielten. Das umfasst auch die KI-generierten. Das Review ist auch der günstigste Platz, um zu überprüfen, ob Produktdaten in Kanälen dem entsprechen, was beim Launch genehmigt wurde.