Die Aufgabe in einem Satz
Ein Growth PM entscheidet, was als Nächstes getestet wird. Er nimmt die Richtung, die der Growth Lead vorgibt – die Metrik, die Strategie –, und macht daraus eine konkrete Experiment-Roadmap: eine gerankte Liste von Tests, jeder mit einer Hypothese und einer klaren Gewinnbedingung. Er ist eine der zwei steuernden Rollen in einem Growth-Team und sitzt zwischen dem Growth Lead, der die Metrik festlegt, und den Marketern, Engineers und Analysten, die die Tests fahren.
Das Test-Briefing ist das zentrale Arbeitsergebnis
Der erste Schritt des PMs ist, ein vages Ziel testbar zu machen – aus „Aktivierung verbessern“ werden konkrete Wetten wie ein kürzeres Anmeldeformular oder eine Einrichtungs-Checkliste. Jede Wette wird zu einem Briefing, dem Ergebnis, an dem ein Growth PM gemessen wird. Ein gutes Briefing nennt die Hypothese (was wir glauben und warum), die primäre Metrik, die Varianten, Zielgruppe und Stichprobe und was als Gewinn oder Verlust zählt, bevor der Test läuft. Ist es gut geschrieben, kann ein Marketer oder Engineer den Test ohne Meeting bauen – und der Analyst das Ergebnis lesen, ohne den Aufbau neu zu verhandeln.
Priorisierung: Impact, Confidence, Aufwand
Es gibt mehr Ideen, als das Team fahren kann, also rankt der PM sie. Die gängige Kurzform ist ICE – Impact, Confidence, Ease –, bekannt gemacht von Sean Ellis und breit dokumentiert von Teams wie denen, die bei Reforge schreiben. RICE stellt noch Reach voran. Das Framework zählt weniger als die Disziplin: Bewerten Sie jede Idee nach denselben Kriterien, und die Wette mit dem höchsten Erwartungswert kommt zuerst.
Rhythmus, nicht Kanäle
Ein Growth PM betreut selten selbst einen Kanal. Sein Ergebnis ist die Rate validierten Lernens: wie viele sauber spezifizierte Tests pro Zyklus live gehen und wie eindeutig jeder einzelne ausgeht. Brian Balfour beschreibt Growth als wiederholbaren Prozess – Ziel, Ideen, Priorisierung, Test, Auswertung, der in einem festen Tempo läuft. Der PM verantwortet dieses Tempo und hält den Backlog in Bewegung, während der Rest des Teams umsetzt.
Testen in Ihren Journeys
In fromHello lebt ein Test in der Journey, die er verändert. Ein A/B-Split-Schritt schickt Menschen in dem Prozentverhältnis, das Sie festlegen, auf zwei Varianten, und Sie wählen die Erfolgsmetrik: das Erreichen eines späteren Schritts, eine zugestellte, geöffnete oder geklickte E-Mail oder ein Event innerhalb einer festgelegten Zahl von Tagen. Die Ergebnisse der Journey zeigen pro Variante die Zahl der erreichten Personen und die Raten, mit einer Signifikanzanzeige, die bei dünner Datenlage keinen Gewinner kürt, und einer Benachrichtigung, sobald ein Gewinner feststeht; Funnels zeigen, wo Menschen abspringen, bevor Sie das nächste Briefing schreiben. Ein MCP-Client kann den Engagement-Funnel oder die Performance der Journey abrufen und die nächste Variante als Journey-Entwurf anlegen; sie über einen Agenten zu veröffentlichen, erfordert einen Bestätigungsschritt in Ihrem KI-Client. Zum Vergleich mit einer Suite, die Sie kennen, siehe fromHello vs. HubSpot.