Entwicklung und alles, was dazugehört

In den letzten zwei Jahren haben sich 31.832 Menschen als Product Manager bei Whatnot beworben. Wir haben einen eingestellt. Die Wahrscheinlichkeit, ein Loch in einem zu treffen, ist doppelt so hoch wie die Wahrscheinlichkeit, durch eine einfache Bewerbung einen Job zu bekommen.

Das ist kein Prozessversagen. Ich entwickle seit über einem Jahrzehnt Produkte – und Produktteams – und einer der größten Faktoren für meine Entscheidung, vor etwa 3 Jahren zu Whatnot zu kommen, war die sehr bewusste Produktkultur. Niemand weiß genau, was es bedeutet, in der Welt der KI ein PM zu sein, aber alles, was ich sehe, deutet darauf hin, dass sich die Branche in unsere Richtung bewegt und dahin, wie wir hier entwickeln – denn kein Tool wird dich nützlich machen, wenn du nicht den richtigen Job machst.

Zuerst müssen wir Folgendes müssen wir anerkennen: Der durchschnittliche PM ist zutiefst durchschnittlich.

Die Produktfunktion entstand als Reaktion auf Skalierung – Engineering-Teams wurden zu groß, als dass CEOs oder GMs sie direkt verwalten konnten, also brauchte es eine Schnittstelle zwischen Business und Technik. Im Laufe der Zeit haben wir die Rolle fälässig verallgemeinert zu „Jedes Mal, wenn du einen Engineering Manager einstellst, stellst du einen PM ein PM ein.“ Aber wo ein Eng Director 30-40 Leute durch seine EMs führte, führte ein PM Director nur fünf. Anreize regieren die Welt, also wurden die Jobs dieser Directors zu „das Wachstum meiner Engineering-Partner rechtfertigen“, damit sie wiederum ihr eigenes Wachstum rechtfertigen und VP werden konnten. Langsam verlagerte sich die Rolle der Junioren von „CEOs des Produkts“ zu „Babysittern von Buttons“ und produktdenkende Ingenieure zu infantilisierten Auftragsabwicklern.

Dann kam COVID und die Branche stellte in nur vier Jahren unglaubliche 500.000 neue Softwareentwickler ein, und etwa 80.000 neue PMs wurden dazu geschaffen. Das sind 80.000 PMs, die in riesigen Teams bei FAANG vergraben sind, weit weg von jedem Kunden, 50 Ebenen entfernt von dem Zoom, in dem die Entscheidungen fallen, die in einer Produktschule nach dem Prinzip „Malen nach Zahlen ausgebildet wurden, in einer Ära unverdienten Engagement-Wachstums, in der schein scheinbar alles funktionierte.

Die Wahrscheinlichkeit, dass daraus jemand mit großartigen Produktinstinkten, Erfahrung und Durchhaltevermögen hervorgeht, erscheint tatsächlich geringer als ein Loch in einem zu treffen.

Zweitens: Wir haben unsere Besten schlechter gemacht.

Wenn dein Job darin besteht, fünf Leute zu beaufsichtigen, kannst du mit deinem Tag nur in die Arbeit anderer Leute eingreifen. Sie mögen das nicht und bezeichnen es in einer anonymen Umfrage als Mikromanagement, also ziehst du dich zurück. Wie verbringst du dann deine Zeit? Du erzählst Geschichten, bringst Dinge durch Reviews, damit deine Teams „erfolgreich“ sind, rechtfertigst Ressourcen. Aber du weißt nicht, welche Geschichte du erzählen sollst, also stellst du ein User-Research-Team auf, das dir sagt, was zu tun ist, und dann eine PMM-Funktion, um diese Geschichte den Kunden zu erzählen. Die Funktion, die strategisch wichtig wurde, weil sie Kontext zu sammeln und Klarheit zu verbreiten, zog sich in immer höher.

