Blog

5. März 2023

JTBD Research und Produktentwicklung

Mit Jan Milz, Jobs to Be Done Researcher und Produktentwickler

In dieser Episode tauchen wir tief in das Thema „Jobs to Be Done“ ein und erfahren von den Herausforderungen, guten Frameworks und missverstandenen Werkzeugen, die in diesem Bereich existieren. Unser Gastgeber Peter Rochel, einer der erfahrensten JTBD-Praktiker im deutschsprachigen Raum, hat den Jobs to Be Done Researcher und Produktentwickler Jan Milz zu Gast. Gemeinsam werden sie dir wertvolle Einblicke in die Welt der Produktentwicklung und Forschung geben und dir zeigen, wie man durch die Anwendung von JTBD-Methoden Produkte auf ein neues Level bringen kann. Freu dich auf eine inspirierende und ggf. etwas nerdige Episode, die dir dabei helfen wird, deine Kunden besser zu verstehen und somit erfolgreichere Produkte zu entwickeln.

Überall zu hören, wo es Podcasts gibt:

Diese Episode kannst du auch hier auf der Website hören:

Hier findest du alle Kapitel dieser Episode mit Zeitangabe:

00:00:00 Intro
00:02:06 2013 vom Value Proposition Canvas zu JTBD
00:17:30 Context creates Value – nicht Features
00:33:24 Hypothesenbildender Research vs konfirmierender Reserach
00:42:14 Die Rolle der Mandatsklärung
00:49:20 Krieg der JTBD Rechthaber
01:07:48 Das JTBD Praxisproblem mit dem Transfer
01:12:42 JTBD Retreat
01:19:00 Kontext macht das Value Proposition Canvas
01:24:14 Get Out

Über JTBD Research und Produktentwicklung

Die Integration von Jobs-to-be-Done (JTBD) Forschung (im Sinne von Markt- und Marketingforschung) in den Produktentwicklungsprozess ist eine aufregende und vielversprechende Entwicklung. Unternehmen, die diese Methode nutzen, können nicht nur wettbewerbsfähig bleiben, sondern auch innovative Produkte entwickeln, die die Bedürfnisse ihrer Kunden erfüllen.

Die Idee hinter JTBD Research

Die Idee hinter JTBD ist einfach: Kunden kaufen Produkte, um ein bestimmtes Ziel oder einen bestimmten Job zu erledigen. Indem man die Bedürfnisse des Kunden versteht und die Jobs, die sie erledigen müssen, identifiziert, kann ein Unternehmen Produkte entwickeln, die diese Bedürfnisse erfüllen und den Job optimal erledigen. JTBD Forschung ermöglicht es Unternehmen, Produkte zu entwickeln, die sich auf die spezifischen Bedürfnisse ihrer Kunden konzentrieren und somit bessere Ergebnisse und höhere Kundenzufriedenheit erzielen.

Signifikant höherer Produkterfolg durch JTBD

Ein weiterer Vorteil von JTBD Forschung ist, dass sie eine höhere Erfolgsrate bei der Produktentwicklung aufweist. Wenn Unternehmen ihre Produktentwicklung aufgrund von Annahmen oder Vermutungen durchführen, besteht ein höheres Risiko, dass das Endprodukt nicht den Bedürfnissen der Kunden entspricht. Durch die Verwendung von JTBD Forschung können Unternehmen sicherstellen, dass sie Produkte entwickeln, die tatsächlich einen Bedarf erfüllen.

Beispiel: Apple und der iPod

Ein Beispiel dafür ist der iPod von Apple. Apple hat das Konzept des MP3-Players nicht erfunden, aber sie haben den Job des Musikgenusses besser verstanden als ihre Konkurrenten. Apple hat den Fokus auf das Ziel des Nutzers, nämlich Musik hören, gelegt und ein Produkt entwickelt, das einfach und benutzerfreundlich ist, um diesen Job optimal zu erledigen. Der iPod wurde ein großer Erfolg und veränderte die Art und Weise, wie wir Musik hören.

Insgesamt ist die Integration von JTBD Forschung in den Produktentwicklungsprozess ein aufregender Schritt in Richtung innovativer und erfolgreicher Produkte. Unternehmen, die diese Methode nutzen, können sicherstellen, dass ihre Produkte die Bedürfnisse ihrer Kunden erfüllen und somit höhere Erfolgsraten und Kundenzufriedenheit erzielen.

Alle Episodenlinks:

• Verbinde dich mit Jan auf LinkedIn
• Peters Talk mit Bob Moesta und die Anfänge von JTBD
• Interview zu ODI mit Martin Pattera
• Outperforming Marketing für Yogamatten dank JTBD Research
• Infos zur Orange Party in Leipzig

Hier das komplette Transkript zu dieser Episode:

Intro

Willkommen bei Innovate & Upgrade.

Mein Name ist Peter Rochel und hier geht es um Tools, Methoden und Praxis der strategischen Unternehmensentwicklung.

Es geht um Business Model Design, Jobs-to-Be-Done, Purpose und Progress, Exploration, Exploitation, Innovation und Transformation.

Weil all das untrennbar miteinander verwoben ist und die Zukunft von Unternehmen bestimmt.

Auch in deinem Unternehmen.

Schön, dass du dabei bist.

Es geht heute um Jobs-to-Be-Done-Research und vor allen Dingen auch um Transfer.

Das bedeutet Transfer in dem Sinne von, was wird denn eigentlich aus diesem Research?

Wie wird denn daraus jetzt eigentlich ein besseres Produkt, ein besseres Marketing oder ein besseres Geschäftsmodell?

Vermutlich wird das ein etwas nerdiger Deep Dive, könnte ich mir vorstellen.

Denn mein Gast heute ist Jan Milz, seines Zeichens Diplom-Informatiker, Lean-Product-Manager sowie Jobs-to-Be-Done-Researcher seit 2013 und seit Anfang dieses Jahres im Team bei Oberwasser Consulting.

Hallo Jan, habe ich was vergessen?

Jan: Moin Peter, das hast du schon ganz gut, den Informatiker hättest du dir vielleicht sparen können.

Peter: Steht bei LinkedIn so noch auf deinem Profil.

Jan: Ja, das ist lange her.

Peter: Okay.

Jan:  Aber ja gut, irgendwo einen technischen Hintergrund habe ich vielleicht.

2013 vom Value Proposition Canvas zu JTBD

Peter: Ja, sag mal, wie bist du zum Thema Jobs-to-Be-D<one gekommen?

Was ist 2013 passiert in deinem Leben, dass dir das plötzlich da auf den Zettel kam?

Jan: Gute Frage.

Das war bei Xing damals.

Ich hatte mal einen Ausflug gemacht in die Festanstellung, also nachdem ich Anfang der 2000er begonnen hatte, selbstständig zu werden, während des Studiums, kam ich irgendwann mal auf meinen Weg des ganzen Freelancings und was ich damals so gemacht habe, zu der Gelegenheit mal eine Festanstellung auszuprobieren.

Das war bei Xing.

Da war ich von 2013 bis 2016 Product Owner für die Startseite.

Und da haben wir im Team die schöne Aufgabe bekommen, eine sogenannte Discovery durchzuführen.

Und ja.

Peter: Was soll das sein? – Was ist das?

Jan: Discovery bei Xing, das hieß, man beschäftigt sich mal drei bis sechs Monate mit einem Thema und dann wäre man damit fertig und würde dann gut begründen können, warum gewisse Features oder Teilprodukte jetzt in die Plattform gelauncht werden.

Das war also so üblich, dass das ist eine gute Sache, eine Discovery vor dem Launch zu tun.

Und so waren wir in diesen Prozessen auch unterwegs.

Das heißt, irgendwie war das dort gang und gäbe, dass man eben Product Discoveries durchführt und auch über einen längeren Zeitraum.

Ja, und da haben wir uns im Team, im Wesentlichen war das mit Nickel damals (Nickel Blaase, das ist ein guter Freund von mir seit damals, seitdem wir im Team waren). Und wir haben angefangen, uns dann die Frage zu stellen, ja, wie machen wir das denn jetzt?

Wir wollen ja irgendwie Kundennutzen vermutlich in unserer Discovery finden.

Und nicht nur einfach ein paar Monate jetzt tun, um dann irgendwas zu launchen, sondern es soll irgendwie Hand und Fuß haben und wir wollen ja auch für unsere User und Kunden was verbessern.

Und da kam dann die ganze Jobs-to-Be-Done-Geschichte kam mir dann so ins Bewusstsein.

Und da gab es damals ja so, also ich sage jetzt mal echt damals, das ist ja schon echt länger her.

Zehn Jahre her fast, also ziemlich genau.

Da gab es dann ein sogenanntes Jobs-to-Be-Done Handbook, das von Bob Moesta und Chris Spiek und, glaube ich, Ervin Fowlkes Jr. oder so hieß der, rausgegeben worden ist.

Und das versprach Anleitung, wie macht man das jetzt eigentlich?

Das haben wir uns…

Peter: Das war ja auch tatsächlich die einzige Anleitung, die es überhaupt gegeben hat zu dem Zeitpunkt.

Also so ein Titel wie Anleitung, also es waren zumindest ein paar Werkzeuge drin und es stand ungefähr skizzenhaft, wie man sie anwenden könnte oder sollte, glaube ich.

Jan: Genau, das haben, also wenn ich das richtig verstanden habe, haben die das…

Also Bob Moesta hat ja eine Firma, die heißt Rewired Group oder Rewired…

Ich weiß gar nicht, wie die heißen, Corporation oder so.

Peter: Ja, Rewired Group, glaube ich.

Jan: Und die haben aus der Praxis heraus, aus ihrer Arbeit, dieses Handbuch geschrieben.

Und haben halt versucht, dann eben Leuten zu erklären, ja, wie geht das überhaupt?

Also haben erst mal beschrieben, was ist überhaupt Jobs-to-Be-Done?

Und dann haben sie Frameworks dort eingeführt, wie die sogenannte Timeline und das Kräftemodell.

Und haben dort eben erklärt, wie man so ein Research überhaupt durchführt. Also wie macht man Interviews? Wie ist die spezielle Fragetechnik?

Dass ich eben mit dem Moment der Entscheidung des Kaufens beginne und dann mich zurückfrage in die einzelne Kaufgeschichte oder in die einzelne Geschichte eines Probanden, bis ich diese Geschichte wirklich bis ins letzte Detail verstanden habe.

Da kommen wir gleich nochmal zu kommen, wie das alles so geht.

Aber wir haben damals dann eben…

Also weil du gefragt hast, wieso war das jetzt in meinem Leben der Moment für Jobs-to-Be-Done?

Es war einfach…

Ja, wir hatten einen gewissen Struggle.

Wir sollten eine Discovery machen und suchten nach helfenden Frameworks, um uns in unserer Discovery-Aufgabe eben Kundennutzen zu finden, zu unterstützen.

Also, welche Tools können uns hier helfen, das durchzuführen?

Peter: So, ganz kurze Unterbrechung.

Ich habe nämlich vergessen zu Anfang eine Ansage zu machen, die ich unbedingt noch loswerden wollte, weil es sonst womöglich zu spät ist.

Es wird am Samstag, den 18. März in Leipzig ein erstes Bitcoin-Podcast-Summit stattfinden und da treffe ich mich mit mehr als zehn anderen Bitcoin-Podcast-Hosts aus dem deutschsprachigen Raum, also Leute, die Podcasts produzieren, in denen es sich immer mal wieder oder sogar schwerpunktmäßig um Bitcoin dreht.

Und das ist ein Arbeitstreffen für uns. 

Abends wird es dann eine große Party geben, die öffentlich ist und dort werden wir dann einen Live-Mega-Mashup-Podcast zum Thema Bitcoin produzieren mit allen anwesenden Hosts. Und natürlich mit Party hinterher.

Diese Party ist ausverkauft, aber wir dürfen zwei Menschen mitbringen und einladen, sich da auf die Gästeliste von uns setzen zu lassen.

Wenn du also denkst, ich bin sowieso in Leipzig und da hatte ich immer schon mal Bock drauf, da will ich unbedingt mit dabei sein, dann melde dich bei uns.

Es gilt First Come, First Serve. Das heißt, die Ersten, die sich melden und sagen, hey, her damit, ich bin dabei, ich möchte da gerne hingehen, meldet euch bei mir, podcast.oberwasser-consulting.de. Und die Ersten, die sich melden, die setzen wir mit auf die Gästeliste.

Und jetzt geht es weiter in unserer heutigen Episode.

Das war ja auch die Zeit 2014, kam dann Value Proposition Design von Alex Osterwalder in Deutsch raus. 2013, glaube ich, auf Englisch erst mal.

Und die haben ja vorher auch schon offen damit experimentiert.

Und ich glaube, das war so der Moment, wo dann auch dieser Terminus Jobs-to-Be-Done irgendwie so ein bisschen in den Mainstream der UX-Community geschwappt ist.

