Ein Onboarding-Test hebt die Aktivierung um vier Prozentpunkte. Ein Quartal später will niemand mehr den neuen Flow anfassen, und die Supportanfragen steigen.
Mit schlechter Arbeit hat das selten zu tun. Solche Szenen entstehen, wenn ein starkes Produktteam und ein ehrgeiziges Growth-Team nebeneinander existieren, ohne als ein System zu arbeiten. Product Management definiert die langfristige Wertlogik und schützt die Kohärenz des Produkts. Growth kümmert sich um Funnel, Experimenttempo, Aktivierung, Retention und Monetarisierung. Beide arbeiten am selben Geschäftsergebnis, aber mit verschiedenen Zeithorizonten und Entscheidungslogiken. Ist die Schnittstelle dazwischen nicht gestaltet, entstehen doppelte Arbeit, politische Konflikte und lokale Optimierungen, die dem Ganzen schaden.
Heikel ist diese Schnittstelle, seit Growth weit über Marketing und Akquise hinausgewachsen ist. Wachstum passiert heute tief im Produkt: beim Einstieg neuer Nutzer, bei der Aktivierung, in Gewohnheitsschleifen, an der Bezahlschranke, beim Preis, in automatischen Nachrichtenstrecken und zunehmend in KI-gestützten Funktionen. Was früher als Performance-Thema galt, ist oft ein Produktproblem. Umgekehrt kann Product Management Conversion und Monetarisierung nicht mehr als nachgelagerte Optimierungsfragen behandeln.
Dass beide Teams eng zusammenarbeiten müssen, bestreitet niemand. Offen ist, wie man die Zusammenarbeit so organisiert, dass Tempo und Konsistenz gleichzeitig möglich werden. Gutes Organisationsdesign stützt sich dafür auf drei Bausteine: gemeinsame Metriken, festgelegte Entscheidungsrechte und wiederkehrende Rituale. Welcher davon fehlt, verrät meist schon die Art, wie die Schnittstelle bricht.
Die Schnittstelle bricht an Zuständigkeit, Takt und Tempo
Die meisten Spannungen haben einen unspektakulären Grund. Beide Funktionen optimieren legitimerweise verschiedene Dinge. Produktmanagement soll Kernwert schaffen, Probleme sauber definieren und Erlebnisse konsistent halten. Growth soll Reibung abbauen, Lernzyklen verkürzen und messbare Verbesserungen entlang des Funnels erzeugen. Problematisch wird es erst, wenn die Organisation daraus keinen klaren Arbeitsmodus ableitet.
Am greifbarsten wird das bei der Zuständigkeit. Wem gehört die Aktivierung? Wem das Onboarding? Wer treibt Retention-Experimente? Auf dem Papier klingen diese Fragen banal. In der Praxis sind sie hochpolitisch, weil an ihnen Budgets, Roadmap-Platz und Sichtbarkeit hängen. Ohne Klärung gibt es zwei Ausgänge. Entweder arbeiten zwei Teams an derselben Oberfläche, oder niemand übernimmt sie, weil jede Seite die andere für näher dran hält.
Beim Takt wiederholt sich das Muster. Produktteams optimieren auf langfristige Wertschöpfung und Systemgesundheit, Growth-Teams werden an Bewegungen im Funnel gemessen, die nach zwei Wochen sichtbar sind. Growth drängt deshalb auf schnell testbare Maßnahmen, Produkt priorisiert Architektur und Konsistenz. Ohne gemeinsame Übersetzung über Metriken und Entscheidungsregeln hat bald jede Seite das Gefühl, die andere blockiere den Fortschritt.
Am schärfsten prallen die Logiken beim Tempo aufeinander. Growth braucht schnelle Hypothesentests. Produkt muss verhindern, dass diese Tests das Erlebnis beschädigen, technische Schulden aufbauen oder die Strategie verwässern. Mit KI wird der Konflikt härter: Varianten, Texte und Personalisierung lassen sich immer billiger erzeugen, während die Risiken für Vertrauen, Kosten und Konsistenz wachsen. Das Organisationsdesign muss schnelles Lernen ermöglichen, ohne das Produkt in ein Labor ohne Leitplanken zu verwandeln.
Zuständigkeit, Takt und Tempo kreisen um dieselbe Frage: Wer hat im System welche Aufgabe? Hilfreich ist das Bild einer gemeinsamen Wertkette. Produktmanagement verantwortet die Erzeugung des Kernwerts. Growth verantwortet, dass dieser Wert schneller verstanden, öfter genutzt und häufiger bezahlt wird. Das klingt nach einer Feinheit, entscheidet aber darüber, wer Budget, Roadmap-Platz und das letzte Wort bekommt.
Erzeugt ein Produkt keinen echten Wert, kann Growth nur kurzfristige Effekte erzwingen. Gutes Messaging, bessere Aktivierung oder aggressiveres Pricing machen ein schwaches Produkt eine Zeit lang effizienter, aber nicht gesund. Umgekehrt reicht auch ein hervorragendes Produkt nicht, wenn Nutzer seinen Wert zu spät verstehen, das Onboarding stockt oder die Monetarisierung schlecht eingebettet ist.
Daraus folgt ein duales Modell. Das Produktteam trägt Kern-Experience, langfristige Produktlogik, Aufbau von Fähigkeiten und strategische Richtung. Das Growth-Team konzentriert sich auf Aktivierung, Funnel-Effizienz, Retention, Messaging und experimentelle Monetarisierung. Beide teilen sich ein Territorium und bearbeiten verschiedene Ebenen desselben Systems. Damit muss nicht jede Diskussion neu klären, wer „eigentlich“ zuständig ist. Es steht fest, wer den Kernwert schützt und wer seine Wirkung beschleunigt.
Was der Onboarding-Test wirklich gekostet hat
Ein Rechenbeispiel mit runden, frei gewählten Zahlen zeigt, warum der Test vom Anfang mehr Fragen offenlässt, als die Präsentation beantwortet hat. Ein SaaS-Produkt hat 8.000 Neuregistrierungen im Monat. Die Aktivierung steigt von 35 auf 39 Prozent, das sind 320 zusätzlich aktivierte Nutzer. Von ihnen werden 20 Prozent zahlende Kunden, also 64, bei 30 Euro im Monat. Das bringt 1.920 Euro neuen monatlichen Umsatz pro Kohorte.
Auf der Kostenseite steht der Support. Der neue Flow erzeugt mehr Rückfragen: statt 0,3 Tickets pro Neuregistrierung jetzt 0,5. Bei 8.000 Registrierungen sind das 1.600 zusätzliche Tickets im Monat. Kostet ein Ticket 6 Euro, sind das 9.600 Euro.
Ob der Test ein Gewinn war, entscheidet also eine Zahl, die niemand gemessen hat: wie lange die 64 zusätzlichen Kunden bleiben. Die Ticketkosten von 9.600 Euro sind nach 9.600 / 1.920 = 5 Monaten Umsatz eingespielt. Kündigen diese Kunden mit 8 Prozent pro Monat, bleiben sie im Schnitt 12,5 Monate, und der Test lohnt sich deutlich. Sind es Nutzer, die nur durch den neuen Flow „durchgeschoben“ wurden, und kündigen 25 Prozent pro Monat, bleiben sie im Schnitt vier Monate. Dann hat das Team Geld verloren und zusätzlich einen Flow gebaut, den niemand mehr anfassen will.
Die Regel daraus: Ein Aktivierungstest wird erst dann skaliert, wenn neben der Aktivierung zwei Folgegrößen vorliegen, die Supportlast pro Neukunde und die Kündigungsrate der zusätzlich aktivierten Kohorte über mindestens zwei Abrechnungszyklen.
Das Warten kostet etwas, und man sollte den Preis kennen. Bleiben 10 Prozent der Neuregistrierungen zwei Abrechnungszyklen lang in der alten Variante, verzichtet das Team auf rund 32 zusätzlich aktivierte Nutzer im Monat. Gegen ein mögliches Minus von 9.600 Euro Supportkosten im Monat ist das ein günstiger Preis.
Eine Metrikhierarchie entscheidet, bevor gestritten wird
Das duale Modell bleibt eine Absichtserklärung, solange beide Teams Erfolg an verschiedenen Zahlen messen. Growth schaut auf Akquisitionskosten (CAC), Aktivierung, Conversion, den Zugewinn aus Tests und die Bindung über die Zeit. Produkt schaut auf Nutzwert, Nutzung der Funktionen, erledigte Aufgaben, Product-Market-Fit und die North Star Metric. Jede Sicht ist legitim. Problematisch wird es, wenn die Zahlen in keiner Hierarchie zueinander stehen.
Eine gute Hierarchie beginnt mit einer North Star Metric, die den zentralen Nutzwert abbildet. Darunter folgen die Growth-Hebel: Akquise, Aktivierung, Retention und Monetarisierung. Noch darunter liegen Produktmetriken wie Feature-Adoption, Zufriedenheit, Friktionspunkte und Erfolgsraten bei Kernaufgaben. Ganz unten stehen Experimentmetriken, mit denen einzelne Tests bewertet werden. Wie viele Ebenen es sind, ist zweitrangig. Entscheidend ist, dass beide Teams sie gleich lesen.
Die Hierarchie verhindert zwei Fehlentwicklungen. Sie bewahrt davor, lokale Maxima zu jagen, wie die Aktivierung im Onboarding-Test, die eine Ebene höher Geld kostet. Und sie schützt vor Strategierhetorik ohne Hebel: Ein Produktteam, das nur auf langfristige Wertlogik verweist und keine Verbindung zu Funnel und Nutzersignalen herstellt, gilt schnell als realitätsfern.
Praktisch heißt das: Vor jedem Test steht ein vereinbartes Gesamtkriterium fest, an dem das Experiment gemessen wird, und es umfasst mehr als die eine Zahl, die der Test bewegen soll. Für unser Beispiel hieße das: Aktivierung zählt nur, wenn Supportlast pro Neukunde und Kündigungsrate innerhalb vorher festgelegter Grenzen bleiben. In der Praxis reichen zwei Grenzen. Die Supportlast pro Neukunde darf um höchstens 10 Prozent steigen, die Kündigungsrate der Kohorte nach 60 Tagen um höchstens einen Prozentpunkt. Beide Werte sind Beispiele. Entscheidend ist, dass sie vor dem Test feststehen.
Es gibt einen guten Grund, das Kriterium nicht einem Team allein zu überlassen. Eine Kennzahl, nach der ein Team allein bewertet wird, verliert mit der Zeit ihre Aussagekraft, weil das Team lernt, genau diese Zahl zu bewegen. Ein Growth-Team, das allein an Aktivierung gemessen wird, findet Wege, Aktivierung zu erhöhen, die mit Nutzwert wenig zu tun haben. Deshalb schreiben Produkt und Growth die Hierarchie gemeinsam, und Änderungen daran sind eine gemeinsame Entscheidung.
Experimente brauchen ein gemeinsames Betriebssystem
Geteilte Metriken bewegen sich über Experimente, und genau dort fehlt oft der gemeinsame Rahmen. In vielen Unternehmen besteht Experimentation aus Feature Flags, einem Dashboard, ein paar A/B-Tests und einer Growth-Roadmap. Für die Zusammenarbeit reicht das nicht. Nötig sind einheitliche Hypothesenvorlagen, eine Priorisierungslogik, statistische Standards, QA- und Release-Regeln, dokumentierte Entscheidungen und ein Archiv der Erkenntnisse.
Koordinieren kann den Prozess das Growth-Team. Verantworten sollte ihn, wer Instrumentierung, Auswertung und sichere Releases zuverlässig organisiert, und Produkt bleibt mitverantwortlich dafür, dass Experimente technisch und strategisch anschlussfähig sind. PMs geben deshalb nicht jeden Test frei. Aber das Experimentiersystem darf nicht von der Produktlogik getrennt laufen. Optimiert Growth isoliert, entstehen widersprüchliche Varianten, Brüche im Erlebnis oder Maßnahmen, die nur funktionieren, weil sie etwas verschlechtern, das noch niemand misst.
Ein gemeinsamer Auswertungsstandard nimmt Signifikanz und Interpretation aus dem Bauchgefühl: Mindeststichprobe, Laufzeit und Erfolgsmetrik stehen vor dem Start fest, und niemand beendet einen Test vorzeitig, weil die Zwischenstände gerade gut aussehen. Mindestens so viel hängt an der Formulierung. Wer einen Button-Test als Hypothese über Wertwahrnehmung aufschreibt („Wer den Nutzen vor der Registrierung sieht, schließt das Onboarding häufiger ab“), kann das Ergebnis auf andere Stellen im Produkt übertragen. So wird aus einzelnen Tests belastbares Wissen über Nutzerverhalten.
Wie viel ein solches System bringt, zeigt eine einfache Warteschlangenrechnung: Durchlaufzeit gleich Bestand geteilt durch Durchsatz. Liegen 30 Experimentideen im Backlog und schafft das Team fünf Tests im Monat, wartet eine neue Idee im Schnitt sechs Monate. Ein gemeinsames Betriebssystem setzt an beiden Größen an. Die Priorisierung hält den Bestand klein, weil schwache Ideen früh fallen. Vorlagen und feste Auswertungsregeln erhöhen den Durchsatz, weil nicht jeder Test neu verhandelt wird.
Wer entscheidet, muss schriftlich feststehen
Ein Experimentiersystem kann noch so sauber gebaut sein: Sobald unklar ist, wer am Ende entscheidet, stockt es. Wer bestimmt die Kern-UX des Onboardings? Wer darf Aktivierungsexperimente priorisieren? Wer verantwortet das Abomodell? Wer führt Pricing-Experimente durch, und wer setzt ihren strategischen Rahmen? Bleiben diese Fragen offen, entscheiden Hierarchie, informelle Macht oder Lautstärke.
Abhilfe schafft eine Matrix der Entscheidungsrechte. Sie legt fest, wer entscheidet, wer berät und wer ausführt. In vielen Fällen ergibt sich ein stabiles Muster. Die Kern-UX des Onboardings liegt bei Produkt. Aktivierungsexperimente entscheidet Growth operativ, mit Produkt als beratender Funktion. Abomodelle und Paywalls gehören oft in einen geteilten Raum, weil sie Produktwert, Monetarisierung und Erlebnis zugleich betreffen. Pricing-Experimente brauchen einen strategischen Rahmen von Produkt und Business und eine experimentelle Validierung durch Growth und Vertrieb. Bei personalisierten Lifecycle-Nachrichten gehört zusätzlich der Datenschutz in die beratende Rolle, weil Einwilligung und Zweckbindung bestimmen, welche Segmente überhaupt angesprochen werden dürfen.
Für das Onboarding vom Anfang hätte eine Zeile genügt: Änderungen an der Schrittfolge entscheidet Growth, aber nur mit Supportlast und Kündigungsrate als Leitplanken, und ab einem Anteil von mehr als 20 Prozent der Neuregistrierungen im Test nur mit Zustimmung von Produkt. Die Schwelle ist ein Beispielwert, den jedes Team selbst setzt. Wichtig ist, dass es eine gibt.
Die Matrix gehört schriftlich festgehalten und sollte länger stabil bleiben. Ändern darf man sie, doch jede Änderung ohne Not öffnet dieselben Zuständigkeitsdebatten von Neuem. Für Fälle, die sie nicht abdeckt, braucht es eine Regel: Der Konflikt geht in die nächste wöchentliche Funnel-Review und wird dort entschieden, nicht in einer Eskalationsschleife bis zur Geschäftsführung.
Der PM schützt das System, der Growth-PM beschleunigt es
Der Product Manager verantwortet Produktstrategie, Wertversprechen, langfristige Vision und die Architektur des Erlebnisses. Er definiert Nutzerprobleme, arbeitet eng mit Engineering und verhindert, dass kurzfristige Optimierungen das größere System beschädigen. Mit Kontrolle hat das wenig zu tun. Der PM sorgt dafür, dass das Produkt als Ganzes sinnvoll bleibt.
Der Growth Product Manager verantwortet die Leistung des Funnels und den Testplan. Er formuliert Hypothesen und arbeitet mit Design, Analytics, Engineering und Marketing daran, Hürden abzubauen und Onboarding, Botschaften, Aktivierung und Bindung zu verbessern. Dazu gehört ein wirtschaftlicher Blick: CAC-Payback, LTV-Effekte und ARPU sind Kern des Profils, und die Rechnung aus dem Onboarding-Beispiel ist genau seine Aufgabe. Wer im Growth-PM bloß einen marketingnahen PM sieht, unterschätzt die Rolle. Sie macht Wachstum zu einer Disziplin, die sich testen und steuern lässt.
Growth Engineers, Data Scientists, Analysten, Design und Lifecycle-Teams ergänzen das System. Growth Engineers sorgen dafür, dass Tests schnell und technisch sauber laufen. Data und Analytics sorgen dafür, dass alle Ergebnisse gleich gelesen werden, bilden Nutzergruppen und prüfen, ob ein Effekt wirklich vom Test kommt. Design achtet darauf, dass Tests das Erlebnis nicht dauerhaft beschädigen. Lifecycle und Marketing tragen Growth in E-Mails, Pushes und andere Kanäle.
Produktteams fürchten oft, mehr Experimente bedeuteten mehr Instabilität. Das hängt vor allem an der Größe der Änderungen. Eine Variante, die einen einzigen Schritt verändert und sich über ein Feature Flag in Sekunden abschalten lässt, ist leichter zu prüfen und zurückzunehmen als ein Umbau, der drei Bildschirme auf einmal anfasst. Growth Engineering setzt deshalb auf viele kleine Varianten statt weniger großer, und mehr Tempo bedeutet dann nicht automatisch mehr Risiko.
Wie die Rollen zugeschnitten werden, hängt von der Reifephase ab. Eine Struktur für alle gibt es nicht. In frühen Phasen funktioniert eine hybride PM/Growth-Rolle oft gut, weil das Unternehmen für getrennte Einheiten noch zu klein ist. Wichtiger als saubere Trennung ist dann, Onboarding, Aktivierung und die ersten Wachstumsschleifen zu verstehen.
Mit dem Wachstum entsteht meist ein eigenes Growth-Team, eingebettet in Produktsquads oder als zentrale Funktion. Ein brauchbares Signal für diesen Schritt: Sobald zwei Squads im selben Monat Tests auf demselben Funnel fahren, reicht informelle Abstimmung nicht mehr. Eingebettete Growth-Kapazität bleibt nah an der Produktrealität. Der Preis sind doppelte Arbeit und uneinheitliche Methoden, wenn keine zentrale Klammer existiert. Ein zentrales Growth-Team skaliert Standards, Tooling und Disziplin besser, läuft aber Gefahr, zu weit weg von der Produktlogik zu arbeiten.
Viele SaaS-Organisationen fahren deshalb gut mit einer hybriden Product-Led-Growth-Struktur. Growth-Spezialisten sitzen in oder nahe an den Squads, eine zentrale PLG-Funktion definiert Standards, Instrumentierung und das Experimentiersystem. Sehr reife Unternehmen bilden oft Missionsteams um Aktivierung, Retention oder Monetarisierung, in denen Produkt und Growth das Ergebnis ausdrücklich gemeinsam verantworten. Das funktioniert nur, wenn Entscheidungsrechte, Metrikhierarchie und Governance schon stehen.
Bleibt die naheliegendste Lösung: Man setze einen Head of Product über beide Teams, und der Konflikt hat einen Schiedsrichter. Bei zwei oder drei Squads trägt das oft, weil eine Person alle Experimente überblicken kann. Ab etwa fünf Squads, die denselben Funnel berühren, kippt es. Dann wird die eine Person zum Engpass, jede strittige Variante wartet auf ihren Kalender, und das Unternehmen hat Politik durch Warteschlange ersetzt. Ab dieser Größe ersetzen Matrix und Hierarchie den Schiedsrichter, statt ihn zu ergänzen.
Rituale machen aus dem Organigramm Zusammenarbeit
Kein Modell trägt, wenn PMs und Growth-Teams nur bei Eskalationen miteinander sprechen. Rituale gehören deshalb zum Organisationsdesign. Bewährt hat sich ein fester Takt: eine wöchentliche Funnel-Review von 30 Minuten, gemeinsame Planung der Experiment-Roadmap alle zwei Wochen, ein monatlicher Strategie-Sync, eine quartalsweise Neuausrichtung der KPIs und eine Retrospektive nach jedem Experiment, das eine Entscheidung verändert hat. So sehen beide Teams dieselben Daten und lesen sie mit der Zeit auf dieselbe Weise.
Ein typischer Ablauf beginnt damit, dass ein PM einen Friktionspunkt im Onboarding oder in einer Retention-Strecke findet. Der Growth-PM entwickelt daraus Varianten. Growth Engineering baut sie entlang vereinbarter UX-Leitplanken. Analytics instrumentiert das Experiment. Produkt prüft technische, UX- und Compliance-Risiken. Growth steuert Rollout und Monitoring, über Skalierung, Iteration oder Verwerfen entscheiden beide gemeinsam. Die Schritte darf jedes Unternehmen anders schneiden. Wertvoll ist, dass alle den Ablauf kennen und bei einem neuen Friktionspunkt niemand erst aushandeln muss, wer was übernimmt.
Die Retrospektive braucht keine Stunde. Sie beantwortet, wie weit das Ergebnis von der Vorhersage abwich und welche Annahme dafür verantwortlich war. Ein Prüfstein für den ganzen Takt ist ebenso leicht zu finden: Präsentiert jemand in der wöchentlichen Review ein Ergebnis, von dem das andere Team zum ersten Mal hört, steht das Ritual im Kalender, findet aber nicht statt.
In Growth Loops wandert jede lokale Verbesserung weiter
Wie eng beide Seiten verzahnt sind, zeigt sich an den Growth Loops. In Akquise-Loops verantwortet Produkt die Wertlogik, Growth die Verbreitung. In Aktivierungs-Loops optimiert Growth die Strecken, Produkt sorgt dafür, dass sie zur Kernarchitektur passen. In Retention-Loops treibt Produkt die Nutzung von Funktionen, Growth optimiert Trigger, Timing und Messaging. In Monetarisierungs-Loops definiert Produkt Preis- und Angebotslogik, Growth prüft Zahlungsbereitschaft und ARPU-Effekte.
Eine harte Trennung zwischen Produkt und Growth ist deshalb wenig sinnvoll. Beide arbeiten am selben Mechanismus, mit verschiedenen Schwerpunkten. Gefragt ist eine disziplinierte Kopplung, bei der jede Seite weiß, an welcher Stelle des Loops sie eingreift und wen sie dort informiert.
Im Loop wandert jede lokale Verbesserung weiter, weil der Ausgang einer Stufe der Eingang der nächsten ist. Der Onboarding-Test vom Anfang ist genau so ein Fall: Die Aktivierungsstufe gewann, die Kosten tauchten eine Stufe weiter im Support auf. Wer pro Experiment mindestens eine Leitplanken-Metrik auf die nachgelagerte Stufe setzt, sieht solche Verschiebungen, bevor sie ein Quartal alt sind. Im Beispiel wäre das die Ticketquote pro Neuregistrierung gewesen, 0,5 statt 0,3, auf derselben Testauswertung wie die Aktivierung.
Sechs Reibungsmuster mit zwei gemeinsamen Ursachen
Wo diese Kopplung fehlt, tauchen in Unternehmen jeder Größe dieselben Reibungsmuster auf, und es lohnt sich, sie nicht als sechs getrennte Probleme zu behandeln. Die meisten gehen auf zwei fehlende Bausteine zurück. Widersprüchliche KPIs und lokale Maxima sind Symptome einer fehlenden Metrikhierarchie. Überlappende Zuständigkeiten, ein Growth-Team ohne Bezug zur Produktstrategie und PMs, die Tests bremsen, sind Symptome fehlender Entscheidungsrechte und Leitplanken.
Am teuersten sind meist die widersprüchlichen KPIs, weil sie jedem weiteren Streit Munition in Form von Zahlen liefern. Losgelöstes Growth und bremsendes Produkt verstärken sich gegenseitig. Je öfter Growth an der Produktlogik vorbei optimiert, desto mehr Vorbehalte baut Produkt auf. Je zäher die Freigaben werden, desto stärker weicht Growth auf Flächen aus, die niemand bewacht.
Die fehlende Experiment-Governance ist der sechste Fall und der unauffälligste, weil viele Tests nach Fleiß aussehen, auch wenn kaum etwas Wiederverwendbares aus ihnen hervorgeht. Gegenmittel sind Standards im Tooling, dokumentierte Rollen, feste Rituale und eine gemeinsame Metrikhierarchie. In Skalierungsphasen können Skill-Assessments helfen, Kompetenzlücken sichtbar zu machen. Später helfen Szenariomodellierungs-Tools, Growth-Szenarien über mehrere Quartale zu modellieren und Portfolioentscheidungen sauberer zu treffen.
Reibungsmuster: woran man sie früh erkennt
- Widersprüchliche KPIs: Produkt und Growth werden an unvereinbaren Erfolgsbildern gemessen. Erkennbar daran, dass dasselbe Experiment je nach Team als Erfolg und als Schaden gilt.
- Growth losgelöst von der Produktstrategie: schnelle Zuwächse ohne Wertlogik. Erkennbar an Funnel-Gewinnen bei gleichzeitig sinkender Retention derselben Kohorten.
- PMs bremsen das Testtempo: Leitplanken und Vorlagen fehlen. Erkennbar daran, dass jede Growth-Initiative als Sonderfall neu verhandelt wird und Wochen bis zum Start vergehen.
- Lokale Maxima: Optimierung auf einen einzigen Funnel-Schritt. Erkennbar daran, dass eine Stufe steigt, während die nachgelagerte unbemerkt fällt.
- Unklare Zuständigkeit: Kein Entscheidungsrecht ist dokumentiert. Erkennbar daran, dass zwei Teams an derselben Oberfläche arbeiten oder niemand sie übernimmt.
- Fehlende Experiment-Governance: Es gibt keinen gemeinsamen Auswertungsstandard. Erkennbar an vielen Tests, aus denen kaum wiederverwendbare Erkenntnisse entstehen.
Zwei Dokumente statt Reorganisation
Für den Anfang braucht es kein Reorganisationsprogramm. Zwei Dokumente genügen. Das erste ist eine Metrikhierarchie, in der jede Experimentmetrik einem Growth-Hebel zugeordnet ist und jeder Hebel der North Star Metric, ergänzt um das Gesamtkriterium, an dem Tests gemessen werden. Das zweite ist eine Matrix der Entscheidungsrechte für die vier Streitfälle, die fast überall zuerst auftauchen: Onboarding-UX, Aktivierungsexperimente, Abo und Paywall sowie Pricing. Beide Teams schreiben sie gemeinsam, damit später niemand behaupten kann, die Regeln seien von der anderen Seite diktiert.
Ob die Dokumente taugen, zeigt das nächste strittige Experiment. Lässt sich mit Blick auf die Matrix in wenigen Minuten sagen, wer entscheidet, und mit Blick auf die Hierarchie, ob ein Aktivierungsgewinn die Retention derselben Kohorte kostet, funktioniert die Schnittstelle. Endet die Diskussion wieder bei Hierarchie oder Lautstärke, fehlt in der Matrix eine Zeile, und genau diese Zeile ist der nächste Arbeitsschritt.
Mit KI und Personalisierung wächst die Zahl testbarer Varianten weiter. Ohne die beiden Dokumente wächst mit ihr vor allem die Zahl der Konflikte.