Discovery- und Validierungs-Frameworks, die tote Features verhindern

Es ist 16:47 Uhr an einem Donnerstag. Der CRO lässt eine Slack-Nachricht fallen: "Großer Logo-Kunde gerade abgewandert. Sie wollten ein individuelles Approval-Routing. Wir brauchen das auf der Q3-Roadmap." Bis zum Leadership-Sync am Freitag ist "individuelles Approval-Routing" eine zugesagte Q3-Lieferung. Zwei Entwickler werden abgezogen. Sechs Monate später wird es ausgeliefert, 9 % der Accounts berühren es in den ersten 60 Tagen, und niemand kann erklären, welches Problem es eigentlich gelöst hat.

Ich habe dieses Feature ausgeliefert. Zweimal. Einmal bei einem Workflow-Tool, einmal bei einem CRM. Beide Male war die Diagnose dieselbe. Wir haben die Discovery übersprungen, weil jemand mit Titel einen einzigen Datenpunkt in eine Strategie verwandelt hat. Das Engineering-Quartal war nicht der Preis. Der Preis waren die drei Opportunities, die wir nicht erkundet haben, weil das Team damit beschäftigt war, das Lieblings-Feature des lautesten Kunden zu bauen.

Wenn Sie ein PM sind, der immer wieder Dinge ausliefert, die niemand annimmt, ist dieser Leitfaden der Discovery-Stack, den mir jemand vor drei Jahren in die Hand hätte drücken sollen.

Warum das Ausliefern der ersten Idee scheitert

Die Produkt-Benchmarks von Pendo sind seit einem Jahrzehnt deprimierend konstant. 60 bis 70 % der Features in B2B-SaaS-Produkten erreichen in den ersten sechs Monaten weniger als 15 % Adoption. Manche Studien setzen die Tote-Feature-Rate sogar höher an. Das ist kein Fehler in einem einzelnen Team; das ist die Grundrate des Bauens vor dem Validieren.

Nennen wir es, was es ist. Unter 15 % Adoption nach 60 Tagen = totes Feature. Nicht "braucht mehr Enablement". Nicht "die GTM-Bewegung stimmt nicht". Tot. Die Kohorte, die es brauchte, hat nicht danach gegriffen, die Kohorte, die es nicht brauchte, hat es ignoriert, und jetzt haben Sie für immer Fläche zu pflegen.

Ein totes Quartal sind nicht 12 Wochen Engineering-Zeit. Es sind 12 Wochen Engineering-Zeit, plus PM-Zeit, plus Design-Zeit, plus QA, plus die technischen Schulden, die Sie jahrelang tragen, plus die Opportunitätskosten der drei anderen Wetten, die Sie nicht eingegangen sind. Ein vierköpfiges Squad, das ein totes Feature ausliefert, verbrennt grob 400.000 $ an voll belasteten Kosten. Davon haben Sie nicht viele, bevor jemand in der Finanzabteilung im QBR anfängt, spitze Fragen zu stellen.

Die Lösung ist nicht "mehr Research machen". Es ist eine Discovery-Praxis, die jede Woche läuft, nicht als Sprint.

Der Opportunity Solution Tree (Teresa Torres)

Teresa Torres' Opportunity Solution Tree ist das eine Artefakt, das am meisten für mein Produktgespür getan hat. Die Struktur ist brutal einfach:

                Outcome
                   |
         +---------+---------+
         |         |         |
    Opportunity Opportunity Opportunity
         |         |         |
      +--+--+   +--+--+   +--+--+
      |     |   |     |   |     |
    Sol   Sol Sol   Sol Sol   Sol
      |
   Assumption tests

Outcome ganz oben: ein messbares Business- oder Produkt-Outcome, etwa "die wöchentlich aktiven Workspaces um 20 % erhöhen". Kein Feature. Kein Launch. Ein Outcome.

Opportunities sind Kundenprobleme, in der Sprache des Kunden gerahmt, die (wenn gelöst) das Outcome bewegen würden. "Neue Admins können nicht erkennen, welche Projekte feststecken" ist eine Opportunity. "Baue ein Projekt-Health-Dashboard" ist es nicht. Das ist eine Lösung.

Solutions sitzen unter den Opportunities, drei bis fünf pro Opportunity. Billig, mehrfach und explizit miteinander konkurrierend.

Assumption tests sitzen unter jeder Lösung. Das sind die tatsächlichen Experimente (Fake Doors, Prototypen, Concierge-MVPs), die entscheiden, ob die Lösung gebaut wird.

