Verlorenes Vertrauen (Lost confidence)

• RICE und andere vertrauensbasierte Priorisierungs-Frameworks sind größtenteils Rauschen; nötig ist eine Methode, Entscheidungen zu treffen, ohne so zu tun, als kenne man die unbekannte Zukunft
• Vertrauenswerte werden bei kleinen Projekten hoch und bei großen Projekten niedrig angesetzt; dadurch werden Projekte mit hohem Wert systematisch verdrängt und Prioritäten verzerrt
• Vertrauenswerte sind unscharf definiert, es fehlt an Validierungsdaten, und Projekte dauern immer länger und haben weniger Impact als erwartet – daher sind sie nicht verlässlich
• Die Lösung liegt nicht im Bereich der Wahrscheinlichkeit (probability), sondern der Unsicherheit (uncertainty): „Was ist über jede Wahrscheinlichkeitsverteilung hinweg ein kluges Handeln?“
• Statt Vertrauen zu quantifizieren, ist es wichtig, mit Techniken wie immer wahren Dingen, Kunden-Impact, Optionalität und asymmetrischen Wetten zu priorisieren

---

Vertrauensspiele (Confidence games)

• Viele Priorisierungs-Frameworks beziehen in ihren Score ein, wie zuversichtlich man ist, mit dem geschätzten Aufwand den geschätzten Impact zu erzielen
  • Es ist an sich rational, sich zwischen zwei Projekten mit gleichem Wert und gleichem Aufwand für dasjenige zu entscheiden, bei dem die Umsetzungssicherheit höher ist
  • In der Praxis läuft es aber nicht nach dem Muster „1) Scores vergeben → 2) klaren Gewinner umsetzen → 3) bei Gleichstand das mit höherem Vertrauen wählen“
• RICE multipliziert Vertrauen direkt in die Score-Formel der ersten Stufe hinein
  • RICE-Formel: Score = (Reach × Impact × Confidence) / Effort
  • RPS-Formel: Score = Reach × Potential × Solution Confidence
• Diese Methode behandelt zwei unterschiedliche Szenarien als gleichwertig und erzeugt so eine falsche Äquivalenz
  • Eine kleine, sicher umsetzbare inkrementelle Funktion
  • Eine große Funktion mit hohem Impact, aber Risiko
• Da das Vertrauen bei kleinen Projekten meist hoch und bei großen Projekten niedrig ist, führt das Multiplizieren mit Vertrauen systematisch weg von der Richtung, in der maximaler Wert geliefert wird
  • Die zentrale Motivation der Agile-Bewegung war genau die Einsicht: „Bei großen Projekten muss die Erfolgssicherheit immer niedrig sein“
• Warum Vertrauenswerte nicht glaubwürdig sind
  • Unklare Definition: Es ist unklar, was „30 %“ bedeuten soll. Eigentlich müsste man die Vertrauenswerte aller Projekte erfassen und mit den tatsächlichen Ergebnissen abgleichen, um die Genauigkeit numerisch zu berechnen; in der Praxis passiert das aber nicht
  • Wenn pro Jahr nur wenige große Funktionen veröffentlicht werden, fehlt selbst im Nachhinein die Datengrundlage zur Validierung
  • Projekte verspäten sich fast immer, und ihr Impact ist kleiner und langsamer als erwartet. Auch ein 9-Monats-Projekt mit sechs Teams wurde gestartet, weil man „ein gewisses Vertrauen“ hatte
• Zitat von Hofstadter’s Law: „Es dauert immer länger als erwartet, selbst wenn man Hofstadter’s Law berücksichtigt“
• Fragt man erfahrene PMs nach „Funktionen, bei denen sie sicher waren, dass sie gut ankommen würden, was dann aber nicht geschah“, hat jeder mehrere Beispiele
  • Selbst wenn es Belege wie Kundengespräche, explizite Wünsche oder Kaufzusagen gibt, nutzt nach dem Bau kaum jemand die Funktion – oft nicht einmal die Person, die es zugesagt hatte
  • Technik zur Verbesserung von Prognosen: Kunden erklären lassen, wie sie die Funktion Schritt für Schritt in ihrem tatsächlichen Workflow nutzen würden. Beim Durchgehen der Schritte erkennen sie oft selbst: „Dafür müssten wir den Code neu schreiben, also machen wir es nicht“
• Bei Content Creators ist es genauso: Ein hastig veröffentlichter Beitrag ohne große Erwartungen erzielt die meisten Aufrufe und Reaktionen des Jahres, während ein Werk, in das Dutzende Stunden geflossen sind, ignoriert wird
  • Die vier Felder einer 2×2-Matrix „Vertrauen ja/nein × Ergebnis (geliebt/Desinteresse)“ sind alle voller Beispiele

