Produkterkennungs-Frameworks mit Beispielen: vom Problem zur Entscheidung

Die Produktfindung leidet unter einem merkwürdigen Problem: Fast alle sind sich einig, dass sie wichtig ist, und fast niemand macht sie richtig. Die Theorie wird überall wiederholt. Verstehen Sie das Problem, bevor Sie es entwickeln, aber wenn es darum geht, es anzuwenden, weiß das Team nicht, wo es anfangen soll.

Der Unterschied zwischen wissender Entdeckung und deren Ausübung liegt in den Rahmenbedingungen: Strukturen, die die gute Absicht, „den Benutzer zu verstehen“, in eine konkrete Reihe von Schritten umwandeln. Ohne sie wird die Entdeckung zu einem vagen Gerede; mit ihnen wird es zur Methode.

In diesem Text werden die wichtigsten Frameworks anhand von Beispielen erläutert. Es handelt sich nicht um eine Liste von Definitionen, sondern um eine Demonstration, wie jeder ein verwirrendes Problem in eine Entscheidung umwandelt.

Vor Frameworks: Was Discovery zu vermeiden versucht

Es lohnt sich, mit dem Problem zu beginnen, das all dies löst. Stellen Sie sich vor, Ihr Team hat eine Idee: Fügen Sie dem Produkt einen Chat hinzu. Sieht nützlich aus. Das Team ist begeistert und will aufbauen.

Ohne Entdeckung wäre der nächste Schritt die Schätzung und Entwicklung. Bei der Entdeckung besteht der nächste Schritt in der Frage: Welches Problem löst dieser Chat und woher wissen wir, dass er tatsächlich existiert? Es ist diese Frage, multipliziert und strukturiert, bei deren Beantwortung Frameworks helfen.

Die zentrale These dieses Textes ist, dass Entdeckung nicht dazu dient, Ideen zu generieren, sondern dazu, die schlechten Ideen frühzeitig und kostengünstig zu töten, bevor sie zu Code werden. Gute Frameworks sind in erster Linie Maschinen zur Eliminierung von Fehleinsätzen.

Opportunity Solution Tree: Ziel, Problem und Idee verbinden

Der Opportunity Solution Tree ist eine der nützlichsten Strukturen zum Organisieren von Entdeckungen. Ganz oben tragen Sie Ihr gewünschtes Geschäftsergebnis ein. Nachfolgend die tatsächlichen Chancen, Probleme oder Bedürfnisse der Benutzer. Nachfolgend die Möglichkeiten, die Kandidatenlösungen.

Konkretes Beispiel. Das Geschäftsergebnis ist „Erhöhung der Kundenbindung im ersten Monat“. In Interviews wurden folgende Chancen entdeckt: „Benutzer versteht den Wert nicht sofort“ und „Benutzer bleibt bei der Ersteinrichtung hängen“. Erst dann entstehen die Lösungen: ein geführtes Onboarding, eine erste Vorlage, ein kurzes Video.

Die Kraft des Beispiels liegt in der Disziplin, die der Baum auferlegt. Sie können eine Lösung nicht rechtfertigen, ohne sie mit einer echten Chance zu verknüpfen. Diese Chat-Idee? Wenn es keine Verbindung zu entdeckten Möglichkeiten herstellt, fällt es. Der Baum enthüllt, was nur Wille war.

Discovery-Interviews: Das richtige Fragebeispiel

Die Befragung von Benutzern scheint einfach zu sein, aber die meisten Leute machen es falsch. Der klassische Fehler besteht darin, nach der Zukunft und Meinungen zu fragen: „Würden Sie eine Chat-Funktion nutzen?“ Die Antwort ist fast immer ein nettes und wenig hilfreiches „Ja“.

Das Discovery-Interview-Framework stellt dies auf den Kopf. Anstatt nach der hypothetischen Zukunft zu fragen, fragen Sie nach der konkreten Vergangenheit: „Sagen Sie mir, wann Sie das letzte Mal Hilfe bei der Verwendung des Produkts benötigt haben. Was haben Sie getan?“

Beispiel für den Unterschied. Wenn Sie nach der Vergangenheit fragen, stellen Sie fest, dass die Person keinen Chat gesucht hat, eine E-Mail gesendet und gewartet hat oder aufgegeben hat. Dies zeigt, dass das eigentliche Problem möglicherweise etwas anderes ist: das Fehlen schneller Antworten und nicht das Fehlen eines Chats. Die richtige Frage verändert die Schlussfolgerung völlig.

Prototypentests: Vor dem Bau validieren

Ein weiterer praktischer Rahmen ist das Testen von Prototypen. Bevor Sie Code schreiben, erstellen Sie eine navigierbare Version der Idee und stellen sie echten Benutzern vor, um zu beobachten, wo sie stecken bleiben.

Beispiel. Das Team erstellt einen Prototyp des geführten Onboardings aus dem vorherigen Baum. Beim Test mit fünf Personen stellt er fest, dass drei von ihnen den wichtigsten Schritt völlig ignorieren. Kein Anforderungsblatt würde dies verraten. Direkte Beobachtung, ja.

