Zielen bevor man schiesst!

Abends in der Kreativwirtschaft, treffen sich: Action Designer und Design Thinker, Usability Consultants und Social Media Experten. An manchen Abenden geht es hier heiss her. Und nicht jeder, der abends voller Elan hereinkam, kam früh morgens aus eigener Kraft wieder heraus. Mein Name ist übrigens Jan Jursa, Ich bin der Gastwirt hier in der Kreativwirtschaft. Und Ihr? Wollt Ihr rein? Zu Gast in der Kreativwirtschaft ist heute Beat Walther. Er ist geschäftsführender Partner bei der Vendbridge AG in Zürich in der Schweiz. Beat, willkommen zur Folge AKW 92, willkommen in der Kreativwirtschaft.

Hören Sie oben zu, oder lesen Sie das Interview unten. Sie können sich hier das Transkript auch als PDF herunterladen.

Willkommen, Jan.

Beat, wo bist du gerade? Von wo kommst Du in die Kreativwirtschaft rein?

Ich bin jetzt gerade in Genf, aber Vendbridge ist in Zürich, da ist das ganze Team und da bin ich auch, wenn ich nicht bei Kunden oder Kunden von unseren Kunden bin.

Auf dem Vendbridge Twitter Account steht zu lesen: „We put first what really counts, the customers’ unmet needs. From there we have to develop value propositions, sales stories and innovative product concepts.” Das hört sich sehr nach Job-to-be-done an, ist das so?

Das ist so. Job-to-be-done begleitet mich bewusst schon seit über 10 Jahren und unbewusst seit über 20 Jahren. Im früheren Leben war ich mal in der Konsumgüterindustrie bei Procter & Gamble, und ich denke, da haben wir bereits die Job-to-be-done-Denke unbewusst angewendet.

Das wollte ich gerade ansprechen. Du bist ja schon seit vielen Jahre im Innovationsmanagement und Consulting Business tätig. Du warst bei P&G, bei McKinsey, bist auch schon seit langem bei Vendbridge, einer Beratung spezialisiert auf Innovation und Wachstum. Kannst du dich noch erinnern, wann Du das erste Mal mit Job-to-be-done in Berührung kamst?

Also das erste Mal, wie gesagt, unbewusst. Das war als Assistent bei Procter im Marketing, als mir mein Chef gesagt hatte: „Geh mal auf einen Home Visit und frage, wie die Frauen ihr Haus oder Wohnung putzen“. Ich war da ein bisschen verloren und dann hat er gesagt: „Ist ganz einfach: du schaust, was sie tun und wenn sie dann etwas tun, fragst du sie, was sie damit erreichen wollen. Vor allem wenn sie komische Dinge tun, dann fragst du: warum hast du das gemacht und was willst du dabei erreichen?“. Und das ist ein Stück weit die Grundidee von Job-to-be-done. Die nächste Begegnung war im Jahr 2000 mit jemand, der ein Business für Change Management hatte. Gleichzeitig hatte er eine Methode aus den USA kennengelernt, die ODI-Methode. Er hat mich gefragt, was er damit tun solle. Da habe ich mich mit ODI beschäftigt und habe ihm gesagt, er soll in Zukunft unbedingt diese Methode anwenden.

Da müssen wir vielleicht ganz schnell sagen, was ODI ist. ODI bedeutet Outcome Driven Innovation.

ODI basiert auf Job-to-be-done. Genau wie Clayton Christensen. Dieser hat 2001 oder 2002 das Buch Innovator’s Solution geschrieben. Im Kapitel 3 propagiert er Job-to-be-done. Aus meiner Sicht hat Clayton Christensen Job-to-be-done in die Innovation gebracht. Früher war Job-to-be-done eher etwas für’s Marketing, denn es kam ursprünglich von Ted Levitt, ein Marketing Guru in Harvard in den 70er Jahren. Er hat Job-to-be-done eigentlich erfunden, und Clayton Christensen hat es dann für die Innovation übernommen.

War das in der damaligen Innovationswelt etwas bahnbrechend Neues? Was hat man denn bis dahin gemacht, wenn es um Innovationsprozesse ging?

Die Innovationsprozesse waren einfach sehr klassisch. Man war sehr technologie- und entwicklungsgetrieben. Man hat einfach entwickelt und das Feld oft den Ingenieuren überlassen. Das ist heute in vielen Unternehmen unterschiedlicher Branchen immer noch so. Für diese ist Job-to-be-done eine Bereicherung, indem die User-Sicht auf eine ganz einfache Art eingebracht wird. Wir können uns danach darüber unterhalten, was Job-to-be-done aus meiner Sicht eigentlich leistet. Aber damals war das alles noch sehr klassisch. Es ist immer noch oft so, dass man einfach aus der Technologie heraus etwas entwickelt, dann auf den Markt bringt und testet und sich dann irgendwie wundert, dass die Kunden oder User nicht begeistert sind. Das ist immer noch der meist verbreitete Ansatz in der Wirtschaft.

Ein Konzept von Job-to-be-done ist ja, dass man Lösungen anheuert und nicht das Produkt selber will. Also ich heuere den Bohrer an, um ein Loch zu bohren, weil ich das Loch in der Wand haben will und nicht am Bohrer selbst Interesse habe. Ist also ein Kernelement von Jobs-to-be-done das Wegkommen von Lösungen und eher ein besseres Etablieren vom allgemeinen Problemverständnis?