Was man statt Vertrauen und Risiko verwenden sollte (What to use in place of confidence and risk)

• Die Antwort liegt nicht im Bereich der Wahrscheinlichkeit, sondern der Unsicherheit (uncertainty)
  • Wahrscheinlichkeit setzt voraus, dass man die Verteilung kennt. Bei 100 Würfen einer fairen Münze lässt sich sehr gut vorhersagen, dass die Zahl der Köpfe wahrscheinlich zwischen 40 und 60 liegen wird
  • Fast alles in Startups ist anders. Erfolg, Strategie und Funktionen sind entweder beispiellos, zu komplex oder haben keine ausreichend präzisen Eingangsvariablen, sodass keine sinnvolle Wahrscheinlichkeitszuweisung möglich ist
  • Das Konzept der „Knightian Uncertainty“ (Knight’sche Unsicherheit) stammt aus einem Werk des Ökonomen Frank Knight von 1921
  • Auch Bayes’sche Methoden benötigen numerische Prior-Wahrscheinlichkeiten und bedingte Wahrscheinlichkeiten; beides ist unbekannt und nicht definierbar
• Die Frage im Bereich der Unsicherheit lautet: „Welche Handlung ist unabhängig von der Wahrscheinlichkeitsverteilung klug?“

• Immer wahr (True always)

  • Fokus auf Dinge, die unter allen Umständen wahr sind — Bezos’ Prinzip der langfristigen Konstanten (long-term constants)
    • Nutzer bevorzugen grundsätzlich schnelle, reaktionsfähige Software. Sie schätzen Hintergrundsynchronisierung, sofortige Interaktionen und Funktionalität auf allen Geräten
    • Im schlechtesten Fall (Gleichgültigkeit gegenüber Geschwindigkeit) wird Geschwindigkeit dennoch nicht negativ bewertet. Im besten Fall wird Performance zum zentralen Differenzierungsmerkmal, wie bei Notion, Figma, Miro, Gmail und Google Docs
  • Nicht jede Funktion hat universelle Anziehungskraft. Statt präzise numerisch aufzuschlüsseln, sollte man Funktionen identifizieren, die praktisch alle Kunden wertvoll finden oder zumindest mögen
    • Manchmal ist etwas sicher, weil es verpflichtend ist. Enterprise-Anforderungen wie SOC-2-Compliance sind zwar nicht spannend, haben beim Verkauf an Unternehmen aber sicher Wert
    • Diese Gewissheit kompensiert fehlende Differenzierung
  • Allerdings fallen die innovativsten und am stärksten differenzierenden Ideen selten in die Kategorie „absolut sicher“
    • Sicheres ist wertvoll, wird aber schwerlich zum strategischen Differenzierungsfaktor
    • Ein großartiges Produkt braucht sowohl verlässliche Verbesserungen als auch innovative Sprünge

• Schnelle Entdeckung, schnelle Erholung (Quick discovery, quick recovery)

  • Es wurde lange dafür plädiert, Ideen vor dem Bau durch systematische Interviews mit potenziellen Kunden zu validieren; doch auch das gerät in die „Vertrauensfalle“
    • Bevor man etwas baut, kann man es nie mit Sicherheit wissen
    • Vor dem Bau ist jedoch Invalidierung möglich, was Monate bis Jahre an Verschwendung verhindern kann; daher bleibt es ein guter Ausgangspunkt
  • Die typische Lösung ist der Bau eines SLC (ein weiterentwickeltes MVP-Konzept): ein einfaches, aber vollständiges Produkt, mit dem man echtes Feedback erhält – Erfahrung statt Prognose
    • Bestehende Produkte sollten ein ausgewogenes Portfolio aus sicheren Erfolgen und innovativen Wetten halten und jeweils unterschiedliche Validierungsmethoden anwenden
  • Beispiel für „Dummy Features“: ein Button, der beim Klicken anzeigt: „Diese Funktion gibt es noch nicht. Bitte erzählen Sie uns, wie Sie sie nutzen würden“
    • Das liefert ein echtes Signal durch Verhalten: Zahl interessierter Nutzer und potenzielle Interviewpartner
    • Ein 100-mal besseres Signal als Umfragen. In Umfragen sagt man leicht „ja“, aber eine Handlung wie ein Button-Klick erfordert echtes Interesse. Beobachtetes Verhalten schlägt erklärte Absicht