Der Grund, warum die meisten Teams mit dem Baum scheitern, ist nicht die Struktur, sondern dass sie ihn als einmaliges Artefakt behandeln. Sie bauen ihn in einem Miro-Board, präsentieren ihn in einem Quartalsplanungs-Meeting, und dann stirbt er. Der Baum soll an einer Wand leben (physisch oder digital), und Sie gehen jede Woche daran vorbei. Neues Interview passiert? Sie fügen einen Opportunity-Zweig hinzu. Assumption test scheitert? Sie schneiden eine Lösung weg. Outcome verschiebt sich? Ganze Teilzweige sterben.

Ich überprüfe meinen Baum jeden Donnerstagmorgen, allein, 30 Minuten lang. Ich füge hinzu, was ich in der Woche gelernt habe, und räume ab, was keinen Sinn mehr ergibt. Wenn Sie das nicht tun, wird der Baum zur Tapete.

Kontinuierliche Discovery: mindestens 3 Kundeninterviews pro Woche

Hier die Regel, die ich von Torres klaue: Ein PM, der nicht mindestens drei Kundeninterviews pro Woche führt, betreibt keine Discovery.

Das klingt aggressiv, bis Sie die Rechnung machen. Drei Interviews × 45 Wochen = 135 Kundengespräche pro Jahr. Die meisten PMs schaffen 30. Der Zinseszinseffekt auf die Mustererkennung ist enorm. Bis zum Ende des ersten Jahres können Sie in den ersten fünf Minuten vorhersagen, was ein Kunde sagen wird, und dann beginnen Sie, Interviews zu führen, die spezifische Annahmen unter Druck setzen, statt nach vagem Schmerz zu fischen.

Vierteljährliche Research-Sprints sind das Gegenteil davon. Sie bündeln Ihre Unbekannten, beauftragen einen Research-Anbieter, bekommen ein 40-seitiges Deck und versuchen, die Erkenntnisse auf eine Roadmap zu setzen, die schon halb zugesagt ist. Bis das Deck landet, hat sich die Welt weitergedreht.

Wöchentliche Interviews beheben drei Dinge auf einmal:

1. Aktualität. Schmerz, den Sie letzte Woche gehört haben, schlägt Schmerz, den Sie letztes Quartal gehört haben.
2. Iteration. Sie können Ihr Interview-Skript anpassen, basierend auf dem, was Sie gestern gehört haben. Sprints lassen das nicht zu.
3. Stakeholder-Glaubwürdigkeit. Wenn der CRO sagt "Kunden wollen X", haben Sie in den letzten drei Wochen mit neun von ihnen gesprochen und können sagen "tatsächlich haben drei von ihnen X erwähnt, aber das größere Muster war Y". Das ist ein anderes Gespräch.

Interviews rekrutieren, ohne CSMs auszubrennen

Das Rekrutierungsproblem ist real. Drei solide Quellen, geordnet nach Qualität:

• In-App-Rekrutierungs-Prompts. Ein einfaches Banner ("PM hier, kann ich 25 Minuten Ihrer Zeit bekommen? 50-$-Amazon-Gutschein.") konvertiert bei grob 1 bis 2 % der wöchentlich Aktiven im B2B. Wenn Sie 10K WAU haben, sind das 100 bis 200 verfügbare Gespräche pro Woche. Die meisten PMs schöpfen das nie aus, weil sie Angst haben zu fragen.
• CSM-Vorstellungen. Verhandeln Sie vorab eine Quote ("Ich brauche 5 Vorstellungen pro Monat aus deinem Kundenstamm"), schriftlich in die Monatsziele des CSM eingebaut. Ohne Quote fällt das in Woche drei auseinander.
• Lost-Deal-Interviews. Sprechen Sie mit Leuten, die Sie evaluiert und abgelehnt haben. Sie erzählen Ihnen Dinge, die aktuelle Kunden nicht erzählen, weil sie nichts zu verlieren haben.

Ein 50-$-Gutschein ist die richtige Schwelle für die meisten ICP-Segmente. Darunter bekommen Sie Schaulustige, die nur plaudern wollen. Über 100 \(fängt die Finanzabteilung an, Fragen zu stellen. Für Executive-Personas (VP+ bei Unternehmen über 500 Mitarbeitern) brauchen Sie meist 150 bis 200\) oder eine Spende für einen guten Zweck, weil 50 $ für sie beleidigend sind.

Was als Interview zählt

Ein Kundeninterview ist kein Sales-Discovery-Call, kein CSM-Check-in und keine Demo. Das PM-geführte Interview hat eine Aufgabe: ein spezifisches vergangenes Verhalten oder einen Schmerz zu verstehen. Wenn Sie Folien zeigen, demoen oder irgendetwas pitchen, führen Sie kein Interview. Sie verkaufen. Halten Sie inne und fangen Sie von vorne an.

