Wer entscheidet, was wirklich zu den Nutzern gelangt

Die Pipeline läuft. Tests sind grün. Der Deploy-Button wartet. Aber niemand drückt ihn.

Warum? Weil jemand entscheiden muss, ob diese bestimmte Version tatsächlich zu den Nutzern soll. Diese Entscheidung ist nicht technisch. Sie ist eine Produkt- und Koordinationsentscheidung. Und wenn sie nicht klar getroffen wird, dreht sich die Pipeline im Kreis.

Zwei Rollen treffen diese Entscheidung: der Product Manager und der Release Manager. Sie sind nicht dieselbe Person und machen nicht denselben Job. Aber gemeinsam beantworten sie die Frage, die kein CI/CD-System beantworten kann: „Soll das jetzt raus?“

Der Product Manager entscheidet, was gebaut wird

Der Product Manager schreibt weder Code noch betreibt er Pipelines. Seine Aufgabe ist es zu verstehen, was Nutzer und das Unternehmen wirklich brauchen, und das in Arbeit für das Engineering-Team zu übersetzen. Im CI/CD-Kontext zählt diese Rolle, bevor auch nur eine Zeile Code geschrieben ist.

Der Product Manager entscheidet, welches Feature in den nächsten Sprint kommt, welches verschoben und welches ganz gestrichen wird. Diese Entscheidung wirkt sich direkt darauf aus, wie reibungslos die Auslieferung läuft.

Priorisiert der Product Manager ein zu großes Feature, wird das Team überfordert und der Release verzögert sich. Wechseln die Prioritäten zu oft, werfen Entwickler halbfertige Arbeit weg. Ein guter Product Manager versteht, dass Priorisierung nicht nur bedeutet „was ist am wichtigsten?“, sondern auch „was kann realistisch fertiggestellt und ausgeliefert werden?“

Hier interagieren Product Manager und CI/CD-System. Eine schnelle Pipeline nützt nichts, wenn das Team ständig am falschen Thema arbeitet. Der Product Manager stellt sicher, dass die Pipeline mit Arbeit gefüttert wird, die klar definiert, richtig dimensioniert und an den Nutzerbedürfnissen ausgerichtet ist.

Der Release Manager koordiniert, wann es rausgeht

Der Release Manager koordiniert, wann und wie ein Release tatsächlich stattfindet. Mal ist es eine dedizierte Rolle, mal rotiert sie unter DevOps-Ingenieuren oder Tech Leads. Die Funktion bleibt gleich: sicherstellen, dass alle bereit sind, bevor eine Version in Produktion geht.

Was koordiniert ein Release Manager konkret?

Erstens den Release-Zeitplan. Arbeitet das Team nach einem festen Rhythmus, etwa jeden Donnerstag um 14 Uhr? Oder wird ausgeliefert, sobald ein Feature fertig ist? Beide Ansätze funktionieren, aber der Release Manager stellt sicher, dass alle wissen, welcher gerade gilt.

Zweitens die technische Bereitschaft. Sind alle Änderungen in den Haupt-Branch gemergt? Sind alle Tests grün? Wurde die Datenbankmigration auf der Staging-Umgebung durchgeführt? Diese Checks klingen banal, werden aber oft übersprungen, wenn jeder annimmt, ein anderer hätte sie erledigt.

Drittens die Kommunikation. Weiß der Support, dass eine Änderung ansteht? Ist das Marketing vorbereitet, falls das neue Feature angekündigt werden muss? Ein Release, der andere Teams überrascht, verursacht Chaos – selbst wenn der Code perfekt ist.

Der Release Manager führt auch die Go/No-Go-Entscheidung herbei. Das ist der Moment, in dem alle zusammenkommen – oft in einem kurzen Chat oder Meeting – und entscheiden, ob der Release durchgeführt oder verschoben wird. Wurde gerade ein kritischer Bug entdeckt, sagt der Release Manager „Stopp“. Sieht alles sicher aus, gibt er grünes Licht.