• Statt auf Vertrauen auf Kunden-Impact fokussieren (Focus instead on customer impact)

  • Vertrauen durch Impact ersetzen. Impact wird auf zwei Arten definiert
    • Mehrheitsregel (Majority rule): Eine Funktion, die von der Mehrheit der Nutzer regelmäßig verwendet wird, ist eindeutig wichtig und wahrscheinlich ein zentraler Grund für Adoption und Bindung
    • Leidenschaftliche Fürsprecher (Passionate advocates): Eine Funktion, die bei einer Minderheit begeisterte Fans schafft. Menschen, die sagen: „Nur deswegen habe ich es gekauft.“ Sie ist nicht universell, erzeugt aber in einem bestimmten Segment tiefe Loyalität („magnificent delighters“)
  • Wenn Nutzer einen bestimmten Teil wirklich lieben, nehmen sie andere Mängel in Kauf
    • Dank der Attraktivität des iPod ertrugen Milliarden Menschen iTunes, die schlechteste Software
    • Schön gestaltete Software wird allein wegen des Design-Erlebnisses akzeptiert, selbst wenn Funktionen fehlen oder Plattformen eingeschränkt sind
  • Quantitative Definition einer High-Impact-Funktion
    • (1) Mindestens 51 % der Kunden nutzen sie regelmäßig, oder
    • (2) mindestens 15 % der Kunden nennen sie als einen der drei wichtigsten Gründe für Auswahl oder Verbleib
    • Das sind hohe Standards, aber für innovative und riskante Funktionen sind hohe Standards angemessen; die Größe der Belohnung muss das Risiko rechtfertigen

• In Leverage investieren (Invest in leverage)

  • Es gibt Bereiche, in denen kleine inkrementelle Änderungen große Ergebnisse erzeugen
  • Es gibt Leverage-Bereiche, die mathematisch und strukturell fast immer gelten
    • (Der Teil mit Buchwerbung wurde als Werbung ausgelassen)

• Optionalität maximieren (Maximize optionality)

  • Wenn man die Zukunft nicht kennt, wählt man so, dass die Zahl der Optionen maximiert wird, die man beim Erreichen der Zukunft haben kann
    • Über bloße Flexibilität und Lock-in-Vermeidung hinaus: so gestalten, dass man mit allem umgehen kann, was entsteht
  • Beispiele
    • Niedrige Kosten beibehalten → Profitabilität sichern und verschiedene Preis- und Packaging-Experimente sowie künftige Resilienz ermöglichen
    • Eine gut validierte und aktiv weiterentwickelte Cross-Platform-UI-Bibliothek bzw. ein Framework wählen → auf die Entwicklung von Plattformen und Geräten reagieren
    • Plugin-Architektur → selbst und durch die Community Dinge bauen, die man sich heute noch nicht vorstellen kann
    • API-first-Architektur → Teams entkoppeln, Frontend, Backend und Kundenintegrationen verbinden
    • Wrapper um Vendor-Services → instabile, teure oder zurückgefallene Anbieter austauschen können
  • Zukunftsoptionen zu schaffen erfordert zusätzliche Arbeit heute
    • Eine Vendor-Wrapping-API liefert heute unmittelbar keinen Mehrwert
    • Für reife Unternehmen, denen Stabilität und Vorhersagbarkeit wichtig sind, ist das klug; für frühe Phasen, in denen man etablierte Anbieter über Geschwindigkeit schlagen muss, kann es die falsche Wahl sein
  • Der Weg, die Optionalität des gesamten Unternehmens zu maximieren, besteht darin, ein großartiges Unternehmen aufzubauen
    • Gesundes und nachhaltiges Wachstum, große und wachsende Bruttomargen, Kundenliebe, belegt durch Retention, Upgrades und Mundpropaganda, sowie Mitarbeiterliebe, belegt durch lange Betriebszugehörigkeit und Karrierewachstum
    • Ein großartiges Unternehmen hat viele Optionen: Übernahme, Fortbestand, Finanzierung, IPO, Nachfolge und mehr