Der Gewinn ist offensichtlich, wenn man ihn erlebt: Die Reparatur eines Prototyps dauert nur wenige Minuten; Das Reparieren von Software in der Produktion dauert Wochen und untergräbt das Vertrauen der Benutzer. Frühzeitiges Testen ist der billigste Weg, Fehler zu machen.

Wie Frameworks in einen Ablauf passen

Diese Rahmenwerke konkurrieren nicht, sie bilden eine natürliche Abfolge der Untersuchung.

Beginnen Sie mit dem Geschäftsziel. Ohne Klarheit über das gewünschte Ergebnis wird die Entdeckung zu einer Reise ohne Ziel.
Entdecken Sie echte Chancen mit Interviews, die sich auf die Vergangenheit und konkretes Verhalten konzentrieren.
Organisieren Sie alles in einem Opportunity-Lösungsbaum, um die Idee mit dem Problem zu verbinden.
Validieren Sie die gewählte Lösung mit einem Prototyp, bevor Sie sich an die Entwicklung machen.

Dieser Fluss verändert die vage Frage „Was bauen wir?“ in einer Kette berechtigter Entscheidungen. Mit jedem Schritt werden schwache Hypothesen eliminiert, sodass das, was in die Entwicklung gelangt, bereits einige Untersuchungen überstanden hat.

Beispiel für eine Entdeckung in einem Einschränkungskontext

Die vorherigen Beispiele gehen von einem relativ komfortablen Szenario aus: einfacher Zugriff für Benutzer, Freiheit für Prototypen, Zeit für Iterationen. Die Realität spielt nicht immer mit, und es ist ein Beispiel für eine Entdeckung unter Einschränkungen wert, denn dort wird die Technik am meisten getestet.

Stellen Sie sich ein Team vor, das einen Dienst für ein schwer erreichbares Publikum validieren muss, beispielsweise Bürger mit geringer digitaler Vertrautheit, die auf einen öffentlichen Dienst angewiesen sind. Sie können sie nicht in einen Testraum rufen; Viele reagierten nicht auf eine formelle Einladung und die künstliche Umgebung würde das Verhalten verzerren.

Discovery passt sich hier an. Anstelle des geplanten Interviews Beobachtung am persönlichen Servicepunkt, wo diese Personen bereits anwesend sind. Statt eines anspruchsvollen digitalen Prototyps eine Papierskizze, zu der jeder eine Meinung haben kann. Sprechen Sie statt quantitativer Forschung mit Mitarbeitern, die jeden Tag im Dienste der Öffentlichkeit stehen und jedes Hindernis kennen.

Das Prinzip von Frameworks bleibt dasselbe: Das eigentliche Problem vor dem Erstellen zu verstehen, die Ausführung respektiert jedoch den Kontext. Dies ist das wichtigste Beispiel von allen: Bei der Entdeckung handelt es sich nicht um eine festgelegte Reihe von Techniken, sondern um eine Verpflichtung zur Realität, die sich an die Einschränkungen des jeweiligen Einzelfalls anpasst. Die Methode in einer Weise anzuwenden, die die Beschränkungen des Publikums ignoriert, bedeutet, den eigentlichen Zweck der Methode zu verraten.

Kritische Reflexion: Ein Beispiel ist kein Rezept

Hier kommt die nötige Sorgfalt ins Spiel. Beispiele helfen beim Verständnis, werden aber als Universalrezept zur Falle. Den Entdeckungsablauf eines anderen Unternehmens zu kopieren, ohne ihn an Ihren Kontext anzupassen, bedeutet, Gesten zu wiederholen, ohne den Grund dafür zu verstehen.

Die Erkennung ist kontextsensitiv. Die Anzahl der Interviews, die Tiefe des Prototyps, die Geschwindigkeit des Zyklus – alles hängt vom Risiko, dem Budget und der Reife des Teams ab. Ein Beispiel für ein Technologie-Startup darf nicht einer öffentlichen Einrichtung mit rechtlichen und Zugangsbeschränkungen dienen und umgekehrt.

Reife liegt darin, das Prinzip hinter jedem Rahmenwerk zu verstehen, und nicht darin, es Schritt für Schritt auswendig zu lernen. Jeder, der versteht, warum sich das Interview auf die Vergangenheit konzentriert, kann die Technik anpassen; Wer nur das Skript kopiert, bricht im ersten Fall außerhalb des Beispiels.

Schließung

Discovery-Frameworks verwandeln die gute Absicht, den Benutzer zu verstehen, in eine replizierbare Methode. Die Beispiele zeigen den Weg: vom Geschäftsziel zur realen Chance, von der Chance zur Lösung, von der Lösung zum validierten Prototyp.

Letzten Endes dienen sie alle dem gleichen Zweck: Sie eliminieren schlechte Wetten, bevor sie Sie kosten. Eine gut gemachte Entdeckung ist nicht das, was die meisten Ideen hervorbringt, sondern das, was die falschen frühzeitig verwirft.

Wenn Ihr Team immer noch auf der Grundlage von Meinungen und Vermutungen aufbaut, könnte das Ausprobieren eines dieser Frameworks bei der nächsten Entscheidung das Ergebnis verändern. Es gibt hier weitere Artikel über Entdeckungen anhand realer Fälle und Produktdesign, die die Diskussion fortsetzen.