Aber die eigentliche Wahrheit liegt in den Datenmodellen deiner Systeme, in Sales-Anrufen, CX-Tickets, in den Analysen – nicht in der hübschen 2x2-Matrix, die alles vereinfachen soll.

Die ganze Zeit, die du mit Management verbringst, bedeutet, dass dein angeborenes Verständnis der Probleme veraltet, deine Instinkte für deinen Kunden stumpfer werden, die Wahrscheinlichkeit, dass du richtig liegst, sinkt.

Unser Schlagdurchschnitt als Funktion sank sowohl, weil der Nenner wuchs, ALS AUCH, weil dieses Wachstum bedeutete, dass jeder, der vor sieben Jahren gut in Produkt war, aus dem eigentlichen Arbeiten befördert wurde (oder reich genug wurde, dass der Anreiz, zu bleiben und Politik zu spielen, gering war).

Der Whatnot-Weg

Seit seiner frühesten Gründung basiert das Whatnot-Produktteam auf einer recht einfachen Prämisse: Wir bedauern, dass Produktmanagement existiert. Vertrieb und Engineering kamen vor unserer Einstellung gut miteinander aus, also sollten sie, wo sie können, einfach ohne prozedurale oder sinnlose Papierkram ausliefern. Produkt ist ein Handwerk, keine Qualifikation. Jeder, der es gut macht, hat es durch Tun gelernt und dadurch, dass er großartigen Menschen dabei zugesehen hat.

Ich war kürzlich in einem Vorstellungsgespräch, wo mir jemand sagte, Whatnot fühle sich an, als hätten Twitch und eBay ein Baby bekommen – kulturell könnte es nicht falscher sein, aber in Bezug auf die Produktspanne ist es ein anständiger Vergleich. Eine konservative Schätzung besagt, dass diese beiden Organisationen zusammen >400 PMs haben. Wir haben 20. 20 PMs für über 1200 Mitarbeiter insgesamt.

Unsere PMs sind Problemen zugeordnet, nicht EMs. Diese beiden überschneiden sich oft, sind aber nicht dasselbe. Wenn du ein neues Verkaufsformat für Mode-Verkäufer baust, wirst du ziemlich eng mit den EMs zusammenarbeiten, die dafür verantwortlich sind, wie Listings und Inventar funktionieren, aber genauso mit den Logistik- und Zahlungs-EMs.

Über mehrere Stacks hinweg zu arbeiten und Auswirkungen auf verschiedene Kunden abzuwägen, ist nicht einfach – es erfordert breites Kontextwissen über das Geschäft, die Fähigkeit, nachgelagerte Auswirkungen von Änderungen an Funktionen vorherzusehen, Geschick im Kontextwechsel, die Fähigkeit, Vertrauen in einer ganzen Organisation aufzubauen und auszugeben, nicht nur mit einem Partner. Deshalb stellen wir fast ausschließlich Senior-PMs ein. PMs, die endlose Abstimmungsmeetings satt haben und es wieder zu bauen. Oder wir konvertieren vielversprechende Leute aus Vertrieb oder Operations und lassen sie durch Tun lernen. Wir suchen immer nach dem Loch-in-einem-Mitte-Karriere-L5/L6-Kandidaten, aber die Statistiken lügen nicht darüber, wie oft wir sie finden.

Schließlich liefert jeder aus, auch ich. Ich arbeite immer direkt mit einem Team von Ingenieuren und Designern zusammen, um Funktionen als IC auszuliefern, und das tun auch unsere beiden Mitgründer auch. Als es an der Zeit war zu testen, ob es für PMs machbar ist, kleine Funktionen zu „vibecoden“, war ich das Versuchskaninchen. Als es an der Zeit war, unseren ersten Verkäufer in Australien einzuarbeiten, war es unser Mitgründer Logan, der das tat. Als Zendesk anfing, Kunden-Tickets fallen zu lassen, war es unser CEO Grant, der mit deren Support-Ingenieur sprach.