Hing das damit auch zusammen oder wie ist das da auf dem Zettel gelandet bei Xing jetzt?

Oder kam die Idee tatsächlich von dir?

Jan: Also von Xing selber, das sage ich jetzt mal ganz salopp, hatte mit dem Thema Jobs überhaupt nichts am Hut.

Das ist bei uns, also bei Xing kannst du dir das so vorstellen, das war damals schon ein großer Laden, 500 plus Leute, dann sind die irgendwann, während ich da war, glaube ich, um weitere 500 gewachsen oder so. Ich weiß gar nicht, wie das heute da aussieht.

Aber das ist ein Riesenapparat und du hast unten, ich sage mal in Anführungsstrichen, unten so eine Art, also da hast du die Teams und die machen die echte Arbeit.

Darüber hast du dann eine Organisation, wie man sie so kennt.

Im Grunde eine ganz klassische, das war eine klassische Matrix-Organisation, ohne das jetzt bewerten zu wollen.

Und in den Teams, da wurde halt Kultur, Produktmanagement, Kultur betrieben.

Und das Selbstverständnis war immer schon so, wir lösen eigentlich unsere eigenen Probleme in unserem eigenen Team, weil Xing war immer schon in sogenannte Dedicated Standing Teams unterteilt. Und jedes Team war im Grunde eigenverantwortlich für das eigene Produkt.

Deswegen war es auch unsere Aufgabe, dann zu überlegen, wie machen wir jetzt Discovery.

Und ich war vor Xing, also ich kam schon vom Business Model Design, also ich habe auch bei, hattest du, glaube ich, auch mal erzählt, bei Osterwalder mal so eine Art Workshop-Seminar gemacht, also Business Model Canvas kannte ich. Und ich kannte auch das Value Proposition Canvas irgendwie so, hatte das aber noch nie benutzt.

Und das hing dann bei uns, wir hatten so einen Discovery-Raum vor dem Teamspace, war noch ein zweiter Space, wo die Wände, da stand ein Sofa drin, und da waren die Wände bunt beklebt.

Und da haben wir unsere Kreativarbeit gemacht. Und da hing das Ding auch an der Wand, tatsächlich, das Value Proposition Canvas.

Und das war damals aber, ja, es hing da halt, und wir haben auch versucht, damit zu arbeiten.

Und es steht eben rechts auch drin, Customer Jobs, Klammern mit dem S.

Und ja, der Bezug von dem einen und dem anderen ist mir in den ganzen Jahren auch nie so richtig klar geworden.

Obwohl ja sogar, ich glaube, Osterwalder und die ReWired-Leute zusammen mal tatsächlich auch einen Workshop gemacht hatten damals.

Es gibt so einen Switch-Workshop oder so.

Peter: Ja, es gibt auch Videos von der Harvard Business School, wo Bob als Dozent, meine ich, arbeitet und Alex Osterwalder vorne in der ersten Reihe sitzt. Diese Videos gibt es aber auch von Alex mit Clay Christensen. Und dann auch noch mal mit Toni Ulwick.

Also, der scheint sich tatsächlich alles angeguckt zu haben. Alle Geschmacksrichtungen von Jobs-to-Be-Done, die es damals gab, wenn das überhaupt so, aber ja, es ist ja so, es geht halt um Kundensprache. Und wenn Kunden das alles demselben zuordnen, dann muss man irgendwie damit leben.

Jan: Ja, jetzt noch mal zurück zu Xing.

Wir haben uns das halt genommen, dieses Framework, nenne ich das mal.

Und wir hatten das, oder ich hatte das Glück, dass ich damals auch eine richtig gute Researcherin in meinem Team hatte.

Die konnte man sich so, ich sage mal, Anführungsstrichen ausleihen aus dem zentralen Research-Labor.

Habt ihr mal Support?

Ich brauche mal jemanden, der mir irgendwie hilft.

Und dann waren wir im Grunde zu dritt und haben dann tatsächlich diese Art von Interviews versucht durchzuführen und versucht, ja, auf dieser Art Job-Ebene zu beschreiben, was sehen wir denn hier für, ja, sagen wir mal, was sehen wir hier für Jobs vielleicht, für Kontexte, für Use-Cases, was auch immer.

Da haben wir uns also darin ausprobiert.

Jetzt rückblickend betrachtet, haben wir sozusagen Job-to-Be-Done-artigen Research gemacht, aber wir haben jetzt nicht die Frage gestellt, wieso hast du dich für Xing entschieden oder wieso hast du Xing gekauft vielleicht als Premium-Mitglied, sondern wir haben eher Teile von dem Framework genommen und darunter noch mal versucht, eigentlich Nutzung zu verstehen.

Das heißt, heute würde ich sagen, das war in dem Sinne auch gar kein gültiger, in Anführungsstrichen, gültiger JTBD-Research.

Das war eher so, was haben wir für Methoden, die uns helfen können bei unserer Discovery?

Da haben wir das genommen und wir haben auch das Value Proposition Canvas versucht.

Das hing aber letztendlich dann an der Wand und da hing es dann auch länger.

Peter: Ich kenne so viele Workshop-Räume und Zimmer, wo dieses Ding hängt.

Hier hing es auch, bei mir im Büro hing es auch lange, immer wieder neu, aber zu den eigenen Sachen hing es da viele Jahre auch wirklich als statisches Poster anstatt als dynamisches Werkzeug zur Produktentwicklung oder Serviceentwicklung, oder wozu auch immer.

Man hat es kaum gebrauchen können.

Jan: Aber wir hatten damals immer einen, was mich daran fasziniert hatte von Anfang an, von Beginn, und ich habe ehrlicherweise versucht, dieses Zitat wiederzufinden.

Vielleicht kennst du das. Vielleicht ist es auch von uns gewesen.

Wir haben damals immer so einen Mantra gehabt, uncover the job and the solution is obvious oder gets obvious.

Peter: Ja, ja, ja.

Genau, das ist, ich weiß nicht, ob das zurückgeht auf eigentlich ein Zitat von Albert Einstein, der ja mal gesagt haben soll, wenn ich eine Stunde Zeit habe, die Welt zu retten, dann nehme ich mir 55 Minuten Zeit, das Problem zu analysieren und dann wird die Lösung offensichtlich.

Kann sein, dass es aus dem Kontext irgendwie angepasst worden ist.

Jan: Ja, da gibt es ja auch irgendwie so, wenn ich einen Baum fällen soll, dann schärfe ich erst mal die Axt 50 Minuten und dann fälle ich zehn Minuten den Baum oder so.

Peter: Ja, das sind ja Plattitüden, denen wahrscheinlich jeder einfach so ungefragt zustimmen würde und das einfach mal abnickt.

Aber machen ist dann schon krasser als nur wollen.

Jan: Genau, für mich war das damals so, das war so ein bisschen so eine Art Mini-Erleuchtung.

Hey, wenn ich diesen Job verstanden habe, und das hat eigentlich für mich gar nicht so viel mit jetzt wie viel Aufwand stecke ich da rein zu tun, sondern eher so das Problem des Produktmanagers oder der Produktmanagerin ist ja immer eine richtige Lösung zu designen, sag ich mal so, oder zu verantworten.

Und dann waren es eben Features, die wir geshiped haben.

Und so Startseite, ich weiß nicht, zwei Millionen aktive Nutzer jeden Tag oder so, also irgendwie schon eine große Verantwortung.

Da wollte ich schon gerne die richtigen Features shippen und nicht irgendwas.

Und da kam dieses Versprechen, wenn ich eben diesen sogenannten Job verstehen würde, dann bräuchte ich halt über diese Lösung nicht mal so viel nachdenken, weil sie sich eigentlich ergibt aus dem, was der Jobs-to-Be-Done-Research liefert.

Peter: Da können wir ja direkt dieses schöne immer wieder bemühte Bohrerloch-Beispiel nehmen. Wenn du dann nach deinem Jobs-to-Be-Done-Research als Hersteller von Bohrern rausgekriegt hast, dass du eigentlich im Business schöner wohnen bist oder Bilder aufhängen, stellt sich ja die Frage, ja tolle Info, aber wie mache ich jetzt aus dieser Information einen besseren Bohrer? Was fange ich damit an?

Oder meinst du, ich spiele so ein bisschen auf dieses Abstraktionslevel ab, wo häufig dann Jobs sehr weit über der Realität schweben und keiner so richtig weiß, was soll man jetzt eigentlich damit genau anfangen?

Oder meinst du noch was anderes?

Jan: Also das ist ja, ja, also, na, ich habe zum Beispiel auch so Tesa-Klebehaken gekauft.

Und das finde ich schon so ein gutes Beispiel für eine offensichtliche Lösung für jetzt dieses Beispiel, ich möchte ein Bild an die Wand hängen.

Wenn ich auf der Ebene bleibe, natürlich, das ist ja, also dieses Absteigen in die menschliche Psyche, sag ich mal so, also was willst du erreichen, für dich wichtig ist oder vielleicht sogar für andere, da kann ich von dem Bohrer ziemlich tief gehen.

Ich kann dann eben irgendwann, komme ich dann bei, ja, Bild an der Wand.

Und bei uns ist es zum Beispiel so, da gibt es ja diesen Samsung The Frame, der dann sich als nächstes anbietet.

Ich weiß nicht, ob du den kennst, diesen Fernseher, kennst du den?

Peter: Nee, sagt mir nichts.

Jan: Das ist ein Fernseher, der ist gleichzeitig Bilderrahmen.

Peter: Ach so, ja, ja, ja.

Jan: Also so aus wie ein Bilderrahmen, also vermeintlich Gäste erkennen nicht den Unterschied.

Und er kann dann eben Bilderkunst von, weiß nicht, Da Vinci oder irgendwas, als Bild darstellen.

Und da kommst du dann von dem Bohrer zum Bild, zum Fernseher und dann komme ich in so eine Geschichte, wie ich möchte meinen Kindern irgendwie, möchte meine Kinder Kunst aussetzen oder so.

Oder ich möchte mich den Nachbarn präsentieren als irgendwas.

Da kann ich dann vom Bohrer relativ weit gehen, in die Motivationsebenen von Leuten.

Was wollen sie eigentlich erreichen in ihrem Leben?

Peter: Ja, und dann kommen Leute wie ich, die dann, oder Eckhart, die dann sagen, ja, aber ihr wisst ja, denkt bitte daran, jeder Job hat unzählige verschiedene mögliche Lösungen, um ihn besser zu erledigen oder auch schlechter.

Und jede Lösung erledigt immer auch gleichzeitig mehrere Jobs.

Schon hast du das nächste Auswahlproblem.

Was mache ich jetzt mit dem Research?

Also was mache ich draus?

Jan: Genau, aber damals, also das ist ja echt, also das ist jetzt ja, um das nochmal abzuschließen mit Xing, das ist ja echt schon sehr, sehr lange her.

Es war so einfach mal so ein erstes Nutzen des Frameworks.

Und für mich war wesentlich von da an, ich wusste, okay, Jobs to Be Done bedeutet, 100-prozentige Kundenzentrierung.

Das ist für mich in der ganzen Geschichte, seitdem ich Product Manager bin, auch sowieso mein Weg. Also ich halte relativ wenig von Anbietersicht.

Context creates Value – nicht Features

Peter: Warum? Also magst du das mal kurz begründen?

Ich gehe da voll mit. Ich habe da sehr, sehr klare Meinungen dazu und kann das auch, glaube ich, jedem Unternehmer in drei Sekunden klar machen, wieso das so ist.

Wie bist du darauf gekommen? Was ist dein Grund?

Jan:  Ich wusste das schon immer. Ich habe es immer schon gefühlt.

Für mich wurde das im Grunde nochmal klarer, als Bob Moesta jetzt vor ein, zwei, drei Jahren, weiß ich gar nicht mehr, dieses Buch Demand-Side-Sales geschrieben hatte.

Und er hat nochmal ganz klar von der, also die Demand, also die nachfragende und die anbietende Seite unterschieden hat und eben auch die Lücke dazwischen beschrieben hat, dass eben das, was Firmen anbieten, nicht unbedingt das ist, was Kunden wollen.

Das wissen wir eigentlich schon seit Peter Drucker 1964, das man aufgeschrieben hat.

Für mich ist die wesentliche Begründung, Kundennutzen entsteht immer nur in einem Kontext.

Also wenn ich irgendein, ich habe also das Zitat heißt, Kontext creates value.

Ist auch von Bob Moesta.

Das heißt, wenn ich in einem Kontext bin und irgendwie etwas brauche, dann passt ein Produkt in meinen Kontext rein.

Und dann entsteht erst Kundennutzen.

Das heißt, die anbietende Seite weiß nie, wann oder ist nicht dafür verantwortlich, wann Kundennutzen entsteht.

Kann sie gar nicht sein, weil sie nicht, weil sie gar nicht weiß, in welche Kontexte sie denn passen könnte.