Es ist eben mehr als ein allgemeines Verständnis, es führt auf ganz einfache Art zu einem Perspektivenwechsel. Wenn man Job-to-be-done richtig anwendet, führt es automatisch dazu, dass man ein Produkt oder eine Lösung aus einer anderen Perspektive wahrnimmt. Es handelt sich dann mehr um eine Perspektive, die eben dem User entspricht. Das Bohrer-Beispiel ist eines, aber wir haben Dutzende von anderen Beispielen. Ich nehme ein einfaches: Kochtöpfe. Wie will ich Kochtöpfe verbessern? Die Entwickler denken bei dieser Frage einfach an den Kochtopf und seine Eigenschaften, weil sie neue Features einbauen müssen. Aber der User, der denkt daran, wie er seine Familie versorgt. Das ist eigentlich der Job, den er machen will. Und wenn man dem Ingenieur oder dem Entwickler klar machen kann, dass der Job vom User „Seine Familie versorgen” ist, dann ändert das seinen Blickwinkel um 180 Grad. Die Entwickler denken dann viel breiter und lösungsneutraler, viel unabhängiger von der Lösung. Und das führt zu neuen Ideen und Ansätzen.

Ein klassisches Job-Beispiel im Job-to-be-done-Sinne wäre auch „Ich möchte mit jemand über Entfernung hinweg kommunizieren”. Da fallen uns sofort diverse Lösungen ein: Briefe, Rauchzeichen, Funkgeräte, Telefon, Email, Messenger, Alphorn. Kann man bei all diesen Beispielen erkennen, dass Lösungen immer etwas Kurzlebiges sind, wobei das Verständnis vom Problem etwas Langlebiges und andauernd ist?

Wir sagen immer «Jobs bleiben, Produkte kommen und gehen». Das ist auf der oberen Ebene von Job-to-be-done sicher richtig. Jobs wie „Über Distanz kommunizieren”, „Musik hören”, aber auch emotionalere Jobs wie zum Beispiel „Sich in seinem Gesellschaftskreis profilieren”, „Andere beeindrucken”, sind alles Jobs, die bleiben. Es gibt sie, seit es Menschen gibt. Aber die Lösungen, die die Menschen dann benutzen, ändern sich laufend. Also kann man sehr gut mit Job-to-be-done in praktisch allen Branchen und Produktarten diesen Perspektivenwechsel herbeiführen.

Gibt es überhaupt so etwas wie neue Jobs? Bei Innovation denkt ja der begeisterte Laie an neue Ideen und Funktionen, die plötzlich aus den Nichts geboren werden. Gibt es das überhaupt ? Oder dreht sich alles am Ende nur um tiefsteckende und urmenschliche Bedürfnisse?

Grundsätzlich schon. Das hängt damit zusammen, wie man Job-to-be-done anwendet. Wenn man auf der Ebene von „Über Distanz kommunizieren” bleibt, dann ist das ein Job, der sehr hoch angesiedelt ist. Man kann dann noch höher gehen und sich fragen, wieso Menschen kommunizieren. Dann kommt man wirklich zu diesen fast archetypischen Bedürfnisstrukturen. Letztlich kann man auch in die andere Richtung gehen, eine Ebene tiefer. Wenn ich sage, ich will jemand kontaktieren, dann muss ich diesen jemand zuerst physisch oder virtuell lokalisieren. Das nennen wir einen Unterjob und diese Unterjobs sind unter Umständen abhängig von der benutzten Lösung. Grundsätzlich kommt es aber ganz darauf an, wie man Job-to-be-done anwendet. Ich finde das Konzept super und alle die Job-to-be-done Gurus können damit begeistern. Es gibt aber relativ wenige, die wirklich sagen können, wie man es konkret anwendet, wie man dann von Jobs auf richtige Anforderungen für die Produktentwicklung kommt. Wir machen das über die Unterjobs, indem wir den Kernjob herunter brechen. Ich erkläre danach wie das geht.

Sehr gerne. Ganz kurz nachgefragt: bei diesen Unterpunkten sprechen wir in der Job-to-be-done-Welt von der Jobmap, richtig? Dahinter steht die Erkenntnis, dass ein Job immer ein Prozess ist und, dass man den Prozess in Unterjobs aufteilen kann. Ist das richtig?

Ja, wir haben diesen Begriff Jobmap ebenfalls eingeführt. Das ist nichts anderes als fünf, sechs Schritte, die oft sequentiell laufen, um den Kernjob, wie wir ihn nennen, herunter zu brechen. Meistens gibt es einen Auslöser, der dazu führt, dass ein Mensch diesen Job ausführen will. Dieser Auslöser steht am Anfang und dann läuft eine Serie von Aktivitäten ab. Diese Aktivitäten muss man so formulieren, dass sie lösungsfrei sind. Was heisst das? Beim Beispiel der Kochtöpfe ist „Die Woche planen” der Auslöser, der kommt immer wieder vor. Die Frau oder der Mann, der zuständig für die Wochenplanung ist, macht das immer gleich: Er plant und dann kommt die Frage, was er kochen soll. Und sicherlich schaut er als Erstes nach, was noch im Haus ist. Das ist ein erster Schritt. Auf-grund von dem macht er dann eine Liste von Dingen, die man einkaufen könnte. Oder er fragt die Familienmitglieder auf was sie Lust hätten. Und so geht man weiter und bricht das Problem in Unterschritte.

Und was habe ich davon als Produktentwickler oder Sales-Anbieter? Was bringt es mir, diese Unterschritte zu kennen?