Annahmen-Mapping

Jede Produktidee ruht auf vier Eimern von Annahmen. David Blands Annahmen-Mapping-Framework, popularisiert in Testing Business Ideas, leiht sich von IDEOs klassischer Desirability/Viability/Feasibility-Perspektive und ergänzt Usability:

Bewerten Sie jede Annahme auf zwei Achsen:

• Risiko. Wenn diese Annahme falsch ist, bricht die ganze Idee zusammen?
• Evidenz. Wie viel echte Evidenz haben wir gerade? (Keine Meinungen. Kein "Wir haben darüber gesprochen." Evidenz.)

Tragen Sie sie in eine 2x2-Matrix ein. Der Quadrant oben rechts (hohes Risiko, niedrige Evidenz) ist der, wo Sie die Discovery-Arbeit zuerst konzentrieren. Der billigste Test, der die Idee killen könnte, kommt zuerst. Wenn die Desirability wackelig ist, fahren Sie eine Fake Door, bevor Sie irgendetwas bauen. Wenn die Feasibility der Killer ist, bauen Sie einen 2-tägigen Spike, kein 6-wöchiges MVP.

Ich halte die Annahmen-Map im selben Miro-Board wie den Opportunity Solution Tree, einen Frame nach rechts. Jeder Lösungszweig zeigt auf seine drei wichtigsten Annahmen. Wenn eine Annahme getestet und widerlegt wird, streiche ich sie rot durch, und die Lösung wird zurückgestuft oder gekillt.

Die Fake Door / der Smoke-Test

Eine Fake Door ist das Discovery-Tool mit dem höchsten Hebel, das ich fahre. Die Prämisse: Bauen Sie den Einstiegspunkt zu einem Feature, ohne das Feature dahinter. Messen Sie, ob irgendjemand klickt. Wenn nicht, ist das Feature tot, bevor eine einzige Zeile Code geschrieben wird.

Wie es in der Praxis funktioniert:

1. Fügen Sie einen Button, einen Menüpunkt oder eine In-App-Karte hinzu, die eine Fähigkeit verspricht, etwa "Wiederkehrende Berichte planen".
2. Wenn Nutzer klicken, zeigen Sie ein "Demnächst verfügbar, Early Access gewünscht?"-Formular, das die E-Mail und ein einzeiliges "Wofür würden Sie das nutzen?" erfasst.
3. Verfolgen Sie die Click-through-Rate gegenüber der Kohorte, die es gesehen hat.

Die Schwellen, die ich tatsächlich verwende

Das sind die Zahlen, die ich über drei Unternehmen hinweg kalibriert habe. Ihre Ergebnisse werden variieren, aber es ist ein Ausgangspunkt:

Die 5-%-Schwelle ist wichtig, weil es grob die Rate ist, bei der Sie eine Engineering-Investition für ein Feature rechtfertigen können, das einen klaren Schmerz adressiert. Unter 2 % jagen Sie einem 1-von-50-Handheber hinterher, und die Kohorte ist nicht groß genug, um sinnvolle Geschäftsergebnisse zu treiben, selbst wenn jeder Klicker konvertiert.

Die ethischen Leitplanken

Sie dürfen Ihre Kunden nicht anlügen. Der "Demnächst verfügbar"-Folgestatus ist Pflicht, ohne Ausnahme. Zwei weitere Regeln:

• Mailen Sie immer jeden an, der geklickt hat, selbst wenn die Antwort "Wir haben uns entschieden, das nicht zu bauen" lautet. Sagen Sie ihnen, was Sie stattdessen tun. Das kostet Sie 20 Minuten und schützt die nächste Fake Door, die Sie je fahren.
• Fahren Sie nie eine Fake Door für etwas, das Sie nie bauen würden. Wenn Sie reines Neugier-Mining betreiben, führen Sie Interviews. Fake Doors sind Validierungs-Tools, keine Marktforschungs-Umfragen.

Ich habe einmal ein Feature im Fake-Door-Stadium gekillt, auf das das Executive-Team sechs Monate lang gedrängt hatte: ein "Predictive Lead Scoring"-Upsell-Modul. Wir starteten den Einstiegspunkt für eine Kohorte von 1.400 Mid-Market-Admins und erwarteten basierend auf Sales-Anekdoten mindestens 8 bis 10 % CTR. Wir bekamen 1,7 %. Von den 23 Klickern dachten 14, "Predictive Lead Scoring" bedeute etwas völlig anderes als das, was wir bauen wollten. Wir zogen das Feature an einem Freitag von der Roadmap, lenkten das Squad auf eine andere Opportunity um, und die neue Wette wurde sechs Monate später mit 41 % Adoption ausgeliefert. Die Fake Door kostete uns vier Tage Design- und Entwicklungszeit. Das Feature hätte ein Quartal gekostet.

