Büsra Coskuner - Impact Mapping 💍 Opportunity Solution Tree

Genau, perfekt. Und damit würde ich sagen, Büscher, dann übergebe ich gerne an dich. Dankeschön, danke, danke. Also Disclaimer, es kann jederzeit passieren, dass diese Tür aufgeht und ein kleiner Zwerg reinkommt und sagt, ich kann nicht, ich gehe nicht. Weil sie kommt gerade aus der Kita raus. Also es kann sein, dass es so auch bei mir kurz laut wird. Also sorry for that, up front. Und wie ihr jetzt schon merkt, diese Präsentation wird in meinem besten und feinsten Denglisch wahrscheinlich ablaufen. Einige Slides sind noch auf Englisch geblieben, weil ich die einfach nicht ins Deutsche übersetzt bekomme. Von daher, sorry for that as well. Aber wenn ihr Fragen habt, jederzeit reinrufen, reingrätschen, generell durch die Präsentation hindurch. Wir haben nämlich ein bisschen was zu besprechen. Dann fange ich mal auch gleich an meinen... meine Slides zu teilen. Seht ihr schon was? Kommt jetzt was? Ja, perfekt. Ja, okay, super. Ich freue mich sehr, über eines meiner Lieblingsthemen reden zu dürfen, mal wieder, und zwar über das Impact Mapping. Warum ist das eines meiner Lieblingsthemen? Weil im Prinzip funktioniert mein Gehirn fast schon im Impact Mapping. In größeren Runden, in kleineren Runden, alleine, wenn ich mir selber was skizziere und so weiter, ist... funktioniert schon in den Grundprinzipien des Impact Mappings. Deswegen spreche ich so gern darüber. Und ein Thema, das mir, oder eine Frage, die mir sehr häufig gestellt wird, ist die Frage, warum soll ich denn ein Impact Mapping benutzen, oder ein Impact Map, wenn ich doch den OpenClean Social Tree habe. Deswegen ist das nicht irgendwie so dasselbe? Was ist der Unterschied? Wie kann man die zusammen benutzen? Und meine Antwort ist immer, ja, irgendwo sind sie sich sehr ähnlich, je nach... Dem, wie man das eine oder das andere tweekt, hat man plötzlich das andere raus. Aber man kann sie auch wunderbar tatsächlich zusammen benutzen. Denn es sind nur Frameworks. Also erlaubt mir die Aussage, nur Frameworks. Wenn wir Frameworks anwenden, dann wenden wir sie nicht an, weil wir Lust drauf haben, sondern wir wenden sie an, weil die Gedanken, Strukturen, die Grundprinzipien, die hinter diesen Frameworks stecken, uns dabei helfen, eine bestimmte Aufgabe zu erfüllen. Und wenn wir von diesen Grundprinzipien ausgehen, dann werdet ihr sehen, wie wunderbar diese beiden Frameworks eigentlich zusammenarbeiten können, um Sub-Headline und Product Discovery nach der Produktstrategie auszurichten. Wir wollen ein Alignment schaffen zwischen Produktstrategie und Product Discovery. Und weil ich schon... angetönt habe, dass wir heute einiges zu besprechen haben, habe ich sogar eine Agenda kreiert, was ich sehr selten mache in meinen Talks, aber ich dachte, dieses Mal macht es mal Sinn. Und zwar machen wir eine ganz kleine Intro, warum das überhaupt wichtig ist, dass wir über dieses Thema sprechen. Dann gucken wir uns ganz kurz an, was Impact Mapping ist, damit wir ein gemeinsames Verständnis haben und was ein Opportunity Solution Tree ist und dann kommen wir in diese Verheiratung. Okay, dann gehen wir Schritt für Schritt durch. Fangen mit den Zielen an. mit den Akteuren, kommt zu den Outcomes und da findet die Verheiratung statt, bei den Outcomes. Wir reden darüber, dann ein bisschen über Kritik, die auch geäußert wird, dann ordnen wir das ein in den End-to-End-Prozess, da steht jetzt A-Model, das sagt euch jetzt noch nichts, es wird euch aber in dem Moment dann was sagen, wenn wir darüber reden und dann schließen wir den Kreis und beenden meinen Braindump. an euch. Also starten wir mit der Intro und die Intro wiederum würde ich gerne mit einer Frage an euch starten. Was glaubt ihr denn ist das Ziel von Product Discovery? Warum kommt so ein Product Coach wie ich rein und sagt, ja wie, ihr macht kein Product Discovery, das müssen wir jetzt aber ändern. Warum? Was ist das Ziel? Ihr könnt gerne einfach reinrufen oder in den Chat schreiben. Reinrufen ist wahrscheinlich besser. Ich ruf mal rein, ich würde gerne das Richtige bauen. Das Richtige bauen. Oh. Product Market Fit finden, würde ich sagen. Product Market Fit finden, rausfinden, was der Kunde will. Haben wir da noch? Oder Kundin. Was noch? Was noch? Okay, also eigentlich hat mir Sebastian schon ein paar Slides voraus meine Antwort weggenommen, aber es gibt einen Grund. Jetzt gucken wir uns mal diesen Grund an. Ich würde behaupten, ganz konkret von Product Discovery selbst, das Ziel ist Geld. Also symbolisch, weil es gibt ja auch Non-Profits, ist wirklich Geld das oberste Ziel. Das oberste vielleicht nicht, aber auch die brauchen Geld, um weiter operieren zu können. Aber es steht eher symbolhaft für Geschäftszweck. Oder nicht Geschäftszweck, das ist ein gesetzter Begriff, ein legaler Begriff. Es ist vielmehr die Ziele, die ein Geschäft hat. Es kann mal sein, wir wollen mehr Revenue machen, mehr Umsatz machen. Es kann aber auch sein, Market Share erweitern. Es kann sein, wir machen jetzt eine Expandierung in den und den Markt und das ist jetzt unser Ziel für dieses Jahr. Also, wenn wir im Business sind, haben wir gewisse Ziele, die wir erreichen wollen. Und wenn wir Produkt Discovery machen, So merkwürdig es klingt, ist unser primäres Ziel nicht, dass wir was für das Produkt oder unser höher gestelltes Ziel nicht direkt, dass wir was für das Produkt herausfinden wollen, sondern wir wollen was für das Produkt herausfinden, um eigentlich im Endeffekt zu unseren Business-Zielen hinzufügen zu können oder mit beitragen zu können. Aber wie? So, und da kam vorhin ein Punkt im Chat, Problem Space. Richtig. Das ist das eine. Product Discovery hilft uns dabei, die richtige Opportunity zu finden. Was heißt das? Wir wollen fünf von sechs Fragen und fünf von sechs W-Fragen im Opportunity Space beantworten können. Wer? Wen wollen wir ansprechen? Auf wen wollen wir uns fokussieren? Was ist unsere Target Group? Wo? Was ist der Markt? Es kann geografisch sein, es kann aber generell einfach zum Beispiel eine Industrie sein. Es kann eine Industrie sein, es kann ein Teil von einer Industrie sein. Aber die Frage ist, wo? Wann? Ist es etwas für jetzt oder ist es etwas für die Zukunft? Gucken wir uns etwas an, was jetzt gerade passiert und wollen ein Problem für das Jetzt herausfinden, was wir lösen können? Oder geht es um in drei Jahren, zehn Jahren? Vielleicht in nur einem Jahr. Was ist die Timeline hier? Was? Was ist das konkrete Problem oder Bedürfnis oder der konkrete Wunsch unserer Zielgruppe auf diesem Markt, das wir in dieser Timeline adressieren wollen, dass es sich lohnt anzugehen? Das ist warum. Diese fünf Fragen wollen wir im Opportunity Space beantworten und dann den nächsten Schritt machen und die richtige Lösung finden. Und das ist das Wie. Themen wie, was ist die richtige Value Proposition, was ist das richtige Business Model, die richtigen Kanäle, wenn wir es nicht verkaufen können, brauchen wir es gar nicht erst bauen. Was ist das richtige Messaging, um halt an unseren Kunden anzukommen? Und so weiter und so fort. Und damit sind wir zusammengefasst bei dem, was Sebastian gesagt hat, ja, das Ziel mit Product Discovery ist, dass wir das Richtige bauen wollen. Wir wollen herausfinden, was das Richtige ist. 100 Punkte, was gibt es für den Gewinner? Was geben wir ihm jetzt? Ein Freibier am Freitag. Da kriegst du deinen Gewinn. Das war Jackpot. Leider hat er es hergenommen. Die Frage ist jetzt, was ist denn das Richtige? Das wiederum kommt drauf an, wen man fragt. Wenn man Business fragt, dann heißt es, ja, baut irgendwas, das uns Geschäftsergebnisse liefert. Was auch immer es ist, es muss Business machen. Also Business ist ein allgemeiner Begriff, also Marketing, Sales, Finance, die Teams oder Departments, die wir normalerweise so unter Business jetzt uns denken würden, Operations und so weiter. Wenn man jetzt aber Product fragt, dann können wir sagen, ja, natürlich, wir müssen Produkte bauen, die unsere Kunden lieben. Bam, so, Mandra der letzten zehn Jahre. Und ich sage falsch, das ist beides nicht. Ich sage beides ist sehr one-sided. Es ist jemals, es guckt auf das Produkt und auf das, was wir machen, nur von einer Perspektive, der Business-Perspektive und der Produkt-Perspektive. Das, was wir eigentlich machen wollen, ist, wir wollen das beides verbinden. Und zwar wollen wir etwas bauen, was das Business antreibt und unsere Kunden glücklich macht. Also treibt das Business an. mit Produkten, die eure Kunden nehmen. Das ist das Richtige. Das ist das, was wir bauen wollen. Das müssen wir aber erst mal finden. Es war nicht so einfach. Also wie finden wir etwas, das unser Business antreibt und gleichzeitig unsere Kunden aber auch lieben? Im Prinzip ein Produkt, das unsere Kunden lieben und somit das Business antreibt. Wie machen wir das? Bevor wir darüber reden, noch ein paar kleine Worte über mich, wer ich bin. Cliffhanger, ich weiß. Oh, was kommt denn jetzt? Scheiße. Okay, also, ich bin die Bishra. Danke für die Intro. Ich, ja, kenne mich selbst auf LinkedIn, wenn man mich so da herumposten sieht, the no bullshit product coach und der Grund, der ist ganz einfach, ich bin Berlinerin und ich kann einfach nicht anders. Also, wenn ich denke, das ist scheiße, dann nenne ich das scheiße. Ganz einfach. Wenn ich denke, aber das ist super, dann sage ich auch, das ist super und ich bin nicht. Sag nicht hier so ein bisschen pampern und sagen, das war ganz nett. Das ist super. Also ich kann nicht anders und deswegen bin ich der No Bullshit Product Coach für Produktteams, Produktmanager und auch Produktleader. In meiner Arbeit ist es mir sehr wichtig, aufgrund dessen, weil ich die Dinge so ansprechen will, wie sie sind, abstrakte Produkttheorie greifbar und praktikabel zu machen, damit man es auch situativ anwenden kann. Deswegen habe ich eingangs von Grundprinzipien gesprochen. Und mein Ziel, mein Endziel damit ist es eben, Produktteams und Produktmanagern zu helfen, diese geschäftsrelevanten Produkte zu bauen, die ihre Kunden auch lieben. Wie mache ich das? Ich bin auf der einen Seite Personal Trainer für Produktmanager, die vorankommen wollen, Team Trainer für Teams, die schon mehr oder weniger wissen, in welche Richtung, aber nicht genau wissen, wie weiter. Und ich biete auch In-House-Workshops und Trainings an, spezialisiert auf Themen, die letztendlich, und darum geht es heute, Produktstrategie mit dem verbinden, was wir am Ende bauen. Damit wir nicht einfach irgendwas bauen, sondern wir bauen etwas, was den Kunden glücklich macht und von der Strategie her in unsere Geschäftsziele hineinpasst. Hier sind einige meiner Lieblingsthemen, Impact Mapping, North Star Metric, KPI Tree, Lean-Produktexperimente und Aim-Up. Sagt euch nichts, das Letztere wird es aber nachher. Und noch viele andere Themen. So, jetzt mache ich mal wieder die Kurve wieder hoch, weil jetzt machen wir dort weiter, wo wir aufgehört haben. Wie kommen wir da hin? Das ist die Antwort. Impact Mapping. Nein, das ist nicht ganz die Antwort, aber das ist der eine Teil der Antwort. Aber wir fangen jetzt mit dem Impact Mapping mal an und bauen uns langsam so in diese Richtung der Antwort, wie wir Produkt Discovery benutzen können, um herauszufinden, was das Richtige ist, was nämlich ein Produkt ist, das sowohl Kunden lieben, als auch das Business antreibt und in die Produktstrategie so mit reinpasst. Was ist Impact Mapping? Impact Mapping ist ein visuelles Tool, ein Mapping-Tool von Gojko Atic. Er sagt, er hat es nicht erfunden. Für mich ist er der Erfinder. Und wer anfangen will mit Impact Mapping, kann auf impactmapping.org gehen. Das ist die beste Adresse, womit man einfach mal loslegen kann und man findet da alles, was man braucht. Es hilft dabei, das Business-Ziel, was ganz vorne steht, mit der täglichen Arbeit eines Produktteams miteinander zu verbinden durch fünf Elemente. Das Ziel am Anfang, dann die Akteure, Impact, Deliverables und dann in die Auftragung in Stories, wenn es dann in die Umsetzung geht. Jetzt ist es so, dass dieses Wording für... Produktmenschen ein bisschen verwirrend ist, weil es ein bisschen aus dem Projekt-Wording kommt und deswegen benutze ich selber eine angepasste Variante davon mit Wörtern, die mehr in unseren Space passen. Goal bleibt Goal, manchmal nenne ich das eigentlich Impact, aber ich will es jetzt mal nicht zu sehr auf die Spitze treiben mit der Verwirrung. Akteur bleibt Akteur oder Actor. Das, was im Original Impact ist, nenne ich Outcome, weil es das ist, was gemeint ist mit Impact. Es ist gemeint, das Verhalten des Akteurs, das wir verändern wollen, damit wir die Business-Ziele erreichen. Deliverable wird dann bei mir zu Solution oder Output. Ihr werdet merken, ich werde mal Solution, mal Output sagen, ist für mich dasselbe. Und dann am Ende geht es für mich nicht nur um Stories, sondern dass wir entscheiden, was machen wir denn jetzt. Brauchen wir vielleicht noch ein paar Experimente hierzu? Müssen wir einfach mal eine Datenanalyse starten? Wir entscheiden, was wir dann mit der Solution machen. Basierend darauf, wie wie viel Evidenz wir haben, dass es wirklich was mit der Lösung, dass diese Lösung wirklich erfolgreich sein könnte. Wie sieht ein Impact Map aus? Hier ist ein Beispiel, machen wir es ein bisschen mehr greifbar. Hier ist ein Beispiel aus einem Product Analytics Bootcamp. Die Frage war, stellt euch vor, ihr seid Airbnb und ihr kriegt jetzt diese Aufgabe. Es ist Half of the Year und ihr kriegt die Aufgabe Increased Number of First-Time Bookings in the US by 10% by End of Year. Gut, ihr habt sechs Monate, vielleicht fünf, noch immer. Und jetzt müsst ihr dieses Business-Ziel angehen. So, Aufgabe Nummer eins, überlegt euch, welche Akteure gibt es, die positiven oder negativen Effekte darauf haben könnte, dass ihr dieses Ziel erreicht. Das ist die Definition vom Actor. Interne Actor sein, externe Actor sein. Es kann Nutzer sein, es kann Käufer sein, aber muss nicht. Denkt an Airbnb und die Behörden. Die könnten jederzeit irgendwas herausbringen, irgendeine neue Regelung, was es den Airbnb-Hosts schwer machen würde, Airbnb zu vermieten. Also sprich, irgendeine Gruppe, die positiven oder negativen Effekte darauf haben könnte, dass wir dieses Business-Ziel erreichen. Das, womit sie gebrainstormt haben, waren jetzt diese vier. Zufällig sind das Käufertypen. Aber das war jetzt bei... Also es ist... Der Baum ging sogar noch größer, das ist jetzt auch nur so ein Snapshot davon, aber es sind zum Beispiel diese vier. People visiting the US for the first time, vocationers, musicians with no hotel budget, single parents looking for a temporary stay. Ihr merkt, es ist auch nicht einfach nur Nutzer, sondern es ist ziemlich detailliert auf fast schon Persona-Level, welche Art von Benutzer ist es. Es ist jetzt zufällig nur Nutzer, also wie gesagt, als möglich sein. Dann geht es um Outcomes. Welches Verhalten wollen wir denn sehen von dem Nutzer, damit der Akteur uns dabei hilft, dieses Business Ziel zu erreichen? Gucken wir auf das Erste. Und erst dann, im nächsten Schritt. Brainstorm mal Lösungen. Wie könnten wir das angehen, wie könnten wir das lösen, dass wir dem Akteur dabei helfen, dieses Outcome zu erreichen, dass wir gerne von ihm sehen würden, damit wir diese Business-Ziele erreichen. Das ist so die Gedankenkette. Dann gibt es auch eine Art und Weise, wie man so einen Pfad liest. Das ist so quasi der Pitch. Wir glauben und das ist eine Annahme, deswegen lesen wir es als Annahme. Das jetzt mal auf Englisch, das kann man natürlich auch in Deutsch übersetzen. So, jeder Pfad ist eine Annahme. Solange wir die Connection dazwischen nicht wirklich mit Evidenz nachgewiesen haben, ist es eine Annahme. So. Jetzt habe ich erwähnt, dass ich gesagt habe, ja, jetzt brainstorm mal Solutions. Okay, wir überlegen uns einfach mal was. Meinst du mit Annahme gleich Hypothese? Nein, mit Annahme meine ich Annahme. Also, als Frau eines Wissenschaftlers muss ich sagen, dass Annahme und Hypothese nicht dasselbe ist, aber ich weiß, dass wir in der Produktwelt es sehr gerne als dasselbe benutzen, aber eine Annahme liegen oft mehrere Hypothesen, oder hinter einer Annahme liegen oft mehrere Hypothesen, und eine Hypothese kann man durch verschiedene, mehrere Experimente... Das ist auch wieder ein Baum, ich liebe Bäume, genau. Also deswegen, nein, Annahme und Hypothese ist nicht das, das ist eine Annahme. So, jetzt ist natürlich die Frage, Lösungen, wie kommen wir auf Lösungen? Brainstorm, ja genau. Woher wissen wir denn, wonach wir eigentlich suchen sollen, wenn wir Lösungen finden wollen? Und da kommt jetzt der Opportunity Solution Tree ins Spiel. Was ist der Opportunity Solution Tree? Ganz kurz, ist auch ein Baum. Ich habe schon erwähnt, dass ich Bäume liebe. Dieser Baum fängt aber mit Product Outcomes an. Nicht mit einem Business-Ziel, sondern mit einem Product-Ziel. Dann... gehen wir in Interviews und Research und so weiter und dann finden wir verschiedene Opportunities, brechen diese hinunter in Sub-Opportunities, bis wir auf ein Level kommen, wo wir sagen, okay, das ist klein genug, dass wir wissen, wir könnten einen Einfluss darauf haben. Es ist groß genug, dass es uns genug Raum gibt, um zu gucken, welche Lösung für diese Opportunity eigentlich oder Sub-Opportunity eigentlich. gut wäre. Das heißt, wir befinden uns auf Blätterlevels, sind diese drei, diese zwei und wieder diese drei, suchen uns eine Sub-Opportunity aus, die wir glauben, einen großen Impact haben zu können und überlegen uns dann Lösungen und haben am Ende noch Solution-Experiments, um zu validieren, ob diese Lösung wirklich eine gute ist oder nicht. Ich habe vorhin über meine Tochter gesprochen. Meine Tochter ist jetzt zweieinhalb und sie hat gerade mit dieser wunderschönen Phase angefangen. Hä? Wieso denn? Warum? Und 5 Millionen Mal das Warum-Spiel. In die erwachsene Sprache übersetzt die Frage ist, wo kommt das eigentlich her, dieses Product-Outcome? Also Theresa Torres sagt, es fängt mit dem Product-Outcome an. Kriegen wir das her? Scheiße. Sie sagt, ja ist doch klar, aus dem Business-Outcome. Okay, danke. Wie kommen wir jetzt vom Business-Outcome zum Product-Outcome? Macht ja Sinn. Das Ziel ziehen wir uns ja nicht irgendwo her aus den Haaren herbei. Das muss schon von irgendwo kommen. Und das kommt aus einem übergeordneten Ziel, was das Business Outcome ist. Um vom Business Outcome zum Product Outcome zu kommen, gibt es jetzt mehrere Möglichkeiten. Jetzt gucken wir es mal kurz an. Wie verdammt nochmal kommen wir da hin? Man kann ein KPI-Tree benutzen und den verbinden mit dem Baum, der aus einer North Star Metric Herleitung kommt. Ja, schon wieder Bonn. Ich liebe Bonn. Man kann aber auch einen weiteren Baum, und zwar den Userflow machen, oder den Customerflow, Customer Journey, User Journey, als Flow, als Baum, und den KPI-Tree damit mappen. Man kann ganz allgemein Driver-Trees machen, also man startet mit dem Business-Ziel und macht eine Kaskade aus Business-Outcomes, bis man auf der Ebene von User-Outcomes ist, und dann hat man Vordergrund-Outcomes. Man kann das Business-Ziel durch gezielte Fragen herunterbrechen, zum Beispiel mit Hilfe des Goals-Questions-Metrics-Frameworks oder des Goals-Signals-Metrics-Frameworks. Man kann Datenanalyse machen. Wenn man Data Scientists oder Data Analysts hat, ist das sehr geil. Das flutscht wie Öl. Ansonsten gibt es da auch verschiedene andere Tools. Man kann Korrelationsanalysen machen. Man kann Kausalanalysen machen, man kann User-Interviews machen und einfach schauen, wie die ganzen Business-Zahlen und die Produktzahlen miteinander korrelieren und wo auch Kausalität sind. Man kann brainstormen, na klar, und man kann das Impact-Mapping einsetzen. Und das Beste kommt natürlich zum Schluss. Das gucken wir uns jetzt an, wie man mit dem Impact-Mapping vom Business-Outcome zum Product-Outcome kommt. Und da kommt es zur Verheiratung. Tada! Und ich glaube, jetzt habt ihr schon alle so ein bisschen den Gedanken, ja, ja, ich weiß schon, wie das geht, ich weiß schon, wie das geht. Super, also gucken wir uns das mal an, wie es geht. Im Pipe-Mapping, jetzt fangen wir von vorne an. Wir starten mit dem Ziel. Das Business-Ziel. Wichtig im Discovery-Kontext ist, wenn ihr das Business-Ziel auswählen sollt, das ist immer ein Streitthema, okay, welches Ziel nehmen wir denn? Entweder nehmt ihr das wichtigste Business-Ziel, Das ist meistens irgendwo obvious für euch, aber wenn ihr dann die Manager fragt, heißt das, ja, die sind alle wichtig, gleich wichtig, müssen alle erreicht werden. Ist so. Gut, okay, nächster Schritt. Entweder nehmt ihr das Offensichtlichste. Offensichtlicherweise, wenn wir Berater sind, also Agency zum Beispiel, dann ist offensichtlicherweise ein wichtiges Ziel, die Beratungsstunden zu erhöhen. Das ist ein No-Brainer. Oder ihr nehmt das Komplizierteste. wo eigentlich keiner genau weiß, wie soll man dieses verdammte Business-Ziel eigentlich erreichen, weil unsere Aufgabe ist es ja auch zu de-risken. Und das können wir auch, indem wir einfach versuchen, das Komplizierteste zu nehmen, das herunterzubrechen, zum Beispiel bei einem KPI-Tree und dann ein Sub-Business-Goal zu nehmen. Je nachdem, was ihr bewirken wollt. Es muss ein Smart-Goal sein, spezifisch, weil es bei Attraktiv-Realistisch terminiert, das brauche ich nicht erklären, kennt jeder. Es muss ganz wichtig ein Business-Ziel sein. Warum unterstreiche ich das hier? Ein Impact Map, Original Impact Map, sagt auch, es muss mit einem Business Ziel anfangen. Aber es funktioniert sehr wohl auch, wenn man so ein richtig dickes, fettes Produktziel nimmt. Was ist ein dickes, fettes Produktziel? Zum Beispiel 90-Day-Retention. Versucht mal, die 90-Day-Retention direkt zu beeinflussen. Könnt ihr gar nicht. Versucht mal herauszufinden, ob ihr den direkten Einfluss mit euren Aktionen einen direkten Einfluss auf 90-Day-Retention hattet. Könnt ihr gar nicht. Es ist riesengroß. Das heißt, ein Impact Map könnt ihr sehr wohl auch benutzen, um ein Produktziel, ein großes Produktziel herunterzubrechen. Aber im Discovery-Kontext ist es sehr wichtig, dass wir tatsächlich mit einem Business-Ziel starten. Und dann wieder kann auch durch einen KPI-Tree heruntergebrochen werden. Also wenn es zu groß ist, brechen wir es einfach runter. Jetzt die Akteure. Die kommen nach dem Business-Ziel. Wichtig im Discovery-Kontext. Wenn ihr an neuen oder an einfachen Produkten arbeitet, dann wird es auf euch, es fliegt auf euch zu, es ist meistens sehr offensichtlich, welche Akteure die wichtigsten sind, da gibt es wahrscheinlich gar nicht so viele und in den allermeisten Fällen habt ihr dann am Ende dort im Discovery-Kontext eh ein Nutzer-Segment oder ein Customer-Segment da drin stehen. Ist fein. Meistens leitet euch auch eure Intuition dazu, wen ihr dahin nehmt, aber Vorsicht, nehmt es immer als Annahme. Prüft es nochmal nach, analysiert es nochmal, gegebenenfalls könnt ihr testen und wenn es dann doch die falsche Nutzergruppe war, müsst ihr halt eine andere nehmen. Im Vergleich dazu, wenn ihr an existierenden Produkten versus neu oder an komplexen Produkten versus einfach arbeitet, dann ist es ein bisschen anders. Dann müsst ihr auf gewisse Dinge aufpassen und zwar, dass der Akteur oder die Akteure, die ihr dort auflistet, einen signifikanten Einfluss auf die Zielerreichung haben, dass sie idealerweise unternehmensweit strategisch relevant sind. Zumindest aber in dem ganzen Produktbereich oder in der Abteilung. Ich gehe jetzt davon aus, dass es nicht darum geht, dass wir nur auf euer Produkt gucken. Wenn ihr nur auf euer Produkt guckt, dann ist es natürlich ein Akteur, der für euer Produkt signifikant ist. Wir reden ja von komplexen Gebieten. Und es wird wieder eine Nutzer- oder Kundengruppe sein im Kontext der Product Discovery und nicht eine interne Abteilung zum Beispiel. Ihr werdet wahrscheinlich auch hier wieder bei eurer Intimation landen, aber nochmal, es ist eine Annahme, stellt sicher, dass ihr die ein bisschen wecken könnt. Und wenn es dann doch die falsche Gruppe ist, ändert sich. So, jetzt steht Akteur aber hinter Gold. Ihr könnt aber damit herumspielen. Das heißt, ihr könnt den Akteur auch hinter Outcome stellen im Rahmen der Discovery, in der Verheiratung. Ihr könnt sogar eine zweite Level Akteur mit einfließen lassen, vielleicht sogar eine dritte, je nachdem, wie komplex euer Gebiet ist. Ihr könnt auch zuerst über Akteure sprechen und euch entscheiden, auf welches Kunden oder auf welches Segment ihr euch fokussieren wollt, um dann über Business-Ziele zu reden. Und so weiter. Also ihr könnt mit den Akteuren herumspielen und gucken, wo es am meisten Sinn macht. Das ergibt sich meistens sowieso durch die Gespräche. Jetzt kommen wir zum Knackpunkt Outcomes. Im Impact Mapping sind das Actor Outcomes. Vorsicht, beim Opportunity Solution Tree ist das ein Product Outcome. Was ist der Unterschied? Actor Outcomes kann ein Customer Behavior sein, theoretisch muss es aber nicht. Weil, wie gesagt, es kann auch ein interner Akteur sein, es kann ein kompletter Offstage-Akteur sein. Ich habe die Behörden erwähnt, Behörden sind keine Kunden, aber es ist ein Actor-Outcome, heißt, es kann ein Kunden-Outcome sein, muss es aber nicht. Wir stellen uns die Frage, welches Verhalten wollen wir von diesem Akteur, damit wir das Business-Ziel erreichen? Und die Antwort auf diese Frage ist meist qualitativ formuliert. Beispiel. Die Reisenden finden schnellstmöglich eine passende Untergruppe. Das ist sehr qualitativ worden. Also schnellstmöglich ist ein Adjektiv und Adjektive zeigen, dass es um ein Improvement geht. Product Outcome wiederum, da sagt Theresa Torres, ein Product Outcome ist ein Change in Customer Behavior. Also ist es ganz strikt ein Customer Outcome. Vielleicht auch User Outcome, fine. Aber nichts anderes. Das ist Customer oder User Phase. Es liest sich allerdings wie Produkterfolg, weil es ist mehr in Metriken formuliert als qualitativ formuliert. Beispiel aus Ihrem Blog ist Maintain an Average Product CSAT Score of 83%. Klar, wir wissen, dahinter verbirgt sich Kundenzufriedenheit und das ist sehr Customer-Centric, aber es liest sich wie Produkt fokussiert. Das ist ein kleiner Mind-Trap manchmal. So, und genau an dieser Stelle kommt jetzt auch die Verheiratung, weil der Outcome ist der Teil, wo sich jetzt beide Trees überlammen. Und zwar, indem wir den Actual Outcome in einen Product Outcome umwandeln. C-SAT, C-SAT, Customer Satisfaction Score heißt C-SAT. Also, sprich, wenn man zum Beispiel ein... Nutzer über, oder einen Kunden über ein Feature geführt, ein ganz bestimmtes Feature, dann zeigt man so ein Prompt und fragt zum Beispiel, das ist jetzt eine Variante, wie man es machen kann, wie zufrieden warst du mit dem, das war jetzt schlecht formuliert, zum Beispiel wie fehlerfrei, frictionless hat es für dich funktioniert, oder wie schnell hat es geladen, solche Fragen, die darauf hinzielen, zu verstehen, wie zufrieden der Kunde mit diesem Feature war oder mit dem gesamten Produkt. Also Customer Satisfaction Score. So, jetzt gibt es zwei Fälle, wenn wir von Actor Outcome zu Product Outcome wollen. Fall Nummer 1, der Actor Outcome ist auch gleich Product Outcome. Beispiel Increased Listening Minutes from X to Y. 1 zu 1 Product Outcome. Ist bereits eine Metrik. In OKR-Form wäre es halt Key Result. Oder aber auch, es ist qualitativ formuliert, listen to more items, aber wir wissen, was dahinter steckt. Was ist denn listen to more items? Ja klar, listening minutes increase. Also von daher, es ist so oder so irgendwie eins zu eins dasselbe wie ein Product Outcome. Also sprich, wir haben hier den Actor Outcome und es ist direkt der Product Outcome und dann haben wir unseren Opportunity Solution. Fall Nummer zwei, das ist jetzt ein bisschen heavy Folie. Ich leite euch da. durch, also keine Sorge, dass es euch nicht erschlägt. Fall Nummer zwei, wir haben mehrere Actor Outcomes, die wir dann in einer Product Outcome zusammenfassen. Beispiel, diese fünf hier, listen to more songs, listen to more podcasts, listen to items more frequently, come back to Spotify more often, binge listen. Die Konsequenz von jedem dieser Actor Outcome ist dieselbe. Die Konsequenz ist, dass der Nutzer Product Outcome mehr Minuten hört. Increased listening minutes from X to Y. Das heißt, entweder können wir jeden einzelnen Actor Outcome für sich angehen, wahrscheinlich sind die aber zu klein als Opportunities. Vielleicht aber auch nicht, weil die Alternative ist, wir fassen sie zusammen in einer Product Outcome und wahrscheinlich, also wir können diese einzelnen Actor Outcomes irgendwo als Opportunities oder Sub-Opportunities im Opportunity-Solution-Tier wiederfinden. Wie sieht das aus? Wir haben hier mehrere Actor Outcomes, vielleicht auch aus einem anderen Pfad, wenn es passt. Die werden zusammengefasst zum Product-Outcome und dann kommt der Opportunity-Solution-Tier. Da haben wir den Opportunity-Solution-Tier. Um es zu vervollständigen, kommen dann natürlich noch Solution-Experimente dazu. Erstmal Fragen soweit. Ich habe eine Frage, und zwar, du hast ja am Anfang erzählt, jetzt Product Outcome und Business Goal. Hast du da irgendwo noch einen Bezug zum Product Goal nach Scrum? Ist es irgendwas schon mal gekommen, oder siehst du das äquivalent mit dem Business Goal? Also das Product Goal bei Scrum ist ja noch immer nicht ganz definiert, was das sein soll. Jeder hat da so ein bisschen seine eigene Meinung zu, sage ich mal, seine eigene Interpretation. Wenn man Mich fragt, ich habe keine konkrete Antwort, deswegen benutze ich das Wort fast gar nicht im Kontext von Scrum. Ich benutze eher die Wörter, die halt eine konkrete Definition dahinter haben. Wenn es die Mission ist, dann ist es die Mission. Wenn es die Vision ist, dann ist es die Vision. Wenn es ein Produktziel ist im Sinne von hier, also wie beim Opportunity Solution Tree beispielsweise, dann ist das Product Goal, gleich wie Product Outcome. Ich glaube, da ist es wichtiger, dass man sich im Team erstmal darauf geeinigt hat, was man gemeinschaftlich unter Product Goal versteht, um dann sagen zu können, das ist hier oder da. Und siehst du dann Zeithorizont, also Product Outcome, in welchem Zeithorizont das erreicht werden soll? Es kommt auch immer wieder auf die Discovery. Mission an, also warum machen wir diese Discovery eigentlich? Aber das folgt meistens auch den Smart Goals. Also es muss schon klein genug sein, dass es in einen gewissen Rahmen passt. Also sprich, meistens geht es dann irgendwas in die Richtung, wenn wir jetzt quartalsweise planen, beispielsweise haben wir Timebox, die und die und die Zeit und innerhalb dieser Zeit wollen wir Ergebnisse zu den und den und den Themen wissen. Also es ist sehr wichtig, dass man die Discovery, including the time horizon. als Erwartungshaltungen auch einmal aligned bekommt, bevor man loslegt. Also quartalsweise wäre so eine Empfehlung von dir? Zum Beispiel, genau. Wenn es größere, also klar, wir reden jetzt hier über zielorientiertes Arbeiten, wir reden hier nicht über Innovation oder über Long-Term Trends oder sowas. Das sind längere Projekte. Da geht Discovery weiter und weiter und weiter. Außerdem reden wir hier gerade auch noch nicht über Continuous Discovery, weil das ist ja auch nochmal ein Punkt. Continuous Discovery hört nie auf. Der Fokus ist dann halt einfach immer woanders. Das hört nie auf. Das Ziel der Fokus ändert sich. Gut, Kritik. Reden wir ein bisschen über Kritik. Opportunity, Solution, Impact Mapping sind nicht kundenzentriert. Naja, ich rede die ganze Zeit davon, welchen Outcome soll der Actor... damit wir unser Business-Goal erreichen können. In dem Sinne ist meine Antwort, jein. Ja, ist richtig, ist nicht kundenzentriert, ist es eher Business-getrieben, sagen wir es mal, ist es Business-getrieben, wenn wir es denn so angehen, wie ich es bisher erklärt habe. So wie ich es bisher erklärt habe, ist auch die Theorie. Was habe ich gesagt? Ich mache abstrakte Produkttheorie greifbar und praktikabel. So, jetzt kommen wir mal in die Praxis. In der Theorie, Ein Schritt zurück. In der Praxis brauchen wir beides. Mal das eine, mal das andere und wir müssen die Balance finden. Das heißt, wir haben die eine Möglichkeit, das Ganze business-driven aufzubauen, wie wir es jetzt bisher gemacht haben, diese ganzen Binge-Listen, Increased Listening Minutes und so weiter und so fort. Wir wollen, dass Akteure etwas Bestimmtes machen, damit wir unser Business hier erreichen. Okay. Die andere Möglichkeit ist, das Ganze aber auch actor-driven anzubauen. Das heißt, wir machen dieses Alignment zwischen Business Goal und Actor. haben wir aber unseren Research. Wir wissen, was die Nutzer für Pains oder Bedürfnisse oder für Wünsche haben. Wir haben unsere Hausaufgabe gemacht oder wenn nicht, dann machen wir das. Wir gehen in Interviews raus, wir gehen in die Exploration, wir machen Research und finden so was wie, ich finde den richtigen Song zu meiner Stimmung nicht so schnell. Aha, was ist mit der Search nicht richtig? Kann ich die Songs irgendwie kuratieren? Drei Minuten später, so geht also eine Playlist. Das sind echte, vom Akteur entweder genannte oder durch uns beobachtete Pains oder Needs oder Wishes, die wir adressieren können. So, und jetzt kommt aber wieder der Punkt rein, mit dem wir müssen das trotzdem irgendwie verbinden, mit dem, was wir im Endeffekt erreichen wollen. Das heißt, von den Dingen, die wir herausfinden, picken wir uns jetzt diejenigen, die unsere Business-Ziele erfüllen. Die in der Richtung, in die wir gehen. auch das Richtige sind, was wir jetzt als nächstes anfassen sollen. Weil es gibt viel zu tun, es gibt viel zu fixen. Irgendwo müssen wir anfangen, irgendwie müssen wir priorisieren. Und da wir sagen, wir wollen das Business antreiben mit diesem geilen Produkt, das wir bauen, müssen wir diejenigen priorisieren, die uns dann auch dabei helfen, die Business-Ziele zu hören. So, jetzt kommen wir langsam so in den Wrapper. Warum das Ganze eigentlich? Warum sollten wir das überhaupt machen? Und da erzähle ich euch, wie ich ticke, wenn ich in ein Team reinkomme oder mit einem Produktmenschen rede, Product Owner, Product Manager, I don't care. Ich gehe durch drei Schritte in meinem Kopf. Align, Identify and Measure. Das ist das Aim, das ich ab und zu mal hier jetzt mal gebrockt habe. Worauf ich gucke ist, ich gucke, dass wir die Business-Ziele und die Nutzer-Outcomes und die Produktideen miteinander abstimmen können, um eben diese strategische Priorisierung diese strategische Priorisierung hinzubekommen. Erstmal nur das sich angucken, was auch wirklich aligned ist. Das heißt, ich gucke immer in dem ganzen Produktmanagement-Flow. Haben wir die Verbindung zwischen Product Strategy, Discovery und Delivery? Und ich gucke immer, wie werden Entscheidungen getroffen? Werden sie auf, ja, ich hatte heute mal eine gute Nacht, jetzt machen wir mal das da getroffen, meine Opinion? Oder auf Daten und Evidenzen gestützt und wird überhaupt über Annahmen gesprochen. Spricht jemand aus, ja, aber das ist jetzt aber eine Annahme, da sollten wir mal gucken. Das sind die Dinge, die ich überprüfe. Und das mache ich, indem ich das Team oder den Produktmenschen durch drei Schritte führe. Align, Identify and Measure. Das heißt, am Anfang alinen wir die ganze Business- und Produkterwartungen, so wie wir das erst gemacht haben mit dem Impact Mapping. Dann finden wir die richtigen Outcomes und Lösungen mit dem Opportunity-Solution-Tree und dann machen wir alles measurable. Wie messen wir Erfolg? Können wir es überhaupt messen? Es gibt Dinge, die kann man nicht messen und ich bin kein Fan davon, alles aufwiegen und brechen messbar zu machen, aber es ist eigentlich einfach eine Präferenz. Kann man machen, kann man nicht machen. Und brauchen wir vielleicht noch mehr Evidenz, Erkenntnisse, Daten und so weiter. Das Ganze hat zwei Seiten, einmal die strategische und einmal die taktische Seite. der strategischen Seite eben, alignen wir Business und Product. Auf der taktischen Seite, beziehungsweise in der Mitte, machen wir noch eine Roadmap-Entscheidung, welche Outcomes sind die wichtigsten, auf die wir uns jetzt konzentrieren und welche blenden wir aus, weil es gibt so viel zu tun. Dann auf der taktischen Ebene machen wir eben diese Priorisierung. Wir machen vielleicht eine Discovery, vielleicht machen wir einfach, jeder hat diese... Liste von 500 Ideen, die sich irgendwann mal angesammelt haben und dann können wir die mal durchfiltern und gucken, welche passen überhaupt zu dem Outcome, das wir erreichen. Und das wäre eine Möglichkeit. Ja, vielleicht sind es Creativity Methods oder Brainstorming, wie auch immer wir zu der Lösung kommen und wir kommen dann zu verschiedenen Lösungen. Und am Ende, wie gesagt, machen wir alles messbar und stellen sicher, dass Annahmen auch explizit benannt werden. Das ist dieses Align Identify Fashion. Ich gehe in meinem Kopf genau diese Connection durch und gucke, was fehlt, was haben wir schon, wo funktioniert es schon ganz gut, wo kann man noch ein bisschen was verbessern und so weiter. Und wenn wir jetzt Impact Mapping und Opportunity Solution Team zusammenbringen, das ist dieser mittlere Kreis, den wir uns jetzt angeguckt haben, wie ihr merkt, dann haben wir nämlich Folgendes schon erreicht. Wir haben Business Ziele, die Nutzer Outcomes und die Produktideen aufeinander aligned. Wir können also schon mal eine strategische Priorisierung machen. Wir haben die Produktstrategie und Discovery miteinander verleihen, die Delivery noch nicht, aber die Discovery haben wir schon miteinander verleihen. Und teilweise haben wir schon Evidenz und Insights, auf der wir Entscheidungen treffen und machen Annahmen sichtbar. Teilweise haben wir das dann auch schon geschafft. Also Align und Identify haben wir, mehr so noch nicht. Das kann man dann noch nachholen. Muss das Ganze sein? Müssen wir das alles machen? Nö. Eine Empfehlung. Alles, was wir hier lernen, die ganzen Frameworks, die ganzen Tools, es sind Empfehlungen. Wir nutzen sie, wenn sie passen und wir nutzen sie nicht, wenn sie nicht passen. Vor allen Dingen müssen wir jetzt unbedingt Impact Mapping und Opportunity Station zusammen nutzen. Auch wieder nö. Wie gesagt, Impact Mapping, also die beiden sind sich sehr ähnlich. Impact Mapping ohne einen Actor und mit Product Goals statt einem Business Goal. ist fast schon ein Opportunity Solution Tree. Wenn man die Outcomes dann entsprechend wie Opportunities formuliert, ist es ein Opportunity Solution Tree. Gleichzeitig ein Opportunity Solution Tree mit einem Actor und einem Business Ziel vorne ist ein Impact Mapping. Also, so what? Also, ihr könnt natürlich das eine oder das andere benutzen. Ihr könnt aber auch statt dem Impact Mapping irgendwas anderes nutzen. Ich habe euch Möglichkeiten gezeigt, wie man von Business Outcome zum Product Outcome kommt. Ihr könnt andere Möglichkeiten benutzen, um zum Product Outcome zu kommen. Deswegen, nein, ihr müsst es nicht machen. Es ist einfach eine sehr einfache Methode, um Dinge visible zu machen. Alles, was sichtbar ist, darüber kann man sprechen, darauf kann man zeigen. Und das kann man zu Diskussionen, zur Sprache bringen. Und vor allen Dingen, was das Wichtigste an dem Ganzen ist, warum ich euch das gezeigt habe, ist, dass wir Product Discovery mit Navigation machen und nicht im Blindflug. Weil der Blindflug ist das Schnellste, wie wir das Vertrauen unserer Stakeholder und Manager verlieren können und wir nie wieder den Space bekommen, um wirklich ordentlich Discovery machen zu können. Deswegen macht Product Discovery Navigation statt im Blindflug. Wir haben alle das eine Ziel. Genau, Sebastian, genau. Wir wollen das Rüstige werden. Vielen, vielen Dank. Ich glaube, ich bin ziemlich über die Zeit. Es tut mir leid, ich habe mich einfach so gehen lassen, weil es zu meinen Lieblingsthemen gehört. Wir können generell jetzt gerne diskutieren und ansonsten, klar, wenn ihr euch mit mir in Verbindung setzen wollt, über das Thema sprechen, über andere Themen sprechen, wenn ein sehr offener Mensch, könnt euch gerne mit mir connecten, am besten auf LinkedIn. Genau. Ansonsten habt ihr auch sonst so meine Daten. Ich glaube, das muss man jetzt alles ein bisschen verarbeiten für die, die dieses zumindest Impact Tree oder Impact Mapping und Opportunity Solutions relativ neu sind. Aber wie man sieht, ein richtig mächtiges Tool auf jeden Fall. Vor allem auch noch mit dem, wie man da hinkommt. Das eine Slide fand ich echt sehr interessant. Welches? Jetzt verlasse ich noch ein paar den Raum. Also für die, die vielleicht noch gerne Feedback geben wollen, ich habe noch ein Formular, also einen Teil in den Chat gepostet. Gerne noch Feedback geben und für alle anderen, wie du schon gesagt hast, gerne in die Fragerunde gehen. Ihr könnt entweder in den Chat oder unmuten und direkt die Frage stellen. Ich glaube, das wäre auch vollkommen in Ordnung. Ja. Ich habe tatsächlich eine Frage. Hast du vielleicht ein Beispiel? Du hattest vorher ein paar Beispiele gezeigt von den Outcomes und dann kam ein Slide mit Opportunities, Sub-Opportunities und so weiter. Da fehlt mir so ein bisschen der Unterschied oder was jetzt ein konkretes Beispiel für eins dieser Outcomes als Sub-Opportunity wäre oder als Opportunity. Genau der, ja da. Was der Unterschied zwischen Opportunity und Sub-Opportunity ist, habe ich das richtig verstanden? Ja, oder vielleicht bei dem Slide hier, da steht jetzt ja links diese Actor-Outcomes, die verstehe ich soweit, die sind, ja, aber rechts bei Opportunity ist der Actor-Outcome gleichzeitig die Opportunity jetzt in dem Fall? Ist das so zu verstehen oder? Kann, kann, genau. Also in dem Sinne, jetzt beim, wenn man so Interviews führt zum Beispiel, Fangen wir vorhin an. Also sagen wir, wir haben das Produktziel, das Product Outcome, increase listening minutes from X to Y. Und dann fing mal ein Interview an und dann hört man all diese Dinge so wie, ja, also wenn ich da zum Beispiel meinen Sport mache und dann bin ich auf dem Laufband, dann möchte ich eigentlich... noch mehr Songs hören und ich möchte, dass sie hintereinander ablaufen. Dann haben wir schon zwei von denen, also Listen to More Songs und Binge Listen. Ich möchte eigentlich, dass sie hintereinander ablaufen, weil ich habe keine Hand frei. Ich kann ja nicht meine Hand wegnehmen und dann irgendwie die ganze Zeit rumgucken, was ich denn jetzt als nächstes hören möchte. Das heißt, wir haben da schon zwei Opportunities gehört. Deswegen ja, diese können wir entweder eins zu eins in Opportunities umwandeln. Also ich persönlich würde die als Opportunity sogar direkt sehen und nicht als Sub-Opportunity. Wir können aber auch, wenn es etwas ein bisschen größer ist, zum Beispiel, also come back to Spotify more often, würde ich jetzt vielleicht nicht unbedingt als Opportunity sehen, weil das ist wirklich sehr businessgekriegen. Wir wollen, dass sie zurückkommen. Aber zum Beispiel listen to more podcasts. Wenn dann jetzt jemand sagt, eigentlich hätte ich Bock drauf. Warum soll ich denn zwischen so vielen Apps herum wechseln? Das ist doch alles Audio. Ich habe Audiobook, ich habe Podcast App, ich habe dann noch meine Musik App und mir ist eigentlich alles viel zu blöd. Dann könnte man die Opportunity dahinter sehen, aha, mir ist es zu blöd, zwischen so vielen Audio Apps herum zu wechseln. Opportunity, Überlegung, könnte da vielleicht was dran sein, dass wir auch andere Items aufnehmen als nur Songs. Okay. Ein Level deeper, sagt die Person sowas wie, ja, also vielleicht nicht unbedingt Audiobooks, weil das ist schon ein bisschen was anderes, aber Podcast, warum muss ich denn wirklich zu einem anderen Podcast-App wechseln? Okay, dann haben wir schon mal eine Sub-Opportunity von dieser großen, eine Sub-Opportunity ist Podcasts reinzubringen, eine Sub-Opportunity ist Audiobooks reinzubringen, eine Sub-Opportunity ist vielleicht noch irgendwas anderes, was mir jetzt nicht einfällt, was auch ein Audio-Format wäre. Und dann hören wir... wie mehrere Leute Podcast erwähnen, aber keiner irgendwie so richtig Audiobook erwähnt, dann wissen wir, hinter der Opportunity Podcast steckt was dahinter. Das ist dann die Sub-Opportunity von der größeren Opportunity, die da hieße, andere Formate reinzunehmen. Macht das so ein bisschen Sinn, so als Beispiel? Ja, auf jeden Fall. Also kommt auf jeden Fall drauf an, was der Beraterantwort kommt drauf an. Aber es ist tatsächlich so, wenn ich es richtig verstanden habe, vielleicht auch je abstrakter der Outcome, desto eher verbirgen sich vielleicht auch mehrere Opportunities oder Sub-Opportunities drunter. Genau, ganz genau so ist es. Das ist dann die Kaskade, die wir dann hinführen müssen. Genau. Da war, glaube ich, noch eine Frage im Chat, oder? Ich nehme meinen Cursor nicht. Hilfe. Genau, also ES hat noch eine Frage gestellt. Du kannst sie gerne direkt stellen. Oder ich lese sie vor, wie es dir lieber ist. Bitte vorlesen. Okay. Was war die ungewöhnlichste Kennzahl, Experiments und so weiter, mit der einer deiner Kunden eine Annahme messen, verifizieren konnte oder wollte? Wir haben lange überlegt, ob wir das machen sollen. Wir haben es ein bisschen mit Humor genommen. Danke, danke Grace. Es geht um eine Maschine, wo jetzt neue digitale Lösungen geschaffen werden für diejenigen, die die Maschine instand halten sollen. Und es ging ganz, also nicht ganz, ich darf ja nicht so viel sagen, NDA und so. Es ging um eine Lösung, also ich habe tatsächlich mehrere solcher. Das fällt gerade und merke ich, wie sage ich, genug ohne zu dir jetzt. Also es geht um eine Lösung, wo es darum geht, für diese Personen, die diese Maschine instand halten, das Leben verbessern zu. Das geht irgendwie in die Richtung oder die Annahme, die zu testen war. Also wir glauben, dass die Personen, die das instand halten, wirklich diesen Pain haben. Woher wissen wir das, dass sie wirklich diesen Pain haben? Wir wissen, was wir messen ist, wir machen ein Interview und wir messen die What the Fucks per Sekunde. Also quasi so ein bisschen wie vom Coding abgeguckt in die Richtung, ja jedes Mal, wenn diese Person, also nicht per Sekunde, aber pro Interview, jedes Mal, wenn jemand sich genau über dieses Thema ärgert, wie auch immer die sich... äußern, machen wir einen Strich und dann reden wir mit so und so vielen Leuten und dann gucken wir, wie viele von denen, die wir geredet haben, mindestens fünf Striche haben oder jetzt habe ich jetzt mal so fünf gesagt, also x Striche haben. Ich glaube, wir haben gesagt, mindestens zwei Striche haben wir gesagt, glaube ich. Nee, nee, Moment, wir haben gesagt drei Striche, aber wir haben zuerst gesagt zwei, naja, okay, eins kann Zufall sein, zwei kann auch Zufall sein, drei ist kein Zufall mehr. Genau. Danke fürs Teilen. Gerne. Hat es funktioniert auch dann? Hat es tatsächlich funktioniert. Es war wohl ein Thema, das den Leuten sehr auf den Nerv gegangen ist. Cool, super spannend. Ich habe auch noch was. Also auch nochmal danke von meiner Seite, weil ich fand, ich muss sagen, ich finde dein Approach total systematisch. Das mag ich total gerne. Und auch super visuell. Das passt auf eine Seite und das ist für mich immer so der... Das Killer-Argument für egal, was ich mache. Wenn man gleich auf einen Blick erfassen kann, ist es meistens gar nicht mal so verkehrt. Rein praktisch, wie oft pflegst du das eigentlich und wie oft und mit wem? Den Impact meint man so? Ja, oder die Kombination hier. Die Kombination ist ja eigentlich, wenn du es in Kombination machst, ist es meistens erstmal dieses Alignment-Pfad und das ist oft erstmal so ein One-Off-Ding. Also sprich, wir wollen erstmal verstehen, was jetzt unser Fokus für den Product Discovery für dieses Thema ist, ob es jetzt ein Quartal ist oder halt einfach generell thematisch und dann schmeißt man den ersten Teil meistens auch wieder weg. Meistens guckt man da nicht nochmal drauf. Wenn man will, hat man davon irgendwo eine Kopie, um halt später nochmal zeigen zu können, wie man darauf gekommen ist und dann ist gut. Wenn man aber einen Impact Map jetzt selber macht, dann kommt es tatsächlich wieder drauf an, ob man den pflegen möchte oder nicht. Es gibt wieder so One-Off-Sachen, wenn ich mit jemandem zusammensitze und dann diese Fragen stelle, okay, wer ist das überhaupt, auf wen wollen wir uns konzentrieren, okay, was sind jetzt aber die... die Outcomes sind. Also wenn wir das einmal so scribbeln, ist das meistens auch wieder weg, weil es einfach darum geht, dass wir ein gemeinsames Verständnis von denen haben, warum wir was machen, was wir machen. Wenn wir aber das Ganze benutzen, um einen generellen Discovery anzustoßen, oder sagen wir es mal so, immer dann, es gibt verschiedene Cases, wenn man einen Impact Map macht, immer dann, wenn die Konsequenz, dass man mit seiner Entscheidung falsch liegt, sehr hoch ist, ob es jetzt im taktischen Spaces oder im strategischen Spaces ist, egal, immer dann, wenn das Risiko hoch ist, der Konsequenz, dass man falsch liegt, dann empfiehlt es sich, den Tree einmal anzufangen und mit jedem Learning abzudaten. Man muss aufpassen, er kann sehr schnell sehr groß werden, deswegen muss man sich halt immer nur so auf die wichtigsten fokussieren und sagen, wir glauben gerade, dass das die drei wichtigsten Outcomes, Actors sind. Für diese Actors glauben wir, dass diese drei die wichtigsten Outcomes sind. Von diesen neun Outcomes glauben wir, dass eigentlich nur diese drei hier relevant sind und die packen uns jetzt auf die Vogue. Und dann eben... Okay, cool. Also, ich habe jetzt rausgehört, es ist oft schon im Moment, um Sinn zu machen, um sich zu connecten, um vom gleichen Ding zu reden und Fokus reinzubekommen. Und wenn es wirklich kritisch ist, dann pflege ich das Ding auch. Genau. Und man kann es sogar wunderschön in Reverse anwenden. Also im Prinzip, wenn man hier so ein Impact Map hat. Nein. So weit hinten. Genau, also wenn man hier zum Beispiel so ein Impact Map hat und dann kommt ein Stakeholder und kommt und sagt, ah, ich finde, wir sollten list host from different regions in the US. Ich weiß mal, okay, warum denn? Aber man fragt eben nicht, über welches Problem lösen wir damit, sondern, okay, danke, lieber Stakeholder. Ich sehe, du hast dir Gedanken gemacht. Würdest du mir einfach mal erzählen, damit ich weiß, ob wir das richtig machen? Was erhoffst du dir davon, wenn wir das gelauncht haben? Für wen wird es wichtig sein, dieses Feature und inwiefern? Was wird es bei dieser Person bewirken? Dann haben wir direkt die Konversation über Actors und Outcomes zu dieser Lösung und dann haben wir eine bessere Verhandlungschance. Das heißt nicht, dass es eine Garantie ist, dass das dann auch funktionieren wird, aber wir können dann eher mit anderen Lösungen kommen, als dass wir sagen, ja, das ist doch totaler Bullshit, wo hast du denn deine Zahl? Das funktioniert nie. Ja, total geil. Da kannst du auch sagen, sorry, passt gerade nicht in den Fokus. Genau. Uns wurde gesagt, unsere Business-Ziele und Business-Ziele kommt auch wieder drauf an, ob wir auf dem taktischen oder strategischen Level sind. Das kann Department-Ziel sein. Das kann Team-Ziel sein. je nachdem, wo der Businessziel herkommt. Man kann dann immer sagen, ja, du, unser Departement-Ziel ist gerade das. Wir haben herausgearbeitet, dass wir uns jetzt auf diese Outcomes konzentrieren. Das ist unser Roadmap. Es tut mir leid, es passt nicht darauf. Vielleicht nächstes Mal. Danke. Oder auch Segmente. Apple arbeitet ja sehr stark mit Segmenten, die sagen, das ist unsere Fokus-Persona für die nächste Edition. Sorry, passt nicht in unsere Fokus-Persona. Es ist nicht der Pain, den die haben. Es ist der Pain, den die da haben. Aber auf die konzentrieren wir uns gerade nicht. Perfekt. Du musst nicht Nein sagen, als wie auch immer, Product, Mensch, sondern kannst argumentieren. Ja. Sorry, eins muss noch loswerden, was ich total cool fand. Auf Folie 64, dieses Business-Driven versus Actor-Driven. Ich fand das phänomenal, weil wenn man sich jetzt so Goal-Oriented Product Robles anschaut, so Pichlermäßig, der hatte auch diese Compound-Goals, dieses immer, ich lasse mal Zeit. Genau, der hatte auch immer zwei verschiedene Ziele, nämlich für dein Business und für den Kunden und versucht ja auch irgendwie zu verheiraten. Und das ist immer die Frage, wie passen die Dinge zusammen? Und so bin ich eigentlich, ich fand es ganz smooth, diese Kette da hinzukriegen. Vor allen Dingen das hier, das finde ich halt immer sehr, sehr schön. Ich meine, ich sage die ganze Zeit, ja, na klar, wir wollen, dass die etwas machen, aber dann müssen, also sollten wir, nichts ist ein Muss, aber wir sollten dann halt auch, selbst wenn wir business-driven. das Ganze angehen und wir gesagt haben, ja klar, wir wollen das come back to Spotify more often, also typisch business-driven actor outcome, we want them to come back to Spotify more often. Okay, jetzt gehen wir mal in unsere Kammer und gucken mal, was wir da jetzt schon herausgefunden haben, also selbst da können wir dann sagen, ja, die und die und die Pains, haben wir herausgehört, die und die und die Wünsche haben wir herausgehört. Wir denken, dass die Pains und die Wünsche, also das, was hier zum Beispiel genannt wurde, sehr gut uns dabei helfen. Unsere Annahme ist, dass diese, wenn wir diese Pains und Wünsche angehen, werden sie zu Spotify, also werden sie come back, then they will come back to Spotify more often. Also im Prinzip können wir sogar diese Business und Actor-Driven Outcomes miteinander vereinen. Ist das ein starker Match, finde ich. Und dann hängst du auch nicht in der Luft. Weil oftmals kommst du mit Business-Zielen daher und sagst, okay, make it happen. Genau. Okay. Andere Fragen? Genau, hat noch jemand? Noch Fragen, Anmerkungen, Kommentare? Ja, Sepp. Eine ganz kleine Frage hätte ich dann vielleicht doch noch. Wie vermeidest du denn eigentlich jetzt Bias in deiner Map? Das kann man nicht. Ich bin der Meinung, Bias kann man nie vermeiden. Auch diejenigen, die sagen, ja, das sind jetzt die 10 Rules, 10 Tricks, um komplett Bias-free, gibt es nicht. Wir sind alles Menschen und wir haben alle Biases und die werden wir nie rauskriegen. Was man aber machen kann ist, und deswegen finde ich auch die Methode so stark, was ich erwähnt habe, alles, was wir visible machen können, darüber können wir sprechen. Das heißt, wenn wir einmal alles ausgemappt haben, Oder auch währenddessen, also es kommt drauf an manchmal, also ich spreche immer, in einem Impact Mapping Workshop spreche ich immer von Knowns, Beliefs und Assumptions. Was wissen wir, was glauben wir zu wissen und was ist eine pure Annahme? Und in dem Moment, wo ich das frage, ist das ein Known, Belief oder Assumption? Ich habe eine Definition dahinter, was ist was? Und dann heißt es, das wissen wir aber, da haben wir Zahlen zu. Das glauben wir zu wissen, das ist eine Annahme. Und in dem Moment, wo jemand sagt, das ist eine Annahme. Dann haben wir eine Grundlage, um darüber zu sprechen. Und ich sage noch was, manchmal wollen wir auch eine Annahme hinterherlaufen, weil wir annehmen, dass das der stärkste Pfad ist und wir wollen gucken, ob was da dran ist. Und das ist okay. Also das können wir machen. Wichtig ist, dass wir nachfassen, dass wir analysieren, dass wir eine Evidenz bringen und so weiter. Und wichtig ist, dass sich alle im Raum dessen bewusst sind, dass es eine Annahme ist. Wahrscheinlich hast du auch gute Diskussionen. Wenn jemand sagt so, das ist klar, und jemand anderes sagt so, nö, ist das überhaupt nicht. Ich würde da vielleicht dranhängen, auch noch eine ganz kurze Frage, mit wem machst du das eigentlich, weil das ist ja dann ziemlich interessant, wer der Teilnehmerkreis von so einem, ich weiß nicht, Workshop oder ist. Das wiederum kommt drauf an, also strategisch versus taktisch und wie stark ist das Risiko oder die Konsequenz. wenn wir falsch liegen mit unserer Entscheidung. Je nachdem, wie ich das mitbekomme, kommt dann eine entsprechend andere Zusammensetzung bei raus. Was ich generell sehr häufig mache, ist, wenn ich in so einem, wenn ich jetzt wieder meinen Gedankenprozess dann nehme, in dem Alignment-Part habe ich es gerne, dass auch Stakeholder mit tun, also es nicht einfach nur das Produktteam ist, sondern da wollen wir ja das Alignment schaffen zwischen Management-Ebene und dem Produktteam. Kommt drauf an. Wenn es das Department-Ziel ist, dann reicht es vielleicht auch, wenn der Department-Leader dabei ist und dann eben einige wichtige Akteure im Produkt-Team beispielsweise. Aber es ist wichtig, dass da die Leute mit dabei sind, die dann Steak im Business-Goal haben und im Product-Outcome haben und die auch Hintergrunddaten mitbringen können zu den drei Elementen. Bei der rechten Hälfte. Das mache ich meistens viel lieber mit einem cross-functional Produktteam. Wir hatten es aber auch schon, und es war auch ziemlich geil, dass jemand vom Marketing oder vom Sales mit dabei war, also gerade vom Sales, und wenn die nämlich den Teil mitmachen, dann merken die halt auch, wie schwierig es ist, wirklich gute Ideen zu finden und wie schwierig es ist, die Opportunitäten auch als solche zu deklarieren. Also es ist schon auch, Ganz nice, deswegen kommt es halt so ein bisschen drauf an. Und klar, das Measurement und die Experimente, also das Measuring für dieses Strategic Alignment machen wir dann auch noch mit den Stakeholdern zusammen, also hier diese Outcomes, Stichwort OKRs. Ich bin kein Fan von OKRs, aber für manche Sachen sind die nützlich. Und deswegen eben die Outcomes hier measurable zu machen, das machen wir dann auch oft mit den Stakeholdern mit im Raum. auch Produktmenschen mit dabei. Wir wollen ja nichts über den Zaun werfen. Das ist schon cross-funktional. Und hier wiederum machen wir das eher mit dem Produktteam, auch die Experimente und so weiter. Und wenn ich Produktteam sage, dann meine ich halt wirklich das Cross-Funktional-Team. Also mit Entwicklern, mit Researcher, Design, also je nachdem, wie das Cross-Funktional-Team zusammensetzt. Also die Antwort wieder, it depends. Ja, danke dir. Aber OKRs hast du jetzt gemeint, das siehst du dann in dem Bereich Outcomes. Wenn du OKRs definierst, dann ist auch deine Quelle dann die Outcomes, die ihr definiert habt. Outcomes, auch in den Business Goals stecken, OKRs, also vor allen Dingen die Objectives stecken da drin in den Business Goals. Und Outcomes kann man in OKRs umformulieren. Super, danke dir. Wer hat weitere Fragen? Die Grunde ist schon ein bisschen kleiner geworden, aber je kleiner, desto mehr Fragen. Die, die jetzt rausgegangen sind, haben schon ihre Fragen alle gestellt oder zumindest beantwortet bekommen mit einer Präsentation. Entweder war die Präsentation so klar, dass alle Fragen gequert sind oder so schwierig zu verstehen, dass alle nur noch Brain Exposions haben. Du teilst noch die Präsentation mit mir wahrscheinlich, oder? Dann kann ich die mit dazu stellen zum Video. Das ist immer hilfreich, finde ich. Und ich glaube, zeitlich sind wir gut drin. Sepp, was meinst du? Sollen wir es dann calling the night? Ja, let's call the night, ja. Let's wrap it up. Ja, super cool. Vielen herzlichen Dank nochmal. Es war echt super spannend. Danke für die Einladung. Für alle, die das teilgenommen haben. Ich glaube, die meisten haben schon noch reingefunden, obwohl wir jetzt ein bisschen Schwierigkeiten hatten mit dem Link. Aber ich habe zumindest immer LinkedIn und Meetups geöffnet gehabt. Also Meetups konnte ich tatsächlich ändern, da haben wir mehr Follower drauf. Und LinkedIn haben wir sehr gepostet und da ist jetzt keine Lust reingekommen. Plus wir posten es ja auch noch auf YouTube. Super cool. Genau, und dann würde ich sagen, vielen lieben Dank alle, die noch mal da waren und einen superschönen Abend und noch einen süßen Rutsch ins neue Jahr. Und Für die, die noch da sind, genau nächstes Mal ist es der 9.1. und zu Gast wird der Roman Pichler sein mit Ask Me Anything. Sprich, nicht vergessen, uns auf LinkedIn zu followen, damit ihr den Event-Link bekommt und genau, diesmal den Link auch zum Event dann mit drin ist. Wobei ich mir sicher war, dass er mit drin war, aber keine Ahnung, was das Stück gelaufen ist. Also, genau, danke euch. Danke dir, Büstra.