Das bringt zuerst eine Breite, mit der man das Problem betrachten will. Ich mache ein anderes Beispiel: Wir wurden kürzlich von einem Automobilhersteller kontaktiert, weil sie ihre Sitze verbessern wollen. Da haben wir gedacht: „Sitze verbessern, da sind ja schon die Ergonomen dran.” Und dann haben sie gesagt, dass genau das das Problem ist: „Wir haben Ergonomen, die machen immer nur die Sitze bequemer. Dann haben wir noch sehr viele Techniker, die wollen vor allem Gadgets einbauen. Aber wir glauben, es braucht etwas anderes.” Und dann haben wir den Job anders geframt, so nennen wir das. Framing kommt aus der Psychologie. Und uns gefragt: Wo spielt der Sitz im Auto eine Rolle? Das waren dann Jobs wie zum Beispiel ein- und aussteigen oder schlafen, wenn man an den Beifahrer denkt. Die Jobmap ermöglicht es zu definieren, wie breit man eigentlich geht. Also wenn man das Beispiel vom Ein- und Aussteigen nimmt, das hat so nichts mit dem Sitz zu tun, aber in diesem Moment beginnt der Job „Sitzen”. Und das bringt einen Perspektivenwechsel, weil das eine Diskussion auslöst, wie breit wir eigentlich gehen wollen. Wir glauben, es ist relevant für die Innovation, dass man sich über diese Breite Gedanken macht. Es ist nämlich sehr oft so, dass die Innovation nicht im Kernfeld oder Kernjob stattfindet sondern in einem vorgelagerten oder nachgelagerten Job.

„Auto“ ist ein schönes Stichwort, man hört manchmal das Gegenargument: „Ich muss mich von A nach B bewegen, das ist der Job, dafür kann ich ein Auto nutzen. Es gibt aber auch Luxusautos. Warum sollte ich mir ein Luxusauto zulegen, wenn ich mich nur von A nach B bewegen möchte? Das macht keinen Sinn. Es muss also noch eine andere Motivation geben, in Luxusautos zu investieren.

Das Luxusauto adressiert einen ganz anderen Job als ein normales Auto. Im normalen Auto geht es von A nach B, das ist auch beim Luxusauto so. Aber im Luxusauto geht es darum, seine Umgebung zu beeindrucken. Es geht darum, sich in einem sozialem Umfeld zu positionieren. Das sind alles emotionale Jobs und die Lösungen dazu sind Luxusautos, eine Rolexuhr oder Ferien auf den Bahamas. Das ist der Job, der mit einem Luxusauto adressiert wird.

Es gibt also verschiedene Arten von Jobs im Job-to-be-done-Sinne: Funktional, emotional, sozial. Sind die alle gleich häufig?

Wie häufig, weiss ich nicht. Ich glaube, dass die funktionalen Jobs wirklich relevant sind für die Produktentwicklung. Weil man da letztlich spezifizieren muss, Requirements setzen und dann Technisches entwickeln muss. Ich glaube, dass die emotionalen und sozialen Jobs viel relevanter sind für die Vermarktung, also die Kommunikation oder die Botschaft. Weil da oft die Verknüpfung von emotional und funktional den wirklichen Erfolg ausmacht. Und wir wenden Job-to-be-done nicht nur für die Produktentwicklung an, sondern auch für die Value Proposition, die Verkaufsgeschichte und die Marketing-Positionierung. Das muss alles Hand in Hand gehen aus der Job-to-be-done-Methode heraus.

Jetzt hast du schon ein paar mal eure Arbeitsweise angeteasert und man sieht auf eurer Webseite viele schöne Beispiele und namenhafte Kunden. Wie ist denn so die typische Projektherangehensweise und eure Arbeitsweise, wenn ihr mit der Job-to-be-done-Idee ins Projekt kommt?

Da sind in der Regel vier Schritte, wenn man das so vereinfacht. Den ersten Schritt nennen wir Framing; da geht es darum, die Job Perspektive zu definieren. Das ist genau das, was wir vorhin besprochen haben: man definiert den Kernjob und den funktionalen Job erst mal aus der Innensicht, man erstellt die Jobmap aus der Innensicht und man definiert die Zielgruppe. Zum Beispiel fragt man sich in diesem Schritt, wen man befragen soll oder wer schlussendlich das Produkt nutzen wird. Das ist das Framing. Da geht es auch darum, was ist eigentlich die Businessabsicht des Unternehmens für das wir arbeiten. Der zweite Schritt ist die Exploration. Das ist die Aussensicht. Da gehen wir mit Beobachtung, mit Interviews, mit verschiedenen Methoden rein. Im Gegensatz zu anderen Design-Thinking- und User-Standard-Development-Methoden haben wir bereits klar definiert, wonach wir suchen. Wir finden die Frage nach der Methode, die man dann verwenden soll, nicht nützlich. Was wir hingegen wirklich nützlich finden, ist, dass man überhaupt definiert, wonach man sucht. Das ist aus meiner Sicht bei Design Thinking ein bisschen zu breit gefasst und nicht definiert. Wir haben klar definiert, was wir suchen: das sind einerseits Jobs und anderseits, und das ist ganz wichtig, Erwartungskriterien. Wir nennen es so, Erwartungskriterien oder Expectation Metrics. Das sind Kriterien, die ein User anwendet, wenn er entscheidet oder beurteilt, ob ein Job mit der Lösung, die er momentan benutzt, erfüllt werden kann oder nicht. Und zwar wendet er diese Erwartungskriterien bewusst und unbewusst an. Die ganze Kunst in der Explorationsphase ist, diese unbewussten und bewussten Kriterien aus dem User heraus zu kitzeln. Über Fragetechniken und unterschiedlichste Methoden, die wir anwenden, damit sie auf den Tisch kommen, damit sie bewusst werden und man sie verwenden kann. In der Regel sind das zwischen 100 und 200 solcher Kriterien.