Als Unternehmen verlangen wir von jedem Mitarbeiter, zu verkaufen, zu kaufen und CX-Tickets zu bearbeiten, oder wir geben ihnen eine Bewertung unter den Erwartungen. Wenn PMs in einem Unternehmen mit diesem Engagement für Kundenorientierung führen sollen, müssen wir tief darin sein, wie die Dinge funktionieren, und breit darin, warum. Wir nennen es „T-förmig sein“ – gleichzeitig eine Breite an Kontext und die Tiefe in deinem Bereich zu haben. Tiefe und Erfahrung ermöglichen es dir, schnell Entscheidungen zu treffen; nicht auf 5 Ebenen Management warten zu müssen, die es überprüfen, bedeutet, dass diese Entscheidungen zu Aktionen werden.

Members of Technical Staff

Es gibt gerade so viel Lärm ums „Bauen“… Nein, Product Requirement Docs sind nicht tot. Ein PRD ist nur ein Gefäß, um klar über ein Problem nachzudenken und es anderen zu artikulieren. Mach deins interaktiv, wenn du willst, niemanden interessiert's. Nein. Nein, die Kosten für die Auslieferung eines schlechten Produkts sind nicht auf Null gefallen, sie werden immer noch von deinen Kunden bezahlt. Ihnen 16x schneller Spaghetti an den Kopf zu werfen, ist in der Tat keine Revolution, sondern einfach nervig. Und nein, nicht jeder wird ein S-Tier-Eng und Designer und PM in einem sein. Einige wenige werden es sein, aber die gleichen Treiber der Spezialisierung – was Menschen genießen und worin sie gut sind – werden weiterhin bestimmen, wie wir arbeiten.

Was sich jedoch ändert, ist die Erkenntnis, dass ein IC zu sein eine viel bessere Nutzung der Fähigkeiten, Erfahrungen und der begrenzten Zeit vieler Menschen auf dieser Erde ist, als dasselbeitsdokument zum 5. Mal umzuschreiben, um es dem bevorzugten Format des aktuellen Pedanten anzupassen. Einige PMs bei Whatnot sind Manager, aber jeder von ihnen verbringt 90%+ seiner Zeit als IC. Es gibt keinen Unterschied in unseren Titeln oder unserer Vergütung für diejenigen, die managen oder nicht, weil wir darin keinen inhärenten Wert sehen. KI gibt uns unglaubliche Hebelwirkung – ich kann bei fast jeder Aufgabe im Entwicklungsprozess, sei es das Verstehen von Daten, die früher einen Datenwissenschaftler erforderten, um sie zu entwirren, oder die Umwandlung eines PRDs in jede Permutation von CX-SOPs, die normalerweise Gegenstand langer Nächte im Büro in der Launch-Woche wären. Ich kann einen Bot bauen, der die 100 Fragen pro Woche aus dem Vertrieb sortiert oder die Lokalisierungslücken findet, die wir in einem kürzlichen Experiment hinterlassen haben.

Das Disruptivste an der KI für PMs ist, dass sie gezeigt hat, dass die Hebelwirkung des Coachings von Menschen und der Arbeit durch sie nicht mehr die einzige Hebelwirkung ist, die sie einmal war. Besonders wenn diese Menschen – ohne eigenes Verschulden – zutiefst durchschnittlich sind. Aber diese Hebelwirkung steht nur Menschen zugänglich, die noch wissen, wie man die Arbeit macht.

Besonders ermutigend an diesem Trend ist, dass er die besten PMs wieder dazu bringen wird, echte PM-Arbeit zu leisten. Das Nachdenken über die Bedürfnisse des Kunden und des Geschäfts und den guten Geschmack, um es auf die beste Weise zu lösen. Als Kunde anderer Unternehmen freue ich mich darauf, dass die Leuchttürme unserer Branche wieder mit dem Bauen beginnen – das wird ihre Produkte verbessern. Als jemand, der besessen davon ist, das kleinste, am stärksten gehebelte PM-Team der Geschichte aufzubauen, freue ich mich darauf, dass es die unglaublichen Menschen freisetzt, die seit einem halben Jahrzehnt Roadmap-Reviews nur noch runterbeten.

