Product Management dreht sich alles ums Geschichtenerzählen. Deshalb möchte ich dir anhand einer Geschichte zeigen, wie ich über Product Management denke und wie KI es verändert hat.
Die Interviewfrage, die ich nie vergessen werde
Ich habe meine Karriere als Ingenieur bei RealNetworks begonnen. Nach einigen Jahren war ich für das Produkt- und Engineering-Team von RealPlayer verantwortlich. Es war damals ein sehr bedeutendes Consumer-Produkt – es hatte Hunderte Millionen Nutzer und half dabei, Audio und Video ins frühe Internet zu bringen. Ich saß in Meetings mit Leuten aus dem Business-Bereich, die Ideen vorschlugen wie: „Wir sollten jedes Mal eine Anzeige schalten, wenn der Player startet.“ Ich wusste, dass das nicht richtig war, aber ich hatte keine Möglichkeit, gegen ihre Excel-Tabellen anzukommen, die zeigten, wie viel Geld wir damit verdienen würden. Ich wollte ein echter Product Manager werden und kam zu dem Schluss, dass ich wahrscheinlich auf die Business School gehen sollte.
Ich begann mein Studium an der Berkeley Business School. Kurz nach meiner Ankunft sah ich auf meiner alten Uni-E-Mail-Liste, dass LinkedIn Leute suchte. Ich bewarb mich und fand mich in einem Interview mit Reid Hoffman wieder. Er setzte sich hin und stellte mir eine Interviewfrage, die ich nie vergessen werde:
„Also, du willst Product Manager werden. Was ist das Artefakt, das ein Product Manager produziert?“
Er führte weiter aus. Ingenieure haben ein Artefakt: Code. Business Development hat ein Artefakt: unterzeichnete Verträge. Designer erstellen das visuelle Look-and-Feel und die Grafiken. Der CEO hat den Organisationsplan, den Finanzierungsplan und die Vision, die alle zusammenhält. Was ist mit einem Product Manager?
Ich sagte ihm, dass ich mir nicht sicher sei, ob Product Manager wirklich solche „Artefakte“ hätten, aber dass das Grundlegende, was wir tun, darin bestehe, alles zusammenzutragen, was passiert, und es in einer Spec (Spezifikation) niederzuschreiben. Die Spec ist der Bauplan. Dort definieren wir die Anforderungen und alles, was wir tun werden, und sie wird zu einem der wichtigsten Dokumente im Unternehmen, weil sie jedes Team dazu befähigt, von dort aus zu bauen.
Ich war offensichtlich nervös. Ich glaube, er bemerkte es, denn er beruhigte mich, dass es eine gute Antwort sei. Am Ende bekam ich den Job, brach das Business-School-Studium ab, um zu LinkedIn zu wechseln, und seitdem denke ich über diese Frage nach.
Die Evolution von der Spec zur Story
Weil ich die falsche Antwort gegeben habe.
Das war noch die Ära des Waterfall-Modells beim Softwarebau. Bei LinkedIn versuchten wir, eine Jobplattform innerhalb einer Social-Plattform neu zu denken – wo Recruiter Bewerbungen im Kontext gemeinsamer Kontakte sehen konnten, Kandidaten Stellenangebote sehen und Wege durch ihr Netzwerk finden konnten, um direkt zum Entscheider vorzudringen. Während dieses Entdeckungsprozesses schrieb ich eine 120-seitige Spec, die das gesamte Erlebnis und die Anforderungen definierte.
In den Jahren danach habe ich viel darüber nachgedacht. Denn diese Spec ist offensichtlich nicht das wichtigste Artefakt. Die Story ist es.
Die Spec beschreibt ein System, was es tun muss und welche Kästchen abgehakt werden müssen, bevor es fertig ist. Das ist nicht die Kunst des Product Managements. Product Management dreht sich darum, die Geschichte der Menschen zu erzählen, die das Produkt nutzen werden, und warum es in ihrem Leben eine Rolle spielen wird. Es muss sofort verständlich sein, egal mit wem man spricht. Und es muss wiederholbar sein – die Leute müssen in der Lage sein, es treu weiterzugeben, ohne dass du im Raum bist.
Das ist ein völlig anderes Dokument und ein völlig anderer Job.
Vor zehn Jahren hielt ich einen Vortrag über Product Management, und die Leute schicken ihn mir immer noch; was entweder schmeichelhaft ist oder ein Zeichen dafür, dass sich das Feld nicht bewegt hat. Ich betrachte beide Möglichkeiten. Jedenfalls lief der ganze Vortrag auf einen einzigen Satz hinaus: „Ein Product Manager hilft seinem Team (und Unternehmen), das richtige Produkt an seine Nutzer auszuliefern.“ Den Großteil des Vortrags verbrachte ich damit, diesen Satz Wort für Wort zu zerlegen.
- Hilft seinem Team. Du bist nicht der Anführer. Viele Leute denken, der Product Manager sei der Leader. Du bist die Person, die hilft, die Dinge möglich zu machen. Das bedeutet, dass du …
- Dein Team und dein Unternehmen verstehen musst. Dein Team ist deine Domäne: Du musst es verstehen! Und du musst verstehen, wie es in das größere Bild passt, damit du den Zielen des Unternehmens dienst und nicht nur deinen eigenen.
- Ausliefern (Ship). Wir können so viel reden, wie wir wollen, aber am Ende zählt nur, das Produkt vor die Kunden zu stellen.
- Das richtige Produkt für deine Nutzer. Endlich sind wir beim Kern der Sache angekommen: herauszufinden, was „richtig“ tatsächlich bedeutet.
Wie viel davon ändert sich in einer Welt mit KI?
Was sich ändert
Offensichtlich hat sich etwas geändert, sogar ein paar Dinge. Auf der einen Seite verändert sich, wie wir coden und wie schnell wir von einer Idee zu etwas Laufendem kommen. Auf der anderen Seite verändert sich, was Nutzer von einem Produkt erwarten. Ich denke, wir haben das Potenzial kaum ausgeschöpft, besonders im Consumer-Bereich. Die Fähigkeit, genau zu beschreiben, was man braucht, und vom Produkt geliefert zu bekommen, vielleicht mit Agenten, die im Hintergrund laufen, ohne dass man selbst lernen oder Schnittstellen bedienen muss.
Es steht außer Frage, dass die Kosten für das Herstellen von Dingen eingebrochen sind. Es ist nicht mehr allzu schwierig, etwas abzuschätzen und auszuprobieren; das gibt dir enorme Flexibilität. Aber die Kosten für Urteilsvermögen haben sich überhaupt nicht geändert. Herauszufinden, was gebaut werden soll, ist jetzt wichtiger als je zuvor.
Produktentwicklung ist ein Kreislauf. Früher hatte jemand eine Idee – und das muss nicht unbedingt du sein; in einem guten Unternehmen kann sie von überall her kommen. Du probierst sie aus. Du schreibst eine Spec, ein Produktbriefing oder wie auch immer dein Name für dieses Dokument lautet. Es gibt Vorabkosten: Scoping, Designen, Diskutieren – alles, was passieren muss, bevor du wertvolle Engineering-Zeit investierst. Das sind alles Rituale, die wir erfunden haben, um die Engineering-Zeit vor schlechten Entscheidungen zu schützen. Weil man pro Jahr nur sechs oder acht Durchläufe durch diesen Kreislauf hatte.
Dann wurde das Herstellen von Dingen absurd billig. Nicht etwas billiger; eine andere Größenordnung. Und was passiert ist, ist wirklich interessant. Dieser alte Kreislauf existiert immer noch – nur in einer neuen Reihenfolge angeordnet.
Der alte Kreislauf verlief: Idee, Spec, Kostenschätzung, Scoping, alles andere, dann Bauen. Jetzt:
- Zuerst nimmst du die Idee und baust sie schnell mit KI, nur um zu sehen, wie sie funktioniert und wie sie sich anfühlt.
- Du darfst damit spielen und herausfinden, wie sie sich anfühlt und in das Gesamtbild passt. Prototypen schlagen „Was-wäre-wenn“, jedes Mal.
- Dann designst du es. Jetzt, da du damit gespielt hast, weißt du, was es ist, und du kannst tatsächlich darüber sprechen, was nötig ist, damit es mehr als nur ein Prototyp wird. Mit Design meine ich hier beide Bedeutungen: visuelles und UX-Design sowie technisches Engineering-Design.
- Dann lieferst du aus und lernst.
Es kehrt sich komplett um: von Spec-and-Scope zu Build-and-Play. Ich denke, das verändert das Product Management mehr als alles andere, was gerade passiert.
Das bedeutet endlich, dass die Spec nicht mehr das Lieferobjekt ist; wirklich. Du musst nicht damit beginnen, ein langes Dokument zu schreiben und alles auf Papier richtig hinzubekommen. Das war früher im idealistischen Sinne wahr, aber jetzt ist es buchstäblich offensichtlich wahr.
Aber ich möchte vorsichtig sein, denn es gibt einen gleich großen und entgegengesetzten Fehler, den man machen kann.
Demos sind jetzt fast kostenlos. Funktionierende Produkte sind es nicht. Ich sehe ständig die Kehrseite dieses neuen Ansatzes: „Das ist großartig, liefern wir es einfach aus.“ So funktioniert es immer noch nicht. Wir alle müssen weiterhin respektieren, dass der Weg von einem Prototyp zu etwas Realem immer noch Zeit braucht, um zurückgelegt zu werden.
Es gibt ein Klischee über Product Manager, dass ihr Job hauptsächlich darin besteht zu fragen: „Passt es in den Zeitplan?“ Werf diese Idee komplett weg. Die wichtigste Frage ist: Passt es in das Produkt?
Wir alle haben tolle Ideen, und jetzt haben wir alle Agenten, die für uns coden. Zu entscheiden, was gebaut wird, ist offiziell keine Ressourcen-Diskussion mehr. Es ist eine Impact-Diskussion. „Dieses oder jenes“, nicht „dieses oder gar nichts“. Geschmack und Kuratierung spielen hier eine große Rolle, wenn man eine Vision hat und wirklich weiß, was man für die Welt tun will. Aber das System, das man baut, muss sich trotzdem vollständig anfühlen.
Meine größte Sorge bezüglich KI ist, dass sie uns schneller macht und wir deshalb einfach alles hineinstopfen. Wir sprechen über „AI Slop“ bei Inhalten; das ist, was AI Slop für Produkte bedeutet. Ich habe es schon an einigen Orten beobachtet, und ich denke, wir alle sind ein bisschen besorgt darüber. Wenn jeder alles bauen kann, ist die Entscheidung, was gebaut wird, der ganze Job. Und das ist ein Story-Problem. Welche Geschichte willst du erzählen? Welche Geschichte sollen deine Kunden verstehen? Welche Geschichte soll in ihren Köpfen leben?
Dein Job als PM ist nicht, eine Spec darüber zu schreiben, was das Produkt tun wird. Es geht darum, ein gemeinsames Verständnis zu schaffen – ein gemeinsames Bild davon, was wir tun und warum. Warum ist der Nutzer hier? Was fühlt er in jedem Schritt, und warum ist das wichtig? Wo ist es beeindruckend, und wo ist es langweilig? Es ist okay, wenn ein Produkt gelegentlich langweilig ist, solange du weißt, wo. Aber wenn du kein gutes Skript schreiben kannst, wird das Produkt stumpfsinnig sein.
Das Geschenk, das dir die KI macht, ist, dass du das jetzt kostenlos herausfinden kannst, gleich zu Beginn. Du kannst es schnell bauen, ein Gefühl dafür bekommen, damit spielen und diesen einen Satz herausfinden: Was tut dieses Produkt für jemanden in seinem Leben? Denn wenn du das beantworten kannst, kannst du meine Frage beantworten: „Nutzen die Leute es tatsächlich?“ Denn jetzt hast du gesagt, was es tut, und fragst, ob sie es tun.
Was sich nicht ändert
Was bedeutet es, eine „Vision“ für dein Produkt zu haben?
Wenn ich Vision sage, meine ich kein Leitbild (Mission Statement). Diese sind wichtig, aber sie sind keine Vision. Eine Vision ist der durchgängige Grund für die Existenz des Produkts für die Nutzer. Ich habe ein einfaches Framework dafür:
- Zweck. Warum nimmt jemand dein Produkt und integriert es in sein Leben?
- Kernhandlungen. Was tun sie tatsächlich, wenn sie es aufnehmen? Es kann mehr als eine Sache geben, du musst sie alle verstehen.
- Zyklus. Wie oft wird jede dieser Kernhandlungen erwartet?
Meine gesamte Karriere über, wenn ich mit Gründern und anderen Produktmenschen spreche, frage ich sie: Nutzen die Leute dein Produkt? Und sie springen fast immer direkt zu Nutzerdaten. „Wir haben ein DAU/MAU-Verhältnis von 50 %. Wir haben 10.000 Anmeldungen überschritten. Wir haben eine Million Leute auf der Warteliste. Unser ARR beträgt eine Million. Wir verarbeiten vier Milliarden Tokens pro Tag. Wir sind auf Platz 3 im App Store.“
Ist irgendetwas davon eine Antwort auf die Frage, die ich gestellt habe?
Manchmal stelle ich die Frage erneut, füge aber ein weiteres Wort hinzu: Nutzen die Leute dein Produkt wirklich? Und dann, manchmal, erkennen sie, worauf ich hinauswill.
Der Zweck von LinkedIn war, gefunden zu werden und andere zu finden. Vielleicht war die Kernhandlung für manche Leute einfach, zu antworten, wenn jemand Kontakt aufnahm. Für die meisten ist das keine tägliche Sache; es könnte einmal oder zweimal im Jahr sein.
Schau dir diesen Zyklus an – einmal oder zweimal im Jahr. Dies zu verstehen war entscheidend dafür, dass LinkedIn funktionierte, weil das Netzwerk eine sehr große Anzahl von Leuten brauchte, die bereit waren, gefunden zu werden, und zumindest einige Leute, die das Finden übernahmen.
LinkedIn war schließlich ein soziales Netzwerk, also könntest du versucht sein, Nutzer dazu zu drängen, täglich Aktionen durchzuführen. Das haben wir nicht getan. Stattdessen haben wir in den frühen Tagen enorm viel Zeit damit verbracht, sicherzustellen, dass die Leute ihre Profile aktuell hielten. Es war völlig in Ordnung, wenn du nur einmal oder zweimal im Jahr gefunden wurdest, solange du, wenn es tatsächlich passierte, klicktest und verstandest: „Jemand kontaktiert mich, das ist großartig.“
Wenn du misst, ob dein Produkt funktioniert, sind diese Kernhandlungen das, worauf es ankommt. Konzentriere dich auf direkten Traffic: Finde die Leute, die buchstäblich zu dir gekommen sind. Sie haben die App installiert und das Icon angeklickt, oder sie haben deine Domain von Hand eingegeben; sie sind aus eigenem Antrieb zu dir gegangen. Das ist der Traffic, der zählt, im Gegensatz zu allen anderen Wegen, jemanden in dem Moment zurückzuholen.
Und dann zähle nur wirklich die Leute, die die Kernhandlungen ausführen. Nicht „kurz die App geöffnet“, sondern tatsächlich damit interagiert. Bei Discord wäre das: „an einer Live-Session teilgenommen. Tatsächlich Nachrichten gelesen und gesendet.“
Wenn du nicht definieren kannst, was diese Kernhandlungen sind, dann hast du kein Produkt, weil du nichts hast, das du verstehst.
Nun, eine Sache, die neu ist und die ich liebe, ist, dass du bei KI-Produkten, bei denen der Nutzer mit dem Produkt spricht oder es in irgendeiner Weise promptet, jetzt ein wörtliches Transkript deiner User Journey hast. Du kannst sehen, was Leute in ihren eigenen Worten sagen. Du kannst den genauen Moment sehen, in dem jemand aufgegeben und umformuliert hat. Du kannst sehen, was sie vom Produkt erwartet haben, was es nicht getan hat. LIES DIESE! KI ist großartig darin, Dinge ans Licht zu bringen, die du vorher nicht gesehen hättest, aber du kannst sie nicht alles zusammenfassen lassen, und du kannst sie nicht deine Meinung bilden lassen. Deine Meinung zu bilden – herauszufinden, was die Geschichte tatsächlich ist – ist der Job und die Kunst des Product Managements.
Onboarding
Onboarding ist der einzelne wichtigste Moment, in dem du deine Geschichte einem Kunden erzählen musst. Sie haben dein Produkt entdeckt – vielleicht durch eine Anzeige, eine virale Einladung, einen Artikel, was auch immer. Sie wissen, dass du existierst; sie sind neugierig und wollen es ausprobieren. Du wirst nie wieder so viel Aufmerksamkeit von ihnen bekommen.
Du musst dir an diesem Punkt bewusst machen, dass nicht jeder mit derselben Motivation zu deinem Produkt kommt. Da sind die Eifrigen. Sie wollen so dringend rein. Sie sind bereit loszulegen. Und, nur damit wir uns klar sind, wenn du im Unternehmen arbeitest, lebst du im Land der Eifrigen. Jeder interne Mitarbeiter sollte wie ein Eifriger behandelt werden; sie sind bereits jeden Tag tief im Produkt verwurzelt. Wenn sie onboarden, denken sie: „Ich weiß, was ich tue, das ist langweilig, warum gibt es diesen Schritt?“
Auf der anderen Seite gibt es die Vorbeiflieger. Sie sind einfach nicht so interessiert an dir. Sie haben davon gehört, es ausprobiert, aber die Botschaft ist nicht angekommen, und sie werden abspringen.
Diese beiden Arten von Nutzern sind die Ränder der Verteilung. Dazwischen liegt ein großes, unscharfes Mittelfeld. Das sind Leute, die aus einem Grund erschienen sind: Sie sind neugierig! Sie wollen mehr erfahren! Und du kannst sie tatsächlich in Kernnutzer deines Produkts konvertieren. Das sind die Leute, um die herum du bauen musst. Die Eifrigen bekommst du sowieso. Das Mittelfeld ist das, was du verstehen musst.
Gehe davon aus, dass deine Nutzer motiviert und neugierig sind. Nimm dir die Zeit, das Produkt Schritt für Schritt einzuführen. Mehr einfache Schritte schlagen weniger komplexe. Ich habe dies im Laufe der Jahre in A/B-Tests bei mehreren Unternehmen bewiesen. Wenn jeder Schritt diskret und einfach ist und klar ist, wonach gefragt wird und was gelehrt wird, schlägt das einzelne große Screens oder komplexe Entscheidungen, um die Anzahl der Schritte niedrig zu halten. Jedes Mal.
Wie baust du das also tatsächlich?
Beginne damit, die Kernbotschaft zu wiederholen: Hierfür ist das da. Stelle den Kontext innerhalb des Produkts dar. Es ist in Ordnung, nach den Basics zu fragen – E-Mail, Passwort, Telefon. Erkläre für alles andere, warum du fragst, und wie es zusammenhängt. Dann zerlege dein Produkt in seine Schlüsselkonzepte, jedes mit einer klaren Aktion für den Nutzer.
KI-Produkte haben dies schwieriger gemacht, nicht leichter. Du bekommst das leere Prompt-Feld. In gewisser Weise ist es der schlechteste Onboarding-Screen, der je entworfen wurde. Es ist eine magische Box. Es kann alles tun. Also… was willst du tun?
Viele Produkte beginnen heutzutage mit: „Hi, ich bin hier, um zu helfen, frag mich alles!“ Für mich persönlich bin ich in diesem Moment nicht der artikulierteste oder kreativste Mensch. Du musst Fähigkeiten Konzept für Konzept beibringen. „Wenn du etwas wie dies fragst, kann ich es tun.“ Und dann lass das Produkt es tun. Bringe den Nutzer schnell zu mindestens einem wertvollen Use Case, idealerweise mit seinen eigenen Daten, damit es tatsächlich wertvoll für ihn ist.
Leute fragen mich manchmal: Bei einem längeren Flow, fallen nicht mehr Leute ab? Ja! Aber diejenigen, die durchkommen, sind weit, weit wahrscheinlicher, dass sie dein Produkt tatsächlich nutzen. Wenn du zwei verschiedene Onboarding-Flows per A/B-Test vergleichst, schaue NICHT darauf, wie viele Leute das Ende des Flows erreicht haben. Schaue darauf, wie viele Leute am nächsten Tag oder in der nächsten Woche wiederkommen und wie viele eine Kernaktion ausgeführt haben. Wenn du sie in diesem Moment fragst: „Was ist dieses Produkt?“, sollten sie dir mehr oder weniger die richtige Antwort geben. Deine Retention-Daten sind von diesem Punkt an dein Zeugnis.
Eine Geschichte von Twitter
Ich werde das Ganze zusammenfassen, indem ich dir eine Geschichte von Twitter erzähle.
Ich bin Ende 2009 zu Twitter gestoßen. Wir hatten ein Wachstumsproblem – außer dass es eigentlich kein Wachstumsproblem war. Twitter war ständig in den Nachrichten. Leute bloggten darüber, die Medien sprachen darüber, und viele Leute fragten: „Was ist dieses Twitter-Ding? Ich muss es herausfinden und mich anmelden.“ Und dann taten es Millionen von ihnen. Aber sie kamen nie zurück.
Das Problem war, dass niemand dir erklären konnte, was Twitter war. Ich kann das tatsächlich beweisen:
Bildunterschrift: „Wir landeten schließlich auf Platz eins.“
So wie wir Onboarding machten, meldeten sich Leute an und sahen Optionen wie „Finde deine Freunde“ oder „Folge 20 zufälligen Personen“. Die meisten übersprangen es und landeten auf einer Seite, die so aussah:
Das ist ziemlich schrecklich! Es ist eine große, leere Box. Leute schauten es an und dachten: „...Ich habe nichts zu sagen.“ Und dann gingen sie. Wenn du sie in diesem Moment gefragt hättest: „Was ist Twitter?“, hätten sie gesagt: „Ich denke, es geht darum, etwas in die Welt zu rufen? Oder meine Freunde zu finden? Ich weiß es nicht.“
Also haben wir das Onboarding über ein paar Jahre hinweg neu aufgebaut und fanden die Sache, die funktionierte, nämlich den Learn Flow. Wir brachten ihnen Twitter bei, ein Konzept nach dem anderen, als Geschichte. Und es bewegte die Retention mehr als alles andere, was wir in diesem Jahr ausgeliefert haben.
Der Learn Flow, Bildschirm für Bildschirm
Zuerst die neue Startseite: „Willkommen bei Twitter.“ Wir haben nicht versucht, dort Inhalte zu platzieren, nur: „Finde heraus, was gerade mit den Personen und Organisationen passiert, die dir wichtig sind.“ Das ist ehrlich gesagt eine ziemlich gute Beschreibung von Twitter.
Dann: Dies ist ein Tweet. Es ist eine kurze Nachricht, bis zu 140 Zeichen, und sie kann Links enthalten. Jetzt weißt du, dass Tweets die Einheit dieser Sache sind.
Als Nächstes musst du deinen Timeline aufbauen. Also zeigten wir dir eine Timeline. Wir ließen dich links auf „Folgen“ bei Personen klicken. Und wenn sie auf Folgen klickten, erschienen ihre Tweets rechts. So bekommst du die ganze Idee in einer Bewegung: Ich klicke auf Folgen, Tweets erscheinen, das ist meine Timeline. Was das tatsächliche Konzept von Twitter ist – Tweets, Folgen und eine Timeline.
Und dann, schließlich, deine Timeline. Du würdest jedes Konto darauf erkennen, weil du ihnen tatsächlich selbst gefolgt bist.
Onboarding ist deine Geschichte.
Das richtige Produkt für deine Nutzer
Dein Job als Product Manager ist es, deinem Team und deinem Unternehmen zu helfen, das richtige Produkt an deine Nutzer auszuliefern. In einer Welt mit KI ist das Ausliefern weniger das Problem als früher. Das richtige Produkt herauszufinden und wer deine Nutzer sind, ist genauso wichtig wie eh und je. Wenn nicht wichtiger.
Frage immer, ob die Leute dein Produkt wirklich nutzen. Verstehe, was das bedeutet. Denke über den Zweck, die Kernhandlungen und den Zyklus nach. Verbringe mehr Zeit mit Onboarding, als sich vernünftig anfühlt. Dort konvertierst du das unscharfe Mittelfeld, und dort erzählst du tatsächlich die Geschichte deines Produkts.
Nutze KI, um bei Prototypen schneller zu werden — aber beschleunige nicht dein Urteilsvermögen. Gib dein Urteilsvermögen nicht auf. Sag nicht einfach: „Naja, testen wir es mal und schauen.“ So endet man mit einem schlampigen Produkt. Behalte dein Urteilsvermögen überall. Der schwierigste Teil des Jobs ist immer noch, unsere gesamte Kreativität als Product Manager gegen all die Daten abzuwägen, auf die wir jetzt Zugriff haben.
Viel Glück!