100 Erwartungskriterien – das ist eine Menge.

Jeden Job, den wir angeschaut haben, brechen wir letztlich herunter auf rund 200 Kriterien. Und das ist aus unserer Sicht nötig, weil wir fest daran glauben, dass in der Produktentwicklung und im Marketing das Konkrete immer gewinnt über das Abstrakte. «Konkret gewinnt immer über abstrakt». Was meine ich damit? Ein Nutzer beurteilt ein Produkt auf Grund von ganz konkreten Kriterien und nicht auf Grund von abstrakten Konzepten. Ein abstraktes Konzept ist zum Beispiel Bequemlichkeit -machen wir den Autositz bequemer. Das ist eine Abstraktion. Was es wirklich meint, ist, dass es mich irgendwo am Bein drückt, wenn ich drei Stunden gefahren bin; und das stört mich. Klar ist das Bequemlichkeit, aber was ihn stört ist, dass es am Bein drückt oder, dass er einen Krampf bekommt. Was wir zum Beispiel als ganz interessantes Insight entdeckt haben, passiert beim Einsteigen und dann beim Hinsetzen. Es ist wahrscheinlich jedem Mann schon passiert: Ihm fällt in diesem Moment das Handy aus der Tasche. Das kennt jeder. Es kann aber auch der Schlüsselbund sein. Und wohin fällt es? Es fällt praktisch immer nach Murphy’s Law zwischen die Sitze. Das ist zum Beispiel ein ganz konkretes Erwartungskriterium, das wir aufgedeckt haben und das auch konkret zu einer Lösung führen kann, wenn man bessere Sitze designt. Bei Frauen ist es etwas anderes. Die Frau setzt sich in das Auto und sie hat nichts in der Tasche, aber sie hat eine Handtasche. Und diese Handtasche legt sie auf den Beifahrersitz. Dieser Beifahrersitz ist designt als Sitz. Obwohl in 95% der Fälle ein Beifahrersitz nicht ein Sitz, sondern eine Ablagefläche ist. Bei der nächsten Kurve fällt die Tasche herunter. Das ist also auch ein Kriterium, das lautet: Wie oft fällt meine Handtasche runter wenn ich am Fahren bin oder abrupt bremse? Ein weiteres typisches Erwartungskriterium.

Ja, also ich erkenne mich völlig wieder in deiner Beschreibung. Ich glaube du sprichst hier von mir.

Das sagen unsere Kunden auch, wenn sie die Liste von den 200 Erwartungskriterien sehen, dann erkennen sie sich wieder. Dann sagen sie: „Das wusste ich alles oder vieles davon. Vielleicht sind da 30-40% neue Kriterien, die kannte ich nicht. Und ich habe noch nie eine so komplette Liste gesehen mit Kriterien und Anforderungen, die unsere Produkte erfüllen müssen.“ Das ist eine typische Reaktion, die wir haben nach dieser zweiten Phase, nach dieser Explorationsphase.

Das heisst, diese 100-200 Erwartungskriterien sind nicht immer gleich, die hängen vom Job ab?

Die hängen immer an einem Jobschritt. Wir brechen den Kernjob herunter in Jobschritte und diese Kriterien sind immer einem dieser Jobschritte zugeordnet. Diese Kriterien sind nach einem Format, einer Syntax formuliert mit mindestens drei Elementen. Zuerst kommt das erwartete Resultat: Was erwarte ich als Ergebnis, wenn ich diesen Job ausführe? Element zwei ist die Messgrösse. Das kann Zeit sein oder wie oft etwas passiert, wie viel es kostet oder wie viel Aufwand es ist, etc. Das ist die Messgrösse. Und Element drei ist oft der Kontext. Also wenn ich abrupt bremse, ist das der Kontext. Insofern ist ein Erwartungskriterium wie eine kleine Geschichte, die man erzählen kann und auf der man dann eine Eigenschaft oder eine Marketinggeschichte aufbauen kann.

Das ist also alles Teil der Explorationsphase, in der ich versuche, die Erwartungskriterien pro Jobschritt zu verstehen. Und zwar möglichst umfassend.

Genau, das machen wir mit einer bestimmten Interviewtechnik oder anderen Techniken, die wir anwenden, um das heraus zu kitzeln und bewusst zu machen. Nach dieser Exploration kommt der dritte Schritt und das ist die Validierung. Diese Erwartungskriterien können von der Aussensicht validiert werden. Wir glauben sehr an die Validierung. Das ist nämlich etwas, wo Design Thinking wirklich profitieren kann: Man stützt eine Entwicklung nicht auf eine Anekdote ab, sondern auf Fakten. Auch wenn diese Fakten nicht die letzte Wahrheit sind, man stützt sich trotzdem auf ein validiertes Ergebnis ab. Und so erhalten wir dann die Relevanz. Du kannst dir vorstellen, dass eine Liste von 200 Kriterien erschlagend ist. Da kannst du noch nicht sehr viel mit anfangen, du hast dann mal die Liste. Aber wenn wir das mit der Validierung herunter brechen auf 10 Kriterien, die wirkliche Schmerzpunkte, also PainPoints, sind (ich erkläre gleich, was das bedeutet), dann wird es sehr nützlich für Unternehmen. Wir validieren also die Kriterien, und dann gibt es 5-10 Schmerzpunkte, die viele User in ihrem Segment haben und die nicht gelöst sind. Dieses Wissen kann ein unheimlicher Wettbewerbsvorteil sein in der Produktentwicklung. Man kann nämlich davon ausgehen, dass diese ungelösten Pain Points im Markt unheimlich wichtig sind. So funktioniert der Validierungsprozess: wir ermitteln als erstes die Wichtigkeit von einem Kriterium und dann den Erfüllungsgrad mit aktuellen Lösungen. Die Wichtigkeit crossen wir dann mit dem Erfüllungsgrad und daraus erhalten wir die Schmerzpunkte. Das sind also sehr wichtige Kriterien, die nicht erfüllt sind. Dadurch reduziert sich die Liste von 200 auf z.B. 10. Und darauf wird dann Innovation aufgebaut.