Wenn sie einfach nur aus der Anbietersicht heraus Produkte in einem Markt anbietet.

Peter: Das haben ja auch schon Christensen und Michael E. Raynor geschrieben in The Innovator’s Solution.

Das war das zweite Buch, was dann nach Innovator’s Dilemma kam.

Da geht ja das Zitat daraus hervor.

The critical unit of analysis is the circumstances and not the customer.

Also es geht nicht um soziodemografische Daten von Kunden, die zu verstehen.

Auf der einen Seite, sondern es geht darum, diesen Kontext genau zu verstehen.

Die Umstände, unter denen Menschen eine Lösung brauchen oder ein Produkt beauftragen.

Jan: Genau und Anbietersicht ist halt, ich baue einen Segway und biete diesen Segway an einem Markt an.

Und dann kann es halt sein, dass es Kontexte gibt, wo dieses Produkt Segway Nutzen liefert.

Es kann aber auch sein, dass es eben das nicht gibt.

Und das ist für mich im Grunde ein Beispiel für eine reine Anbieterdenke.

Peter: Ist ja eins der spektakulärsten Innovationsfails überhaupt.

Also gedacht war es als die individuelle Fortbewegungslösung der Zukunft, wie sich Menschen zukünftig bewegen werden.

Was daraus geworden ist, ist ein Spielzeug für Menschen mit zu viel Geld und Tagesfreizeit, die da drauf jetzt Hockey spielen. Und was für Sightseeing in fremden Städten.

Jan: Das Problem ist halt, dass der Segway eben, das ist auch eine Frage, die bei Jobs immer kommt, was ist eigentlich die Konkurrenzsituation?

Weil du ja sagtest, ein Produkt kann viele Jobs erfüllen und ein Job kann durch viele Produkte erfüllt werden.

Wenn man letzteres nimmt, dann konkurrierte der Segway wohl mit zu Fuß gehen und hat halt das Problem, dass er keine Treppen kann.

Peter: Wir hatten so ein Ding in der Firma, hatten eins und haben den für Messen eingesetzt, wo wir dann auf Messen damit rumgefahren sind.

Das war tatsächlich werbewirksam.

Ich habe mich dann ab und an dazu hinreißen lassen, in der Mittagspause mal damit zum Supermarkt zu fahren, um mir was zu essen zu holen.

Ich habe mich selten so dumm und bescheuert gefühlt, wie auf dem Ding in dieser einen Mittagspause.

Jan: Ich glaube, George Bush hat sich da mal hingelegt, hat sich auch nicht so besonders toll damit gefühlt.

Peter: Das kommt ja noch dazu.

Sandiger Boden ist lebensgefährlich auf den Dingern gewesen.

Ich weiß nicht, wie die heute mit der Software das geregelt haben.

Aber jetzt fahren die ja einrädig durch die Gegend.

Jan: Wenn ich jetzt noch mal da zurückgehe, Context creates value.

In welchem Kontext stiftet denn der Segway Nutzen?

Aus der Sicht, ich möchte mobil sein in der Stadt oder so, gab es diesen Kontext nicht.

Heute lösen das die anderen, diese Roller wie Bird oder was auch immer, die lösen das schon viel besser.

Aber das Ding hat in diesem Kontext keinen Nutzen gebracht.

Deswegen ist es so, diese Anbietersicht macht für mich nicht so viel Sinn.

Im Großen und Ganzen wollen wir immer so einen Kreislauf herstellen.

Anbieter create value, aber er möchte ihn ja auch wieder einfangen in Richtung Business-Ergebnis oder irgendwas. Das muss ja irgendeine Art von Kreislaufbeziehung.

Nikkel und ich haben damals Partnerschaft, haben wir das manchmal genannt.

Wir kreieren Nutzen für den sogenannten Value-Partner.

Und der Value-Partner gibt zu uns etwas zurück, zum Beispiel Geld, Daten oder was auch immer.

Und das Ganze ist aber irgendwie eine Art Augenhöhe-Kreislaufbeziehung.

Aber es ist ja immer von der Demandseite aus, wird es im Grunde gesteuert.

Weil ich als Anbieter niemals bestimmen kann, was Nutzen ist. Das ist einfach nicht möglich.

Und deswegen kommt man halt von der Demandseite.

Und wenn man die verstanden hat, dann designt man halt die Lösung.

Ich fange einfach ganz anders an als eine Firma, die anbieterseitig sagt, ich erfinde jetzt diesen Segway.

Peter: Was da noch mit reinspielt, was ich spannend fand, das hat ja auch Bob letztens noch mal gesagt.

Kurz zur Info, wenn einen das noch mal genau interessiert, wie das überhaupt zu Jobs-to-Be-Done kam.

Wir haben eine Podcast-Episode mit Bob Moesta, wo wir auch die Geschichte mit ihm besprechen, wie es überhaupt zu Jobs-to-Be-Done gekommen ist.

Wer sich das anhören mag, das ist, glaube ich, die einzige Episode, die wir komplett in Englisch gemacht haben, bis auf das Intro.

Aber um zurückzukommen auf das, zum Thema Demand.

Bob sagte ja auch, und das war für mich noch mal so ein Punkt, wo ich dann gedacht habe, ja klar, stimmt.

You can’t create Demand.

Demand ist da und du darfst es entdecken, aber du kannst es nicht kreieren.

Und entweder es gibt es oder es gibt es nicht.

Und das gilt es herauszubekommen.

Und dann zu matchen, wie kann ich diese Anforderungen von der Kundenseite, mit welchen Lösungen kann ich die eigentlich bedienen?

Also wie sieht eigentlich die Anforderung aus?

Weil auch ein Jobs-to-Be-Done Research sagt er ja nicht, wie du genau eine Lösung bauen musst. Er sagt ja nur, wie die Zieldefinition ist, wie das aussieht beim Kunden, wenn es gut ist.

Wie du da hinkommst, erklärt er das erst mal nicht.

Jan: Er sagt ja auch dann, build it and they will come. It’s a lie.

Ich kenne es auch.

Ich habe da unzählige Features oder Teilprodukte verantwortet.

Und ich weiß genau, so funktioniert es halt nicht.

Peter: Das ist ja sehr selbstkritisch.

Was ist dir denn…

Jan: Bau mal ein Feature bei Xing wieder aus.

Viel Spaß damit.

Peter: Das haben wir noch nie so gemacht.

Wo kommen wir denn da hin?

Jan: Wo ich das mal erlebt habe, naja.

Ich habe auch mit gewissen…

Also zum Beispiel auch in der Xing-Zeit bestimmt viele Sachen, ja, deployed, sagen wir mal so, die vielleicht nicht unbedingt jetzt nachgewiesenen Kundennutzen hatten oder die ich von der Demandseite abgeleitet hätte.

Das ist aber auch schon lange her.

Und es ist auch schwer.

Es ist tatsächlich sehr schwer.

Peter: Wie ging es dann weiter?

Und wie bist du dann zu intensiverem Jobs-to-Be-Done Research gekommen?

Du hast ja so ein bisschen erzählt, also für mich hörte sich das an, als wenn du da so ein bisschen in so ein Rabbit Hole gefallen bist. Wo du gesagt hast, da hast du was gefunden, was dich sehr fasziniert, was total sinnvoll ist.

Und dennoch ist da immer so ein Struggle geblieben, mit teilweise etwas herbem Nachgeschmack insofern, als dass du dann eine Beobachtung an dir gemacht hast und auch an anderen, die häufig zu Frust führte.

Magst du das mal ausführen?

Jan: Also ich hatte damals dann auch diesen, es gibt auch so einen Videokurs, wo die drei Leute, die das Handbuch geschrieben haben, das mehr oder weniger professionell gefilmt, erklären.

Den hatte ich mir auch gleich dann besorgt und bin da tatsächlich ziemlich abgestiegen.

Hab dann aber auch selber Beispielinterviews geführt, also in privaten Rahmen und hab geguckt, dass ich diese Technik irgendwie verbessere.

Dann parkte das Thema ein paar Jahre.

Also ich war dann irgendwie noch nach Xing irgendwie mal Product-Owner, vielleicht da zwei, drei Jahre in irgendeiner App. Oder dann hatte ich eine Menge Suchmaschinenoptimierung gemacht, war irgendwie ganz woanders unterwegs.

Und dann kam es so, dass ich als, auch zusammen mit Nikkel, dass wir eher so von dieser, also aus dem Product Management könnte man so zwei grundlegende Sachen unterscheiden, wenn man möchte. Also einmal so das Thema Execution und das Thema vielleicht Discovery.

Und also Execution meint, ich hab einen bestehenden Backlog und arbeite mich von Iteration zu Iteration und baue Features, Features, Features. Von dem hab ich mich so gelöst.

Und wir sind dann eher so in diese Frühphasen Produktfindungsgeschichten reingegangen und haben eben einen Discovery Workshop auch angeboten.

Den haben wir, ja, ich weiß gar nicht mehr, so das muss so 2018, 2019 vielleicht, 17, 18, 19 irgendwie. So den haben wir in-house angeboten.

Da sind wir irgendwo als Trainer dann in Firmen gefahren und haben dort erklärt, oder versucht zu erklären, wie man ein Product Discovery macht, den haben wir auch public angeboten.

Und da hab ich dann als Freelancer begonnen, tatsächlich auch Research-Projekte anzunehmen oder zu akquirieren.

Das heißt, ich war dann in meinen Freelance, also nach Xing war ich wieder Freelancer und bin es seitdem. Das heißt, ich werde immer in, ja, Projekte so angefragt und dann gebucht.

Die gehen dann vielleicht drei, sechs Monate, manchmal auch ein bisschen länger.

Und da hab ich dann zunehmend die Rolle des Researchers übernommen.

Also die Person, die dann tatsächlich echte Interviews macht.

Was ich vorher, also, und da bin ich dann, das sag ich dann noch mal, ich bin halt laienhafter Researcher.

Es gibt ja auch professionelle Researcher und Researcherinnen.

Aber wir kommen eher so von der pragmatischen Sicht, dass wir sagen, wir machen lieber den Research selber. Vielleicht machen wir ihn nur 80 oder 70 Prozent wirklich professionell gut.

Dafür können wir alles, was wir gehört haben, auch wirklich anwenden.

Im Gegensatz dazu, wenn ich Research kaufe, dann ist er vielleicht zu 100 Prozent gut, aber ich kann eigentlich nur 10 Prozent anwenden.

Das ist so unsere Erfahrung mit Studien, die man extern besorgt.

Und deswegen war dann, seit Xing damals auch eben die Entscheidung gefallen, ich mach’s selbst. Und hab dann eben angefangen, Interviews zu üben und bin dann auch als Freelancer immer mehr in Research-Projekte gekommen.

Und da kam dann das Thema Jobs-to-Be-Done auch wieder, weil es sich mittlerweile auch irgendwo in der Welt verbreitet hatte.

Es gab dann ja, oder es gibt ja heute mehrere unterschiedlichste Publikationen zu dem Thema, also verschiedene Bücher von verschiedenen Autoren.

Und so war es dann bei mir in meinem Umfeld auch, dass dann eben das Thema Jobs-to-Be-Done angefragt worden ist. Kannst du das machen?

Und ich so, ja, juhu, natürlich mach ich das.

Hatte mich sehr, sehr begeistert, dass es das irgendwie gibt und dass ich das tatsächlich als Freelancer auch machen kann.

Und dann habe ich in den letzten Jahren tatsächlich viele Projekte gemacht, die als vermeintlicher Jobs-to-Be-Done Research begonnen haben.

Aber es stellte sich dann am Ende raus, dass es vielleicht nicht unbedingt das Jobs-to-Be-Done war, was damals ich bei Xing so verstanden hatte, was es denn sein könnte.

Peter: Und das heißt, was genau ist das dann?

Also welchen Unterschied gab’s da?

Jan: Es gab tatsächlich so ganz klassische oder ganz einfach aufzulösende Dinge.

Da kam dann jemand und sagte, kannst du Jobs-to-Be-Done Research machen?

Dann guckte ich mir das an und dann waren die zu untersuchenden Probanden, waren eben Leute, die gar keine Kaufentscheidung getroffen haben, sondern es waren Nutzer von einem System. Und die sollte ich erforschen, wie nutzen sie ein System?

Und dann habe ich das für mich eher so dann als Task-Analyse oder so klassifiziert.

Also was tun die Leute mit einem Software-System?

Und hab dann gesagt, wir können gerne ein Research machen, aber das Ergebnis sind keine Jobs-to-Be-Done, sondern es ist eine User-Story-Map.

Und die hilft uns dann als Backlog und Entscheidungstool, die richtige Software zu bauen, wollt ihr das?

Dann haben die gesagt, ja, das wollen wir.

Also das heißt, das Problem erstmal so beschreiben, das ist für das Team, also es ist ja immer ein Team, das ein Research als Support braucht.

Und erstmal zu klären, wofür braucht ihr das jetzt?