Prototyp-getriebene Validierung

Wenn eine Fake Door die 5-%-Hürde nimmt, haben Sie die Nachfrage bewiesen. Sie haben nicht bewiesen, dass die Lösung funktioniert. Das ist die Aufgabe des Prototyps.

Ich passe die Prototyp-Fidelität an die Annahme an, die ich teste:

• Figma-Click-through-Prototyp. Zum Testen von Usability und Informationsarchitektur. Fünf Nutzer, getestet über unmoderierte Maze-Tests, decken die meisten katastrophalen UX-Probleme auf. Kosten: 1 bis 2 Tage Design.
• Concierge-MVP. Wenn Feasibility- oder Workflow-Annahmen der Killer sind, machen Sie die Arbeit für 5 bis 10 Kunden manuell. Wenn ein Kunde einen automatisierten Wettbewerbsanalyse-Bericht will, erzeugen Sie die ersten zehn von Hand und mailen sie. Wenn Kunden bis Woche drei aufhören, die E-Mails zu öffnen, ist der zugrunde liegende Wert nicht da.
• Wizard of Oz. Das Front-end ist echt, das Back-end sind Menschen. Nützlich, wenn Sie Verhaltensdaten validieren müssen (laden Nutzer die Datei tatsächlich hoch? kommen sie zurück?), ohne echte Infrastruktur zu bauen.
• Hartkodierter vertikaler Slice. Ein echter, aber schmaler Build. Eine Persona, ein Workflow, hässlich, aber funktional. Liefern Sie ihn an 10 bis 20 Design-Partner aus. Das ist Ihr letzter billiger Test vor einer echten Engineering-Investition.

Überspringen Sie keine Ebenen. Gehen Sie nicht von "der CRO hat danach gefragt" direkt zu "vertikaler Slice", ohne eine Fake Door und einen Prototyp dazwischen. Jede übersprungene Ebene ist ein Multiplikator auf Ihren Wirkungsradius, falls die Annahme falsch war.

Der Mom Test (Beeinflussen Sie den Zeugen nicht)

Rob Fitzpatricks The Mom Test hat meine Interview-Praxis mehr verbessert als jede andere einzelne Ressource. Die Prämisse: Menschen lügen Sie in Interviews an, besonders wenn sie Sie mögen. Ihr Job ist es, Fragen zu stellen, die Ihnen die Wahrheit liefern, selbst von Ihrer eigenen Mutter.

Die drei Regeln:

1. Sprechen Sie über ihr Leben, nicht über Ihre Idee. "Was ist der schlimmste Teil Ihres Montagmorgens?" schlägt "Würden Sie ein Tool nutzen, das Montagmorgen repariert?" Der ersten Frage kann man nicht schmeicheln. Der zweiten schon.
2. Fragen Sie nach Konkretem in der Vergangenheit, nicht nach Allgemeinem über die Zukunft. "Erzählen Sie mir vom letzten Mal, als das passiert ist" schlägt "Würden Sie X tun?" Vergangenes Verhalten sind Daten. Zukünftige Absicht ist Fantasie.
3. Hören Sie mehr zu, als Sie reden. Ein gutes Interview besteht zu 80 % aus ihnen, zu 20 % aus Ihnen. Wenn Sie Ihr Produkt erklären, sind Sie fertig. Beenden Sie das Gespräch, machen Sie Notizen, machen Sie es nächstes Mal besser.

Das schädlichste Anti-Muster, das ich in PM-Interviews sehe, ist die als Discovery getarnte Demo. Sie planen ein 30-minütiges Gespräch, um "von einem Kunden zu lernen". Zwanzig Minuten später haben Sie ihm drei Mockups gezeigt und gefragt "wäre das nützlich?" Er sagt ja, weil er höflich ist, weil er verwirrt ist, weil er will, dass das Gespräch endet. Sie protokollieren ein "Validierungs-Interview" in Ihren Notizen. Sie liefern das Feature aus. Es stirbt.

Wenn Sie sich dabei ertappen, während eines Discovery-Calls Figma zu öffnen, legen Sie auf und fangen Sie von vorne an. Das ist kein Interview. Das ist Verkaufen.

Wann man einen Discovery-Faden killt

