Vor kurzem habe mehrere Vorträge zum Thema Outcome Based Innovation gehalten. Zuerst auf dem ProductCampBerlin und letzte Woche beim Lean StartUp Meetup. Es macht also Sinn die Kernideen in einem Blogpost zusammen zu fassen. Outcomes sind eine Verfeinerung des zentralen Konzepts Jobs-To-Be-Done welches vor allem von Clay Christensen populär gemacht wurde (Leider ist er Anfang 2020 verstorben).
Jobs To Be Done Konzept
Das Jobs-To-Be-Done Konzept besagt, dass Kunden die ein Produkt kaufen, es in diesem Moment damit beauftragen einen speziellen Job für sie zu erledigen. Ein Kaffee wird z.B. beauftragt sich wach zu machen, oder um eine angenehme Gesprächsatmosphäre zu erzeugen. Ein Buch wird beauftrag zu unterhalten oder zu bilden oder den intellektuellen Status des Inhabers durch das Stehen im Buchregal zu unterstreichen.
Jobs können typischerweise in drei Kategorien unterteilt werden:
- Funktionale Jobs: Säge zum genauen Durchtrennen von Holz
- Emotionale Jobs: Gemütliche Kleidung, um sich geborgen zu fühlen
- Soziale Jobs: Ferrari, der einen bestimmten Eindruck bei anderen Menschen erzeugt
Wenn man versteht, welchen Job das eigene Produkt für den Kunden erfüllt, versteht man, mit wem man eigentlich im Wettbewerb steht. Hier erlebt man sehr häufig Überraschungen. Viele Kunden nutzen die Produkte nicht wegen ihrer unmittelbar offensichtlichen Eigenschaften. So was in den 70ern zum Beispiel aus dem Blickwinkel vieler Harley-Davidson Kunden, die Alternative zu ihrer Harley die Anschaffung eines Pools hinter dem Haus. Der Job war hier sicherlich nicht von A nach B zu kommen.
Innovationsentscheidungen bei denen Kundenverständnis fehlt
Ich erlebe mehrere typische Situationen in Unternehmen, in denen ein strukturiertes Verständnis des Kundenbedarfs sehr hilfreich wäre, aber häufig fehlt.
Fall 1: Es gibt aus strategischer Sicht die Idee ein bestimmtes Produkt / Dienstleistung anzubieten. Häufig will ein Unternehmen ein offline Produkt auf die Online-/Mobile-Welt übertragen. Es wird eine Marktstudie durchgeführt am Ende gibt es eine Reihe von Merkmalen, von denen die Kunden sagen, dass das neue digitale Produkt diese haben sollte: „einfach oder intuitiv zu benutzen, sehr schnell, zeitsparend, alle Funktionen des Offline Produkts haben, vernetzt sein mit Facebook, etc.“. Der Produktmanager, der dann die Aufgabe bekommt, auf Basis dieser Marktdaten ein Produkt zu entwickeln hat es richtig schwer.
Fall 2: Eine Organisation hat viele Ideen für neue Produktideen. Wie priorisiert man diese? Welche dieser Ideen passen zum Kerngeschäft und welche nicht?
Fall 3: Ein Produkt existiert bereits und es gibt sehr viele Wünsche von Kunden aber auch von verschiedenen Abteilungen des Unternehmens neue Features ins Produkt einzubauen. Wie entscheidet man welche davon passen und welche nicht?
Wichtig, ich spreche nicht von der Priorisierung der Ideen. Dazu kann man Queuing Konzepte wie weighted cost of delay (second generation lean) nutzen. Ich spreche vor allem von der noch wichtigeren „No-Go“-Entscheidung.
Problem- vs. Lösung-Domäne
In allen diesen drei obigen Fällen sind es Kunden, die eine Meinung dazu haben, wie das Produkt auszusehen hat. Dass das keine gute Idee ist, wissen wir schon seit Henry Ford:
„Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde.“ Henry Ford
Es ist wichtig zu verstehen, dass die Entwicklung neuer Produkte natürlich nur mit Kunden funktionieren kann. Es ist nur sehr wichtig dabei zu verstehen, der Kunde kann nur zu seinem Problem etwas belastbares aussagen. Wir, Menschen, sind alles andere als gut darin unser eigenes Verhalten vorherzusagen. Deshalb sind Kundenaussagen darüber wie ein Produkt, sprich die Lösung meines Problems, aussehen sollte leider wertlos und können einen sehr leicht auf die falsch Pfärte schicken.
Jobs und Outcomes helfen uns zu verstehen, wie Kunden ihre Probleme definieren und das ist absolut entscheidend.
Jobs sind entscheidend und häufig nicht offensichtlich
Der Kundenblick kann sich sehr stark von einem internen Blick auf das Produkt unterscheiden. Das wird gut am Beispiel von Snickers und Milky Way Schokoriegel deutlich (siehe Folie 6 in der Präsentation). Man könnte denken, das sie direkte Wettbewerber sind. Schließlich sind beide Schokoriegel und die Inhaltsstoffe sind wahrscheinlich in vielem ähnlich. Wenn ein Produktmanager von Snickers so denkt, würde er vielleicht versuchen einige Features von dem möglicherweise erfolgreicherem Milky Way abzuschauen. Eine gute Idee?
Wenn man sich aber anschaut, welchen Job das jeweilige Riegel erfüllt, gehen einem die Augen auf. Durch Job-To-Be-Done Interviews wurde festgestellt, dass ein Kunde typischerweise ein Snickers Riegel vor einem Ereignis kauft für das er einen kurzfristigen Energieschub benötigt. Ein Milky Way wird dagegen typischerweise als eine Belohnung für ein kürzlich zurückliegendes Ereignis gekauft. Aus der Sicht der Kunden sind das absolut verschiedene Produkte.
Wenn man das weiß, würde man sich als Produktmanager von Snickers auf ganz andere Features konzentrieren als bei Milky Way.
Outcome – noch besseres Verständnis der Jobs
Outcomes beschreiben die Eigenschaften, die der Kunde daran wertschätzt, wie das Produkt seinen Job erfüllt. Der Job eines Rasierers ist es zum Beispiel den Bart zu rasieren. Einige Outcomes dieses Jobs sind:
- Minimieren der Wahrscheinlichkeit, dass ich mich bei der Rasur verletze
- Maximieren der Häufigkeit für die Wiederbenutzung der Klinge
- Minimieren der Häufigkeit an der gleichen Stelle zu Rasieren, damit sie wirklich frei von Haaren ist
Ein Outcome hat immer einen speziellen Aufbau (Seite 7 der Präsentation). Es gibt immer eine Richtung (Maximieren, Minimieren etc.), eine Einheit (Häufigkeit, Wahrscheinlichkeit, Dauer) und den Inhalt des Outcomes.
Es gibt typischerweise sehr viele Outcomes für ein Produkt/Dienstleistung nach denen die Kunden das Produkt beurteilen, häufig ohne sich selbst darüber im Klaren zu sein.
Quantitatives Kundenverständnis
Hat man diese Outcomes mal gesammelt, ist es möglich eine quantitative Befragung der Kunden durchzuführen in der man zu jedem Outcome zwei Fragen stellt:
1. Wie wichtig ist Ihnen dass, ihr Produkt (die Wahrscheinlichkeit minimiert, sich bei der Rasur zu verletzen?)
2. Wie zufrieden sind sie heute damit, wie ihr Produkt (die Wahrscheinlichkeit minimiert, sich bei der Rasur zu verletzen?)
Haben Sie das mit 100-200 Kunden gemacht, können haben sie eine quantitatives Bild davon (Seite 9 der Präsentation) was für Ihre potentiellen Kunden wichtig ist. Sie können dann auch direkt sehen, wo Innovationspotential besteht und die Produktentwicklung direkt an die relevanten Stellen konzentrieren.
Denken in Outcomes
Aber auch als kleines StartUp ohne die Ressourcen für eine große quantitative Studie ist es wichtig, seine Hypothesen über den Markt in Form von Outcomes zu formulieren und jeden Kundenkontakt zu nutzen um diese Hypothese zu verifizieren.
Hat man eine Webseite mit Traffic ist man in der Lage diese quantitative Studie kontinuierlich mit Seitenbesuchern durchzuführen und dabei zu sehen, wie sich die Prioritäten verschieden und die Zufriedenheit durch neue Features ändert.
Als Product Owner können Outcomes einem helfen die User-Stories sehr viel schärfer zu formulieren und sehr viel klarer mit dem Team aber auch mit den Stakeholdern zu kommunizieren. Ich bin grundsätzlich der festen Überzeugung, dass es gerade die Kundenprobleme sind, die das Potential eine funktionierende Kommunikation auf allen Ebenen eines Unternehmens zu ermöglichen. Aber dazu mehr in einem zukünftigen Post.
Wer mehr die Methode und ihre Anwendung auf Marketing, Produktentwicklung, PR erfahren möchte ist sollte das Buch des Ideengebers Anthony Ulwic von Strategyn lesen.
Ich hoffe diese Beitrag war für Sie hilfreich. Was halten Sie vom Konzept der Outcomes?