Es gab aber auch andere, und dann konnte ich dann, hab ich den Research gemacht oder wir, und am Ende kam eine Story-Map raus und das war dann auch gut.

Es war aber ein Problem von, ich hab wenig Zeit und will, also was sind die 20% Software, die ich bauen muss, damit ich 80% Wirkung erreiche? Das war der Hintergrund.

Und in meiner Denke ist Jobs-to-Be-Done nach wie vor, und deswegen sprechen wir ja heute, irgendwie ein größeres Ding.

Also dass ich damit vielleicht dieses Wort Innovation, wenn ich das so benutzen wollen würde, vielleicht dass ich das damit beantworten kann. Wie mache ich eigentlich Innovation und welche dann überhaupt?

Und dann hatte ich teilweise Projekte, wo dann weder den Kunden noch dem Team eigentlich klar war, was zu tun ist.

Und dann wurden diese Research, also diese Interviews gemacht. In der Regel machen wir ja dann zehn Stück oder acht oder so.

Und wenn wir dann wiederkamen, oft waren wir auch zu zweit, also Interviews alleine machen würde ich es nicht so empfehlen, und idealerweise zu zweit oder so. Dann haben wir diese Ergebnisse Jobs-to-Be-Done artig formuliert.

Und dann konnte damit aber dann in den Organisationen, die Organisationen konnten damit relativ wenig anfangen, weil sie eben nicht so genau wussten, was mache ich denn jetzt mit diesen Ergebnissen?

Hypothesenbildender Research vs konfirmierender Research

Peter: Woran hast du das erkannt? Also wie ist dir das aufgefallen?

Jan: Das habe ich ganz einfach daran erkannt, dass ich Stundenzettelt hatte mit Research und dass danach die Projekte einfach gestoppt sind.

Und es danach keine weiteren Stundenzettel gab und auch keine weitere Beauftragung in dem Bereich.

Und dass dieser ganze Research und das ganze Projekt abgebrochen worden ist.

Daran habe ich das erkannt, und das habe ich nicht nur einmal erlebt.

Peter: Es ist ja auch, na gut, wenn man hypothesenbasiert arbeitet, sagt, okay, wir haben jetzt eine Fragestellung oder eine Annahme und untersuchen das jetzt mithilfe eines Experiments, beispielsweise mit einem Jobs-to-Be-Done Research, wo wir mit, „Wir glauben das A, B, C, und dafür sprechen wir jetzt mit zehn Leuten“.

Und wir gucken darauf und darauf und wir liegen mit unserer Annahme richtig, wenn.

Und kann ja sein, dass die Annahme widerlegt ist und dass das deswegen eingestampft wird.

Dann sagt man halt, ja, schade, war halt nichts.

Aber du siehst einen anderen Grund dafür, dass das eingestampft worden ist.

Jan: Erstmal bin ich da ganz selbstkritisch draufgeguckt.

Also es waren halt ungeklärte Mandate in dem Sinne.

Ich habe zum Beispiel ein Beispiel, da wurde halt auch ein Jobs-to-Be-Done Research wirklich benannt als Beauftragung.

Und als ich dann in die Arbeitsebene ging, dann hatte ich am Ende, es ist ja so, zu Beginn rekrutiert man ja Leute.

Das heißt, ich habe da oft so Agenturen, die mir da mal helfen, wenn es manchmal nicht wirklich funktioniert in Haus oder so.

Dann habe ich dann meine Testpersonen bestellt, hatte die alle terminiert, war der Kalender, waren die Interviews da und dann wollten wir eigentlich loslegen.

Und dann sagte der Kunde, ich würde gerne nochmal sprechen und ich würde gerne mal dein Interview Leitfaden sehen.

Peter: Klassiker.

Jan: Und dann kam halt in dem Gespräch raus, ich habe gar keinen Leitfaden.

Und dann hat der Kunde gesagt, das Projekt machen wir nicht.

Du bist ja gar kein richtiger Researcher.

Und hat sozusagen das Projekt beendet.

Und was dahinter steckt, ist ja das Missverständnis.

Der eine, also ich habe gedacht, wir machen ja einen Hypothesen bildenden Research.

Das heißt, das ist für mich immer so die Grundlage von Jobs-to-Be-Done.

Das heißt, ich gehe explorativ in Interviews rein und bilde Hypothesen daraus.

Ich will ja den Job verstehen, ich kenne ihn ja noch nicht.

Das ist ja erstmal meine Grundannahme.

Und wenn ich explorieren will, dann ist das ja das Gegenteil von konfirmieren.

Und konfirmieren wäre Hypothesen überprüfen.

Aber ich will sie ja bilden. Also ergo macht ein Leitfaden wenig Sinn in einem Hypothesen bildenden Research. Weil wenn ich Hypothesen überprüfen will, dann brauche ich vorher Hypothesen.

Die nehme ich mit in mein Interview.

Das gibt es ja auch, dass ich im Nutzer-Test zum Beispiel, das ist ein ganz klassischer konfirmierender Research, da nehme ich mir Hypothesen und versuche sie anhand eines Prototypen zu invalidieren.

In dem Jobs-to-Be-Done Interview, wenn ich sage, ich will explorieren, habe ich sie halt nicht. Und das war das grundlegende Missverständnisses zwischen mir und den anderen.

Und ich glaube, das wurde halt aber auch nicht benannt vorher.

Ich habe mich dann gefragt, wieso haben wir jetzt das Projekt abgebrochen?

Ich verstehe es nicht so ganz.

Peter: Ich glaube, das geht schon.

Also hypothesenbildend auf jeden Fall, ja.

Es ist ergebnisoffen, ja.

Dennoch ist es auch dazu geeignet, bestimmte eigene Hypothesen zu widerlegen oder zu bestätigen. Darüber sollte man sich schon im Vorfeld auch klar sein, was man damit eigentlich will.

Was sind denn so die eigenen Ideen und Grundannahmen?

Häufig hilft das dabei, das dann auch wegzuparken.

Das, was ich feststelle, ist, dass die meisten Menschen, gerade auch jetzt in den letzten drei Jahren mit unserer Pandemie und dem Ganzen, was da an Diskussionen losgetreten worden ist, dass überhaupt kein Bewusstsein dafür da ist, worin eigentlich der Unterschied zwischen qualitativer und quantitativer Marktforschung oder Forschung besteht.

Und die qualitative, die klärt immer das Warum, die Kausalität.

Warum machen Menschen genau das, was sie tun?

Wie hängt das miteinander zusammen?

Und die quantitative klärt, wie viele machen was, wovon.

Und du brauchst immer beides.

Und jetzt ist natürlich das Problem, wenn ich explorierend unterwegs bin, hypothesenbildend, explorierend mit einem Job-to-Be-Done-Interview, dann habe ich natürlich auch die Herausforderung, ich darf, also wenn ich was lernen will, darf ich nichts implizieren.

Also alles, was in Richtung Suggestivfragen und Co. geht, raus.

Alles, was lösungsorientierte Fragen sind, raus.

Wir müssen problemorientiert fragen und wir müssen faktenbasiert fragen.

Und das führt zu der Challenge, dass du dir im Prinzip keinen Leitfaden erstellen kannst.

Du musst ja aber schon darüber im Klaren sein, welche Informationen genau brauchst du eigentlich, welche Art von Informationen.

Und dafür gibt es schon Fragen, aber die sind für alle Interviews gleich.

Mehr oder weniger.

Die variieren jetzt nicht großartig.

Jan: Genau, also ich will damit nicht sagen, dass wir kein Gerüst hätten oder keinen Rahmen.

Es ist nur ein anderer.

Ein Leitfaden ist ja so etwas wie, ich habe mir einen Zettel von Papier vor mir und gehe den halt durch.

Und am Ende, hatte ich mal einen Riesenkonflikt mit einer anderen Researcherin, am Ende habe ich dann acht Interviews. Und wenn ich allen Probanden dieselben Fragen stelle, dann kann ich sie halt vergleichen.

Und da sollte ich dann so Interviews machen, dann habe ich mich halt nicht an diese Fragen gehalten. Dann ist die halt richtig sauer geworden, weil sie zu Recht gesagt hat, ich werde sie nicht benutzen, weil sie nicht in mein Schema passt. Aber wir wollen auch explorieren.

Also immer wieder das Thema.

Und bei mir in diesen Projekten war es halt teilweise so, dass das eben ganz klassische Jobs-to-be-Geschichten waren.

Also da hat jemand ein Produkt gekauft oder wir haben im Bereich Fahrrad-Leasing geforscht. Und ich bin dann ganz klassisch einfach oder auch naiv davon ausgegangen, okay, wir wollen jetzt rausfinden, da kauft jemand irgendwie ein E-Bike zum Beispiel.

Das ist ein gutes Beispiel, weil ich auch selber gerade irgendwann mal eins gekauft habe. Was ist denn jetzt der Job des E-Bikes?

Und da habe ich dann eben mein Gerüst, das ist die Timeline, die wir bekommen haben damals von Bob Moesta, wo er einfach Phasen des Kaufprozesses einfach umbenannt hat in Timeline.

Also dass Kaufprozesse in Phasen ablaufen, das ist ja nichts, was jetzt irgendwie die Jobleute erfunden haben.

Was sie gesagt haben, ist, dass diese Timeline, wie du auch gerade sagst, eben kausal Zusammenhänge hat.

Das heißt, dass ein Schritt nach dem anderen passiert und dass es aber nicht einfach so passiert.

Also Käufe sind nicht einfach so, die sagen ja auch, es gibt keinen Impulskauf, sondern das ist alles kausal immer erklärbar in jeder einzelnen Geschichte, wie kam es jetzt zu diesem Kaufverhalten.

Und so bin ich da auch rangegangen.

Und dann kam ich halt am Ende mit meinen Ergebnissen hier, zum Beispiel bei dem E-Bike, das ist jetzt das Job-to-Be-Done-artige, was wir rausgefunden haben in den verschiedenen Phasen.

Und tolle Erkenntnisse.

Jetzt lass uns doch mal irgendwie das und das machen.

Und das war dann aber auch wieder so ein Moment, wo dann dieser Disconnect fühlbar wurde, weil der Kunde gesagt hat, ich kann damit gar nichts anfangen.

Das ist zwar irgendwie schlüssig, aber wir sind irgendwie ganz anders drauf.

Ein Klassiker ist ja auch, ich habe da schon 30 Leute eingestellt, die haben schon mal angefangen zu programmieren.

Peter: Und wehe dein Ergebnis passt nicht zu unseren Vorstellungen.

Jan: Das ist auch ein Klassiker, den ich auch so erlebt habe. Und auch ein ganz, auch ein wirklich bestellter Jobs-to-Be-Done-Research.

Damals ging es irgendwie um Stromanbieter oder sowas.

Also wann kaufe ich welchen Stromanbieter oder entscheide ich mich für den?

Und da war dann eben, ja, die Leute, die haben schon angefangen.

Und ich verstehe dein Problem, du hast leise die Leute eingestellt und irgendwas müssen sie tun.

Aber warum kommt ihr jetzt mit zum Research?

Und auch da ist dann das Ergebnis, und das war auch ein, ich sage mal, ein astreiner Research, also für eine erste Runde, wenn man acht bis zehn Interviews macht, dann kann man halt auch natürlich nur im gewissen Rahmen Ergebnisse liefern.

Aber da waren dann auch solche Erkenntnisse eben drin. Wie kommt es eigentlich zu der Entscheidung für gewisse, was weiß ich, Fahrräder, Stromanbieter, was auch immer?

Was haben wir rausgefunden? Was ist Kundensprache?

Was sind die Events in der Timeline, die diese Leute von der einen in die nächste Phase geführt haben? Also ein ziemlich gutes Paket aus meiner Sicht.

Aber es hatte halt keinen Connect zu der Realität.

Die einen haben gesagt, wir wollen lieber Performance Marketing in Google machen, dafür brauchen wir jetzt deinen Research eigentlich gar nicht.

Und die anderen haben gesagt, ja, wir programmieren ja schon.

Peter: Das ist ja, also sorry, wenn ich da jetzt dem einen oder anderen mit auf die Füße trete, das ist überhaupt auch echt der dümmste Blödsinn überhaupt.

Also kannst du schon so machen, ist halt kacke.

Also Performance Marketing, mach es.

Wenn du einen funktionierenden Prozess hast, dann bringt das sicherlich was.

Es ist aber auf jeden Fall immer die teuerste Variante dessen, was sinnvoll machbar ist mit den verfügbaren eingesetzten Ressourcen.

Meistens ist das dann ja Geld.

Und ein Jobs-to-Be-Done Research kann ja natürlich auch genau dabei helfen, das komplett auszubauen.

Dafür haben wir auch ein paar echt sehr tolle Beispiele.

Hier an dem Beispiel Yogamatten mit dem Stephan Hück von Mantrafant haben wir das ja mal auch im Podcast sehr eindrücklich beleuchtet, was damit eigentlich machbar ist.

Die Rolle der Mandatsklärung

Ich habe an der Stelle, das kenne ich natürlich dann auch, das ist dann aber ja natürlich auch immer eine Frage der Auftragsklärung im Vorfeld.

Also worum geht es hier eigentlich?

Und wenn, ja natürlich haben die das oft so, dass da schon Sachen angefangen worden sind.

Und am Ende ist dann mein Job oder dein Job, unser Job, hilft mir dabei, das Produkt, was ich gerade schon anfange zu bauen und nicht mehr ändern will, zumindest ein bisschen besser zu verkaufen.

Das kannst du natürlich auch machen.

Jan: Und wo du gerade Auftragsklärung sagst, das ist natürlich das Grundproblem von meinen, sag mal negative Erfahrungen in der Vergangenheit, ist ein nicht geklärter Auftrag, beziehungsweise wir nennen das auch gerne Mandat, weil Auftrag ist irgendwie so, finde ich nicht so toll das Wort.

Auf der anderen Seite habe ich es aber auch hingekriegt, durch eine sehr intensive Mandatsklärung, Projekte gleich zu Beginn schon scheitern zu lassen.

Das heißt, wenn du nämlich dann die Frage stellst, was möchtest du denn mit diesem Research?

Und das habe ich damals bei Xing gelernt.

Da war Britta Ulrich, das ist eine der besten Researcherinnen, die ich so kenne.

Die war dort Head of, ich weiß gar nicht, Head of Research oder irgendwas.

Auf jeden Fall war sie die zentrale Ansprechpartnerin für Product Owner.

Und die hat immer gesagt, ja, also was ist denn deine Researchfrage?

Und ich so, ja, wie, was Researchfrage?

Ja, warum kannst du das Projekt nicht weiter machen ohne diesen Research?

Und dann ist erst mal Stille.

Und wenn du diese Frage Kunden stellst, dann kann das eben dazu führen, dass sie merken, hmm, eigentlich brauchen wir den Research vielleicht gar nicht.

Wir wissen das gar nicht so genau.

Deswegen ist es, auf der einen Seite habe ich die Researchprojekte gemacht, da habe ich nicht gefragt, dann hast du am Ende diese, manchmal diese Überraschung.

Und auf der anderen Seite habe ich es hingekriegt, durch das Stellen dieser Frage, Projekte sozusagen im Keim schon zu ersticken.

Und das ist irgendwie so dieses Grundproblem, wann beauftrage ich denn einen sogenannten Jobs-to-Be-Done-Research?

Weiß ich als Kunde überhaupt, was Jobs-to-Be-Done bedeutet?

Das ist ja auch unser großes Problem mit der Vieldeutigkeit mittlerweile.

Peter: Ja, ich glaube inzwischen, das ist eigentlich egal, ob der Kunde das weiß oder nicht.

Ich muss ja nur verstehen, was meint der eigentlich damit?

Und dann für mich klären, kann ich das abliefern oder nicht?

Oder will ich das vielleicht abliefern oder nicht?

Jan: Und dann habe ich ja in der Vergangenheit auch schon gesagt, okay, ich glaube, du brauchst eine andere Art von Research.

Das können wir auch machen.

Trotzdem ist es so, dass dieses Jobs-to-Be-Done-Wort ja heute in der Praxis tatsächlich benutzt wird und mittlerweile nicht mehr klar ist, was damit eigentlich wirklich gemeint ist.

Das heißt, man hat ein, es ist genau wie mit dem Begriff MVP oder mit dem Begriff Agile, das sind Wörter, die wir als Produkt-Community irgendwie versaut haben in den Jahren.

Wenn du jetzt bei mir einen MVP beauftragst, kann das was völlig anderes sein, als wenn du zu einem anderen gehst und sagst, mach mir mal einen MVP.

Und genauso ist es mit Jobs auch.

Also MVP reicht, ich kenne Leute, die sagen, das ist eine Skizze auf was ich wette.

Es gibt aber Leute, die sagen, nein, ich meine es eher wortwörtlich, ein Minimum-Viable-Produkt.

Dann habe ich aber Viable irgendwo nachgewiesen.

Das heißt, ich habe ein Produkt-Inkrement gebaut in einem Minimarkt, vielleicht für wenige User oder so, aber tatsächlich dort Profitabilität bewiesen.

Und das eine ist eher so das Ende einer prototypischen Reise und das andere ist der Beginn.

Und jetzt sage ich, Peter, kannst du mir mal einen MVP machen?

Also weiter auseinander kann es nicht liegen.

Und der eine sagt, ja, das mache ich dir.

Das dauert aber ein halbes Jahr.

Und der andere sagt, wie so ein halbes Jahr?

Ein MVP ist doch nur eine Serviette.

Verstehe ich jetzt nicht.

Und bei Jobs ist es genauso.

Mach mir doch mal einen Jobs-to-Be-Done Research.

Ja, welches Jobs meinst du denn jetzt?

Vielleicht können wir da auch noch mal kurz …

Peter: Ja, können wir gleich noch mal …

Jan:Ich komme ja so ein bisschen aus der Problematik heraus, dass ich ja auch so ein bisschen tatsächlich mit meinem Latein da am Ende bin, als der Researcher, der dann in Projekte kommt, der oft nicht beteiligt ist an den klärenden Gesprächen.

Das ist ja auch so ein bisschen mein Problem an der Stelle.

Peter: Also du fühlst dich da reingesetzt an einer Stelle, wo du eigentlich nicht mehr viel machen kannst, außer dein Research.

Und der kann dann eben passen oder nicht passen.

Oder was meinst du damit?

Jan: War das jetzt eine Suggestivfrage?

Peter: Klar. Gut aufgepasst!

JanJa, also ich habe das Problem, ich muss in meiner Arbeit erneut klären. Eigentlich wirst du ja gebucht.

Kannst du das und das machen?

Ja, klar. Und dann in dem Moment, wo das Projekt beginnt, muss ich jetzt mal klären, was wollt ihr überhaupt. Und das hätte ich eigentlich gerne vorher geklärt.

Peter: Ja, also ich kenne das sehr gut.

Ich bin da wahrscheinlich schon viel früher dran gewesen, insofern, als dass ich aus einer anderen Ecke kam. Also tendenziell eher aus Marketing und Vertrieb ursprünglich.

Und vielleicht durch mein Managementstudium da ein bisschen mehr Werkzeuge an der Hand hatte, das in so ein Konstrukt zu gießen.

Also das ging ja bei mir los über Vertrieb und Verkauf und diesen Demand-Side-Sales, so wie Bob das dann viele Jahre später mal benannt hat.

Und ich habe von Anfang an immer versucht, so was in den Prozess zu gießen.

Also von Anfang bis Ende etwas, wo irgendwas beauftragt wird und passiert und schon geklärt ist, was soll daraus werden.

Und habe dann irgendwann daraus einen Prozess entwickelt, wo es fast egal ist, an welcher Stelle man jetzt da einsteigt.

Aber das Thema Auftragsklärung, da kommst du halt nicht drum rum, weil das ist ja genau das.

Und das ist ja auch im Sinne der Jobs-to-Be-Done, im Sinne von Jobs as a Progress Thematik.

So das ist, wo ist denn der Fortschritt, den mein Auftraggeber, mein Kunde machen will und wo kann ich da ansetzen.

Und wenn ich jetzt ein Jobs-to-Be-Done Framework, Konzept, Methode, was auch immer habe und eine Vorstellung davon, dann ist es für mich selber, habe ich gemerkt, ich habe meine Vorstellung davon und ich finde dieses Konzept absolut faszinierend, total sinnvoll und logisch. Angefangen beim Innovators Dilemma, wofür die Jobs-to-Be-Done Theorie, ja keine wissenschaftliche Theorie im eigentlichen Sinne ist, sondern ein Gedankenkonstrukt von Clay Christensen, ein ganz, ganz elementarer, wichtiger Grundbaustein ist.

Und darüber haben wir dann eine Interviewsystematik entwickelt, die es ermöglicht, aus einem und demselben Interview, mehr oder weniger gleich alles rauszuholen, was du dann eben für, hilf mir dabei, den Schrott, den ich hier gerade baue, trotzdem zu verkaufen, bis hin zu, wie kann ich dann hinten raus, wenn ich dann einmal festgestellt habe, dass das eigentlich für das, was Kunden wirklich wollen und brauchen und haben möchten, gar nicht so geil ist, was ich hier habe, in der nächsten Iteration trotzdem ein besseres Produkt zu machen.

Krieg der JTBD Rechthaber

Ob sie das dann wollen oder nicht, das müssen die Kunden dann schon selbst entscheiden.

Und ja, dann kam es dazu, du hast ja jetzt zweimal schon Anlauf genommen, dass ja dann auch in dieser Zeit, 2015, 16, 17 ungefähr, an der Kante, ging ja dann dieser Jobs-to-Be-Done-Krieg irgendwie los, für die Jobs-to-Be-Done-Nerds hier, wo dann die große Debatte startete, was ist jetzt, wer hat jetzt eigentlich Recht, mit seiner Auslegung von Jobs-to-Be-Done, was kam dann an weiteren Schwierigkeiten für dich dazu? Oder worin unterscheidet sich das überhaupt?

Das ist jetzt so vom Fachmann für Kenner, da gab es früher mal in der Titanic diese Rubrik, ich weiß nicht, ob dir das was sagt.

Peter: Ja, es gab irgendwann mal, ich habe das auch gehört.

Da war der Sonnenborn noch Chefredakteur in dem Laden, glaube ich.

Jan: Ja, also das ist ja wirklich jetzt tiefste Job-to-Be-Done, ich sage mal Community, aber genau, irgendwann ging dann auf Twitter so eine Art Bashing los, da wo dann der eine behauptet hat, ich mache das richtige Jobs-to-Be-Done und der andere sagt, nee, ich mache es.

Das ging sogar so weit, dass der eine, glaube ich, ein Fake-Profil tatsächlich gepflegt hat, wo er den anderen mit diskreditiert und so, also ganz schlimm, das ging über, weiß ich, ein, zwei Jahre.

Die Leute, die das, das kam halt daher, es gibt so einen Typen, der heißt Alan Klement, oder was kommt mir an den, ob man den so ausspricht, Clement?

Peter: Ja, Alan Klement.

Jan: Der hat, oder ich sage mal so, das Grundproblem, was wir haben, und ich glaube, dass er da, dass ihn das getrieben hat, ist, wir haben ja dieses Handbook bekommen, 2014, mit einer Timeline und einem Forces-Diagramm.

Und dann haben wir diesen Kurs bekommen, und mehr haben wir aber nicht bekommen, als Practitioners.

Und wir müssen, wollen ja irgendwie dann die Arbeit auch anwenden praktisch.

Dann haben wir von dem anderen, haben wir einen Value Proposition Canvas bekommen, und dann sitzt du da und sollst halt Arbeit, Produktarbeit machen.

Und ich glaube, dass Alan Klement versucht hat, einfach das, was Clay und Bob eben, weil der mit denen auch zusammengearbeitet hat, was die halt damit meinten, dass er das einfach versucht hat, in die Praxis zu bringen, um es anwendbarer zu machen.

Für sich und vielleicht für andere.

Und dann gab es aber gleichzeitig einen, ja, du, sag mal.

Peter: Ja, ich rümpfe die Nase, das kann man jetzt nicht hören, aber ich kenne ja den Hintergrund zu dieser ganzen Nummer, wie das losging mit Alan Klement und für wen der eigentlich welche Art von Arbeit gemacht hat.

Und was da im Hinterzimmer abgegangen ist, das führt eigentlich nur dazu, dass ich diese Person, obwohl ich sie überhaupt gar nicht kenne, als äußerst unsympathisch empfinde.

Dennoch hat er ein paar ganz gute Gedanken gehabt zu diesem Thema hinten raus.

Aber das ist eine ganz andere Geschichte.

Erzähl mal weiter, was, also der Angriff ging ja dann gegen ODI und die Ulwik-Fraktion.

Jan: Und dann gibt es noch den anderen, der heißt Toni Ulwik oder Aluwik, weiß ich nicht, wie er sich ausspricht.

Und der macht auch schon seit, ich weiß gar nicht, seit ganz Anfang, macht der auch rum im Bereich Innovation, hat seinen eigenen Innovationsprozess mal etabliert, ODI, Outcome Driven Innovation, hat dazu auch ein Buch geschrieben.

Peter: Haben wir auch eine Podcast-Episode mit Martin Pattera dazu gemacht schon, wo wir das mal beleuchtet haben.

Jan: Der hat dann irgendwann angefangen zu behaupten, dass er den Term Jobs-to-Be-Done eben erfunden hätte und geprägt hätte.

Und das ist so ein bisschen unser Problem an der Stelle.

Und da hat der Klement eben auch, da hat der Klement dann gegen gehalten.

Peter: Das hat er wohl nicht so ganz, während jetzt, ein bisschen ungeschickt gewesen, wie er das gemacht hat vielleicht.

Jan: Und während so die Leute, die Jobs-to-Be-Done mal damals geprägt hatten, sich eigentlich da völlig rausgehalten haben, hat der Clement das halt irgendwie aufgegriffen und hat dann gegen Toni Ulwik oder mit Toni Ulwik so eine Art Streit über Twitter begonnen.

Also wirklich unsäglich und ziemlich peinlich, fremdschämlich.

Und was da aber hinter steckt, ist eben, dass die einen, also das im Grunde, es gibt zwei, ich sag, also ich würde fast sagen, diametral gegenüberstehende, ja, Bedeutungen von dem Begriff Jobs-to-Be-Done.

Und das ist, das hilft natürlich überhaupt nicht, wenn wir in der Praxis dann Jobs-to-Be-Done machen wollen.

Peter: Ja, da bin ich mir gar nicht so sicher, ob das wirklich so unterschiedlich ist an der übergeordneten Bedeutung.

Was aber ein sehr, sehr krasser Unterschied ist, ist die inhaltliche Auslegung davon und wie das dann genutzt und bearbeitet wird.

Das hat tatsächlich auch für mich überhaupt nichts miteinander zu tun.

Jan: Ja, also wo die Unterschiede sind, können wir gleich nochmal gucken.

Und dann haben Leute angefangen, und da gibt es einen, der nennt sich dann, der heißt Kalbach.

Und der hat dann wiederum ein Buch geschrieben, wo er diese beiden…

Peter: …Produktmanager bei Mural aktuell, glaube ich noch.

Jan: Wo er dann diese beiden eigentlich nicht vergleichbaren Dinge, aus meiner Sicht, irgendwie vergleicht und daraus wieder was Drittes baut, was dann wiederum eine Art von Praxisanleitung ist, wie man das denn jetzt machen soll.

Und da frage ich mich dann auch, hilft das gleich oder später, lieber Herr Karl Bach, in der Welt, wo wir eh schon so diese beiden unterschiedlichen Strömungen haben, warum dann noch was Drittes draufsetzen?

Will ich da auch nochmal auf diesem Wort irgendwie mitmachen, oder was?

Oder sollen wir noch mehr Jobs-to-Be-Done Bücher schreiben und noch weitere?

Also das ist für mich so, das kriege ich in meine Realität überhaupt nicht rein, wie ich mir… Also wie komme ich auf die Idee, ein Wort, oder einen Begriff zu nehmen, den irgendjemand mal definiert hat und ihn umzudeuten und das in einem Buch zu publizieren?

Das hat Eric Ries mit dem Begriff MVP schon mal gemacht. Und ich kann das nicht verstehen.

Was da…Also ist denn das Unfälle, oder was?

Das Problem ist halt, wenn Bücher dann bekannt werden und du mehr Reichweite hast als jemand anders, dann verbreitet sich eben die vermeintlich falsche Interpretation von so einem Begriff und dann sind alle so noch verwirrt.

Peter: Also ich glaube, da vermischen sich ein paar Sachen.

Mit Hauptschuldiger an dieser Stelle ist wahrscheinlich der Dunning-Kruger-Effekt, der ja zu einer Art Verblendung führt. Das heißt, wir werden dann alle sehr schnell plötzlich zu Experten, obwohl wir eine Sache erst zur Hälfte verstanden haben, wenn überhaupt.

Und wenn dann der Reiz, jetzt endlich auch mal ein paar Minuten Ruhm einzukassieren, indem ich mich dann vielleicht noch als Autor verdinge, dann kommt halt so ein Zeug irgendwie aufs Papier.

Ich kann da gar nicht so furchtbar viel sagen, wie das inhaltlich ist, ob das jetzt gut oder schlecht ist. Ich hab nur das meiste von dem, was bisher aufgeschrieben wurde, ist wirklich in der Praxis kaum zu gebrauchen.

Also auf der einen Seite, um nochmal Clay und Bob in Schutz zu nehmen, jetzt Competing Against Luck, da haben wir auch schon lange drüber berichtet und ist ein wundervolles Buch.

Das erklärt dir aber auch nicht, wie du es machst. Sondern nur, wie toll und wie schön das ist.

Und das Gleiche tun sie auch an der Harvard Business School. Das ist ja auch schon mehrfach vorgekommen, dass die dann hinterher zu uns kommen, zu mir kommen, weil sie dann wissen wollen, wie sie es jetzt eigentlich genau machen sollen. Weil das steht da nicht drin. Es erklärt dir keiner.

Und es gibt halt zwei große Beratungshäuser, die sich da auf dieses Innovationsthema mit und jetzt nur dieser Überschrift Jobs to Be Done spezialisiert haben, die verraten aber keinem, was sie da machen. 

Das kannst du dann für teuer Geld da einkaufen und kannst dann dran glauben.

Alles, was da passiert, bleibt dann in so einer Art Blackbox und schürt natürlich Spekulationen.

Und jeder, der es mal gehört hat, hat natürlich sofort eine Meinung dazu.

Jan: Also ich wünsche mir an der Stelle irgendwie, eigentlich ist es auch eine Frage von der Mandatsklärung, was willst du machen?

Zum Beispiel ist es so, wenn ich jetzt sage, ich möchte einen neuen Markt und ich nehme das Business Model Canvas.

Ich glaube darauf, dass das Business Model Canvas ist wirklich, also da können wir alle dankbar sein, dass wir das bekommen haben.

Für das value Proposition Canvas, das ist eher so ein Bärendienst gewesen vom Osterwalder.

Das ist meine persönliche Meinung jetzt.

Peter: Wobei ich das Buch deutlich besser finde als das Business Model Canvas.

Jan: Aber es ist auf einigen Würden, dass wir sagen, okay, wir haben da was wie Kundensegmente und die beschreiben im Moment einen Teil von diesem Business Model.

Und ich möchte sagen, ich möchte in einen neuen Markt, ich möchte ein neues Kundensegment auf der Ebene.

Dann kann ich Jobs-to-Be-Done, ich sage mal so, wie wir das vorhin beschrieben haben, in der Frage, für welchen Kundenjob bewerbe ich mich oder wofür hiren mich, also jetzt kommt so ein denglisches, wofür beauftragen mich Leute, dann ist das eine gute Methode, um das Ziel zu erreichen.

Wenn ich jetzt sage, ich möchte eigentlich in meinem Markt bleiben und mein Produkt verbessern, dann eignet sich eher die andere Jobs-to-Be-Done Geschichte, weil was Toni Ulwick macht, ist aus meiner Sicht, das soll jetzt auch nicht bewertend sein, aber es ist eher Anbietersicht, das heißt, er guckt sich viel mehr an, was ist eigentlich die Nutzung von bestehenden Produkten und wie kann ich in einer Detailtiefe diese Nutzung bestehender Produkte ganz stark verbessern.

Das nennt er Innovation.

Während die andere Sache eher ist, ich gucke eigentlich eher in die kategorieübergreifende Konkurrenz und überlege dann, weil eigentlich ist es so, wie du sagst, wenn ein Produkt hat, löst viele Jobs und ein Job kann von vielen Produkten gelöst werden und für mich, oder ja, das Interessantere ist eigentlich, finde ich, für mich ist es das Letztere und da bin ich dann ganz klar bei der Bob Moesta Geschichte, wobei ich auch gar nicht, überhaupt gar nicht dafür argumentieren würde, ob es ein Letzter oder ein Letzter ist, sondern ich bin der Meinung, die einen haben Jobs benannt und das ist das halt so und wenn ich was anderes mache, dann muss ich mir ein anderes Wort überlegen.

Aber der Zug ist halt leider abgefahren mittlerweile.

Peter: Ja, wie auch immer.

Ich denke auch, es gehört, es hat beides seine Berechtigung, um das nochmal abzurunden, jetzt mit dem Thema der Ulwick-Part, das sagen die ja auch selber, der basiert auf Six Sigma, was ein Werkzeug zur Prozessoptimierung ist, und das haben sie halt erweitert und streiten sich dann um diesen Terminus Jobs-to-Be-Done.

Und das ist natürlich hervorragend geeignet, um Bestehendes zu verbessern und auch da auf bessere Wege und Lösungen zu kommen.

Ich halte es für extrem aufwendig und der Kosten-Nutzen-Faktor, da denke ich, auch wenn wir es im direkten Vergleich sehen, das ist für die meisten vollkommen over-delivered und ich verfolge da eher den Ansatz, dass wir mit unserem Framework dafür sorgen, dass wir mit einem und demselben Research, der auch sehr schnell und sehr effizient funktioniert, einen Datenstamm zu erzeugen, der dir dann alles ermöglicht.

Und es ist dann eine Selektionsaufgabe, aus diesem Datenstamm die Daten rauszusuchen und zu selektieren, die dir deinen Fokus geben, den du brauchst, um dann ein konkretes Ziel zu erreichen.

Ein kurzfristiges, mittelfristiges oder langfristiges Ziel, das lässt sich damit alles machen.

Kurzfristig kann eben auch sein, ein Produkt zu iterieren, zu verbessern.

Kann auch sein, wir erfinden hier was ganz Neues, was wir überhaupt gar nicht auf dem Zettel hatten, weil wir plötzlich Dinge entdeckt haben, und auch das sagen uns dann genau die Daten, auf das wir überhaupt gar nicht gekommen wären oder einen ganz neuen Markt finden; Wo wir plötzlich feststellen, hier ist eine Wettbewerbslandschaft mit Riesenopportunitäten für uns und wenn wir die drei Sachen ändern an unserem Produkt, dann kommen wir da an vollkommen neue Geschichten dran und erledigen und bewerben uns, um in dieser Terminologie zu bleiben, auf einen ganz anderen Job.

Dafür muss ich aber natürlich genau auch wissen, was sind denn jetzt die subjektiven Wertmaßstäbe für Verbesserung aus Kundensicht?

Also was muss ich denn genau abliefern, damit Kunden sagen, Hurra, das ist ja zehnmal besser als das, was ich hier bisher gekannt habe.

Und was kannst du auch alles weglassen?

Und dann spielt es eigentlich gar nicht mehr so eine große Rolle.

Jetzt hast du aber noch berichtet, wir müssen ein bisschen auf die Zeit gucken, wir sind ja schon fast eine Stunde dabei, das hast du auch bei anderen beobachtet, dieses dann, also mit diesem Research, mal unabhängig davon, welche Jobs- sowie dann Geschmacksrichtung jetzt da dran ist, da findet selten Transfer statt oder die Kunden, Auftraggeber in dem Sinne dann, für diesen Research, stehen dann da und sagen, ja, spannend, die Daten kommen in die Schublade und dann passiert weiter nichts.

Und das ist mitunter frustrierend.

Woran liegt das?

Also außer an mangelnder Auftragsklärung vielleicht, wo es noch in Schwierigkeitsfelden liegt.

Jan: Also ich, eigentlich ist es ja, ich hätte da vorhin schon gesagt, ich muss es eigentlich auch selbstkritisch so ein bisschen betrachten, also was habe ich nicht geliefert, dass die sagen, okay, wir handeln jetzt.

Und das ist, glaube ich, der Punkt, das vom Mandat mal abgesehen, dass die Anwendbarkeit der Ergebnisse, also ihr könnt konkrete Überführungen in vielleicht Maßnahmen oder auch in neue Projekte, dass die gefehlt hat.

Wir kamen dann oft mit so einem Research-Ergebnis, hier, das sind Jobs to Be Done, und dann haben wir gefragt, was wollt ihr denn jetzt damit machen?

Wollt ihr vielleicht eher das oder das oder so?

Natürlich haben wir schon irgendwo auch Vorschläge geliefert, aber letztendlich haben wir den Ball ein bisschen zurückgespielt zu den Kunden.

Und die waren dann aus meiner Sicht, oder vermutlich waren sie mit dem Ergebnis irgendwie, es war nicht erwartungskonform, die waren damit vielleicht überfordert, weil wir vorher nicht gut geklärt hatten, was zurückkommt.

Vielleicht war dann so was wie, ja, also jetzt einen neuen Markt, das können wir doch gar nicht leisten, das ist alles viel zu, und Marketing wollen wir eigentlich auch irgendwie, machen wir sowieso anders, also was sollen wir damit jetzt tun?

Das ist zwar nett, aber wir können es nicht anwenden.

Und das ist, glaube ich, der Grund, warum dieser Transfer nicht stattfinden kann oder nicht stattgefunden hat.

Und genau, dann haben wir uns ja irgendwo da im letztes Jahr mal kennengelernt im Internet.

Peter: Ja, auch über einen gemeinsamen Bekannten, den du zumindest gar nicht so richtig kennst, aber er hat zumindest mal euch getroffen, das ist auch ein sehr, sehr geschätzter Kollege, der Florian, der war auch schon hin und wieder bei uns in den Clubhouse-Talks mit dabei.

Jan: Ja, ich war letztes Jahr so ein bisschen im Dezember drauf.

Ich hab LinkedIn irgendwie das erste Mal benutzt irgendwo, hab dann angefangen, Leute dort irgendwie, ich weiß nicht, ich hab Sachen gepostet, hab irgendwelche Likes bekommen, dann hab ich Leute angeschrieben, und das führte dann zu mehreren so Kennenlern-Kaffee-Gesprächen, unter anderem ja auch mit dir oder mit dem Florian.

Und ich hatte deinen Podcast gehört, und dann hab ich gedacht, okay, also ich kannte den eh schon vorher, im Grunde war dann dieser LinkedIn, war eher so tatsächlich in meiner Job-to-Be-Done-Zeit, so der Moment, jetzt schreib ich den mal an.

Eigentlich war ich schon passiv, vorher schon hab ich, und ich hab immer gedacht, okay, der, ich hatte ja mit Bob viel gesprochen, und wenn ich mit Bob gesprochen hatte und hab dann andere Podcasts gehört, war dann deiner immer einer von denen, eigentlich sehr, ja tatsächlich sehr wenigen, wo ich gedacht hab, okay, der spricht so, wie ich das auch irgendwie verstehe.

Und ich glaube, aus der Problemlage heraus, irgendwie komm ich in meinen Job-to-Be-Done-Research-Projekten nicht so richtig weiter, das ist jetzt ein Punkt.

Im Grunde ist es so tatsächlich, jetzt wenn ich jetzt so immer so reflektiere, das war ein Punkt, wo ich tatsächlich in meiner eigenen Timeline gesagt hab, es reicht, so geht’s nicht weiter.

Ich muss jetzt was ändern, damit ich in Zukunft besser, erfolgreich Job-to-Be-Done-Research anwenden kann.

Weil ich selber komm in diese Situation als Freelancer, der meistens unbeteiligt in der Auftragsklärung ist, der dann in diese vermeintlichen Job-to-Be-Done-Projekte, die vielleicht eher Ulwick-artig sind, wo ich gar nicht arbeiten will, weil mich das nicht motiviert, wo ich dann reinkäme, das geht so nicht mehr weiter, ich muss was ändern, und dann hab ich eben Peter Rochel auf LinkedIn angeschrieben, der hat gesagt, du machst doch auch so Job-to-Be-Done, und du hast auch Kunden, und wollen wir nicht mal irgendwie zusammen, und dann war bei mir so ein bisschen die Intention dahinter, tatsächlich für mich persönlich in meinem Akquise-Prozess, was zu ändern, und vielleicht bei jemandem, der das Problem aber für mich löst, nämlich richtige, oder für mich passende Job-to-Be-Done-Aufträge zu akquirieren, wo ich dann das machen kann, was ich machen will, und nicht das Problem mit dem Mandat und mit dem späteren Transfer, weil ich auch nicht aus meiner Situation, ich wusste nicht, wie kann ich das ändern, ich hatte jetzt keine Lösung parat, weil wenn ich versucht hatte, Mandate zu klären, dann ging das immer nach hinten los, das soll ich also nicht tun, ich soll eher arbeiten, ich soll, es ist auch generell, ich vertreibe mich relativ selten selbst, meistens bin ich angewiesen auf ein Vertriebsnetzwerk, weil ich bin eher immer auf der Arbeitsebene, ich kann dann schwer die Perspektive so schnell wechseln, in eine C-Level-Perspektive gehen, das ist nicht so mein, das brauche ich auch nicht machen, ich soll sozusagen arbeiten, und die anderen sollen Mandate klären.

Genau, und so habe ich dich dann angeschrieben, und dann haben wir uns ausgetauscht, haben zusammen auch ein bisschen Beispielinterviews in einem deiner Projekte gemacht, und so sitzen wir jetzt hier.

Peter: Genau, das hat ganz gut gepasst, und dann kam ja noch die Idee dazu, wo du gesagt hast, du glaubst, du bist ja nicht alleine mit diesem Struggle, mit diesem Thema, irgendwie so dieses Gefühl, irgendwie so, ja, wie so ausgesetzt in so ein Projekt rein, und hinterher das Gefühl haben, so eigentlich ist das ein bisschen schade, dass da so wenig draus passiert, und gar nicht so genau wissen, wie kriegt man das jetzt übersetzt in bessere Produkte, oder wie kann man den Leuten dabei helfen, und dann haben wir nochmal draufgeguckt, und gesagt, wir haben ja auch einen kompletten Prozess für sowas, wie sowas geht, wo wir den Leuten das auch sehr schnell und sehr einfach auch zeigen können und das mit denen machen, und wenn die das machen, dann kriegen die das auch hin, und dann haben wir überlegt, okay, dann lass uns doch mal gucken, vielleicht sind da noch mehr, die da zu sich auch austauschen wollen, die das auch lernen wollen, die diesen Prozess auch kennenlernen möchten, um ihn anwenden zu können, und sich einfach mal auszutauschen, hatten diese Idee, da einen Retreat zu machen, das kannst du gleich nochmal erzählen, was da genau dahinter steckt, ich wollte noch kurz anmerken, dass wir da natürlich auch einen eigenen Research gemacht haben und festgestellt haben, jo, da scheint es schon noch ein paar mehr zu geben, die das auch genauso für sich erfahren haben, und es gibt aber auch andere, die das Problem überhaupt gar nicht haben, die sagen, das ist keine Schwierigkeit, bei uns fluppt das so durch, ich habe aber trotzdem Bock auf einen Austausch, auch wenn das nicht unser Problem ist, weil wir machen das hier dreimal im Jahr inzwischen selber, und kriegen das wunderbar hin, da Produkte draus zu machen, oder Marketing, oder was auch immer.

Was war dann die Idee zu dem gemeinsamen Projekt?

Das JTBD Praxisproblem mit dem Transfer

Jan: Ja, also genau, ich habe dann ja mir von dir zeigen lassen, was bietet er überhaupt, also weil, ich kam ja so aus der Geschichte, ich will seit 2013 eigentlich Jobs-to-Be-Done machen, und mittlerweile glaube ich schon, dass wir tatsächlich irgendwie ein Problem von Praxis, also ein Praxisproblem, Theorie ist immer schön und gut, und die Geschichten sind im Nachhinein immer leicht erzählt, aber wie mache ich es denn jetzt selber praktisch, und dann haben wir zusammen Interviews gemacht, in deinem Projekt, und dann habe ich mir von dir einmal den Prozess zeigen lassen, wie kommst du eigentlich von Interviews am Ende hin, zu einer Art von, ich nenne das mal Synthese, Zusammenfassung, oder das, was am Ende halt rauskommt, und das Problem bei solchen Synthese-Prozessen ist ja, so kenne ich das, dass man alle abhängt.

Das heißt, ich mache, und das ist früher auch bei den Studien bei Xing gewesen, da sind da 50 Interviews, und am Ende kriegst du drei Slides mit irgendwelchen Ergebnissen, und keiner versteht, was das eigentlich sein soll, weil du den Prozess nicht mitgegangen bist.

Und das hatte ich bei dir auch vermutet, also ich habe das sehr kritisch angestellt, aber dann habe ich halt gemerkt, ich habe dann mit einer deiner auch Kolleginnen gesprochen, die ein Beispielprojekt auch hatte, da habe ich mir das von ihr mal zeigen lassen, das verdichtete tatsächlich eben.

Peter: Die Katharina, die gerade ihre Masterarbeit dazu geschrieben hat, wir gucken mal, ob wir uns dann noch mal dazu hinreißen lassen, dann ein Buch zu schreiben.

Es scheint tatsächlich auch in der Forschung, überhaupt in der Literatur, es scheint es nahezu keinen sonst zu geben, der irgendwie so einen schlüssigen Prozess hat.

Also wir haben nichts dazu finden können bisher, was mich offengestanden, ein bisschen gewundert hat.

Jan: Genau, die Katharina, die hat mich gefragt, kannst du mir beim Prototyping helfen?

Ich weiß gar nicht, wie das so, ja, ein bisschen ausgetauscht.

Und dann habe ich mir halt ihr Prozessergebnis halt angeschaut und überraschenderweise konnte ich es lesen.

Peter: Verrückt!

Ja, und wenn du dir das, wir machen das ja heute oft, dann Miro oder Miro oder was auch immer, wenn du so ein Board auszoomst, dann ist das extrem viel, sehr, sehr viele einzelne Daten, die dann am Ende verdichtet werden, wie so ein Trichter.

Am Ende kommt dann eine Sache raus.

Aber ich konnte das verstehen, was sie mir gezeigt hat.

Das heißt, ich konnte es schlüssig nachvollziehen, ohne in den Prozess mitgegangen zu sein.

Das ist genau der Punkt.

Was macht sie hier?

Wieso ist das jetzt für diese Zielgruppe Kundennutzen?

Wieso ist, also die Kundensprache war da drin.

Sie konnte mir relativ gut erklären, was sie jetzt als nächsten Schritt machen will.

Und ich konnte diesen Schritt mitgehen.

Und das ist ja genau der Punkt.

Ich war ja in der Perspektive von einem Außenstehenden.

Peter: Vielleicht ein Product Developer oder?

Jan: Ich war im Grunde in der Perspektive meiner Kunden.

Und da kommt dann jemand und sagt, hier, das ist das Researchergebnis.

Mach jetzt was damit.

Der nächste Schritt ist der.

Und ich sage, okay, das macht Sinn.

Und du hast ja dann in deinem Prozess nicht nur einen nächsten Schritt, sondern du hast ja mehrere unterschiedliche, wirklich ganz konkrete Sachen, die man dann damit machen kann.

Und das war für mich an der Stelle neu, weil bisher habe ich entweder selber nicht genau gewusst, was ich machen soll oder es war dann eine Job-to-Be-Done-Beschreibung.

Aber das ist ja auch, eine Job-to-Be-Done-Beschreibung ist ja eben noch nicht obvious.

Obwohl, es ist klar, das ist der Job-to-Be-Done.

Okay, ich verstehe das.

Es gibt da Leute die irgendwo, so.

Aber was heißt das jetzt für meinen Laden?

Und da habe ich dann gemerkt, okay, wenn man jetzt den Peter-Rochel-Prozess nimmt, und die Arbeit bleibt die gleiche.

Das ist immer hart und anstrengend und wir müssen da durch.

Interviews sind hart und das zu besprechen.

Aber am Ende hat es sich auch gelohnt, weil wir können dann weitermachen.

Das ist für mich so der Game-Changer an der Stelle.

Und deswegen haben wir dann gedacht, okay, lasst uns doch mal irgendwie gucken, ob wir dieses Transferproblem ganz konkret nochmal anbieten, der Stelle zu helfen.

Also allen Leuten, die da irgendwo. 

Peter: Genau, um das auch nochmal klar zu machen.

Das ist mehr ein Anliegen, das ist offen.

Wir geben auch diesen Prozess als Creative Common raus.

Das ist kein Geheimnis, was wir da machen.

Also das ist vielleicht im Moment noch privat, aber es ist nicht geheim.

Jan: Es muss auch kein Geheimnis sein, weil du kannst das eh nur tun, wenn du bereit bist, die Arbeit reinzustecken.

Deswegen macht es auch keinen Sinn, das geheim zu halten, während andere das natürlich trotzdem tun.

Und dann hatten wir beide unabhängig voneinander, lustigerweise, die Idee, also ich habe die auch schon seit längerem, ich weiß nicht, wie lange du da schon hast.

Peter: Mindestens drei Jahre, seit 2017 ziemlich konkret.

JTBD Retreat

Jan: Ich hatte auch schon so eine Art Produktseminar oder Retreat, oder wie man das auch nennen will, also eine Art Minikonferenz oder so für Produktleute.

Zu diesem Thema hatte ich immer schon auch im Hinterkopf.

Und wir haben das Retreat genannt, weil geile Location und irgendwie abgelegen.

Du hattest auch gesagt, so ein bisschen inspiriert von dem einen Film.

Peter: Under the Volcano, das ist hier von den George Martin Studios, Beatles-Produzent und Police, Sting, Elton John, keine Ahnung, der erfolgreichste, Dire Straits, genau, Mark Knopfler, erfolgreichste Produzent, den es, glaube ich, je gegeben hat.

Jan: Also ein Ort, wo Leute sich getroffen haben und dann in der Abgeschiedenheit und in der umgebenden Natur den Kopf frei bekommen haben und dort dann kreativste Prozesse zu fahren, die dann zu den erfolgreichsten Alben der Musikgeschichte geführt haben.

Peter: Bis der Vulkan ausgebrochen ist und das ganze Studio plattgemacht hat.

Jan: Genau, so ein Ort wollten wir dann auch finden.

Das heißt, ein Ort, der uns ermöglicht, im Fernab von Büro und beruflichem Alltag diese wichtige Arbeit zu tun.

Am besten in der Nähe von einer Naturkatastrophe, die dann in fünf Jahren das Ganze begräbt.