Zeigen, nicht erzählen

Im Folgenden werde ich (vollständig) das eine Dokument kopieren, das wir darüber haben, wie wir bei Whatnot im Produktbereich arbeiten. Wenn wir uns auch nur einmal getroffen haben, musst du mir nicht sagen, wer der Autor ist – so reden und arbeiten wir.

Du kannst dir auch ansehen, wer in unserem Team arbeitet – es gibt mindestens sechs Leute im Team, die CPO bei einem Series-B-C-Startup sein könnten, die ihren Abend damit verbringen, mit Verkäufern zu telefonieren, 400 Queries tief in einem Hex-Thread zu sein oder den ersten Entwurf der Kommunikation für den morgigen Launch zu verfassen. Es sind vier ehemalige Gründer, die noch nie in ihrem Leben zugestimmt haben, dass etwas außerhalb ihres Zuständigkeitsbereichs liegt. Es sind vier ehemalige FAANG-Direktoren, die ihre Tage nicht mehr damit verbringen, darüber zu debattieren, wo Menschen in einem Nine-Box-Grid leben sollten. Es sind sechs frühe PMs mit unglaublichem Geschmack, denen gesagt wird, dass sie mehr Dinge ausprobieren müssen, weil wir nur durch Tun lernen.

Ich bezweifle, dass unsere einstige Erklärung von maximal 20 PMs Bestand haben wird – die Chance, die vor uns bei Whatnot liegt, ist so enorm, dass wir uns nicht künstlich einschränken werden – aber die Messlatte für diejenigen, die wir einstellen, wird nur steigen, da die Branche und KI-Tools großartige ICs weiterhin mit Hebelwirkung belohnen. Wenn du einer dieser Leute bist und das, was ich oben beschrieben habe, dich antreibt, wirst du herausfinden, wie du mich erreichen kannst.

Bauen bei Whatnot

Große Produkte zu bauen ist schwer. Es geht nicht nur darum, die richtige Erkenntnis über das Problem zu haben, die Details richtig zu machen, es richtig auf den Markt zu bringen, es richtig zu messen, um seine Leistung zu verstehen, oder schnell daran zu iterieren. Es geht darum, dass du all diese Dinge tun musst, sonst funktioniert es nicht. Schlimmer noch, Scheitern ist teuer. Wir haben wenige Teams und eine enorme Menge an Chancen vor uns – einen Schlagdurchschnitt von .300 zu haben, ist großartig, wenn du in der MLB spielst, aber um unsere Ziele zu erreichen, brauchen wir eher .500. Ohne einen hohen Durchschnitt schränken wir entweder das Wachstum kurzfristig ein oder wir koppeln das Geschäftswachstum an das Personalwachstum und schränken uns langfristig ein.

Dieses Dokument hat 2 Teile:

1. Unsere Philosophie – diese wird sich nicht ändern
2. Unsere Prozesse – diese werden sich weiterentwickeln, der aktuelle Stand wird hier festgehalten

Wie wir bauen, gibt uns Hebelwirkung

Du kannst ein Gebäude nicht Raum für Raum für Raum bauen, du musst das gesamte Gebäude auf einmal entwerfen und bauen. Zum Glück arbeiten wir nicht im Baugewerbe, sondern in der Softwareentwicklung. Iteratives Bauen ist unsere Superkraft. Wir bringen immer die kleinste Einheit auf den Markt, die echten Benutzerwert und eine solide Benutzererfahrung bietet, aber wir entwerfen Dinge weiter im Voraus, um sicherzustellen, dass wir sie skalieren können.

Der Happy Path eines erfolgreichen Produkts hier durchläuft konsequent 7 Schritte:

1) Es ist etwas, das für Benutzer und unser Geschäft wichtig ist

