Das ungeschriebene Playbook, um 12 Apps mit 5 Personen zu betreiben

Montagmorgen. Du bist ein Fünf-Personen-Studio mit zwölf Live-Produkten. Drei werfen Crash-Alerts, die du irgendwann lesen musst. Zwei verlieren Retention an das App-Update eines Konkurrenten vom Wochenende. Eines hat einen Store-Eintrag, der bis Freitag aktualisiert werden muss, sonst fällt es aus dem Featured-Slot. 47 Kundenbewertungen warten. Die Ausgaben für Game 4 sind irgendwie um 30 % gestiegen. Burak fragt nach einem Roadmap-Call. Jemand im Team fragt nach Game 7. Deine Woche beginnt in acht Minuten.

Das ist Portfolio Operations. Niemand hat das Playbook dafür geschrieben.

Die meiste Ops-Beratung wurde für das falsche Format geschrieben

Der Operations-Kanon (die Bücher, die Threads, die LinkedIn-Posts) geht davon aus, dass Sie eine einzige Sache betreiben. Stellen Sie einen Head of Growth ein. Richten Sie Ihr Funnel-Dashboard ein. Halten Sie Ihr wöchentliches Product Council ab. Wählen Sie eine North-Star-Metrik.

Nichts davon überlebt den Kontakt mit einem Portfolio.

Ein Fünf-Personen-Studio mit zwölf Produkten ist kein kleineres Enterprise. Es ist kein Startup im Scale-up. Es ist ein völlig anderes Betriebsmodell: schlanke Teamgröße, hohe Produktanzahl, geringer Kontext pro Produkt, reichhaltiger produktübergreifender Kontext. Die Personalkalkulation erlaubt es nicht, für jedes Produkt einen Head of Growth einzustellen. Die Produktanzahl macht es unmöglich, für jedes ein wöchentliches Product Council abzuhalten. Playbooks, die für das eine oder andere Format gebaut wurden, stoßen an ihre Grenzen und scheitern.

Die meisten Studios bemerken das um das fünfte Produkt herum. Die ersten drei fühlten sich machbar an. Das vierte war hart. Beim fünften wurde klar: Das Framework, das Sie hierher gebracht hat, bringt Sie nicht auf zehn.

Dieses Modell hat noch keinen festen Namen. Manche Betreiber nennen es Portfolio. Manche nennen es Holdco. Die meisten sagen einfach: "Wir betreiben einen Haufen Zeug." Wie auch immer man es nennt, die operative Disziplin ist eine ganz eigene Sache (Portfolio Operations), und das meiste davon ist ungeschrieben, weil es in den Köpfen von Betreibern existiert, die keine Zeit zum Schreiben haben.

Dieser Beitrag ist ein Versuch, es endlich festzuhalten. Konkret: die fünf Punkte, an denen Single-Product-Playbooks bei Multi-Product-Studiosscheitern, und was man stattdessen tun sollte.

Die fünf Fehlermuster

1. Manuelles Scannen frisst den Montagmorgen

Der erste Fehler ist am leichtesten zu erkennen und am schwersten zu beheben. Jeden Morgen scannt jemand im Team jedes einzelne Produkt. Crash-Dashboards. App-Store-Bewertungen. Spend-Reports. Engagement-Panels. Kundensupport-Postfach.

Bei Produkt eins ist das Aufgabe der Gründer und dauert dreißig Minuten. Bei Produkt fünf ist es immer noch Aufgabe der Gründer und dauert drei Stunden. Bei Produkt zwölf findet es gar nicht mehr statt – und das Studio erfährt von echten Bränden erst über Kunden-Tickets.

Manuelles Portfolio-Scanning skaliert nicht. Nicht, weil Operatoren schlecht darin wären, sondern weil der Aufwand linear mit der Produktanzahl wächst und der Operator nur eine Person ist. Man kann sich mit Dashboards etwas Zeit erkaufen, aber man kann sich nicht aus der Notwendigkeit heraus-dashboarden zu wissen, welcher von zwölf Produkt-Alerts wirklich zählt.

Die Arbeit, die getan werden muss, ist Signal-Triage, und sie muss passieren, bevor der Operator das Dashboard öffnet, nicht danach.

2. Erkenntnisse gehen zwischen Produkten verloren

Nach drei Monaten mit mehreren Produkten führst du dasselbe schmerzhafte Gespräch zweimal: Jemand im Team spricht ein Problem bei Game 4 an, und ein erfahrenerer Kollege sagt: "Das haben wir letzten März bei App 2 gelöst." Dann wird allen klar, dass sich niemand mehr daran erinnern kann, wie die Lösung eigentlich aussah.

