Die meisten Head-of-Product-Jobs werden auf das Bauen geschrieben. In der Realität ist das Aufhören die schwerere Entscheidung. 14 FTE aus zwei EOL-Produkten in eine Wachstumsunit umzuziehen ist kein Delivery-Thema — es ist eine Organisationsentscheidung, die als Produktentscheidung verkleidet ist.
Das Schweigen über Feature Freeze
In Product-Management-Literatur gibt es viel über Discovery, Pricing, Roadmaps, Stakeholder-Management, OKRs. Feature Freeze — das explizite Aufhören, Neues an einem Produkt zu bauen — kommt kaum vor. Wenn es auftaucht, dann als operative Konsequenz: "Produkt X geht EOL, also kein neues Feature mehr." Die Entscheidung dahinter wird nicht diskutiert.
Das ist auffällig. Weil genau diese Entscheidung in jeder reifen Produktorganisation die schwerste ist.
In der Wachstumsphase ist Produktarbeit ein Additions-Job. Man baut dazu. Man skaliert. Man nimmt Kunden mit, man nimmt Features mit. Alle Beteiligten sind in dieselbe Richtung motiviert — Engineering will bauen, Product will liefern, Sales will verkaufen, Kunden wollen mehr.
In der Portfolio-Reifephase ist Produktarbeit ein Subtraktionsjob. Man baut ab. Man konsolidiert. Man nimmt Kunden nicht immer mit — weil man eine Produktlinie schließt, von der sie abhängen. Alle Beteiligten sind in verschiedene Richtungen motiviert. Engineering liebt das alte Produkt, weil sie es gebaut haben. Product Management hat den Business-Case für den Abbau geschrieben und wird trotzdem im Meeting gefragt, ob das wirklich nötig ist. Sales will die Kunden nicht verlieren. Kunden wollen keine Migration.
Und mitten in dieses Spannungsfeld kommt die Führungskraft und sagt: Wir hören auf.
Die Mathematik dahinter ist simpel
Bei d.velop gab es zwei Legacy-Produkte, die in ihrer Zielarchitektur nicht mehr zum strategischen Kurs passten. Sie liefen noch, sie hatten noch Kunden, sie waren noch profitabel in der Wartung. Aber sie waren nicht der Ort, an dem die Zukunft lag.
Die Zukunft lag in der d.velop postbox — der Plattform-Unit, die gleichzeitig die Mobile-Strategie, die Identity-Strategie und die Cross-Produkt-Kollaboration tragen sollte. Die Zielkapazität der postbox-Unit für 2025: 31,5 FTE, was 80 % der relevanten Gesamtkapazität entsprach.
Der Weg dorthin: 14 FTE aus den beiden Legacy-Produkten herausziehen und in die postbox-Unit umziehen. Nicht als HR-Aktion, sondern als Produktentscheidung mit HR-Konsequenz.
Die Mathematik dahinter ist simpel. Wenn du 14 FTE in ein wachsendes Produkt investierst, investierst du 14 FTE × 1,5 Jahre × durchschnittliche Projekt-Velocity — in neuer Technologie, in der richtigen Architektur, an der Schnittstelle, an der deine Kunden in fünf Jahren sein werden. Wenn du die 14 FTE in zwei Legacy-Produkten lässt, bekommst du Wartung. Wartung ist wichtig — Wartung ist nicht Zukunft.
Die Mathematik ist simpel. Die Entscheidung ist schwer.
Warum Feature Freeze härter ist als Feature-Launch
Drei Gründe.
Erstens: Es gibt keinen Launch-Moment. Bei einem Feature-Launch hast du einen Tag, an dem die Arbeit sichtbar wird. Alle klatschen, die Zahlen ziehen an, das Team hat ein Erfolgserlebnis. Bei einem Feature Freeze hast du einen Tag, an dem die Arbeit unsichtbar wird. Keiner klatscht. Die Zahlen passieren woanders. Das Team, das das alte Produkt gebaut hat, hat ein Abschieds-Erlebnis, kein Erfolgs-Erlebnis.
Zweitens: Die Opposition ist rational. Jemand, der gegen einen Feature-Launch argumentiert, hat meistens einen schwachen Punkt — fehlende Validierung, unklare Monetarisierung, zu viel Scope. Das ist produktiv, aber argumentierbar. Jemand, der gegen einen Feature Freeze argumentiert, hat meistens einen starken Punkt — das alte Produkt hat zahlende Kunden, das Team hat Expertise, der Umsatz ist real. Die Gegenargumente sind wahr. Sie sind nur nicht relevant, wenn man auf Portfolio-Ebene entscheidet.
Drittens: Die persönliche Kosten-Seite ist asymmetrisch. Ein erfolgreicher Feature-Launch verbessert den Ruf eines Head of Product. Ein erfolgreicher Feature Freeze verbessert ihn nicht — er verhindert im besten Fall, dass in 18 Monaten eine Organisation mit zu viel Ballast kippt. Das ist ein negativer Ergebnis-Raum: die Abwesenheit eines Schadens, nicht das Vorhandensein eines Gewinns. Menschen erinnern sich nicht an vermiedene Schäden.
Die Mechanik einer guten Feature-Freeze-Entscheidung
Wie trifft man sie gut?
Erster Schritt: Die Entscheidung ist eine Kapazitätsentscheidung, keine Produktentscheidung. Die Frage ist nicht "Lohnt sich das alte Produkt noch?" — die Frage ist "Wo erzeugen 14 FTE in den nächsten 18 Monaten den höchsten Portfolio-Wert?" Wer die erste Frage stellt, bekommt eine Debatte über Umsatz und Kundenbindung. Wer die zweite Frage stellt, bekommt eine Debatte über Kapazitäts-Allokation. Nur die zweite Debatte ist steuerbar.
Zweiter Schritt: Der Feature Freeze ist nicht der EOL. Das ist die wichtigste sprachliche Disziplin. Feature Freeze heißt: keine neuen Funktionen mehr, aber weiterhin Wartung, Security-Updates, Kunden-Support auf vertraglich zugesicherten Niveau. EOL heißt: das Produkt geht aus. Wer die beiden vermischt, erzeugt bei Kunden Panik und bei Sales Widerstand. Wer sie trennt, macht den Freeze zu einer operativen Neuigkeit, nicht zu einer Existenzkrise.
Dritter Schritt: Der Team-Umzug braucht eine klare Heimat. 14 FTE aus einem vertrauten Setup in eine unklare Struktur zu bewegen, erzeugt Attrition. Der Umzug funktioniert nur, wenn das Zielprodukt eine erkennbare Story, ein erkennbares Team und ein erkennbares Stück Arbeit hat, auf das die Menschen sich freuen können. Bei d.velop war das die postbox-Unit mit klarem strategischem Mandat, Plattform-Ambition und wachsendem Scope.
Vierter Schritt: Kunden-Kommunikation erst nach interner Entscheidung. Wer öffentlich macht, was noch nicht intern entschieden ist, verliert Verhandlungsspielraum. Wer intern die Entscheidung getroffen hat, kann Kunden sauber einordnen: was ändert sich, was nicht, bis wann.
Fünfter Schritt: Die Cross-Training-Investition. Zwei postbox-Consultants wurden seit Q4 2024 cross-trainiert, um Ressourcen-Bewegungen zwischen Produkten zu ermöglichen. Das ist kein operativer Overhead — das ist die Voraussetzung dafür, dass ein Feature Freeze nicht zu einer Kompetenz-Insel wird, die später wieder aufgetaut werden muss.
Was Feature Freeze über Head-of-Product-Arbeit verrät
Wenn ich mir die 2024er d.velop-mobile-services-Zeit anschaue, war Feature Freeze eine der drei härtesten Entscheidungen. Die anderen waren die Taskforce für einen kritischen Enterprise-Account und die Einführung des "Operative Kühe"-Prozesses für Querschnittsrisiken.
Alle drei haben das gleiche Muster. Sie bewegen Kapazität, nicht Features. Sie sind die Art Arbeit, für die in einem PM-Job-Profil selten ein eigener Abschnitt steht — und die trotzdem den Unterschied zwischen einer Produkt-Unit, die skaliert, und einer, die in die Breite läuft, entscheidet.
Drei Einsichten, die ich aus der Freeze-Arbeit mitnehme:
- Die Frage "Was bauen wir als Nächstes?" ist interessanter. Die Frage "Was hören wir auf zu bauen?" ist wichtiger. Nicht jedem Head of Product liegt die zweite Frage. Manche Rollen brauchen explizit die Erlaubnis, sie zu stellen. Wenn die Erlaubnis nicht kommt, kommt auch das Ergebnis nicht.
- Roadmap-Diskussionen kaschieren häufig fehlende Kapazitätsdiskussionen. Wer eine Roadmap mit 12 Features vorstellt, die auf 4 FTE geplant sind, stellt keine Roadmap vor — der stellt eine Wunschliste vor. Eine ehrliche Roadmap beginnt mit der Kapazitätszahl und endet bei dem, was sie erlaubt. Feature Freeze ist die Vorbereitung dafür, dass die Kapazitätszahl überhaupt in Bewegung kommt.
- Die Bewertung eines Head of Product sollte den vermiedenen Schaden einschließen. Eine Organisation, die in 18 Monaten 14 FTE auf Legacy-Wartung hat, die in die falsche Richtung läuft, ist eine Organisation mit einem 14-FTE-Problem. Wenn der Head of Product es rechtzeitig bewegt, sieht man das Problem nie. Das ist eine Leistung, die schwer sichtbar zu machen ist — und die trotzdem die wichtigste ist.
Zurück zur Eingangsfrage
Feature Freeze ist kein operatives Nebenthema. Feature Freeze ist der Führungsakt, der eine Produktorganisation vom Addieren zum Komponieren bewegt. Wer Head of Product ist und nie einen Feature Freeze entschieden hat, hat entweder Glück gehabt — oder die Portfolio-Ebene nie betreten.
Die 14 FTE bei d.velop sind mittlerweile in der postbox-Unit angekommen. Die beiden Legacy-Produkte laufen im Wartungsmodus, ihre Kunden sind informiert, ihre Rolle im Portfolio ist klar. Die Wachstumsunit hat die Kapazität, die sie für 2025/2026 braucht.
Das ist, was nach einem guten Feature Freeze zurückbleibt: eine Organisation, die an der richtigen Stelle arbeitet. Still, aber entscheidend.