Priorisiere gnadenlos die wirkungsvollsten Dinge, die für unsere Benutzer und Geschäftsbedürfnisse lösen.

• Du musst in der Lage sein, diesen Wert explizit zu artikulieren: „Ermögliche skalierte Einzelhändlern, Produkte, die an mehreren Standorten gelagert werden, in einer einzigen Sendung zu verkaufen – indem ‚versendet von‘ zu einem Produktfeld gemacht wird, nicht zu einem Sendungsfeld“
• Denke über das System nach.

1. Ist dieses Produkt sofort nach der Einführung wertvoll?
2. Ist es ein ‚Baustein‘ für andere Dinge?

Wenn (1) nicht zutrifft, fahre nicht fort. Wenn (1) zutrifft, arbeite heraus, wie es im Laufe der Zeit zu (2) werden kann.

2) Es ist etwas, das die Leute wollen

Verstehe ihre Schmerzpunkte, Wünsche und Verhaltensweisen, um ein Produkt für sie zu schaffen.

• Das weißt du nicht, es sei denn, du verstehst den Benutzer, für den du baust, im Detail. Verbinde qualitativ und quantitativ.
• Denke über dein Produkt im Kontext bestehender Produkt-Workflows nach.
• Lege keine Schicht über Mist.
• Zerstöre keinen Workflow, der Problem B löst, weil du auf Problem A fokussiert bist
• Wenn das Problem real ist – weißt du, wie sie es heute umgehen?
• Hüte dich vor glänzenden Objekten. Besonders glänzenden Objekten, die du anderswo in der Vergangenheit gebaut hast.

3) Kundenbedürfnisse stimmen nicht mit unseren Organigrammen überein / werden nie mit einer einzigen Funktion erfüllt.

Wenn du lokal baust, baust du naiv.

• Du musst von einer vollständigen Kundenerfahrung ausgehen, nicht von Code-Besitz. Geh das Problem an, Punkt.
• Das Gegenteil ist auch wahr – andere PMs werden in „deinen Bereich“ drängen müssen. Hilf ihnen.
• Dieses Prinzip ist der Grund, warum wir ein so kleines kleinstmöglichen Produkt- und Designteams anstreben. Je mehr Leute es gibt, deren Rolle eng definiert ist, desto kurzsichtiger werden Roadmaps und desto mehr Zeit verschwenden wir mit Koordination und Abstimmung.

4) Es ist die einfachste mögliche Lösung, die das Problem löst.

Der Schlüssel zum schnellen und zuverlässigen Bauen von Produkten, die Benutzer lieben, ist die Vermeidung unnötiger und nicht wirkungsvoller Arbeit

• Einfach ist nicht nur schnell zu bauen, sondern in der Regel auch am erfolgreichsten.
• Über das System nachzudenken bedeutet nicht, das gesamte System im Voraus zu bauen.
• Je mehr du baust, bevor du weißt, dass du richtig liegst, desto teurer ist es, wenn du falsch liegst.

5) Es wurde mit dem kleinstmöglichen Publikum validiert.

Du rätst nur, bis es jemand benutzt.

• Bring Papier- oder klickbare Prototypen so schnell wie möglich in die Hände von Verkäufer. Das Dogfooding der Mitarbeiter findet Fehler besser, als es eine Lösung validiert, weil wir nicht unsere Kunden sind.
• Denke über deine GTM-Bewegung nach
• Verkäuferorientierte Produkte: Beginne mit <10 Verkäufern, skaliere entweder nach Anzahl der Verkäufer oder auf wenige Kategorien, bevor du in den GA gehst.
• Käuferorientierte Produkte: Beginne entweder mit einer Kategorie oder einem kleinen Prozentsatz und steigere dich mit Signal.
• Ökosystem-Produkte (für beide sichtbar): Beginne entweder mit einer Kategorie oder einem kleinen Markt
• Wenn du dich im Validierungsmodus befindest, ist, ist das Lösen von Bekanntheit (intern oder extern) ein Fehlermodus.
• Es ist so subskalig, dass es die Menschen nicht wirklich beeinflusst
• Du weißt noch nicht, ob es funktionieren wird – verschwende nicht die Zeit der Leute