Single-Product-Organisationen lösen das mit Wikis und Runbooks. Portfolio-Studios können das nicht, weil das entscheidende Learning im Kontext eines anderen Produkts vergraben liegt. Im Runbook für Game 4 steht es nicht. Im Runbook für App 2 steht es zwar, aber das liest nur der Lead von App 2. Das produktübergreifende Gedächtnis existiert in niemandes Kopf verlässlich.

Die Lösung ist kein größeres Wiki. Die Lösung ist institutionelles Gedächtnis pro Produkt strukturiert, aber produktübergreifend lesbar. Das Problem von Game 4 und die Lösung von App 2 müssen standardmäßig dieselbe Struktur haben, am selben Ort liegen, ohne dass sie jemand umformatieren muss.

3. Entscheidungsmomente verstreichen

Jedes Multi-Product-Studio hat denselben Backlog: Entscheidungen, die eigentlich letzten Dienstag hätten getroffen werden müssen und es nicht wurden. Der Mindestgebots-Floor bei Game 4, der vor Wochen hätte angepasst werden sollen. Das Store-Listing-Update bei App 7. Der Retention-Test bei Game 11, an dessen Abzweigung niemand gedacht hat.

Dem Studio fehlt es nicht an Urteilskraft. Es fehlt an Momenten. Die Entscheidung, die zehn Minuten dauern würde, wenn der Kontext bereitstünde, erfordert zwei Stunden Vorbereitung – also wird sie verschoben. Oft genug verschoben, findet sie gar nicht mehr statt.

Was gebraucht wird, ist ein Entscheidungskadenz: eine Garantie dafür, dass für jedes Produkt bestimmte Entscheidungen in einem vorhersehbaren Rhythmus getroffen werden – mit bereits zusammengestelltem Kontext. Kein Meeting-Plan, sondern ein Vertrag darüber, dass dieser Moment vorbereitet eintrifft.

4. Cross-funktionaler Kontext fragmentiert

In einem kleinen Studio bedeutet "cross-funktional" nicht verschiedene Teams. Es bedeutet dieselben drei Personen mit jeweils drei Hüten auf. Die Person, die Ads schaltet, betreut auch den Store-Eintrag und kümmert sich um Live-Ops. Sie sind nicht uneins – sie sind mit sich selbst phasenverschoben.

Das Problem ist die operative Oberfläche. Die Werbeausgaben liegen in einem Tool. Der Store-Eintrag in einem anderen. Das Live-Ops-Dokument in einem dritten. Jedes erzählt eine andere Geschichte über dasselbe Produkt am selben Tag. Der Betreiber ist das Einzige, dem bewusst ist, dass es sich um dasselbe Produkt handelt.

Funktionsübergreifender Kontext geht es in einem Portfolio-Studio nicht um bessere Meetings. Es geht um einen einzigen Datensatz pro Produkt, den dieselbe Person aus drei verschiedenen Blickwinkeln lesen kann. Wenn die Frage lautet: "Was passiert heute bei Game 4?", sollte es eine Antwort zu lesen geben, statt drei mühsam zusammenzusetzen.

5. Growth Loops zerfallen still und leise

Der teuerste Fehler im Portfolio-Betrieb ist der, den niemand bemerkt. Ein Growth-Loop geht live, funktioniert zwei Wochen lang und driftet dann ab. Der Retention-Test, der nach der ersten Kohorte abzweigen sollte, wird nie geforkt. Die Monetarisierungskurve, die im März feinjustiert wurde, driftet bis Juni wieder auf den Standardwert zurück. Niemand liegt falsch; niemand macht überhaupt etwas falsch. Der Loop wird schlicht nicht gepflegt.

Bei Single-Product-Ops erinnert sich der Gründer. Bei Portfolio-Ops muss sich der Gründer an elf andere Dinge erinnern.

Eine selbstlaufender Growth Loop ist einer, über den das System stets den Überblick behält: Es meldet sich, wenn der Loop nachlässt, wenn sich seine Annahmen geändert haben, wenn er abzweigen muss. Der Betreiber entscheidet weiterhin. Das System stellt sicher, dass der Moment für die Entscheidung nicht verstreicht.

Was wirklich funktioniert

Die Lösungen für die fünf Fehlermuster sind nicht fünf separate Tools. Sie sind derselbe grundlegende Wandel, angewendet auf verschiedene Oberflächen. Die meisten Multi-Product-Studios, die jenseits von zwölf Produkten überleben, haben irgendeine Version davon selbst herausgefunden – meist auf die schmerzhafte Tour. Hier ist die kürzere Fassung.

1. Die Einheit ist das Produkt, nicht das Unternehmen.

