Produktentdeckung in der Praxis: In realen Fällen getestete Frameworks

Der teuerste Teil beim Bau eines Produkts ist nicht die Technik. Es geht darum, kompetent das Falsche zu bauen. Ganze Teams verbringen Monate damit, in tadelloser technischer Qualität eine Lösung zu liefern, nach der niemand gefragt hat, für ein Problem, das es nicht gab.

Um genau dies zu vermeiden, gibt es die Produkterkennung. Es sind die Praktiken, die vor dem Bau eine brutale Frage beantworten: Lohnt es sich, so etwas zu bauen? Für wen? Warum?

Discovery-Frameworks helfen bei der Strukturierung dieser Untersuchung. Aber ihre Theorie ist leicht zu loben und schwer anzuwenden. Aus diesem Grund basiert dieser Text auf realen Fällen, Situationen, in denen die Entdeckung über das Schicksal des Produkts im Guten wie im Schlechten entschied.

Der Fall der Funktion, die niemand genutzt hat

Beginnen Sie mit dem häufigsten Fehler. Ein Unternehmen beschließt, eine Funktion zu entwickeln, weil „Kunden danach gefragt haben“. Das Team führt aus, startet, feiert und die Akzeptanz ist nahezu Null.

Was ist passiert? Kunden fragten zwar, aber sie fragten nach einer Lösung, sie beschrieben kein Problem. Wenn Sie buchstäblich das bauen, was der Kunde verlangt, ohne das dahinter stehende Problem zu untersuchen, liefern Sie oft etwas, was er sich falsch vorgestellt hat.

Discovery hätte hier das Spiel verändert. Eine Interviewrunde, die sich darauf konzentrierte, den Kontext zu verstehen, nicht das Merkmal, sondern den Schmerz, würde zeigen, dass das eigentliche Problem ein anderes war, mit einer viel einfacheren Lösung. Die Lektion: Der Kundenwunsch ist ein Symptom, nicht die Diagnose.

Der Fall einer digitalen Regierung, die niemand nutzen konnte

Im öffentlichen Sektor wiederholt sich das Muster mit schwerwiegenderen Folgen. Stellen Sie sich ein Rathaus vor, das eine Dienstleistung digitalisiert, beispielsweise die Terminvereinbarung oder die Ausstellung eines Dokuments, und dabei in robuste Technologie investiert.

Das System geht in Betrieb, wird als Modernisierung angekündigt und die Warteschlange vor Ort bleibt gleich. Warum? Weil niemand überprüft hat, ob echte Bürger es nutzen könnten. Zur Zielgruppe gehörten Menschen mit geringer digitaler Vertrautheit, instabiler Verbindung und Zweifeln, die der Flow nicht vorhergesehen hatte.

Entdeckung ist hier kein Startup-Luxus. Dadurch wird vermieden, dass öffentliche Gelder für Systeme ausgegeben werden, die ihre soziale Funktion nicht erfüllen. Ein paar Gespräche mit echten Bürgern vor dem Bau hätten Hindernisse aufgedeckt, mit denen kein internes Treffen gerechnet hätte. Die Entdeckungskosten sind vernachlässigbar im Vergleich zu den Kosten einer Dienstleistung, die diejenigen ausschließt, die sie erbringen sollten.

Frameworks, die funktionieren, wenn man sie ernst nimmt

Praxisbeispiele zeigen, dass einige Discovery-Frameworks unter Druck besser standhalten als andere.

Kontinuierliche Entdeckung (kontinuierliche Interviews). Anstelle einer einmaligen Recherche vor dem Projekt, wöchentliche Gespräche mit Benutzern im Laufe der Zeit. Die typische Erfolgsgeschichte ist das Team, das einen kritischen Einwand frühzeitig entdeckt, weil es in ständigem Kontakt mit den Anwendern des Produkts stand.
Opportunity Solution Tree. Verbindet Geschäftsergebnisse, entdeckte Opportunities und Kandidatenlösungen in einem sichtbaren Baum. Es funktioniert, weil es das Team dazu zwingt, zu begründen, warum eine Lösung eine echte Chance löst und nicht eine Intuition.
Prototypentests vor dem Code. Der klassische Fall besteht darin, eine Idee mit einem navigierbaren Prototyp zu validieren und an einem Nachmittag festzustellen, dass der Ablauf keinen Sinn ergab, was wochenlange Entwicklungszeit spart.

Der gemeinsame Punkt dieser erfolgreichen Frameworks ist der direkte und häufige Kontakt mit der Realität. Entdeckungen, die nur in einem Besprechungsraum stattfinden, mit Hypothesen über den Benutzer statt mit Gesprächen mit dem Benutzer, schlagen im realen Fall normalerweise fehl.

Der Entdeckungsfall, der zur Ausrede wurde