6) Einmal validiert, iterieren wir es wie verrückt.

Sobald es für Kunden live ist, liefern wir wöchentlich, wenn nicht täglich, Verbesserungen aus.

• Wenn du hörst „Sobald wir X ausliefern, können wir zu Y übergehen“, ist das eine riesige rote Flagge.
• Sobald wir wissen, dass es ein Ding wird, musst du zurückgehen und für Catex und CX lösen
• Launch, validiere, messe, iteriere, iteriere, iteriere > dann gehe zur nächsten Priorität.

7) Wir rennen durch Wände, sobald wir in der Beta sind.

Einen Funken zu bekommen ist schwer. Sobald du einen hast, musst du Sprit draufgießen, sonst stirbt er.

• Das größte Risiko beim Starten von hypersimplen, sehr frühen Produkten ist, dass sie unvollständig und daher nicht wirklich langfristig nützlich sind. Sobald du startest, bist du im Rennen, um von hohem Potenzial zu hoher Wirkung zu gelangen.
• Konzentriere dich darauf, den Wert, den du schaffst, zu maximieren und nicht jede kleine Beschwer Kleinigkeit, jedes Risiko oder jede Auswirkung zu managen.
• Herauszufinden, welche Beschwerden, Risiken und Auswirkungen du beachten musst, ist eine Frage des Urteilsvermögens für jeden Launch. Sich um Nicht-Risiken zu sorgen, ist genauso gefährlich, wie sich nicht um sie zu sorgen.

8) Das hier ist nicht der Bachelor – entkopple alles

Es gibt eine natürliche Tendenz beim Entwerfen eines Systems, mehrere Teile davon gleichzeitig ausliefern zu wollen. In einem ausreichend komplexen System wie unserem arbeiten wahrscheinlich mehrere Teams parallel an Komponenten eines Systems, und es mag sinnvoll erscheinen, sie gemeinsam auszuliefern, damit es eine große Änderung ist statt zwei. Es ist auch eine Falle.

• Solange jedes Teil unabhängig lebensfähig und vorteilhaft für Kunden ist, bringe sie so schnell wie möglich auf den Markt
• Es ermöglicht uns, jedes effektiver zu messen und ihre relativen Beiträge zu verstehen
• Vorteilhafte Produkte im Staging auf andere warten zu lassen, ist schlecht für Kunden

Die Rolle von Reviews und Feedback

Wir haben einen Produktprozess dokumentiert, dessen Ziel es ist, sicherzustellen, dass wir an den richtigen Dingen und auf die richtige Weise arbeiten. Dies umfasst Sichtbarkeits-, Genehmigungs- und Rechenschaftsfunktionen. Wichtiger als das blinde Befolgen dieses Prozesses ist jedoch die Verinnerlichung der zugrunde liegenden Philosophie – die in diesem Twitter-Thread gut artikuliert ist … (ernsthaft, lies ihn, bevor du fortfährst)

1. In einem komplexen System brauchst du viel mehr Abstimmung, als du denkst, um tatsächlich zur richtigen Antwort zu gelangen. Weil dieses Wort falsch interpretiert werden kann:
2. Abstimmung bedeutet niemals Konsens. Konsens ist der Feind guter Entscheidungsfindung.
3. Abstimmung bedeutet nicht, Arbeitsabläufe zu koppeln. Koordination ist der Feind von Geschwindigkeit.
4. Der Lackmustest für Abstimmung – ein schriftlicher Plan. Wenn Grant nach einem fragt, sind wir nicht abgestimmt.
5. Autonomie bei Whatnot ist Autonomie der Autonomie der Umsetzung. Niemand hat oder sollte Autonomie der Strategie erwarten. Ohne Abstimmung ist Autonomie verschwendet.

