Ich baue mir das Betriebssystem, das mir als Solo-PM fehlt.

Ein Team gibt dir einen Takt vor. Ein Sprint-Board zwingt dich, etwas fertig zu machen. Als Solo hast du nichts davon. Also habe ich mir den Takt gebaut.

Im Essay über saasrebels.de endet die Geschichte mit einem Satz: Nach dem Launch habe ich den Fokus auf das nächste System verschoben. Das ist dieses System. Es heißt PMOS — Product Management Operating System — und es ist diesmal kein Produkt für andere, sondern der Apparat, der mir als Einzelner fehlt.

Das hier ist ein Teaser, kein Teardown. Die Innereien bleiben vorerst geschlossen. Aber die Idee dahinter — und was sie über mein eigenes Arbeiten verrät — ist es wert, erzählt zu werden.

Die Lücke, die das nötig macht.

Ein Produktmanager mit Team hat lauter Dinge, die ihn zwingen: Standups, Reviews, ein Board, das Druck macht. Als Solo, der nebenbei Produkte baut, hast du davon nichts. Kein externer Taktgeber, kein Stakeholder, der nachfragt. Trello und ein Obsidian-Vault sind kein Ersatz dafür — sie speichern, aber sie laufen nicht. Sie erinnern dich, sie zwingen dich nicht.

PMOS ist der Versuch, diesen Takt als Infrastruktur zu bauen: etwas, das wirklich läuft, statt nur Notizen zu halten.

Was drinsteckt.

Vier Schichten, von vorne nach hinten:

1. Ein Ideen-Funnel. Jede Idee wird erfasst, bewertet und durch ein Gate geschickt — Los, Park oder Stopp. Keine Idee bleibt unsortiert im Kopf hängen.
2. Eine visuelle Flow-Engine. Abläufe sind ein Knoten-Graph, den ich auf einem Canvas zusammenstecke: Stufen und Gates. Ein Lauf hält an einem Gate an, wartet auf meine Eingabe, läuft dann weiter. Genau das Human-in-the-Loop-Muster aus dem saasrebels-Essay, hier als bedienbare Oberfläche.
3. Ein Second Brain als Wissensgraph. Notizen werden klassifiziert, verdichtet und über Embeddings verknüpft — ein durchsuchbarer Graph statt eines Ordner-Friedhofs. Wissen, das sich verbindet, statt zu verstauben.
4. Ein Worker mit Agenten. Im Hintergrund läuft ein Dienst auf einem eigenen Server, der die Flows abarbeitet — die Agenten, die im saasrebels-Stack neben mir programmiert haben, hier fest verdrahtet als Ausführungsschicht.

Vier Schichten, ein Login. Idee oben rein, ausgeführter Ablauf unten raus.

Wie es gebaut ist — und was das über Tempo sagt.

Gebaut nach demselben Muster wie saasrebels.de — nur schneller, weil ich die Werkstatt diesmal schon kannte. 954 Commits in gut drei Wochen. Die erste lauffähige Version war in einem einzigen, weitgehend autonomen Lauf fertig — rund acht Stunden, dreizehn zusammengeführte Pull Requests, am Ende des Tages mehrere live geschaltete Oberflächen.

Dahinter arbeitet nicht ein Modell, sondern mehrere nach Aufgabe: Opus orchestriert und trifft die Entscheidungen, Sonnet führt den Code aus, ChatGPT übernimmt die adversariale Gegen-Review. Daneben laufen spezialisierte Stränge — Gemini für die Bildgenerierung, eigene Stimmen-Modelle für die Video-Pipeline. Welches Modell an welcher Stelle genau sitzt, bleibt Teil der geschlossenen Werkstatt.

Das ist nicht "die KI hat das gebaut". Es ist dieselbe Verschiebung wie beim letzten Produkt: Die Ausführung kostet fast nichts mehr, also wird die Entscheidung zum Engpass. Nur dass ich diesmal die Werkstatt schon kannte und sie nicht erst einrichten musste.

Was das Projekt über sich selbst verrät.

Jetzt der unbequeme Teil. In der eigenen Anleitung für die Agenten steht ein Satz, den ich selbst hineingeschrieben habe: Pascal neigt dazu, Werkzeuge und Prozesse zu überoptimieren, statt zu liefern — und PMOS selbst sitzt genau in diesem Risiko.

Das ist keine Koketterie. Ein Betriebssystem fürs eigene Produktmanagement zu bauen, ist die Königsdisziplin des Sich-Verzettelns. Die Gefahr ist real, dass die Meta-Schicht — das System, das Systeme baut — zur bequemen Ausweichbewegung wird, weg vom eigentlichen Liefern. Deshalb ist in PMOS eine Frage fest eingebaut, die bei jeder Architektur-Entscheidung gestellt wird: Schafft das Wert, oder produziert es nur mehr Meta-Schicht?

Ich weiß noch nicht, auf welcher Seite dieser Frage PMOS am Ende landet. Es läuft, täglich, und es ist nützlich. Ob es nützlich genug ist, um den Bau zu rechtfertigen, entscheidet sich erst über Monate. Das ist die ehrliche Antwort.

Was als Nächstes kommt.

Wenn sich abzeichnet, dass die Antwort "ja" lautet, schreibe ich den Teardown: die Flow-Engine im Detail, das Second Brain, die Agenten-Orchestrierung. Bis dahin bleibt es bei diesem Bild — ein PM, der sich den fehlenden Takt selbst gebaut hat, und der ehrlich genug ist, die Falle zu benennen, in die genau dieses Vorhaben führen kann.