Kommt dann noch ins Spiel, ob diese jeweiligen Pain Points für die jeweiligen Entwickler oder Dienstleister machbar und technisch umsetzbar sind?

Ja, das kommt dann im nächsten Schritt. Vom ersten Schritt bis in die Validierung sind wir absolut lösungsfrei. Weder die technische Machbarkeit noch das Geschäftsmodell interessieren uns. Oft haben wir Kunden, in einem Geschäftsmodellkonflikt; für sie greifen die kommenden Innovationen ihr Geschäftsmodell an. Das interessiert uns gar nicht in der Phase. Wir wollen wirklich unverfälscht die Aussensicht haben und entwickeln daraus einen Standpunkt, der möglichst den Markt abdeckt. Erst dann gehen wir in die Lösungsphase, wo dann Kriterien wie Machbarkeit angesprochen werden. Das braucht man natürlich, da die User sehr widersprüchlich sind. Sie wollen ein Auto, das möglichst umweltfreundlich ist, mit 300 PS.

Ja, natürlich, will ich auch.

Und da sagt jeder in der Automobilindustrie „Geht nicht”. Bis Tesla kommt und genau das bringt. Also Innovation ist genau diese Widersprüche aufzulösen, die der User hat, mit einer Lösung, damit der Widerspruch plötzlich gelöst ist. Damit fordern wir die Unternehmen heraus, indem wir konsequent die User Sicht einnehmen. Damit man einen Weg findet, um diese Schmerzpunkte zu adressieren. Da sind wir schon in der vierten Phase. Jetzt wird von Lösungsraum, Ideenentwicklung, oft auch von Beurteilung von bestehenden Ideen und Projekte, gesprochen. Das ist etwas, was man ein bisschen vergisst, wenn man im Design Thinking ist oder in der user-zentrierten Designwelt. Die Unternehmen haben oft schon sehr viele Ideen, aber sie haben Schwierigkeiten, diese Ideen zu priorisieren. Sie haben viele Ideen, oft wissen sie nicht, welche von diesen wirklich erfolgreich sein werden. Und da können wir über die Nutzer-Perspektive beitragen, gewisse Projekte zu beschleunigen oder andere zu stoppen. Manchmal „spinen“ (Anm.: von Spin Doctor) wir Projekte, das bedeutet, wir drehen sie so um, dass sie besser auf die Nutzerbedürfnisse passen.

Ich meine zu beobachten, dass in so einem Innovationsansatz die Innovation mit einer Brainstormingphase beginnt. Man fängt immer erst an, Ideen zu sammeln, die wir nachher validieren oder prüfen. Du hast sehr schön geschildert, wie vor der eigentlichen Ideenentwicklung ganz viel passiert: Das Framing, die Explorationsphase, die Validierung der Aussensicht, diese drei Schritte hast du genannt, bis wir dann erst den vierten Schritt, in die Lösungsphase, die Ideenentwicklung kommen.

Das ist unser Grundansatz. Viele Unternehmen entwickeln einfach Ideen, sie machen mal einen Workshop und dann haben sie 1000 Ideen und das Gefühl, sie haben etwas gearbeitet. Sie wissen aber nicht, welche von diesen 1000 Ideen wirklich gut ist, und sie wissen nicht, ob es noch eine 1001te Idee gibt, die wirklich gut ist. Das ist unser Grundsatz: Lieber zielen bevor man schiesst. Die ganze Grundidee von uns ist, zuerst in Nutzerverständnis zu investieren, um dann viel treffsicherer zu entwickeln, um Innovation näher zu bringen. Absolute Grundvoraussetzung, glaube ich.

Sind diese Insights, die ihr im Job-to-be-done-Prozess generiert, eigentlich für ein ganz spezielles Team auf Kundenseite interessant, wie z.B. das Design- oder Marketing-Team? Oder kann man sie auf Kundenseite mehrfach anwenden?

Man kann sie mehrfach verwenden. Unsere Erfahrung ist, dass man an einem Ort anfängt, z.B. mit der Produktentwicklung, und dass sehr schnell Marketing mit ins Spiel kommt oder der Vertrieb. Typischerweise arbeiten wir für die Geschäftsleitung, den CEO. Ich gebe da ein Beispiel für einen Medizinaltechnik-Konzern. Im Diabetesbereich haben wir mitgeholfen, eine neue Generation Produkte zu entwickeln. Diese war noch nicht eingeführt. Und dann haben wir den (beschriebenen) Prozess durchgeführt. Sehr schnell kam dann die Marketingabteilung zu uns und sagte: „Wir müssen wissen, welche Claims wir machen können und wie wir aus Patientensicht diese Lösung positionieren müssen“. Also waren sie dabei. Dann kam das Lifecycle-Management dazu. Das sind die, die nach Einführung des Produktes es immer fortlaufend verbessern müssen. Am Schluss waren es drei Teams, die am Projekt beteiligt waren. Das passiert immer wieder.