Die meisten operativen Tools setzen standardmäßig auf einen Unternehmens-Workspace: eine Wissensdatenbank, ein Kanal, ein Dashboard. Für Multi-Product-Studios ist das die falsche Voreinstellung. Die kanonische Gedächtniseinheit muss das Produkt sein. Game 4 erhält sein eigenes Entscheidungsprotokoll, sein eigenes Signal-Log, seinen eigenen Kontextspeicher. Das Portfolio greift übergreifend darauf zu, wenn nötig, aber die Einheit bleibt das Produkt.

Das ist produktspezifisches Gedächtnis. Es klingt offensichtlich; fast kein Standard-Tool sieht das standardmäßig vor.

2. Entscheidungen sind First-Class-Objekte, keine Dokumente.

Die meisten Tools erfassen, was gemacht wurde. Was gebraucht wird, ist auch, warum es gemacht wurde, welches Signal die Entscheidung ausgelöst hat und was in Betracht gezogen und verworfen wurde. Ein Entscheidungsprotokoll ist kein Dokument. Es ist ein strukturiertes Artefakt, das das Vergessen des Betreibers überdauert.

Der Test: Kann in drei Monaten ein neues Teammitglied den Datensatz zu Game 4 lesen und die Gedankengänge des Betreibers zum Zeitpunkt der Entscheidung nachvollziehen? Wenn ja, erfüllt der Datensatz seinen Zweck. Wenn nein, wird das Studio dieselbe Lektion zweimal lernen.

3. Kadenz vor Kapazität.

Portfolio-Ops löst man nicht durch Neueinstellungen. Man löst es, indem man dafür sorgt, dass anstehende Entscheidungen in einem Rhythmus getroffen werden, den das Studio durchhalten kann. Entscheidungskadenz ist der Vertrag. Die Aufgabe des Studios ist es, ihn einzuhalten.

4. Spezialisierte Agenten statt allgemeiner Assistenten.

Die Versuchung, als KI-Tools aufkamen, bestand darin, einen einzigen allgemeinen Assistenten nach allem zu fragen. Den Montagmorgen in einem echten Studio hat das nicht überstanden. Was funktioniert, sind Spezialisten-Agenten: einer pro operativer Funktion, mit abgegrenztem Gedächtnis und einer einzigen Aufgabe. Derjenige, der Crash-Reports überwacht, versucht nicht, Texte zu verfassen. Derjenige, der Store-Listings beobachtet, schlägt keine Änderungen an der Monetarisierung vor.

Der abgegrenzte Fokus ist der Vertrauensmechanismus. Ein spezialisierter Agent mit vollständigem Gedächtnis für eine Funktion kann auditiert, kalibriert und zurückgesetzt werden. Ein allgemeiner Agent mit Zugriff auf alles kann das nicht.

5. Ein operativer Verstand für das gesamte Portfolio.

Die fünf obigen Punkte funktionieren nur, wenn sie am selben Ort leben. Andernfalls hat man nur zwölf Dashboards durch zwölf bessere ersetzt. Der Sinn der Sache ist ein operativer Verstand: dasselbe Gehirn, das jedes Produkt liest, dieselben Agenten, die über alle Linien hinweg agieren, und der Operator nicht länger die einzige Integrationsschicht.

Eine Anmerkung zu Qualia

Das ist das Playbook, an dem wir Qualia ausrichten. Das Produkt ist das AI COO für Portfolio-Operatoren: kleine Studios mit 2–10 Personen, die 3–20 Live-Games oder Apps betreiben. Die Architektur besteht aus Pro-Produkt-Gedächtnis plus spezialisierten Agenten plus einem geteilten Portfolio-Brain. Der Standard ist Human-in-the-Loop. Die Metrik, an der wir uns messen, ist Operator-Langeweile: Wenn ein Gründer beim Lesen eines Qualia-Screens gähnt, ist der Screen falsch.

Wir stehen noch am Anfang. Zwei Kunden. 30-Minuten-Setup. Wenn du ein Multi-Produkt-Studio betreibst und eines der oben genannten Fehlermuster deine Woche auffrisst, möchten wir mit dir sprechen. Demo buchen.

Warum dies ungeschrieben ist

Die meisten Playbooks gehen davon aus, dass man nur eine Sache skaliert. Portfolio-Betreiber skalieren gegen die Vielfalt: mehr Produkte, gleiche Teamstärke, kein Puffer pro Produkt. Die Arbeit ist anders. Also müssen es auch die Tools sein. Und ebenso das Playbook.

Wenn du Varianten davon entdeckt hast, die wir übersehen haben, möchten wir davon hören.