Sollen wir Misserfolge feiern?

In den letzten Jahren gehörten Fuck Up Nights nicht nur ins Repertoire von Gründer:innen, sondern auch von Produktmanger:innen. Fehlerkultur ist das Thema in jedem zehnten Blogartikel und der Wandel hin zu einer guten Fehlerkultur wird in jeder zweiten Firma propagiert. Aber es gibt gute Fails und schlechte Fails! Wir spielen heute einmal den Advocatus Diaboli.

Sollen wir Misserfolge feiern?

Soll ich es wirklich machen oder es lieber sein lassen? JEIN. Es ist leider so unbefriedigend, wie so oft im Produktmanagement, denn die Antwort ist: Es kommt drauf an.

Es gibt jedoch eine gute Nachricht: Wir werden dir heute anhand von zwei Beispielen zeigen, worauf es wirklich ankommt.

Failing Big or Failing Small?

Beispiel 1

Die Firma Fail Big arbeitet an einem neuen Produkt. Drei Monate sind schon in die Forschung geflossen. Das Produkt ist gescoped und kommt nun in die Entwicklung. Drei bis vier Monate später geht die erste Version an die Kunden raus.

Nehmen wir an, das Produkt ist ein Fehlschlag, weil es einfach keinen Markt gibt. Sollten wir diesen Misserfolg feiern?

Beispiel 2

Unsere Firma Fail Big, also die gleiche wie oben, arbeitet an einem zweiten Produkt. Dieses Mal fragt sich das Team folgende Frage zuerst: Wird das Produkt am Markt erfolgreich sein?

Es beginnt in den ersten zwei Wochen mit fünf bis zehn Kundeninterviews im Problemraum und baut daraufhin innerhalb von zwei weiteren Wochen einen kleinen Prototyp. Das Team testet mit den gleichen fünf bis zehn Kunden seine Lösung und bekommt viele Komplimente.

Dann bittet es die Kunden, das Produkt vorzubestellen. Keiner stimmt zu. Es fehlt das Commitment. Die Lösung war wohl doch noch nicht so gut!

Welche Fails sollten wir feiern?

Schauen wir uns die beiden Beispiele noch einmal an.

Beispiel 1

• 7 Monate Zeitinvest
• 3 Monate UX/Business-Ressourcen
• 3-4 Monate Development-Ressourcen

Beispiel 2

• 1 Monat Zeitinvest
• Keine Entwicklungsressourcen

Product vs. Discovery Fail

Beispiel 1 ist das, was wir als Product Fail bezeichnen. Product Fails sind immer schlecht, weil sie teuer sind und wir sehr wenig von Ihnen lernen können. Im Grunde ist die einzige Erkenntnis: Funktioniert es oder funktioniert es nicht?

Beispiel 2 ist ein typischer Discovery Fail. Discovery Fails sollten wir feiern, weil wir innerhalb von kurzer Zeit und mit geringem monetärem Investment etwas lernen können. In diesem Fall war die Erkenntnis, dass der Kunde noch nicht bereit ist, das Produkt zu kaufen. Die sechs weiteren Monate, die wir in Beispiel 1 verbraten haben, um ein Produkt zu bauen, können wir hier für Verbesserungen nutzen. Wir können lernen, warum unser erster Prototyp noch nicht verkaufsbereit ist.

Was ist der wichtige Unterschied zwischen Beispiel 1 und Beispiel 2? Im ersten Beispiel haben wir eine Lerniteration innerhalb von sieben Monaten geschafft. In Beispiel 2 könnten wir in der gleichen Zeit (basierend auf der ersten Iteration) sieben Iterationen schaffen, also 7-mal mehr lernen.

Key Takeaways

• Feiern sollten wir nur, wenn wir frühzeitig günstige Fehler machen.
• Es geht nicht darum, ein günstiges Produkt zu bauen, sondern smart zu lernen. Es ist besser, etwas unperfektes schnell auf den Markt zu bringen und zu lernen, welcher Aspekt der Lösung den Kunden wirklich hilft.
• Wir wollen möglichst viele Lernzyklen (Iterationen) schaffen. Gerade am Anfang, wo die Unsicherheit hoch ist, geht es darum, möglichst schnell, viel zu lernen. Das geht nur mit Interviews, Prototypen (PowerPoint, Low Code, Paper Prototyping), Landingpages usw.

In diesem Sinne: „Fail often, fail early“. Dann klappts auch mit der nächsten Fuck Up Night ;-)

‍