• Portfolio von Wetten (Portfolio of bets)

  • Ein Portfolio reduziert Volatilität, aber auch das maximale Upside
    • Die Wahrscheinlichkeit, gar keine Gewinne zu erzielen, ist niedrig, daher ist die Downside nicht schlecht; aber Gewinne müssen Verluste ausgleichen, sodass selbst gelegentliche große Treffer nicht so groß sind wie bei einer Einzelwette
    • Analogie: Amazon beim IPO zu kaufen und für immer zu halten wäre ideal gewesen; hätte man denselben Ansatz auf andere IPOs desselben Jahres angewandt, hätte man bei $0 landen können. Ein Portfolio fällt nicht auf null, aber das maximale Wachstum ist viel kleiner als beim besten Einzeltitel
  • Mathematische Seitenleiste: Der Grund, warum Portfolios unabhängig von der Verteilung funktionieren, ist der zentrale Grenzwertsatz (Central Limit Theorem)
    • Zieht man wiederholt N Stichproben aus einer Grundgesamtheit mit stabiler, aber unbekannter Verteilung und zeichnet ein Histogramm der Stichprobenmittelwerte, konvergiert diese Verteilung gegen eine Gauß-Verteilung (Normalverteilung): Mittelwert gleich Populationsmittelwert, Varianz gleich Populationsvarianz geteilt durch n
    • Der Lindeberg–Lévy-CLT zeigt, dass dies auch gilt, wenn jede Stichprobe aus einer anderen Verteilung stammt (unter den Bedingungen von Unabhängigkeit, endlicher Varianz und keiner Dominanz durch eine einzelne Variable)
    • In Startup-Umgebungen häufige Verteilungen können diese Bedingungen jedoch verletzen (manche Power Laws haben unendliche Varianz)
  • Portfolios funktionieren, wenn man vorhersagbare, aber durchschnittliche Ergebnisse will, nicht wenn man Ausreißer sucht
    • Beispiel Venture- und Angel-Portfolios: 65 % machen Verlust, und nur etwa 10 % erzielen Renditen, die Risiko und Illiquidität rechtfertigen
    • Wer auf Ausreißer zielt, braucht keine Portfolios, sondern All-in-Investitionen (weil Startup-Ertragsverteilungen Power Laws sind, die das Lindeberg-Kriterium verletzen)
  • Fazit: Wenn es bei Priorisierung um Marktdifferenzierung und Wachstumstreiber geht, ist ein Portfolio das falsche Werkzeug. Es eignet sich für kleine, verlässliche inkrementelle Ergebnisse; in diesem Fall muss man nicht über Vertrauen streiten

• Asymmetrische Wetten (Asymmetric bets)

  • Der natürliche Gegenpol zum Portfolio. Wenn Portfolios der Verlässlichkeit dienen, dienen asymmetrische Wetten Ausreißern
    • Man sagt nicht den Erfolg oder Misserfolg der Wette voraus, sondern geht Wetten ein, deren Downside begrenzt und quantifiziert ist, während die Upside groß ist
  • Wenn der schlimmste Fall „2 Monate Verlust“ und der beste Fall „vollständige Differenzierung“ ist, sind Wahrscheinlichkeiten nahezu bedeutungslos
    • Es reicht, wenn die Downside überlebbar ist und die Upside groß genug, um mit einem einzigen Gewinn zehn Verluste auszugleichen
    • Die genaue Wahrscheinlichkeit kennt man nicht, aber die Form (shape) jeder Wette kann man kennen
  • Asymmetrische Wetten auf Strategieebene haben ihre Form meist schon im Voraus (ein neuer Markt, in dem sich Empfehlungen mit Zinseszinseffekt aufbauen, ein Graben, der mit jedem Verkauf tiefer wird)
    • Auf Funktionsebene muss man Asymmetrie selbst konstruieren. Denn die Grundform von Softwareprojekten driftet von „2 Wochen → 2 Monate → schon so lange investiert, dass wir es fertigstellen müssen“
    • Der Mechanismus ist ein vorab aufgeschriebenes Budget: „2 Engineers, 3 Wochen, danach stoppen und prüfen“. Die Timebox ist die begrenzte Downside
  • Eine Möglichkeit ist, Vertrauen durch „Wie asymmetrisch ist es?“ zu ersetzen
    • RICE verlangt, eine Wahrscheinlichkeit zu schätzen, die man als unbekannt anerkennt
    • Asymmetrie stellt zwei tatsächlich schätzbare Fragen: Worst Case nach Zeit und Kosten und Best Case nach Kundenwert. Beides ist konkret, und wenn alle Zahlen auf Zehnerpotenzen beschränkt werden, lassen sich in Meetings konsensfähige Zahlen finden

Fazit

• Aufhören, so zu tun, als könne man Vertrauen quantifizieren oder definieren
• Stattdessen Techniken einsetzen, die immer dann funktionieren, wenn die Zukunft unvorhersagbar ist — denn die Zukunft ist immer unvorhersagbar

[hmmhmmhm]

„Verwende stattdessen Techniken, die immer dann funktionieren, wenn die Zukunft unvorhersehbar ist – denn die Zukunft ist immer unvorhersehbar.“ Schön.

[spilist2]

Ein sehr guter Artikel.