Es gibt auch die Gegenseite, und es ist ehrlich, sie anzuerkennen. Entdeckung kann zur Lähmung werden. Ich habe Teams gesehen, die „Wir befinden uns noch in der Entdeckungsphase“ als Schutzschild nutzen, um niemals eine Entscheidung zu treffen.

Forschung, die niemals konvergiert, ist keine Sorge, sondern Angst. In einem realen Fall eines Startups verzögerten monatelange Recherchen eine Markteinführung, die der Markt bereits verlangte, und ein weniger vorsichtiger, aber entschlossenerer Konkurrent übernahm den Platz.

Die Entdeckung muss eine Frist und einen Zweck haben. Das Ziel war nie, alles zu verstehen, sondern die Unsicherheit so weit zu reduzieren, dass man verantwortungsbewusst entscheiden kann. Wenn das Team Entdeckung mit der Suche nach absoluter Gewissheit verwechselt, tauscht es das Risiko, Fehler zu machen, gegen das ebenso reale Risiko ein, niemals zu handeln.

Der Entdeckungsfall, der die Strategie veränderte, nicht nur die Funktion

Es ist ein Fall wert, der zeigt, dass die Entdeckung auf einer anderen Ebene funktioniert, nicht um eine Funktionalität zu entscheiden, sondern um den Verlauf einer gesamten Wette zu korrigieren.

Stellen Sie sich ein Unternehmen vor, das davon überzeugt ist, dass seine Zielgruppe ein umfassenderes Produkt mit vielen Funktionen wünscht. Die Intuition der Führung war klar: Der Wettbewerb war zu einfach und die Differenzierung würde durch Tiefe erreicht. Die gesamte Roadmap wies in diese Richtung.

Eine ernsthafte Entdeckungsrunde, fortlaufende Gespräche und die Beobachtung der tatsächlichen Nutzung zeigten das Gegenteil. Die Benutzer wollten keine weiteren Funktionen. Sie wollten, dass das Wenige, das bereits existierte, einfacher und zuverlässiger funktioniert. Die Komplexität, die das Unternehmen aufbauen wollte, war genau das, was die Leute fernhielt.

Der Wert der Entdeckung bestand in diesem Fall nicht darin, ein paar Wochen Entwicklung einzusparen. Damit sollte verhindert werden, dass das Unternehmen monatelang in die Entwicklung seiner eigenen Strategie in die falsche Richtung investiert. Wenn Discovery ernst genommen wird, passt es manchmal nicht an, was Sie erstellen, sondern stellt die Frage, ob Sie es erstellen sollten.

Dies ist die schwierigste und wertvollste Verwendung. Es erfordert, dass die Führung bereit ist, anzuhören, dass ihre Überzeugung falsch sein könnte. Teams, die Entdeckungen durchführen, nur um zu bestätigen, was sie bereits entschieden haben, untersuchen nicht; Sie suchen Applaus. Und Applaus schützt niemanden vor einer Fehlentscheidung.

Wenn sich Entdeckungen wirklich lohnen

Die Entscheidung darüber, wie viel Entdeckung gemacht werden soll, ist im Wesentlichen eine Risikoanalyse. Je größer die Unsicherheit und je höher die Kosten für Fehler sind, desto mehr sind Entdeckungen gerechtfertigt.

Ein kleines, umkehrbares und günstiges Feature bauen? Manchmal lohnt es sich, ein Risiko einzugehen und in der Praxis zu lernen, umfangreiche Entdeckungen wären eine Verschwendung. Eine teure, schwer rückgängig zu machende Wette aufbauen, die die Strategie des Unternehmens definiert oder Tausende von Bürgern betrifft? Dann ist die Entdeckung kein Kostenfaktor, sie ist sicher.

Reife Führungskräfte kalibrieren dies von Fall zu Fall. Entdeckung in allem als obligatorisch zu betrachten, ist ebenso naiv wie sie in allem als optional zu betrachten. Die richtige Frage ist immer proportional: Wie viel verliere ich, wenn ich falsch liege, und wie viel kostet es, es zuerst herauszufinden?

Schließung

Reale Fälle vermitteln die gleiche Lektion auf unterschiedliche Weise. Wer das Problem vor dem Bau untersucht, verschwendet weniger, macht mehr Dinge richtig und schläft besser. Diejenigen, die diese Phase überspringen, zahlen später, in Form von Nacharbeit, in Geld, manchmal unter Ausschluss derjenigen, die am dringendsten bedient werden mussten.

Entdeckung garantiert keinen Erfolg. Es stellt sicher, dass Sie, wenn Sie einen Fehler machen, kostengünstig und frühzeitig einen Fehler machen und die Chance haben, ihn zu korrigieren. Im Produkt ist das fast alles.

Wenn Ihre Organisation dazu neigt, zuerst aufzubauen und später zu entdecken, könnte es sich lohnen, die Reihenfolge umzukehren, bevor Sie die nächste große Wette eingehen. Hier gibt es weitere Artikel über Discovery- und Design-Frameworks, die tiefer in das Thema einsteigen.