Die eigenen Ideen zu killen, ist die schwerste Fähigkeit im Produkt. Drei Signale sagen mir, dass ein Faden tot ist:

• Drei gescheiterte Assumption tests in Folge. Fake Door unter 2 %, Prototyp mit fünf Nutzern getestet und drei blieben stecken, Concierge-MVP sah keine wiederholte Nutzung. Das ist kein Pech. Das ist das Universum, das Ihnen sagt aufzuhören.
• Kein Pull aus Interviews nach 6 bis 8 Gesprächen. Wenn Sie mit acht Kunden über ein Problem gesprochen haben und nicht einer freiwillig gesagt hat "ja, das ist ein echter Schmerz, für dessen Lösung wir zahlen würden", ist die Opportunity nicht da. Befragte werden ein oder zwei Gespräche lang ausweichend antworten. Bei acht ist das Muster ehrlich.
• Opportunity-Scores unter der Schwelle. Ich bewerte jede Opportunity in meinem Baum auf drei Dimensionen: Häufigkeit (wie oft der Schmerz auftritt), Schwere (wie schlimm, wenn er auftritt) und Reach (welcher % unseres ICP ihn spürt). Wenn zwei von drei nach einem Monat Discovery schwach sind, stirbt der Zweig.

Wenn ich einen Faden kille, schreibe ich ein einseitiges Kill-Memo. Nicht aus Politik. Für mich, in sechs Monaten, wenn jemand die Idee wiederbelebt und ich mich erinnern muss, warum ich sie geparkt habe. Vorlage:

Idee: [Name]
Opportunity, die sie adressieren sollte: [Opportunity aus dem Baum]
Getestete Annahmen: [Liste]
Gesammelte Evidenz: [Stichpunkte]
Grund für das Killen: [das spezifische Scheitern]
Was wir sehen müssten, um es erneut zu prüfen: [die Bedingungen]
Datum: [JJJJ-MM-TT]

Das Kill-Memo lebt im selben Notion-Ordner wie der Opportunity Solution Tree. Wenn der CRO sechs Monate später zurückkommt und fragt "Was ist eigentlich aus dem Predictive Lead Scoring geworden", schicke ich das Memo. Zwei Minuten Gespräch, nicht zwei Wochen, in denen wir dieselbe Debatte wiederholen.

Mein wöchentlicher Discovery-Takt

Hier der Rhythmus, den ich fahre, falls er als Ausgangsvorlage nützlich ist:

• Montagmorgen. Drei Interview-Slots werden für die Woche gebucht. Ich bestätige sie, bereite Fragen vor und aktualisiere den Interview-Tracker. Die Rekrutierung läuft über In-App-Prompts (laufen kontinuierlich) und CSM-Vorstellungen.
• Dienstag bis Donnerstag. Interviews finden statt, je 45 Minuten. Notizen gehen in Dovetail. Highlight-Reels werden mit Eng und Design geteilt (Fünf-Minuten-Clips, keine Transkripte). Entwickler schauen die Clips tatsächlich an.
• Donnerstagmorgen. Solo-Review des Opportunity-Baums. 30 Minuten. Neue Opportunities hinzugefügt, tote Zweige weggeschnitten. Annahmen-Map aktualisiert.
• Freitagnachmittag. Ein Assumption test geht pro Sprint live (Fake Door, Prototyp oder Concierge-MVP). Am Freitag schreibe ich die Spec für den Test des nächsten Sprints.

Das war's. Kein vierteljährlicher Research-Sprint. Keine 40-seitigen Decks. Drei Interviews pro Woche, ein Opportunity-Baum, ein Assumption test pro Sprint. Die langweilige Disziplin schlägt die dramatische Anstrengung, jedes Mal.

Die PMs, die ich am meisten respektiere, haben keine besseren Instinkte als der Rest von uns. Sie haben eine bessere Discovery-Praxis. Sie haben dieses Jahr mit 135 Kunden gesprochen, 26 Fake Doors gefahren, 18 Ideen gekillt und die vier ausgeliefert, die überlebt haben. Deshalb erreichen ihre Features 40 % Adoption, während alle anderen auf 9 % starren.

Sie brauchen kein größeres Budget oder mehr Researcher. Sie brauchen drei Interview-Slots im Kalender der nächsten Woche und die Disziplin, sie gebucht zu halten, wenn das Quartal laut wird. Fangen Sie dort an.

Mehr erfahren

• Vorlage für die Product-Manager-Stellenbeschreibung
• Roadmapping, ohne Stakeholder anzulügen
• PRDs schreiben, die Entwickler tatsächlich lesen
• PM-Metriken: Outcome statt Output, North Star, Frühindikatoren