Um die Erwartungen bei Whatnot zu erfüllen, muss ein PM oder Designer

1. Dinge identifizieren, die sofortige Abstimmung erfordern, und diese aktiv suchen
2. Schnell von der Abstimmung zur Umsetzung übergehen, weil sie die Diskussion und die Abstimmung tief verstehen. Sie hören nicht in Diskussionen auf ein „Ja“.
3. Die Umsetzungsdetails mit ihrem Team ausfüllen / schnell Entscheidungen entblocken, die der Abstimmung folgen.

Warum Geschwindigkeit wichtig

Unser ganzes System basiert auf der Maximierung der Geschwindigkeit, mit der wir das Richtige ausliefern. Die Schritte 1-3 des Happy Paths drehen sich darum, herauszufinden, was wir für das Richtige halten, 4-7 darum, wie wir dieses Ding validieren, iterieren und skalieren. Wir tun das, weil:

1) Alles in unserem System wirkt sich aus – das Gute und das Schlechte

Im Jahr 2025 haben wir etwa 250 Geschäftstagen 750 Experimente durchgeführt, was ungefähr 3 Ship/Don't-Ship-Entscheidungen pro Tag entspricht. Wenn du die langfristigen Auswirkungen simulierst, jede dieser Entscheidungen nur 3 Kalendertage schneller zu treffen, beträgt die Auswirkung über einen Zeitraum von 2 Jahren >1,1 Mrd. USD an zusätzlichen Ertrag für Whatnot-Verkäufer. Nicht die Auswirkungen dieser Produkte, sondern nur die Auswirkungen, diese Entscheidungen geringfügig schneller zu treffen. Jede Verzögerung beim Ausliefern des Richtigen schadet unseren Kunden, und je größer wir größer werden, desto mehr Opportunitätskosten entstehen durch Langsamkeit.

2) Einmal verlorene Geschwindigkeit kommt nie zurück

Menschen passen sich natürlich an und verlassen sich auf Prozesse, sodass selbst für enge Anwendungsfälle erfundene Prozesse großzügiger angewendet werden als beabsichtigt. Anreize verschieben sich dahin, dem System zu folgen, anstatt die Wirkung zu erzielen, die das System sicherstellen soll, und das Muskelgedächtnis der Organisation, „zu wissen, aber zu gehen“, verkümmert und geht verloren. Es gibt fast keinen einzigen Fehler, den wir verhindern könnten, der langfristig ein guter Kompromiss dafür wäre, die Geschwindigkeit zu verlangsamen, mit der wir bauen.

3) Geschwindigkeit ist nicht der Grund für Fehler/Irrtümer

Ausschüsse verhindern Fehler nur als Nebenprodukt der Verhinderung von Fortschritt. Urteilsvermögen ist es, was tatsächlich Fehler verhindert. Häufigeres Ausliefern baut unser Urteilsvermögen auf – wie ein Sportler werden wir durch Wiederholungen stärker. Während sie Wiederholungen aufbauen, können Teams das Urteilsvermögen derjenigen mit mehr Wiederholungen und mehr Kontext nutzen – kontinuierliche ad-hoc-Beratung durch die Produktführung, Sichtbarkeit für wichtige Risikominderungen wie Recht und Kommunikation in den frühesten Planungsphasen (wenn es Hurrikane gibt, die wir im Atlantik vermeiden müssen, müssen wir das wissen, wenn wir den Kurs planen, nicht wenn wir ablegen), Kategorie- oder Länderverantwortliche, die stellvertretend einschätzen können, wie bestimmte Kunden reagieren könnten. Als Teil des Nachdenken über das System sollten PMs versuchen, die Auswirkungen ihrer Launches vorherzusehen, werden aber niemals dadurch blockiert, dass sie Feedback/Input eingeholt oder angenommen haben. Product Review ist das einzige Tor in unserem Entwicklungsprozess.