Wie diese beiden Rollen mit dem Engineering-Team zusammenarbeiten

Product Manager und Release Manager agieren nicht im luftleeren Raum. Sie stehen ständig im Austausch mit dem Engineering-Team.

Der Product Manager spricht mit den Entwicklern, um den Aufwand eines Features einzuschätzen. Ein Feature, das für einen Nicht-Techniker simpel klingt, kann Wochen Arbeit bedeuten. Der Product Manager braucht diese Einschätzung für realistische Priorisierungen.

Der Release Manager spricht mit der QA, um zu erfahren, ob die Tests ausreichen. Er spricht mit DevOps, ob die Infrastruktur für die neue Version bereit ist. Er spricht mit dem Product Manager, ob eine Verzögerung bei einem Feature den gesamten Release-Plan beeinflusst.

In reifen Teams wird diese Interaktion durch Praktiken wie Feature Flags flüssiger. Mit Feature Flags kann der Product Manager steuern, welche Features für welche Nutzer aktiv sind, ohne auf einen Release-Zeitplan warten zu müssen. Der Release Manager fühlt sich ebenfalls weniger unter Druck, weil der Code bereits in Produktion ist – auch wenn er noch nicht aktiv ist.

Doch Feature Flags sind kein Wundermittel. Sie erfordern weiterhin Koordination. Flags, die sich ohne Bereinigung ansammeln, werden zu technischen Schulden. Product Manager und Release Manager müssen nachverfolgen, welche Flags existieren, welche aktiv sind und welche entfernt werden können.

Diese Rollen sind keine Gatekeeper

Es ist leicht, Product Manager und Release Manager als Hindernisse zu sehen. Entwickler wollen ausliefern. Die Pipeline ist bereit. Warum auf ein „Ja“ warten?

Aber diese Rollen verhindern Verschwendung. Stell dir vor, Entwickler coden tagelang, nur um festzustellen, dass das Feature nicht dem entspricht, was Nutzer wirklich brauchen. Oder das Team ist bereit zum Deployen, aber das Marketing hat die Ankündigung nicht vorbereitet. Beide Szenarien verschwenden Aufwand und erzeugen Frustration.

Der Product Manager verhindert das erste Szenario, indem er sicherstellt, dass das Team das Richtige baut. Der Release Manager verhindert das zweite Szenario, indem er sicherstellt, dass die Organisation bereit ist, die neue Version zu empfangen.

Praxis-Checkliste für Product und Release Manager

Wenn du eine dieser Rollen übernimmst oder mit Menschen in diesen Rollen zusammenarbeitest, hier eine kurze Checkliste für eine reibungslose Auslieferung:

• Vor der Sprintplanung: Bestätige, dass das Feature klar definiert und realistisch dimensioniert ist. Ist es zu groß, zerlege es.
• Bevor Code geschrieben wird: Sprich mit den Entwicklern über Aufwandsschätzungen. Geh nicht davon aus, dass ein Feature klein ist, nur weil es einfach klingt.
• Vor dem Merge: Prüfe, ob alle Änderungen reviewed und getestet sind. Lass „das reparieren wir später“ nicht zur Norm werden.
• Vor dem Release-Tag: Bestätige, dass Support, Marketing und andere Teams über den Release informiert sind. Überraschungen verursachen Chaos.
• Vor der Go/No-Go-Entscheidung: Prüfe Testergebnisse, Migrationsstatus und bekannte Probleme. Ist etwas unklar, verschiebe den Release.
• Nach dem Release: Verfolge, welche Feature Flags noch aktiv sind. Räume sie vor dem nächsten Release-Zyklus auf.

Das Fazit

Eine schnelle Pipeline nützt nichts, wenn die falschen Features gebaut werden oder die Organisation nicht bereit ist, sie zu empfangen. Product Manager und Release Manager sind nicht da, um dich auszubremsen. Sie sind da, um sicherzustellen, dass der Knopfdruck wirklich etwas bedeutet.