Peter: Na, okay, dann müssen wir uns einen anderen Ort aussuchen.

Das wäre mir zu schade.

Jan: Vielleicht was mit Hochwasser.

Dann haben wir gedacht, wenn wir beide schon diese Retreat-Idee hatten, wollen wir das nicht einfach mal anbieten.

Und da stehen wir dann jetzt, wo wir überlegt haben, wir würden das gerne anbieten.

Peter: Genau, und sind jetzt gerade dabei zu gucken, Feedback haben wir schon.

Also Interesse ist auf jeden Fall da.

Das wird mit Sicherheit auch begrenzt sein.Es wird dann natürlich auch nochmal um Zeit und Ort gehen, was noch nicht genau geklärt ist.

Wenn da jetzt jemand dabei ist, der zuhört und sagt, da hätte ich aber auch Bock drauf und kann mir das vorstellen.

Am Ende von den Kosten her wird das ähnlich sein wie unsere Masterclasses seinerzeit.

Die waren immer so, glaube ich, um die 2000 Euro in etwa, hatten wir die angeboten.

Von der Location her ist das im Prinzip kein Unterschied.

Die Kosten, haben wir festgestellt, sind eigentlich egal, ob wir das jetzt hier in einem Coworking-Space machen, in einem Konferenzraum oder irgendwo einen Raum buchen oder ob wir fernab irgendwo eine Location buchen.

Der einzige Unterschied ist dann halt die Anreise dazu, Anreise und Unterkunft.

Natürlich, wir sind noch nicht ganz klar, wie das sich genau dann vom Budget her verhält.

Ich glaube aber nicht, dass es teurer sein wird.

Das wäre, glaube ich, schon fast eher die Obergrenze an der Stelle für sowas.

Und wer da Bock drauf hat, einfach mal laut geben.

Wir haben ja so eine Feedback-Funktion auch.

Man kann im Prinzip direkt aus dem Podcast-Player bei uns auch auf die Voicemail sprechen, eine Sprachnachricht absenden auf die Tonspur.

Da geht das oder kurze Nachricht, E-Mail oder was auch immer.

Dann haben wir euch da mit im Sinn.

Ich glaube, das wird relativ schnell voll werden, das Ding.

Jan: Und Anbietersicht, was bringen wir mit?

Peter: Was bringen wir mit?

Also, was wir gelernt haben, ist ja, dass viele tatsächlich da einen Struggle haben.

Also nicht wissen, wie können sie jetzt ihren Kunden dabei helfen, das in ein besseres Produkt zu übersetzen.

Also, um mal jetzt mal bei Produkt zu bleiben an der Stelle erst mal.

Da ist das Angebot, das komplett zu teilen, wie wir das machen, gemeinsam zu machen, vorzumachen.

Und am Schluss alles, was bei uns auf dem Menü ist von diesem gesamten Innovationsprozess, den auch zu zeigen, zu teilen, zu besprechen, Möglichkeiten zu geben, wie auch Angebote, sofern gewünscht in Bezug auf, wie kann ich meine Interview-Techniken verbessern bis hin zu, wie mache ich eine Auftragsklärung oder, oder, oder.

Die Idee ist, das ist ja auch noch nicht fest, das tendenziell eher so ein bisschen auch in so einem Unconference-Format zu machen.

Das heißt, vor Ort sich zu treffen erst mal mit Gleichgesinnten, ein Mindestlevel sollten schon Leute sein, die auch mit Jobs-to-Be-Done-Research bereits Erfahrungen gemacht haben.

Und dann zu klären, was wird genau gebraucht.

Ich glaube, da haben wir genug im Koffer.

Also, das ist ja, ich habe inzwischen, ich habe es mal zusammengezählt, es sind mehr als 700 Kunden, die wir da schon begleitet, beglückt und betreut haben, mit Teilen oder den kompletten Prozessen.

Also, da kommt schon ziemlich viel Praxis, Erfahrung aus dem echten Leben zusammen.

Und das sollte dann schon im Deibel zugehen, wenn wir da nicht was rausholen, was für jeden, der da hinkommt, auch ein echter Fortschritt ist.

Plus Netzwerk, plus Location.

Jan: Genau, und die Location ist mir tatsächlich persönlich, ja, ich habe da sehr hohe Ansprüche.

Das heißt, wir werden auch irgendwie einen adäquaten Ort finden.

Das wird jetzt kein irgendwie x-beliebiges Seminarhaus sein, sondern das ist tatsächlich schon auch für mich Teil des Angebots irgendwie, dass es sowohl was die Räumlichkeiten angeht, als auch was die umgebende Natur oder so angeht, einfach in einer echt extrem guten Location stattfindet.

Weil da glaube ich ganz fest dran, dass das der Raum…

Peter: Extrem gut im Sinne von inspirierend.

Jan: Genau, dass der Raum halt einfach wichtig ist für sowas.

Und genau, und wofür man jetzt Jobs to be dann alles anwenden kann, das können wir vielleicht noch mal besprechen.

Es gibt ja wirklich ganz konkrete, wirklich sehr einleuchtende Beispiele auch, wo es sehr konkret werden kann, auch im kleinen Rahmen.

Das brauchen wir jetzt nicht noch mal im Detail besprechen, aber das ist so, jeder kann auch seine Sachen mitbringen.

Wir können an eigenen Cases, Projekten arbeiten.

Das können wir mit NDAs irgendwie absichern oder so, wenn da irgendwie Bedenken bestehen.

Das ist tatsächlich so auch auf Augenhöhe wirklich hands on.

Also wir stehen ja für Praxis.

Was wir nicht machen wollen, ist wie auf irgendeiner Konferenz irgendeinen Vortrag halten.

Das werden wir nicht tun.

Peter: Von der Kanzel predigen.

Jan: Sondern wir kommen ja aus der Praxis und so habe ich es schon immer gehalten, dass wir nur das anbieten, was wir selber auch, was ich selber praktisch für gut befunden habe.

Kontext macht das Value Proposition Canvas

Das heißt, was werden wir nicht machen?

Nein, Spaß.

Kein Value Proposition Canvas.

Peter: Ja, doch, das spielt schon eine Rolle.

Aber es geht ja darum, wie können wir es einsetzen, sodass es richtig Sinn ergibt.

Jan: Das können wir ja noch mal als Appetizer.

Also Peter hat ja einen Weg gefunden.

Versuche mal die Stimme ein bisschen zu flüstern.

Er hat ja einen Weg gefunden, das Value Proposition Canvas zumindest in meinem Erleben das erste Mal sinnvoll einzusetzen.

Ich habe das Ding schon in x Workshops und irgendwann haben wir es verbannt.

Das machen wir nicht mehr.

Das hat immer nur verwirrt.

Aber jetzt, es gibt tatsächlich aus unserer Sicht, es gibt auch einen Ort für das Ding.

Peter: Tatsächlich, ja.

Zwar nicht ganz da, wo es im Business Model verortet ist, aber so als kleiner Spoiler, aber es gibt tatsächlich in einem anderen Buildingblock einen guten Platz dafür.

Stimmt das so?

Peter: Ja, das stimmt.

Wobei, da wo es hingehört, ist es nach wie vor.

Aber es gibt einen anderen Ort, wo es außerdem Sinn macht.

Und dann ist halt wirklich, ich glaube, das, was den Unterschied macht, ist dann auch, welche Daten kommen da drauf?

Also was genau muss da jetzt rein?

Ich glaube, ein Hauptproblem der Value Proposition, also da gibt es zwei Hauptprobleme, um das dann damit jetzt auch mal abzuschließen, ist dann auf der einen Seite, was ich erlebt habe in der Zeit 2011 bis 2015, 16, wo ich unzählige Value Proposition Design Workshops besucht habe, gesehen habe, selber veranstaltet und gemacht habe, bis hin zur Masterclass bei Alex Osterwalder, ist, dass auf der rechten Seite, wo der Kreis ist, da werden sich Daten ausgedacht zu Jobs.

Also da ist keine Evidenz, sondern da sind ausschließlich Mutmaßnungen und Annahmen.

Das ist das eine Problem.

Das haben wir damit erledigt, indem wir vorne einen Jobs-to-Be-Done-Research reinstellen und wirklich belastbares Material haben, was da drauf kommt.

Und das nächste Problem ist dann, dass da in aller Regel viel zu viel drauf ist und dann keiner weiß, was macht man jetzt damit eigentlich genau.

Und wenn wir das reduzieren, das ist mit der Schlüssel, das dann wirklich auf die wirklich absolut tagesaktuell relevanten Themen reduzieren, das impliziert eine Auftragsklärung natürlich auch, was ist das jetzt, was kurzfristig, mittel- oder langfristig ist, geht es hier um Erhaltungsinnovation, Effizienz oder marktschaffend oder Disruption oder sonst irgendwas.

Und das dann so zu selektieren, dass es passt und dann kommen da auch sehr, sehr klare Anforderungen für das jeweilige Nutzenversprechen oder Wertversprechen raus.

Jan: Ich will da auch noch einen Satz dazu sagen, dass das Value Proposition Canvas ist oft ohne Kontext.

Und das ist das, wenn du auf der anderen Seite sagst, Context creates Value, dann merkst du schon, irgendwas macht da keinen Sinn.

Das heißt, dieses Ding in Kontext zu bringen, das ist die Aufgabe und dann kann ich es auch sinnvoll füllen.

Aber das ist eben, wenn du das im Business Model einfach als eine Ebene tiefer von Value Proposition und Kundensegment nutzt und da einfach alles reinschreibst, was irgendwie matchen könnte, irgendwie so, dann ist es halt relativ kontextlos, je nachdem, wie das Business Model halt aussieht.

Und da sind wir wieder beim Jobs-to-Be-Done Thema, weil wenn ich jetzt mit Tesla komme, welche Jobs erfülle Tesla und ich hab dann einen Value Proposition Canvas und schreib da alles rein, dann hab ich eben den Kontext verlassen.

Dann hab ich den Kontext verlassen und dann ist der Value nicht mehr erklärbar und deswegen macht das Ding auch so viel Verwirrung, weil nur durch den Kontext kann ich Nutzen erklären.

Aber wie gesagt, Versprechen ist, wir haben das gelöst.

Peter: Es ist auch nur ein Werkzeug, viel wichtiger ist vorher, wie strukturierst du die Daten aus deinem Jobs-to-Be-Done Research.

Wenn du das schon nicht gemacht hast, dann hilft dir das auch nicht zu wissen, wie man dann hinterher mit einem Value Proposition arbeiten kann.

Jan: Ja, aber das Problem ist ja, ich hab viele Leute gesehen, die dann sogenannte Discoveries machen, in meinen Produktkreisen und die nehmen dann das Ding und dann, so, das ist der Startpunkt.

So, ich hab jetzt genug darauf rumgeritten.

Peter: Okay, also nochmal, um das jetzt abzuholen.

Jan: Jetzt ein Call to Action.

Get Out

Peter: Also, wenn du, liebe Zuhörerinnen, lieber Zuhörer, jetzt denkst, cool, da hätte ich auch mal Bock drauf auf so ein bisschen Urlaub arbeiten, gleichzeitig mit Fokus voll auf Kopffrei, Innovation und wie kann ich hier mehr aus meinem Jobs-to-Be-Done Research machen, dann ist das vielleicht genau das Richtige für dich.

Also, dann kurz die Fahne hochhalten, Rauchzeichen geben, Zettel unter der Tür schieben, E-Mail schicken oder uns auf das Band sprechen.

Dann merken wir dich da mit vor, nehmen dich dann mit in den Verteiler.

Wir sind halt auch gerade drin, hier gilt ja das Gleiche wie das, was wir für unsere Kunden erwarten.

Das ist noch nicht hundertprozentig fertig.

Das nächste, was wir erklären, ist dann Ort und Zeit.

Dann schon mal vormerken, dann kommst du mit in den E-Mail-Verteiler.

Ja, und das war’s. Hast du noch famous last words nach fast einer Stunde, 25 Minuten, Jan?

Jan: Ich denke mal, wer bis hierhin mitgehört hat, kriegt eh schon einen Ehrenpreis. kriegt auf jeden Fall ein großes Dankeschön von mir, dass er oder sie so lange durchgehalten hat.

Peter: Das ist ja gut, okay.

Ja, das war’s auch schon wieder für dieses Mal.

Und wenn du uns Feedback geben magst, weil es dir gefallen hat oder vielleicht auch nicht, oder du Anregungen oder konstruktive Kritik hast, dann teste doch mal unsere Sprachbox aus.

Einfach anklicken, findest du in den Shownotes, Anruf wird ausgelöst ins deutsche Festnetz nach Köln, keine zusätzlichen Gebühren.

Wir würden uns wahnsinnig freuen und ansonsten natürlich auch wie gewohnt ein Sternchen und Rezensionen bei Apple Podcasts.

Das wäre wirklich grandios.

Und dann hören wir uns hoffentlich beim nächsten Mal wieder.