Problemstellung und Annahmen

Eine gute Formulierung eines Problems setzt den Benutzer, den Kontext, das Hindernis und die beobachtbare Konsequenz, aber versteckt nicht die Lösung im Inneren. Schreiben Sie nach dem Framing Annahmen über Wert, Verhalten, Kanal, Technologie und Wirtschaft auf; Testen Sie als Erster den, dessen Fehler die gesamte Initiative zerstören wird.

Warum Sie Framing und Annahmen brauchen

Warum nur zu einer Lösung zu gehen, ist eine schlechte Strategie

Jedes Produktteam kennt die Versuchung: schneller im Prototyping und Piloting. Aber ohne eine klare Definition des Problems ist es einfach, unnötige Features zu erstellen. Die Gestaltung und Kritik von Hypothesen hilft, die Bemühungen auf den richtigen Punkt zu lenken.

Beispiel aus der Praxis
Das B2B-SaaS-Team beschloss, einen Chatbot zur Unterstützung der Website hinzuzufügen. Ohne ein klares Verständnis des Problems erhielten wir einen Monat später eine geringe Nutzung. Framing zeigte, dass es den Nutzern nicht an Unterstützung mangelte, sondern an einer unbequemen Navigation im Produkt. Die Konzentration auf ein anderes Thema sparte Monate Arbeit und Budget.

Die Rolle von Annahmen in der Entdeckung

Annahmen sind das, was du ohne Beweise für wahr hältst. Ohne Überprüfung werden sie zu Fallen und kostspieligen Fehlern.

**Beispiel ** Das mobile “Gesundheits” -Team schlug vor, dass Benutzer das Tagebuch nicht ausfüllen, weil das Formular zu lang ist. Entfernen Sie den Überschuss, aber die Retention ist immer noch nicht gewachsen. Dann interviewten sie die Benutzer und fanden heraus, dass es die ungleichen Erinnerungen waren. Assumptions Testing veränderte den gesamten Fokus der Discovery Iteration.

Wie man das Problem richtig formuliert

Identifizieren Sie, was den Benutzer blockiert, nicht was Sie tun möchten.

Framie-Problem im Format: “Der Benutzer erlebt X, weil Y zu Z führt.”

Implementierung in Teams
Zu Beginn der Discovery-Sitzung schreibt das Team keine Features (“Button hinzufügen”), sondern Szenarien: Der Käufer wirft den Korb in der Zahlungsphase, weil er Angst vor einer fehlerhaften Abschreibung hat. Es hilft, sich daran zu erinnern, dass der Fokus immer auf dem Benutzer liegt, nicht auf der Technologie.

Gutes Problem Framing: Beispiele und Fehler

In Ordnung. Der benutzer verliert oft den zugang zum support-chat, weil unklar ist, wo und wann er arbeitet, was die lösung des problems verzögert.

Schlecht: Lassen sie uns einen online-chat ohne arbeitsplan machen.

** Anti-Muster:**
Feature Framing, vage Formulierung (“machen Sie es bequemer”, “fügen Sie etwas hinzu”).

Wie man mit Annahmen arbeitet

Wie man Annahmen findet und sie priorisiert

Schreiben Sie für jedes Problem auf, was das Team für selbstverständlich hält: Was der Benutzer will, weiß, weiß.

Auswirkungen/Risiko der Matrix: Wenn sich die Annahme als falsch herausstellt, wie sehr beeinflusst sie den Erfolg der Entscheidung?

Antrag:
Die Gruppe diskutiert: Wir gehen davon aus, dass Kunden ein Abonnement für ein neues Feature kaufen werden. Lassen Sie es uns zuerst für das Testen durch Custdev oder Experiment setzen.

Wie man Annahmen überprüft - schnelle Techniken

1. Nutzerinterviews – an die Wurzel gehen, echte Motivation hören.
*2. Fake Door Experimente – damit Sie klicken und eine nicht verfügbare Funktion ausprobieren und das Interesse messen können.
**3. Datenanalyse: Bestätigen Sie eine Hypothese mit Aktionen, nicht mit Worten.

**Beispiel ** In dem Produkt gefunden: Nutzer wollen angeblich Muster. Der Templates Button führt zu einem Stub mit einem Fragebogen. Nur 4% der Klicks werden angeklickt – der Rest geht vorbei. Die Annahme eines hohen Bedarfs wird also nicht bestätigt.

Wie man Arbeit dokumentiert: Frameworks und Formate

Format der Problemstellung

Es gibt Standard-Canvases und Formeln:

Jobs To Be Done: Wenn ich sein will, will ich sein.

**HMW (Wie könnten wir …): **
Wie können wir einem Charakter helfen, etwas zu tun, um Wert zu bekommen?

Beispiel von JTBD in einem echten Team Wenn ein Benutzer nach einer Pause zum Dienst zurückkehrt, möchte er sich schnell daran erinnern, was geplant ist, um keine Zeit mit der Navigation zu verschwenden.

Einfache Vorlage für Annahmen

Es wird normalerweise aufgeschrieben: Wir glauben, dass [die Annahme], und wenn wir falsch sind, wird es eine [negative Konsequenz].

** Beispiel:**
Wir glauben, dass die Benutzer Exporte starten wollen, und wenn wir falsch liegen, werden wir vergeblich Zeit investieren, und das Feature wird nicht gefragt sein.

Siehe ProductPlan

Wie man nicht in Fallen tappt

Typische Fehler

1. Beginnen Sie mit dem Aufbau einer Lösung, bevor Sie das Problem überprüfen 2. Trennen Sie persönliche Meinungen nicht von User Insights 3. Machen Sie keine Annahmen explizit 4. Bedenken Sie, dass jede Annahme nach einem Interview bestätigt wird

Anti-Team-Muster

• Das Treffen diskutiert “was Sie möchten”, ohne sich auf Daten zu verlassen.
• Die Frage ist: “Was passiert, wenn die Annahme unwahr ist?”

FAQ

**Was ist das Problem beim Framing zu Beginn der Entdeckung? ** Es konzentriert das Team auf den wirklichen Bedarf, ermöglicht es Ihnen, sich nicht mit Lösungen hinreißen zu lassen, die Benutzer nicht brauchen.

**Woher wissen Sie, dass Annahmen für den Erfolg entscheidend sind? Risikobewertung: Wenn diese Annahme falsch ist, verliert das Team die meiste Zeit oder Ressourcen für unnötige Arbeit.

**Wie stellen Sie sicher, dass das Problem das tatsächliche Nutzerverhalten widerspiegelt? **
Beobachten Sie Benutzer, kommunizieren Sie mit ihnen, suchen Sie nach Bestätigungen in Daten und Analysen.

**Ist es möglich, das Problem Framing nach den ersten Stadien der Entdeckung zu ändern? Ja, das ist normale Praxis. Oft verschiebt sich der Fokus nach dem ersten Interview, Experiment oder Analyse.

**Wann können Annahmen als verifiziert betrachtet werden? Wenn unabhängige Bestätigungen durch verschiedene Methoden erhalten werden: Interviews, Experimente, Metriken.

Wo finden Sie Vorlagen und Checklisten zum Thema? Empfohlen Atlassian Team Playbook, ProductPlan. Es gibt Strukturen für die Gestaltung und Validierung von Annahmen.