LInkedin: https://www.linkedin.com/company/93148216


Büşra wandelt idealistische Produkttheorien in reale Produktpraxis um, fokussiert durch ihren No-Bullshit-Ansatz. Mit Erfahrungen von Start-ups, Scale-ups bis Großunternehmen wie u.a. Doodle, Deutsche Telekom und home24 kann sie Frameworks der Situation anpassen. Als Coach im Produktmanagement hilft sie Teams und Führungskräften, neue Methoden effektiv umzusetzen und echte Ergebnisse zu erzielen.

Ein modernes und erfolgreiches Produktmanagement basiert auf einer Insights basierten Entscheidungsfindung und einer strategischen Priorisierung der von uns entdeckten Opportunities. Daher ist es für Product Leaders und Teams von entscheidender Bedeutung, die Opportunities, die wir verfolgen, und die Lösungen, die wir entwickeln wollen, mit der übergreifenden Produktstrategie abzustimmen. In dieser Präsentation wird das Konzept des Impact Mapping und seine Rolle bei der Stärkung der Zusammenarbeit, der Verknüpfung von Product Strategy und der täglichen Arbeit, und dem Kick-off der Product Discovery vorgestellt. Wir werden uns anschauen, wie sich Impact Mapping nahtlos mit anderen beliebten Frameworks wie OKRs, Lean Startup und dem Opportunity Solution Tree verbinden lässt, und werden tiefer in die Verbindung mit dem Opportunity Solution Tree eintauchen.

Das Event ist auf Deutsch, mithilfe von Google Meets kann der Untertitel in jede Sprache live übersetzt werden. Wir freuen uns auf rege Teilnahme.