Kommt dieser Job-to-be-done-Ansatz möglichst früh im Prozess der Produktentwicklung zum Tragen? Oder ist man unabhängig vom Entwicklungszeitpunkt?

Aus meiner Sicht sollte Job-to-be-done wirklich eine Unternehmensphilosophie sein, wie man den Markt betrachtet. Und idealerweise sollte das wirklich von oben getrieben sein, dass man die Märkte aus Job-to-be-done-Perspektive anschaut. Dann sollte man in der Entwicklung eines neuen Produktes oder einer neuen Produktgeneration unbedingt früh investieren in Kundenverständnis. Das sagt ja auch der Design-Thinking-Prozess. Es ist nicht so neu, nur finde ich Design Thinking geht da ein bisschen sehr schnell und sehr qualitativ an das Thema heran. Und ich denke, wenn man eine Entwicklung startet, die dann hinten heraus Millionen kostet und dann noch Millionen für die Markteinführung, dann lohnt es sich am Anfang ein bisschen systematischer in Nutzerverständnis zu investieren, um dann schneller und kosteneffizienter zu sein. So bringen wir eine höhere Treffsicherheit hin. Das versichern auch unsere Auftraggeber, die dann ganz konkret die Ergebnisse umsetzten. Und wenn sie es umsetzen, sieht man das am Marktanteil und man sieht es an der Marge, weil sie die Preise halten oder steigern können. Man sieht es auch in der Einführungs-Pipeline. Das ist natürlich nicht bei allen so, nur bei denen, die die Philosophie und die Logik von CFI und von Job-to-be-done anwenden.

CFI muss man vielleicht aufschlüsseln: Customer Focused Innovation. Eure Methode, um Job-to-be-done anzuwenden. Treffsicherheit ist auch ein schönes Wort. Aus Business-Sicht bin ich immer interessiert, die Performance auch zu messen. Ist da dieses Konzept der Treffsicherheit ein guter Messpunkt, den man im Auge behalten kann?

Also Treffsicherheit im Sinne von Nutzerakzeptanz. Ich finde, das ist eine Messung, die man auf dem Radar haben soll, damit man abschätzen kann, wie gross die Nutzerakzeptanz sein wird. Das geht weit über Kundenzufriedenheitsumfragen hinaus, weil wir eben viel viel tiefer gehen, zum Beispiel über diese Erwartungskriterien. Es gibt Unternehmen, die nehmen diese Kriterien oder eine Auswahl davon und nutzen sie in sogenannten Tracker-Studien. Das haben wir gerade erst erlebt in einer ganz neuen Produktkategorie. Da geht es um E-Zigaretten. Dieser Markt entwickelt sich jetzt und da gibt es viele Lösungen, aber diese sind nicht optimal. Und überall auf der Welt passieren unterschiedliche Dinge. Dieses Unternehmen führt eine globale Tracking-Studie durch, die sie alle 6 Monate laufen lässt, um herauszufinden, wie sich eigentlich die Werte, also die Wichtigkeits- und Zufriedenheitswerte auf diesen Erwartungskriterien verschieben. Wir sind der Meinung, dass die Erwartungskriterien über die Zeit stabil bleiben, aber dass die Bewertung dieser Kriterien sich über die Zeit verschiebt.

Das heisst, die Erwartungskriterien sind lösungsunabhängig?

Weil sie lösungsunabhängig sind, sind sie stabil, es wird sie auch noch in 50 Jahren geben. Es gibt aber Kriterien, die sind abhängig von einer anderen Lösung. Zum Beispiel beim „Kommunizieren über Distanz”. Das Thema Batterie, das war vor 100 Jahre kein Thema, aber, dass die Kommunikationsverbindung abbricht, weil das verwendete Mittel scheitert, war schon vor 100 Jahren ein Thema. Oder dass das Aufnehmens des Kontakts schwierig ist, war schon vor 300 oder 3000 Jahren ein Problem. Die Batterie ist in dieser Perspektive nur ein Problem, das durch die Technologie entstanden ist. Heute bricht das Handy bricht ab, und das mögen die Nutzer nicht. Früher hat der Wind die Rauchzeichen verweht.

Jetzt sind viele Job-to-be-done Beispiele, die man hört oder liest eher in dieser klassischen, haptischen Produktwelt verankert. Milchshakes, Matratzen, Autositze, E-Zigaretten. Funktioniert das Konzept nicht in der digitalen Welt bei Plattformen wie Amazon und Ebay, oder kann man da auch Job-to-be-done anwenden?

Ich finde, dass es genau bei solchen Dienstleistungen funktioniert, denn auch da nutzt der User eine Lösung, ob sie digital ist oder nicht. Ich nutze eine App und mit dieser will ich einen Job erfüllen. Funktioniert genau so. Wir haben ein Projekt für ein neues Museum gemacht und haben dort digitale Lösungen eingebaut – wobei man erst im zweiten Schritt darauf kommt, dass es eine digitale Lösung ist. Oder das Auto-Beispiel: Digital Car, Connected Car ist ein Riesenthema. Alle sind daran, das Auto mit dem Rest der Welt zu vernetzen. Was ist der Job? Er ist zum Beispiel „Mit der Welt ausserhalb vom Auto in Kontakt kommen und Informationen erhalten” oder „Den Weg finden”, das sind alles Jobs, die mit digitalen Lösungen, also mit dem Connected Car besser erfüllt werden. Also ist Digitalisierung eine Lösung für einen Job. Das vergisst man ein bisschen im momentanen Digital Hype. Es geht nicht um digital, sondern um den Job. Und wenn ich sage „Ich will den Weg finden”, dann bin ich sehr schnell beim Navigationssystem und sage „Ich will es möglichst schnell und ohne Stau“. Das sind alles Kriterien, die man mit digitalen Lösungen heute besser erfüllen kann als vor 10 Jahren. Z.B. weil die Stauvorhersage dank der digitalen Lösung viel besser ist. Siehe Google, die haben zum Beispiel eine Lösung, wie sie die Staus viel präziser vorhersagen können als die Staumeldung im Radio. Sie messen einfach, wie viele Android Phones sind auf der Autobahn und wie schnell bewegen sie sich. Mit Algorithmen können sie dann vorhersagen, wo es bald Stau geben wird. Das ist eine clevere digitale Lösung, die nichts anderes macht als auf die Erwartungskriterien «Möglichst schnell ans Ziel kommen», «Möglich selten in einen Stau kommen», «Sich möglichst selten verirren, wenn ich einen Stau umfahre», eine Antwort zu geben. Alles Kriterien, die waren schon vor 10 oder 20 Jahren da, als man noch nicht von digital sprach.

Würdest du sagen, dass man sich als Unternehmen einen Wettbewerbsvorteil verschafft, wenn man via Job-to-be-done tief in die Bedürfnisse der Nutzer eintaucht, also gerade im digitalen Umfeld, wo man Features sehr leicht kopieren kann? Der Konkurrent macht einen Newsletter, machen wir auch einen Newsletter, er macht einen Warenkorb, machen wir auch einen Warenkorb – ohne die Notwendigkeit dahinter zu verstehen. Also habe ich einen Vorteil davon, wenn ich durch die Job-to-be-done-Methode in eine umfassende Betrachtung investiere?

Ich denke schon, weil man schneller und treffsicherer wird. Und viel schneller eine Lösung bringt, die dann auch Akzeptanz bei den Anwendern hat. Genau das ermöglicht letztendlich einen Wettbewerbsvorteil. Es ist klar, dass das natürlich weniger schützbar ist als ein Patent. Das ist ein Problem, welches mit der Branche zu tun hat. Man kann die IT nicht schützen und Codes kann man relativ schnell kopieren im Vergleich zu Pharma, wo ich Patente habe, die mich schützen. Aber ich glaube, genau da ist es umso wichtiger, dass man das Kundenverständnis in der Tiefe versteht. Auch, weil man da so viele Möglichkeiten hat und sehr schnell auf Irrwege kommt. Im Sinne von: Jetzt entwickeln wir eine App. Es sind ja alle daran, eine App zu entwickeln.

Die sind ja total lösungsverliebt.

Total lösungsverliebt, das ist ein gutes Stichwort. Unternehmen verwenden 95% der Zeit darauf, Lösungen zu entwickeln und höchstens 5% darauf, Kunden oder Nutzer zu verstehen. Und eigentlich sollten sie viel mehr Zeit dafür verwenden, Nutzer zu verstehen, weil dann die Lösungsentwicklung einfacher, sicherer und schlussendlich treffsicherer ist. Wir haben Beispiele, als wir die Schmerzpunkte angeschaut haben , da sagte der Auftraggeber: „Ja, aber wir haben eine Lösung dafür, die gibt es ja schon“. Nur der Nutzer kennt sie nicht, das ist das Problem. Und das sind sogenannte Low Hanging Fruits: es genügt, dass sie diese Lösung kommunizieren und dann sind die Schmerzpunkte gelöst. Das kommt ziemlich oft so vor.

Beat, ich will langsam zum Schluss kommen. Ihr seid ja bei Vendbridge Job-to-be-done-Pioniere, ihr beobachtet und beackert das Feld schon lange. Hast du das Gefühl, dass Job-to-be-done als Methode sich etabliert hat oder, dass sie mit zunehmender Nutzung in den Fokus gerät? Oder ist es komplett unter dem Radarschirm und in der Produktentwicklung eigentlich völlig unbekannt?

Es war lange ein Geheimtipp, der für die Unternehmen, die sich Job-to-be-done auf die Fahne geschrieben haben, Vorteile gebracht hat. Ich glaube es kommt langsam hoch, es könnte eine Welle kommen, dass Job-to-be-done auch populärer wird. Es wird auch viel mehr darüber geschrieben. Es gibt zum Beispiel Alex Osterwalder im Business Model Design, der Job-to-be-done entdeckt hat, und Clayton Christensen hat gerade ein neues Buch heraus gebracht.

Ja genau, Competing against Luck, das habe ich eben zu Ende gelesen. Sehr lesenswert.

Ja, ich bin noch daran. Tony Ulwick, das ist eben der von Outcome Driven Innovation, hat auch gerade ein Buch heraus gebracht.

Ja, das heisst Jobs-to-be-Done, das lese ich gerade. Ist auch sehr interessant.

Wir haben von 2000 bis 2008 direkt mit Tony Ulwick und seiner Consultingfirma Strategyn zusammen gearbeitet und ODI angewendet. Ab 2008 haben uns aber von ODI Innovation gelöst, weil wir viele Ideen hatten, wie man den Ansatz verbessern und neu erfinden könnte. Und das haben wir in den letzten 8 Jahren gemacht. Insgesamt haben wir sehr vieles weiter entwickelt und wir haben viele neuen Ideen rein gebracht zusammen mit unseren Auftraggebern. Wir verstehen uns auch ein bisschen als Co-Creators: wir entwicklen unsere Methode zusammen mit unseren Auftraggebern. Wir lernen von jedem Projekt etwas und geben es dann wieder zurück, indem wir Best-Practice-Austausch machen, indem wir unsere Kunden aus unterschiedlichen Industrien einladen und austauschen lassen. So lernen wir sehr viel von unseren Kunden und bauen es dann in den CFI Ansatz ein.

Das ist sicherlich ein sehr schöner Ansatz. Ich finde diese Job-to-be-done-Herangehensweise, da ich im Web-Design, App-Design, digitaler Entwicklung zu Hause bin, auch sehr interessant. Man lernt nämlich sehr oft „Frage Nutzer nicht nach ihren Wünsche, denn Nutzer wünschen sich alles Mögliche. Diese Nutzer sind nicht die Lösungsexperten, lege ihnen deine Lösung vor und lasse sie dann damit umgehen.“ Aber was du da sagst, was die Job-to-be-done-Methode lehrt ist: „Nutzer sind vielleicht nicht Lösungsexperten, sie sind aber sehr wohl in der Lage, ihre Ergebniserwartungen exakt zu formulieren. Und da meine ich, können wir in der Web-Design, App-Design-Welt sehr viel von Job-to-be-done lernen.

Ja, Kunden kennen sehr wohl, was sie für ein Ergebnis erwarten, man muss es nur heraus kitzeln. Und Menschen sind generell sehr skeptisch, wenn sie neue Lösungen sehen. Das ist die Problematik beim Prototyping. Denn wenn die Lösung wirklich innovativ ist, hat der Mensch die Tendenz wegzurennen und skeptisch zu sein und zu sagen „Das kann nicht funktionieren”. Wenn es unvorstellbar innovativ ist, wird er oder sie auch eher mit Skepsis reagieren. Und dann wird Prototying schwierig. Ich kann extreme Beispiele geben. Z.B. das Mikrowellen-Beispiel: Wenn man vor 50 Jahren einer Hausfrau gesagt hätte, „Es gibt eine Kiste, da kannst du deine Suppe herein tun und dann auf den Knopf drücken und 3 Minuten später ist sie warm“, dann hätte sie gesagt „Ja, was soll das?”. Es ist genau das Gleiche wie wenn ich heute sage: „Es gibt hier eine Box, da kannst du rein gehen, auf den Knopf drücken und du kommst in Sydney raus.” Startrek hat das erfunden – es gibt es aber noch nicht. Das ist ein bisschen die Problematik mit Prototyping. Da darfst du mich aber nicht falsch verstehen, wir sind Fan von Prototyping. Wir finden es sehr gut, aber man muss es eben richtig machen.

Es gibt ja dieses berühmte Henry-Ford-Zitat, was aber gar kein Zitat von ihm ist, hat sich gerade herausgestellt: „Wenn ich Kunden gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde”. Auch da wiederum ist der Fokus auf der Lösung. Wir sollen Kunden nicht nach Lösungen fragen, sondern nach ihrer Ergebniserwartung oder nach dem Problem, das sie im Sinne eines Fortschritts zu lösen suchen.

Genau, dieses Zitat tut uns manchmal weh, weil es falsche Vorstellungen bildet. Ich glaube sehr wohl, dass man Kunden fragen kann, was sie erreichen wollen, um von A nach B zu kommen, und was dabei wichtig ist, was sie stört. Das sind eben diese Kriterien, die heraus kommen. Und dass Nutzer sehr wohl sagen können, was sie stört, was sie nervt und was gut geht.

Wo kann man mehr über Job-to-be-done und Vendbridge lernen? Ihr habt ja eine Webseite (vendbridge.com), Twitter Account ist @Vendbridge. Du unterrichtest, glaube ich, auch irgendwo oder bist sozusagen anderweitig noch unterwegs ?

Ja, wir haben in Berlin eine Reihe, die heisst, Job-to-be-Done. Vom Pain Point des Kunden zum erfolgreichen Produkt, da wenden wir Job-to-be-done an. Es ist ein zweitägiger Workshop, den wir in Berlin und Zürich durchführen. Es geht darum, die Job-to-be-done-Methode anzuwenden. Es gibt zwei Formate, das eine ist so: man lernt es kennen, anhand von Beispielen illustriert und die Teilnehmer sind nachher in der Lage, Elemente davon anzuwenden. Das zweite Format ist firmen-spezifisch. Wir arbeiten konkret an Problemen und entwickeln in zwei Tagen Lösungsansätze nach Job-to-be-done und nach CFI-Erwartungskriterien. Das sind zwei Formate und das eine läuft in Berlin. Im März ist wieder einer angekündigt bei unserem Partner Creative Game und heisst Job-to-be-Done. Vom Pain Point des Kunden zum erfolgreichen Produkt.

Beat, vielen Dank, dass du dir Zeit genommen hast in die Kreativwirtschaft hereinzuschauen und mit mir über dieses wunderbare Thema Job-to-be-done zu plaudern. Mir hat es Spass gemacht. Danke vielmals!

2018-05-06T11:27:41+00:00

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.