Liefere die Demo, nicht das Memo.

Ein Memo lässt alle nicken. Eine Demo zeigt Empty States, fehlende Permissions und das erste Missverständnis — genau dort versteckt sich meistens die Entscheidung. Warum die Rechnung zwischen Dokument und Prototyp gekippt ist.

„Don’t deliver the memo. Deliver the demo.”

Der Satz stammt von Olivia Meng, die auf LinkedIn beschrieben hat, wie Product Manager bei Cursor arbeiten. Er klingt erst offensichtlich, wenn man den Workflow dahinter gesehen hat.

PMs bei Cursor schreiben nicht nur Specs. Sie prototypen. Sie passen UI selbst an. Sie schauen in Datadog. Sie räumen Tickets auf.

Nicht, weil jeder PM Production-Engineer werden soll. Sondern weil eine Demo das Gespräch verändert.

Ein Memo lässt alle nicken

Zustimmung zu einem Dokument ist billig. Sie kostet die Zustimmenden nichts und verpflichtet zu nichts. Ein gutes Memo erzeugt Alignment — aber Alignment über eine Vorstellung, die in jedem Kopf anders aussieht.

Ein Dokument bittet die Leser, sich den Workflow vorzustellen. Es versteckt Empty States und Edge Cases. Es erzeugt Einigkeit, bevor die Realität widersprechen kann.

Eine Demo zwingt den Workflow zu antworten. Sie zeigt die unbequemen Stellen:

den Empty State, für den niemand einen Plan hatte,
den Schritt, der sich zäh anfühlt,
die Permission, die fehlt,
das Erste, was ein Nutzer falsch versteht.

Genau dort versteckt sich meistens die Entscheidung. Nicht in Kapitel 4 des PRDs.

Memo vs. Demo — ein Dokument sammelt Zustimmung, ein Prototyp erzeugt Evidenz

Die Rechnung ist gekippt

Das Argument ist nicht neu. Es war nur lange unpraktisch.

Ein PRD kostete Stunden, ein funktionierender Prototyp Wochen. Bei dieser Kostenlage war das Dokument die rationale Wahl: billige Abstimmung vor teurem Bau.

Diese Rechnung hat sich umgedreht. Die Kosten für einen testbaren, funktionalen Prototyp sind in kurzer Zeit um rund 90% gefallen. Wenn die Demo einen Nachmittag kostet, wird das zwölfseitige Dokument zur teureren Option — nicht in Schreibzeit, sondern in dem, was es kauft: Alignment ohne Evidenz.

Dahinter steckt der Unterschied, auf dem unsere ganze Methode aufbaut: Ein Dokument sammelt Meinungen darüber, was Menschen tun würden. Ein Artefakt erzeugt Verhalten — jemand klickt, bricht ab, versteht falsch, kommt wieder. Nur das Zweite trägt eine Produktentscheidung.

Wo das Memo bleibt

Dokumente sind nicht nutzlos. Es gibt Arbeit, die weiter Dokumente braucht: irreversible Architektur-Entscheidungen, Compliance, Schnittstellen-Verträge, Koordination über viele Teams. Überall dort, wo der Schaden einer falschen Entscheidung groß und der Weg zurück teuer ist, bleibt das geschriebene Argument das richtige Werkzeug.

Die Demo ersetzt das Memo als Entscheidungsinstrument früher Produktarbeit — nicht als Spezifikation für Systeme mit großem Schadensradius.

Und sie ist ein ehrlicher Filter: Wenn die Demo niemanden überzeugt, wird das Dokument sie auch nicht retten.

Was das praktisch heißt

Der Unterschied zeigt sich im Meeting. Statt 30 Slides über ein Konzept: zehn Minuten durch einen funktionierenden Flow klicken. Die Fragen ändern sich sofort — von „stimmt die Annahme auf Seite 3?” zu „warum ist dieser Schritt so langsam?” und „was passiert, wenn hier noch keine Daten liegen?”.

Die zweite Sorte Fragen ist unbequemer. Sie ist auch die, aus der Produkte entstehen.

In unseren Projekten heißt dieses Prinzip Design Doing: Statt eines Konzeptpapiers bauen wir einen Behavioral Prototype, der eine falsifizierbare Frage beantwortet — und mit echten Nutzern echtes Verhalten erzeugt. Das Memo dokumentiert danach, was die Demo gezeigt hat. Nicht umgekehrt.

Quelle

Olivia Xiaodan Meng, LinkedIn-Post über den PM-Workflow bei Cursor: Prototypen, kleine Code-Änderungen, Ticket-/SQL-/Transcript-Querbezüge, Demos als primäres Deliverable.