We help to innovate
and upgrade your business

Wertvolle Kundenbed├╝rfnisse entdecken ist keine Zauberei! Wir sind f├╝r dich da, ruf einfach an.

Jetzt Kontakt aufnehmen
Blog

JTBD Research und Produktentwicklung

Mit Jan Milz, Jobs to Be Done Researcher und Produktentwickler

Jobs to be Done Research Marktforschung und Produktentwicklung

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:

jobs to be done podcast

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.

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.

Abonnenten erhalten jede neue Episode automatisch!

Um jede neue Episode sofort automatisch vor allen anderen auf deinen Player zu bekommen, abonniere Innovate+Upgrade 100% kostenlos! z.B. bei:

Weitere Artikel zu verwandten Themenbereichen findest du hier: