Product Discovery, OKRs, Strategy: Was läuft und was nicht? – Erfahrungen aus 7 Jahren Coaching – Tim Herbig zu Gast

Was machen die meisten Organisationen richtig – und was falsch, wenn sie Product Discovery betreiben, OKRs einführen oder eine Produktstrategie etablieren?

In dieser Folge des PRODUKTKRAFT-Podcasts spreche ich mit Tim Herbig über Stolpersteine und einfache Erfolge in diesen drei Konzepten, die besonders in den letzten fünf Jahren in einem großen Teil der digitalen Organisationen der DACH-Region in der ein oder anderen Form Einzug gehalten haben. Wir rekapitulieren, was genau unter Product Discovery, Objectives & Key Results und Product Strategy zu verstehen ist, und sprechen über die einzigartige Erfahrung, die Tim als Coach und Berater gesammelt hat. Sein einzigartig breiter Blick auf die deutschsprachige Konzern- und Mittelstandslandschaft ermöglicht spannende Einblicke.

Was funktioniert überall? Woran scheitern viele Teams? Und wie lassen sich die häufigsten Hürden überwinden? Hört rein, um mehr zu erfahren!

Product Support Needed?

Du brauchst freiberufliche Hilfe im Produktmanagement? Egal ob Coaching, operativer Support, interimistische Product Leadership oder Consulting: Melde Dich gerne unverbindlich unter jan@produktkraft.com bei mir und wir besprechen, wie eine Zusammenarbeit aussehen könnte.

Credits

Host & Producer: Jan Hoppe - https://www.linkedin.com/in/jan-hoppe-30b38ba3/ - http://www.produktkraft.com

Gast: Tim Herbig - https://www.linkedin.com/in/herbigt/ - https://herbig.co

Audio Engineering: Tim Nippert - https://www.linkedin.com/in/tim-nprt-69a377286/

Links

• https://www.producttalk.org/2021/08/product-discovery/

• https://herbig.co/impact-mapping-product-discovery/

• https://herbig.co/scaling-product-discovery-case-study-stepstone-group/

• https://www.romanpichler.com/blog/the-strategy-stack/

• https://www.lennysnewsletter.com/p/building-substack-sachin-monga-substack

Transkript (Auto Generated)

Jan: Moin moin, das hier ist der Produktkraft Podcast, in dem ich, Jan Hoppe, mit immer neuen Gästen über die vielen Aspekte des digitalen Produktmanagements in Deutschland, Österreich und der Schweiz spreche. Wenn dir das gefällt, dann freue ich mich sehr über das Teilen abonnieren und gute bewerten. Unser heutiger Gast ist Tim Herbig. Viele von euch kennen Tim durch seine starken Beiträge zu Debatten rund um Product Discovery, OKRs und Product Strategy. In den sieben Jahren seitdem Tim als selbstständiger Product Coach und Consultant arbeitet, hat er mit unzähligen Speaker-Auftritten, Blogbeiträgen, Newslettern, Podcast-Aufnahmen und LinkedIn-Posts immer wieder zum Nachdenken über unsere Zunft angeregt und vielen von uns geholfen, unsere Begriffe und Techniken zu schärfen. Bei so viel Präsenz übersieht man fast, dass Tim nicht immer als Solodienstgleister unterwegs war. Vor seiner Selbständigkeit blickt er auf viele weitere Jahre Hands-on-Produktarbeit zurück, in denen wir, Fun Fact, sogar einmal dieselbe Rolle in einer Boutique-Consultancy innehatten, allerdings nacheinander, sodass wir uns damals nicht kennengelernt haben. Da er, wenn man seine Workshops mit einbezieht, vermutlich mit hunderten Produktleuten aus unterschiedlichsten Unternehmen der Dachregion gearbeitet hat, bin ich besonders gespannt mit ihm darüber zu sprechen, welche Aspekte in Bezug auf Product Discovery, OKRs und Product Strategy überall gut anlaufen, aber auch zu beleuchten, welche Anti-Patterns wir immer wieder sehen. Also ab ins Gespräch. Ja, moin Tim. Schön, dass du dabei bist.

Tim: Hi Jan.

Jan: Schön, dich hier begrüßen zu dürfen.

Tim: Ja, sehr schön, dass ich dabei sein kann. Dankeschön für die Einladung.

Jan: Ja, gerne, gerne. Für diejenigen, die uns zuhören, die deinen Namen gegebenenfalls noch nicht kennen sollten, erzähl uns doch mal, wie du überhaupt mal ins Produktmanagement gekommen bist.

Tim: Total gerne. Das war 2010. Da hab ich in Hamburg in der Performance-Marketing-Agentur gearbeitet, so Werkstudent im Account-Management. Und dann hatte der CTO damals die Idee, er möchte, es gab ein internes Tool und das internes Tool sollte jetzt mit Scrum weiterentwickelt werden. Und er hat noch einen Product Owner gesucht und die Wahl fiel dann auf mich. Und da ging es irgendwie los und dann saßen Entwickler, ich und der CTO dann auch gleichzeitig der Scrum Master in einem Raum und das uns erstmal so ein paar Sachen vom Scrum Mythologie erzählen, von Story Points und Sprint Planning und Burnt Down und User Stories. Und ich dachte, ja, okay, verstanden, was soll ich jetzt machen? Dann hat man gesagt, du musst euch die User Stories schreiben, guck mal, hier ist eine Word-Template. Okay, und dann habe ich angefangen, wirklich old school Word-Templates auszufüllen mit User Stories und eine physische Wall, ich hab die ausgedruckte User Story Templates, die hingehangen und dann kannst du dir vorstellen, wie gut das gelaufen ist, wenn damals 20-Jähriger versucht, den Senior-Entwicklern zu sagen, übrigens das machen wir jetzt, der gesagt, extrem gut, nämlich so gut, dass das nach ein paar Wochen keinen mehr interessiert hat. Und damals war ich so, okay, diese Leidenschaft für Produkte, die war da, ich dachte, okay, das ist ja nur Buzzwords, da ist ja gar kein Mehrwert dahinter. Weil wir haben ja auch, wir sind auch von der, ich würde sagen, wir sind ja auch von den Artefakten, die Routine gestartet und gar nicht vom Mehrwert. Was soll uns das jetzt bringen? Warum arbeiten wir so? Ganz zu schweigen von buy-in zur Methode.

Jan: Das heißt, die Bedeutung deiner Rolle hat man dir damals noch nicht erklärt?

Tim: Nee, es war ja auch total das gleiche, was ich heute bei Firmen beobachte, weil man sagt, klar, es ist einerseits H-Spalte, andererseits auch wichtig. Product Owner suggeriert ja, das ist die Person in charge. Der Person, die Person besitzt, der gehört das Produkt. Und das hat natürlich überhaupt nicht funktioniert. Genau, dementsprechend wurde das auch gar nicht weiter erklärt, zumindest in meiner rückwirkenden Gedanken nicht mehr. Ich war Product Owner und der schreibt die Anforderungen so mehr oder weniger. Und dann wirklich da hab ich mir dann abgebrochen, das als Sachen als User-Story zu formulieren. Ich glaub, das kennt auch jeder Product Manager, Product Managerin ganz gut. Irgendwann in seiner Karriere hat jeder mal so eine Story geschrieben, die heißt, als Produkt Manager möchte ich, dass der Nutzer mehr kauft, damit die Firma mehr Geld verdient und so. Es versucht, uns Backlog zu schmuggeln.

Jan: Durchaus bekannt, ja.

Tim: Genau. Das ist, finde ich, ein schönes Beispiel von dem Englischen, soll ich mal sagen. When the framework gets in the way of the work. Ich glaube, wenn die Art des Arbeitens eigentlich mehr im Weg ist, als dass sie hilft, Wert zu kreieren. Genau, das war mein Einstieg.

Jan: Ja, und bei dem Einstieg ist es dann ja offensichtlich nicht geblieben. Also, so wie ich dich wahrnehme, hast du dich deutlich tiefer in die Materie eingearbeitet, als es damals der Fall war. Was ist denn dann passiert?

Tim: Genau, User Stories schreibe ich nicht mehr. Dann bin ich, es war in Hamburg, genau, dann bin ich fast wie damals in Traumlerfüllung gegangen. Ich hatte die Chance bei stern.de als Produktmanager anzufangen. Also da Sterns Nachrichtenportal, damals Teil von Gunn und Jahr, wahrscheinlich immer noch am Bauunfall, witzigerweise direkt gegenüber. Und dann durfte ich dann Produktmanager werden für die mobile App vom Stern. Was Wahnsinn war, weil Stern war so diese Kindheitserinnerung, das lag bei meinen Großeltern auf dem Tisch. Die Zeitung hat auf einmal, fummel ich dann der App rum.

Jan: Große Imminenz.

Tim: Ja, große Imminenz. Und natürlich hat mir das viel, es ist bei weitem keine Product Company gewesen, aber trotzdem habe ich erstaunlich viel über Produktmanagement gelernt. Aufgrund von tollen Chefs, die ich hatte, die mir diese Chance gegeben haben, aber auch vom, okay, es ist ein Produkt, das Produkt ist werbefinanziert. Das heißt, das ist ein Stakeholder, das Produkt lebt von den Inhalten. Das ist der zweite Stakeholder. Und du hast damals noch eine Out-Gesource-Entwicklung gehabt, das ist eine externe Agentur. Das war ein ganz anderes Orchestrieren von Stakeholdern, als heute nur das eigene Internativ zu machen. Ich muss sagen, das größte Learning, was ich von damals hatte, ist, dass kurz bevor ich angefangen hatte, relativ kurz davor, hatte die App großen Erfolg und hatte dann aber technische Probleme und hat wahnsinnig eine Reichweite verloren, weil irgendein Bug in der App drin war. Es war ein riesiger Rebuild der ganzen App im Gegengange. Das wurde dann auch ge-released alles und mit ein paar Gimmicks und so. Und es hat auch ein bisschen stabilisiert. Aber mein großes Take-Away ist, wenn du ein Produkt hast, musst du immer verstehen, was ist der Kern der Wertschöpfung. Und ich glaube, du kannst über ein Produkt wie ein Medienangebot, wo klar ist, die Leute besuchen nicht die Website oder die App wegen der App, sondern wegen dem Inhalt. Und ich glaube, du kannst mit der Hülle den Produkt nur verlieren, aber fast nicht gewinnen oder inkrementell gewinnen. Also du kannst Leder verlieren, wenn das Produkt noch nicht schlecht zu bedienen ist, aber nur weil es funktioniert, kannst du nicht gewinnen, weil das Gewinn passiert über die inhaltliche Ausrichtung.

Jan: Ja, macht glaube ich bei dem Produkt besonders viel Sinn total.

Tim: Und ich würde es auch zum Beispiel übertragen und vielleicht an Überleitungen, sondern ich habe später meiner Karriere durfte ich auch bei Xing arbeiten. Und ich glaube Xing ist relativ ähnlich zu sehen als Netzwerk. Ist genau das gleiche. Klar, ich kann verlieren, wenn es ganz schlecht zu bedienen ist. Aber wenn meine Kontakte nicht mehr da sind, ist es egal, wie es aussieht, weil es ist ein Netzwerk. Der Wert ist das Netzwerk mit anderen. Ich glaube, es gibt so einige Produkte, wo man merkt, was eigentlich die Kernwertschöpfung und was ist die Rolle von dem, was gemeint als Produkt betrachtet wird, UXUI, Funktualität, Stabilität und dem Kernwert und wo kommt der eigentlich her?

Jan: Das glaube ich gerade in aktuellen wirtschaftlichen Zeiten ist da sehr viel Wahrheit drin, diesen Kern und auch sehr viel Wichtigkeit drin, diesen Kern immer voll im Fokus zu behalten. Da bin ich total bei dir.

Tim: Genau, ich war noch auf Backsync, ich hab 2,5 Jahre, hab da als Produktmanager in der Premium-Mitgliedschaft arbeiten dürfen. Was spannend war, weil es viel Traffic, viel Professionalität, tolle Leute, es sind immer noch einige der tollsten Produktleute, die ich kenne im Umkreis. Mein Witz ist immer Silicon Valley hat die Paypal-Mafia, aber hier die Rocket-Mafia und in Hamburg die Xing-Mafia. Also trifft man überall, das ist auch schon einige Xigar und Xigar bei dem Podcast. Von daher.

Jan: Ja, ich versuch tatsächlich diesen Xing-Bias gar nicht so drin zu haben, aber als in Hamburg lebender Mensch ist es einfach so, ja es passiert sehr schnell, weil einfach jede zweite Produktperson dort mal gearbeitet hat.

Tim: Ja, ich finde das immer bei der Project Heart so bezeichnend, das ist dann wie so, du kannst keine zwei Meter laufen, ohne in Ex-Xigar oder Neu-Xigar rein zu laufen und dann treffen sich die verschiedenen Strenge. Neu ich auf der Project Heart habe ich eine alte Kollegin von Coulon ja getroffen, die jetzt bei Statista ist, wo wiederum auch einige Ex-Xigar sind und dann treffen sich so die ganzen Strenge. Gibt so diese Hubs einfach in der Stadt. Ja, genau. Ich hatte auch eine über User-Stories gesprochen haben. Ich hab dann zwischen stern.de und Xing hab ich bei einem kleinen Stand-Up mitgemacht von einem Kumpel, das hieß Mygassi. Genialer Name. War ein Marktplatz für Hundesitter und Hundebesitzer. Problem war, keiner von uns hatte einen Hund. Entsprechend nutzerunzentriert war das Produktrückwirkend gesehen, außer ein Investor hatte einen Hund, der wusste genau, was alles rein muss natürlich. Und ich hab kurz vor in das Scrum Product Order Zertifizierung gemacht tatsächlich und dachte geil, ich weiß wie Produktmanagement geht. Und dachte, wenn ich nur User Stories schreibe, da sind wir wieder, und wir in Sprints arbeiten, dann wird das ein Erfolg. Ohne zu realisieren, dass das eigentlich völlig egal ist, wenn man an den falschen Sachen arbeitet oder gar nicht die richtigen Probleme löst. Und das war in dem Moment von okay, ich will nochmal mit Profis arbeiten, der mich dazu gesehen geführt hat.

Jan: Ja, schlaue Entscheidung. Das war ja wirklich eine ganz schöne Graderschmiede in der Zeit damals. Du bist aber ja nicht auf der angestellten Product-Owner-Seite geblieben, richtig?

Tim: Genau, ich bin dann nochmal verheißungsweise unabsichtlich in die Beratung gerutscht. So beschreibe ich es immer gerne. Es gab die gemeinsame Vergangenheit, die wir teilen. Ich war bei Orbit, Orbit Ventures, jetzt im Teil von e-Tribes reingekommen. War dann damit konfrontiert, okay, wie erklärst du nicht nur Product-ManagerInnen und Leuten, die auf einem ähnlichen Wissensstand sind zusammen, sondern wie erklärst du und enables Produktmanagement in Firmen, die einen ganz anderen Stand haben? Das war eigentlich die spannende Challenge. Da hab ich das erste Mal gemerkt, dass mir das Thema Themen, Herausforderungen verständlich rüberbringen und andere enablen und weiterzubilden, dass mir das sehr viel Spaß macht und sehr, sehr liegt. Ich fand es auch eine tolle Herausforderung, dass man so viele verschiedene Branchen zu machen, von Immobilien über Versicherungen über was weiß ich, was wir noch gemacht haben damals. Ich hatte nur gemerkt, dass mir so beratend Spaß macht, aber nicht in einer Beratung. So sage ich es immer ganz gerne. Und habe dann mir noch mal eine Art halben Wunschtraum erfüllt und noch mal B2B-Produktmanagement gemacht, weil ich bis dahin fast nur B2C gemacht habe. Dann noch mal eine AB-Testing-Plattform mit Fokus auf Agenturen und Enterprise-Kunden gebaut, sozusagen wie so eine Art Intrapreneur als Teil von einer großen Conversion-Agentur in Deutschland. Und habe das knapp zwei Jahre gemacht und dann den Sprung der Selbstständigkeit gewagt. 2019 war das, genau.

Jan: Wo du jetzt Beratent, aber nicht am Arbeiten in einer Beratung bist.

Tim: So sieht es aus. Tatsächlich merke ich das immer wieder. Es ist das Coole von früher, ohne das, was ich nicht so cool fand von früher.

Jan: Cool, was ist denn da so der motivierende Unterschied, wenn ich da reinfragen darf? Was sind die Aspekte, für die du jetzt eins sich brennen kannst? Und was war das Störfeuer für dich persönlich vorher?

Tim: Ja, also ich muss dazu sagen, dass ich sagen wollte, ich hab ganz viel über Beratung als Business gelernt, bei OBE zu sein. Ich erinnere mich noch, da gab es einen Kollegen, Jan, der mit mir angefangen hat als Head of Technology. Der kam von ThoughtWorks, eine riesige Tech-Beratung. Von dem hab ich ganz viel über Beratung gelernt tatsächlich, was auch spannend war, also das Business von Beratung. Das fand ich richtig, richtig gut und auch über Kundenbeziehung, Kundenarbeit, Pricing, Angebotsgestaltung. Das war schon viel dabei. Was mich damals gestört hat, war zweierlei a. eine gewisse Eingeschränktheit, was die Kunden anging und sozusagen ja schon die Interessen des Großen Ganzen über die eigenen Stellen. Also welchen Firmen will ich arbeiten, was für Menschen, was für Angebote will ich machen und so weiter. Was logisch ist, die Firma braucht was anderes als was ich will. Wir hatten damals auch relativ, würde ich glaube ich alle auch so unterschreiben, einen relativ großen Fokus auf Billable-Hours pro Woche, was einfach eine Messgröße ist, die mich nicht so gereizt hat, und dazu kamen auch relativ viele, also überraschend viele Reisen, jetzt gar nicht so super viel, aber überraschend viele Reisen, was zu einem neugeborenen Sohn damals nicht gut gepasst hat. Das waren so verschiedene Faktoren.

Jan: Das ist tatsächlich eine schlechte Kombination. Und ich meine das Thema mit den billable hours, es ist halt ein Teil des Agenturgeschäftes, dass die Agentur ein Geschäftsmodell hat. Also ich verstehe das sehr gut.

Tim: Genau, ist auch so. Und weil du gefragt hast, was ist der Unterschied? Für mich ist der Unterschied A, dass ich mir meine Positionierung ganz für mich selber aussuchen kann. Das würde ich sagen, ist das Größte. Dass ich meine Tätigkeit auch wie ein Business betrachte, wie ein Produkt betrachte. Es ist wiederum eine Frage, die kriege ich häufig, ob man nicht die Arbeit am Produkt fehlt. Und ich sage immer, nee, weil ich bin das Produkt. Ich hab Analytics, ich hab Newsletter, ich hab KPIs, ich hab Metriken, ich hab OKRs, ich hab Angebote, ich hab ne Strategie, es ist das gleiche, nur anders. Und dass ich das selbstbestimmt machen kann. Sei es von Branding über Positionierung, über Kunden, über Preise ausprobieren und auch grundlegende Entscheidungen. Ich hab eine der größten Entscheidungen oder Fragen, die ich oft gekriegt hab zum Start meiner Selbstständigkeit war, ob ich nicht aufwachsen will, ob ich nicht eingestellt, ob ich nicht eine Verratung machen will. Hab das irgendwann gemerkt, ja, ist das irgendwie interessant, ist das sexy, irgendwie war so ein Ego-Ding. Also ich hab aber gemerkt, nee, das will ich gar nicht. Ich will mich gar nicht mit Hiring, Payroll, Admin beschäftigen. Ich will eigentlich nur mit Firmenarbeiten dabei Spaß haben. On my own terms. Gründwirkend ist diese Entscheidung, die ich getroffen habe, Sodopreneur zu sein sozusagen, mit Freelancern, die mich bei vielen Bereichen toll unterstützen. Ich hab eine der besten, die ich je treffen konnte für meine Selbstständigkeit. Weil der Grad der Freiheit, den ich dadurch habe, ist quasi unübertroffen. Und aus einer Strategiesicht ist es natürlich so, dass ich dann dafür vielleicht manche großen Kunden nicht kriege, die sagen, wir wollen eine Armee von Beratern, wir wollen zehn Leute oder wie skalierst du? Und so nach Strategie Playbook versuche ich aber den Nachteil Vorteil zu drehen. Und wie ich das drehe ist immer A, ihr bezahlt bei mir keinen Kostenapparat mit, von anderen Leuten im Hintergrund und B, wenn ihr zu mir kommt, mit mir zu arbeiten, arbeitet ihr auch nur mit mir. Das heißt, ihr kriegt Tim Herwig. Ich bringe auf einmal so ein Junior Associate rein, der oder die dann die Arbeit macht. Und daran fühle ich mich extrem wohl, muss ich sagen.

Jan: Cool. Und ich glaube, man sieht es auf jeden Fall von außen auch, dass du damit auch ziemlich erfolgreich drei Themen besonders in der Dachregion besetzt. Und zwar Product Discovery, OKRs und Product Strategy, so als drei große Themenblöcke. Und deswegen habe ich mir überlegt, du machst jetzt seit sechs, sieben Jahren, bist du selbstständig beratend tätig und arbeitest an diesen drei Themen. Du hast wahnsinnig viele Firmen besonders in der Dachregion gesehen. Wahrscheinlich mehr verschiedene Firmen als fast jeder andere, den wir in der deutschen Product Community haben. Und weil diese drei Themen, also Product Discovery, OKRs und Product Strategy, immer wieder so als Buzzwords auftauchen und gleichzeitig alle ihre einfachen und schweren Aspekte mit sich bringen, dachte ich, wäre es für uns eine ganz coole Sache, wenn wir einmal alle drei Bereiche durchgehen würden und du vielleicht mal aus der Breite deines Erfahrungsschatzes als Berater und Coach erzählst, welche Muster finden wir eigentlich immer wieder, welche Sachen fallen eigentlich allen schwer und was sind aber auch die Wins, die eigentlich jeder mal schnell herausziehen kann. Und da bin ich sehr gespannt auf deine Perspektive.

Tim: Ja gerne, freue ich mich auch drauf. Wie so ein lautes Reflektieren für mich wahrscheinlich und da ist das ganz cool.

Jan: Ja cool, dann lass uns doch direkt mal reinstarten. Vielleicht fangen wir mal mit dem ersten Thema an und sprechen über Product Discovery. Wie definierst du Product Discovery?

Tim: Ich stelle es immer so vor, dass für mich Product Discovery eigentlich alle Aktivitäten sind, die einem Produktteam oder einer Firma dabei helfen, Unsicherheit oder Risiko zu reduzieren. Und das Risiko und die Unsicherheit kann sich natürlich darauf beziehen, auf welche Probleme lohnt es sich zu lösen, welche Lösung lohnt es sich zu bauen. Natürlich ist es nie ein ganz glasklarer Schnitt, aber meistens darum. Und das ist auch einer der größten, glaube ich, Aha-Momente in meiner Kommunikation oder auch für viele Firmen, dass ich Discovery eben nicht an bestimmten Methoden ausrichte. Ja, sowas wie Discovery ist Designsprint, Discovery ist jede Woche Interviews, was auch immer es ist. Es kann all das sein, aber man muss es eben nicht.

Jan: Sprich du sagst, wenn wir von Discovery reden, tun wir uns einen Gefallen, wenn wir da methodenagnostisch rangehen und sagen, am Ende geht es darum, Probleme und mögliche Lösungen zu identifizieren, aber nicht darum, wie wir dahin gekommen sind. Verstehe ich das richtig?

Tim: Genau, so würde ich es machen. Das kommt auch daher, weil ich oft merke, dass vielleicht ein gemeinsamer Länder über alle Bereiche hinweg, alle Teams, die ich treffe, oder überwiegend viele Teams, die ich treffe, niemand braucht mehr neue Methoden oder Frameworks. Niemand muss eine neue Methode lernen, ein neues Framework lernen. Aus einer Müdigkeit, aber auch fairerweise aus, und unsere Branche war sehr gut darin, viele Methoden und Frameworks über die Jahre zu erfinden, zu kreieren. Viel weiterweinen in neuen Schläuchen, wie man es so schön sagt. Wo sich dann irgendwann schon der Mehrwert stellt. Was macht jetzt dieses vierte Kern was anders als das erste? Und natürlich ist da immer, glaube ich, ist es immer wichtig, dahin ein bisschen hinterzugucken, wer hat das vorgestellt, passt das zu einer strategischen Ausrichtung einer Person. Aber was ich versuche, immer gern zu machen ist, also kann mich gerne korrigieren lassen, aber mein Hauptansatz ist eigentlich, wenn ich über Methoden rede mit Leuten, dass ich versuche immer zur Originalquelle der Methode zurückzugehen. Was war dann eigentlich die Idee dahinter? Und ist das eigentlich der Wert, der euch was bringt? Wie war es ursprünglich gedacht, statt zu sagen, wir machen jetzt drei von vier Sachen anders mit dieser Methode und deswegen geben wir die einen neuen Namen? Ich bin eher ein Freund von die Methode so zu belassen, wie sie ist und sie einfach anzupassen auf den Anlass, den man braucht, ohne sie künstlich zu verändern.

Jan: Ja, finde ich ziemlich smart, weil auch ich teile diesen Eindruck, dass wenn man zu viele Methoden abfeuert, man so ein bisschen den Wald vor lauter Bäumen auch irgendwann nicht mehr sieht. Also ich beobachte das. Einerseits habe ich es bei mir in meiner frühen Karriere beobachtet, aber ich beobachte es auch jetzt immer, wenn ich ProduktmanagerInnen dabei beobachte, wie sie Erfahrungen sammeln, wie immer mal so eine Phase kommt, wo auf einmal die einzelnen Frameworks und Methoden mehr Präsenz haben als das eigentliche Ziel, um das es dahinter geht. Und da muss man glaube ich auch immer mal wieder den Finger in die Wunde legen. Wie ist denn das bei den Kunden, mit denen du arbeitest? Tastiert das oft, dass so eine Framework-Blendung eintritt?

Tim: Ich würde sagen, es ist eher, wenn ich quasi beauftragt werde von anfangsstrichen den höheren Ebenen, also sagen wir mal VP Product Aufwärts, die vielleicht entweder das Mandat gekriegt haben von ihren CEOs, jetzt etwas bestimmtes einzuführen, weil es jetzt angesagt ist oder toll ist oder was auch immer. Ich würde sagen aus der Bottom-Absicht, wenn ich jetzt eher so hertage, Product Abwärts, Richtung Teams und Product Manager, Product Managerin, da ist es selten, da geht es eher darum, hilf uns mal bitte das hier besser zu machen oder daran besser zu werden oder Sachen aufzufrischen. Also es ist auch ein bisschen so ein Reifheitsgrad. Ich glaube das Spannende ist für mich auch, wie es oft betrachtet ist, ich hab mal witzigerweise so einen schönen Spruch gehört von einem YouTuber, der über Thumbnails und Clickbait-Titel gesprochen hat und der hat es eigentlich so gerechtfertigt, dass er gesagt hat, gib den Leuten was sie wollen, damit du ihnen geben kannst, was sie brauchen. Und so ein bisschen finde ich das mit Methoden eigentlich auch ganz spannend. Ich glaube es gibt viele Methoden, wo der Name einfach klickt für die Leute und sie wollen das und dann ist das eigentlich wie, also intern auch offener, wie so ein trojanisches Pferd. Okay, ja, wir machen das, aber eigentlich geht es um das, was dahinter steckt. Das größere Issue sozusagen. Haben wir drüber gesprochen, sagen wir, wir machen jetzt continuous discovery. Warum es aber eigentlich geht, ist, dass die Teams mehr Experimente machen, dass die wagnisfreudiger sind, dass die schneller Sachen lernen. Es geht um schnelleres Lernen. Das ist eigentlich, was die Firma erreichen will. Jetzt geben wir denen das Label continuous discovery, weil alle finden Theresa gut und das ist ja auch richtig zu machen. Aber das ist nur das Mittel zum Zweck. Und das ist auch okay.

Jan: Vollkommen fair. Wenn wir sagen, das Mittel zum Zweck, auch das Durchführen von Experimenten, ist ja nicht der Endzweck. Vielleicht erwähnen wir einmal für unsere weniger erfahrenen Zuhörerinnen im Feld. Warum ist Product Discovery überhaupt so ein wichtiges Thema?

Tim: Ich glaube auch da, ich weiß gar nicht, ob das mal die Kaken oder Jeff Patton war, aber irgendwann mal diese schöne Definition gemacht. Product Delivery ist die Sache richtig machen und Product Discovery ist das, das richtige machen. Das richtige bauen versus das Feature richtig bauen. Und wir haben eine andere Produktmanagerin, die ich mal coachen durfte, die hat das noch mal anders formuliert. Die hat gesagt, bei Discovery geht es darum, das Investment der Firma zu beschützen. Und ich glaube, wenn man die Sachen auf den Tisch legt und sagt, okay, ein Produktteam ist ein Investment, was die Firma macht. Das muss man nicht, das ist so. Die Leute kosten Geld, die sollen Geld kosten, die verdienen Geld. Das ist eine Summe, die ist bekannt. Und es geht ja darum, was mache ich mit diesem Geld? Und ich will ja idealerweise, dass dieses Investment möglichst gut eingesetzt wird. Und möglichst gut bedeutet ja möglichst zielgerichtet. Und zielgerichtet liegt für mich immer an der Schnittstelle zwischen den strategischen Prioritäten der Firma. Ich will jetzt international expandieren oder ich will ab Market gehen, was auch immer der Shift ist. Und was meine Kundengruppen brauchen. Und an dieser Schnittstelle operieren zu können als Produktteam, was eben Investment ist der Firma. Klar, die strategische Richtung kann die Firma vorgeben, aber um zu sagen, welche Nutzerprobleme kann ich dort hinkommen. Das wiederum ist dann die Aufgabe von Discovery. Wie gesagt, das probiere ich. Entweder kriege ich das raus, indem ich sage, ich muss grob erst mal blank canvas explorieren, wie funktionieren Nutzerinnen in diesem Markt. Oder gibt es schon konkretere Ideen, was gemacht werden soll. Sei es, wir haben bestehende Lösungen aus dem einen Markt, die müssen in den anderen Markt rüber. Dann gucke ich auf die Risiken der Lösung, statt auf das Problem vielleicht im ersten Schritt.

Jan: So immer dahinschauen, wo das Risiko am größten ist.

Tim: Würde ich auch sagen. Risiko, Unsicherheit, verschiedene Begriffe. Und das Spannende ist für mich da, was ich gerade mache in Firmen, dass ich sie einfach mal einlade bei Workshops oder Vorträgen, einfach zu sagen, für eine Minute, denk mal nach, was ist denn eine große Unsicherheit in einem Projekt, in dem du gerade arbeitest. Und fast jeder findet irgendeine Unsicherheit. Das kann eine Ressourcenunsicherheit sein, das kann eine Machbarkeitsunsicherheit sein, eine Desirabilityunsicherheit. Aber meistens gibt es irgendwo eine. Dann sag ich mal Glückwunsch. Ihr wisst, wo ihr Discovery machen könnt.

Jan: Cool. Und du hast ja so ein Discovery Workshop Format, dass du wahrscheinlich, lass mich lügen, aber wahrscheinlich mit hunderten von Produktmanagerinnen gemacht hast, richtig?

Tim: Möglich, ja. Ich hab auch noch nicht mal überlegt, ob ich mal zählen müsste, aber es ist nicht unwahrscheinlich, ja.

Jan: Okay, aber das heißt, wir haben einerseits die Workshop-Erfahrung auf der einen Seite, dann hast du ja auch mit einigen Kunden direkt gearbeitet. Was sind denn, wenn wir über Product Discovery als Konzept nachdenken, die Sachen, wo du, wenn du in deine Kunden und deine Workshops guckst, die bei allen sofort klicken und wo jeder schnell Erfolge sieht?

Tim: Was für viele klickt ist, wie verbinde ich die Discovery- und Delivery-Arbeit mit den übergeordneten Zielen einer Firma. Weil das ist ein, ich beschreib das gerne so, es ist wie zwei Sprachen. So ein Top-Management einer Firma, und vielleicht für Context, die meisten meiner Kunden sind mittelständisch bis Enterprise große Firmen. Also ich sag mal 100, 200, 300 aufwärts bis 1000, 2000 Leute. Das heißt, das ist so der Beiß, den ich mitbringe, wenn ich jetzt über meine Kunden rede. Das Top-Management redet in Business-Zielen und die Produkt-Teams ja normalerweise in Nutzerverhalten oder Feature-Performance. Und da ist ein Gap. Und dieses Gap zu überwinden ist wichtig und die wichtigste Gap ist zu sagen, es ist die Verantwortung von Produkt-Teams, High-Level-Business-Ziele zu übersetzen in Dinge, die sie beeinflussen können. Und das sind ja, weil sie Metriken oder Nutzerverhältnisse halten. Und dafür sind grundsätzlich Baum, Metrics, Trees, Bäume. Ich weiß gar nicht, ob es ein gutes deutsches Wort gibt, ehrlich gesagt. Decision Trees wäre so der englische Begriff als übergeordneter Begriff. Dafür extrem gut. Da gibt es viele Subformen. Es gibt Stumpe Metrics Trees. Es gibt Opportunity Solution Trees von Theresa. Mein persönlicher Favorit ist das Impact Mapping. Meines Wissens gibt es das am längsten. Ich hab es 2014 kennengelernt, mag es seitdem sehr. Was im Prinzip auch dir dabei hilft, Firmenziele und Nutzerprobleme zu connecten. Für bewusste Entscheidungen, um eben auch wieder zu diesem Punkt von eben zurückzukommen. Nur weil Nutzerprobleme existiert, heißt es nicht, dass ich es lösen muss. Ich sollte mich auf die Probleme fokussieren, die der Erreichung der Firmenziele am dienlichsten sind. Und diese Pfade zu verknüpfen, ist eben eine Stärke von Methoden wie dem Impact Mapping zum Beispiel. Und das ist etwas, das klickt wirklich bei vielen, weil das Impact Mapping, wie fast jede Methode, ist natürlich auch garbage in, garbage out. Das heißt, wenn ich nie Research mache und eine schlechte Strategie hab, ist die Impact Map wahrscheinlich auch nicht nützlich.

Jan: Magst du die Impact Map vielleicht ganz knapp einmal umreißen für alle? Total.

Tim: Also ursprünglich ist es ein Vier-Ebenen-Framework. Ich hab das best abgebundelt. Mittlerweile, ich heiße, ich arbeite in fünf Ebenen. Es gibt die obersten Ebenen. Und jeder dieser Ebenen antwortet auch eine Frage. Ganz oben hab ich das Why. Warum mach ich das überhaupt? Das versuch ich zu beantworten über den Impact. Das ist meistens so ein Firmen oder einen großen Firmen, ein Department-Level-Business-Ziel. Growth, Satisfaction, Process, Quality, was auch immer. Die nächste Ebene beantwortet das Wer, also das Who. Und das wird in Impact-Mapping-Sprache über die sogenannten Actors abgebildet. Also ich segmentiere und der Unterschied zu Personas zum Beispiel ist hier, ich segmentiere im Kontext des Business-Ziels. Also ich segmentiere nicht immer gleich 30- bis 35-Jährige, Großstadt, Vorstadt, Markt, Kaffee, mag keinen Kaffee, sondern ich sage, okay, wenn ich ein Monetarisierungsziel treiben will, dann müssen meine Actor an den verschiedenen Monetarisierungsstufen ausgerichtet sein. Wenn ich ein NPS-Ziel treiben will, dann sollte eben meine Actors an den NPS-Segmenten ausgerichtet sein.

Jan: Ja, spannend, also gar nicht so userzentriert als Methode eigentlich und trotzdem hilfreich in der Discovery in deinem Zeitpunkt.

Tim: Also userzentriert im Sinne von, was ich halt finde, dabei hilft, also die Frage, die die eben beantwortet ist, welches Segment hat den größten Hebel, um das Business-Ziel voranzutreiben? Mein liebles Beispiel ist, du hast ein übergeordnetes Conversion-Rate-Ziel und du stellst fest, 5% Conversion-Rate-Ziel und du stellst fest zwischen Mobile, Tablet und Desktop gibt es drei verschiedene Conversion-Rates, Mobile hat schon 5%, Tablet hat 4,8% und Desktop hat 1%. Dann sollte ich mich auf Desktop-Nutzer fokussieren, weil das ist ja der größere Hebel. Und das hilft mir dann natürlich in den nächsten Discovery-Schritten im Sinne von, ich sollte nicht alle Nutzer interviewen, ich sollte Desktop-Nutzende interviewen und Usability-Issues vom Desktop rücksichtigen. Also es ist wie so ein, ich nenne das dann ein bisschen wie so Targeting. Es hilft dir so das Targeting deiner Discovery festzulegen. Und das beeinflusst halt ganz taktisch auch, wen rekrutiere ich für Interviews, wessen Analytics-Daten gucke ich mir an, wem schalte ich den AB-Test auf, wessen Feedback interessiert mich im Rollout. Genau.

Jan: Ja, ganz spannend und ich könnte mir vorstellen, dass Impact Mapping, ich hab selbst tatsächlich noch nicht direkt angewendet, aber ich würde mal einen Link in die Show Notes tun. Du hast ja wahrscheinlich eine Doku dazu, richtig? Ja. Genau, die würde ich dann mal platzieren. Ich könnte mir vorstellen, dass das auch die Übersetzung sehr leicht macht in auch traditionellere Unternehmen, die noch nicht so product-led arbeiten, weil man einfach mit den Business-Zielen startet. Also dass das zumindest das Vokabular Übersetzungsleistung weniger nötig macht.

Tim: Ja und nein, weil witzigerweise ich hab ja vorhin gesagt, dass ich selten mit Framworks um die Ecke komme, mit Firmen, mit der Impact Map ist es ähnlich. Ich nenne das fast nie Impact Map, sondern witzigerweise ist es mit den meisten Leuten, meisten Firmen starte ich eher auf der zwei Ebenen tiefer, auf der Output-Ebene im Lösungsraum, weil da die meisten Teams operieren. Was ich dann sowas mache, sowas Simples wie wir schreiben jetzt mal die Outputs auf, an denen ihr arbeitet und dann versuchen wir mal die Map von unten nach oben zu bauen, weil das eigentlich viel mehr klar macht, wo die Leute ihren Gap haben. Okay, wenn ich zum Beispiel über dem Output, also zwischen dem Actor und dem Output sitzt der Outcome, also das How, die Verhaltensänderung, und wenn die Leute die Verhaltensänderung nicht benennen können, haben sie ein Gap im Nutzerverständnis. Und dadurch ging sie raus, okay krass, ich baue dieses Feature, ich weiß aber gar nicht, ob und wie das auf dieses Business-Stil, was hier oben ist, einzahlt, geschweige denn welches Segment relevant ist. Und entweder ich treffe die bewusste Entscheidung, sage es mir egal, ich brauch es trotzdem, oder ich nehme es als Anlass zu sagen, okay, vielleicht soll ich das erst mal verstehen, weil das mir ja auch hilft, dann später den Erfolg von dem Feature zu bewerten. Statt zu sagen, ich bewerte das Feature anhand von Durchschnittsmetriken über alle Nutzen dann hinweg, kann ich jetzt sagen, ich berücksichtige konkrete Outcome-Metriken aus einem bestimmten Segment und zu gucken, ob das Feature erfolgreich war.

Jan: Okay, das heißt, wir haben in der Frage, welches Feature bauen wir eigentlich und auf welches Business-Ziel zahlt das ein? Wenn man diese Überlegung erstmal macht, das ist ein Aspekt in Discovery, der den meisten Firmen und den meisten Teams relativ leicht fällt. Sind es noch andere Sachen, die in Discovery-Prozessen grundsätzlich einfach sind, wenn du so Firmenübergreifend guckst?

Tim: Ja, ich würde sagen, was auch einfach ist, ist sozusagen auch hier wieder, kann ich mit den Leuten in klarer Sprache reden, statt in Methoden. Ich hab vorhin ja gesagt, dieser Mini-Trick von, das ist kein Trick, diese Mini-Frage, was ist die Unsicherheit? Das kann ich natürlich ein bisschen formalisieren und mach das als eine Art Assumptions-Workshop sozusagen. Ich sammle die Annahmen, die Leute haben. Ich priorisiere die Annahmen, um herauszukriegen, welche davon sind eigentlich bewiesen, welche sind unbewiesen. Auch hier, das ist nicht mal, ja, kein Framework, das ist ja wirklich eine klare, also deutsche Sprache oder englische Sprache mit den Leuten. Um dann zu überlegen, okay, mal genau, ihr hättet eine Woche oder zwei Wochen oder drei Wochen, um diese Annahme so gut wie möglich zu testen, was würdet ihr tun? Und ich mag diese Timebox, das ist auch eine der häufigsten Fragen im Discovery-Kontext, so wie lapp geht Discovery, wann bin ich fertig und so weiter. Und ich glaube, es ist diese Balance zwischen, ich kann schwer sagen, in sechs Wochen habe ich das und das erreicht mit Discovery. Und gleichzeitig glaube ich, sollte ich auch nicht sagen, ich dauere so lange wie es dauert. Ich glaube Teams brauchen Constraints, z.B. durch Zeit oder eben Business Ziele. Aber weil es geht nicht um perfekte Discovery, es geht nicht um den Abschluss aller Schritte. Es geht darum, wie kann ich die Unsicherheit maximal reduzieren? Und dann ist eben die richtige Discovery Methode, in Anführungsstrichen, liegt halt am Schnittpunkt zwischen, wie schnell kriege ich den Inside, beantwortet das die richtige Frage, die ich habe und ist es die richtige Methode für die Frage.

Jan: Das leitet dann vielleicht auch gleich ein bisschen dazu über, welche Anti-Patterns man findet. Eine Sache, die ich immer mal beobachte, ist, dass es gelegentlich Leute gibt, die sich in Discoveries verzetteln, die aufwendiger sind als die eigentliche Umsetzung der Sache, die man da gerade derisieren will. Ist das ein Thema, das nur ich beobachte oder bist du da auch drüber gestalpert?

Tim: Jein, ich glaube, ich bin etwas anders. Ich habe dieses Pushback oder diese Diskussion auch ein paar Mal bei Teams erlebt, die gesagt haben, das Experiment dauert länger als es zu bauen. Und das ist natürlich fair und gleichzeitig ist das auch ein Indikator davon, wie eine Firma denkt oder was eine Firma incentiviert. So eine Aussage ist natürlich oft ein Zeichen für mich von, die Firma incentiviert dann am Ende doch mehr das Bauen als das Lernen. Das ist so ein geflügeltes Wort. Weil ich würde sagen, selbst wenn ich es baue, wenn ich etwas baue, selbst wenn es schneller ist, habe ich ja gewisse Schulden, die ich damit aufbaue. Ich muss es trotzdem, ich habe ein bisschen Tech-Dap, es ist integriert, ich habe vielleicht ein bisschen UX-Dap, ich habe vielleicht nur Customer Service. Ich habe es den Leuten rausgegeben, dann muss ich sie wieder wegnehmen. Und ganz zu schweigen davon, ist die Firma eigentlich gut genug aufgestellt, um dieses Feature auch metrikenbasiert zu evaluieren. Und das sind, würde ich sagen, das sind eher so die Gegenargumente, wo ich sagen wollte, manchmal ist es komplett zu bauen, selbst wenn es eine Woche schneller ist, dann vielleicht doch nicht die richtige Antwort, um zu lernen. Ich mag das Wort lernen nicht immer, weil es ein bisschen geflügelt ist. Aber das ist so ein bisschen die Idee dahinter. Ich hab bei den Firmen aber alles kann. Das wäre, glaube ich, das Problem. Guck dir auch viele große Reife mit Shoe-Firmen an, wie Booking oder was auch immer, die wahnsinnig viele Sachen einfach raushauen. Ja, die können damit aber auch was anfangen.

Jan: Ja, ich glaube, da musste ich gerade schmunzeln, als du das erzählt hast, weil mir da ist mir aufgefallen, dass unsere Perspektiven natürlich verschieden geprägt sind. Du hast es ja eingangs gesagt. Du kannst ja auch gleich noch mal zwei, drei Worte zu den Kontexten sagen, die du so kennst, aber ich hab die letzten 11 Jahre zu großen Teilen in Start-ups verbracht, wo du so einen Rennen zum Product Market Fit machst und der Tech-Dev, den du da aufbaust, am Ende, du hast halt wenig Lebenslinie und klar, technische Schuld ist nicht toll, aber überhaupt nicht rauszufinden, welches Produkt du überhaupt bauen sollst im Sinne von, was nimmt der Markt am Ende an, ist natürlich noch schlechter. Wenn ich jetzt aber ein reifes Unternehmen bin, das schon eine gewisse Kernvalue proposition draußen hat, das schon ein erfolgreiches reifes Produkt hat, sieht die Situation natürlich ganz anders aus. Und das ist das Feld, in dem du dich ja mehr bewegst, richtig?

Tim: Genau, das ist ein sehr guter Punkt. Ich würde jetzt auch mal sagen, gibt ja diesen schönen Ausdruck 0 bis 1 Produkt oder 1 bis 10 und ich bin sicherlich eher beim 1 bis 10 Produkt unterwegs. Das Produkt hat eine gewisse Traction oder die Firma hat eine gewisse Traction und es geht darum, okay, wir haben so diesen initialen Founder Genius Spark, der hat uns bis zum Product Market Fit getragen und auf einmal sind wir aber zehnmal so viele Leute und wollen professionalisierter arbeiten. Das ist das Umfeld, in dem ich bin. Ich bin auch wie bei dir. Das ist auch der Grund, warum ich mit mit mit Startups gar nicht so viel arbeite, weil ich mag diese Stärke von mir, würde ich sagen, ist eben dieses veranschaulich machen von Theorie und anfassbar machen und übersetzen in verschiedene Kontexte und fairerweise muss das ein Startup nicht können. Wie du gesagt hast, geht es ums Überleben. Ich muss Sachen schnell gegen die Wand schmeißen, gucken, was kleben bleibt, in einem gewissen professionellen Baseline, damit es funktioniert. Ja, total.

Jan: Ich würde in dem Startup Kontext aber auch anmerken, da ist Delivery of Discovery. Also wenn du da nicht auswertest, was du da gemacht hast oder was dein schnell rausgeworfenes Feature in Production macht, dann machst du es auch falsch. Also eigentlich machst du einfach viel Discovery über Delivery, wenn es schneller geht.

Tim: Genau, das ist eigentlich ganz schön, wie es am Anfang hatten sozusagen. Brauchst du immer die Hilfe Unsicherheit zu reduzieren. Und es wird immer diesen Punkt geben, das ermutige ich, weil es gibt zwei Sachen, die ich Teams mit an die Hand gebe, ist, du kannst das perfekt formulierte, bewiesene Problem haben von der größten Nutzergruppe, wenn du nie irgendeine Lösung in die Hände von Nutzern bringst, hast du nichts erreicht im Sinne von weder Erfolg für Kunden und Kundinnen kreiert, noch Ergebnisse fürs Business. Das muss aber immer klar sein. Nur das Problemverständnis ändert erst mal nichts an Ergebnissen. Und das zweite ist, wie du schon auch gesagt hast, manchmal ist der einzige Weg noch mehr zu lernen, noch mehr Unsicherheit zu reduzieren, das Shippen des Produkts. Und das müssen eben auch glaube ich Leute verstehen, weil sonst sag ich, Theresa Torres hat auch mal diesen Spruch so gesagt, You're never one interview away from success. Und ich glaub, das ist auch wichtig. Das hab ich auch definitiv in meiner Karriere oft genug gemacht, zu sagen, ah, noch einmal interviewen, um mich abzusichern. Ja, aber ich glaube, das ist so, müssen viele Leute lernen, darf man auch lernen.

Jan: Also gängiger Fehler, zu lange discoveren oder zu kurz discoveren.

Tim: Alles ist möglich. Genau. Also ich glaube, entweder discovery eben wie so ein Feignant zu benutzen, sagen wir machen discovery, wir haben wöchentliche Interviews. Ja, aber was fragt ihr da drin? Und ist überhaupt ein Interview das richtige Grad? Also was heißt das? Oder ja, wir machen Jobs, Twitter.

Jan: Was heißt das?

Tim: Also eher sozusagen das doing zu evaluieren. Warum macht ihr diese Methode? Warum macht ihr das jetzt? Worauf zahlt es eigentlich ein? Und genauso eben aber auch zu sagen, ja, ich hab jetzt mal eine dreimonatige Feldstudie angelegt, um die Usability vom neuen Login-Screen zu testen. Das wird dir etwas sagen, aber nicht das, was du wissen musst.

Jan: Das heißt immer wieder runterbrechen, warum mache ich das eigentlich? Das ist die Falle, in die manche Leute reinlaufen, das zu selten zu tun?

Tim: Das nicht zu machen, genau. Also zu sagen, worauf zahlt es jetzt ein? Und ich würde sagen, vielleicht einen Firmenpattern, weiß nicht, was ein Pattern ist, aber was ich schon beobachte ist, dass Firmen auch damit strugglen, gerade zu Beginn von Discovery. Und ich hab irgendwann mal gelesen, das ist vielleicht normaler Weg von Change-Prozessen, den Prozess oder den Akt von Discovery zu sehr formalisieren und standardisieren zu wollen. Im Sinne von, hab ich auch einen Artikel drüber geschrieben, das ist gar kein Geheimnis, ich hab lange mal in StepStone gearbeitet für Discovery. Und da mit dem Product Operations Team, und die haben selber geschildert, was für Evolution sie durchgegangen sind, von einem ganz regides Playbook, ein sehr lockeres Mural, dann irgendwas in der Mitte, um rauszufinden, was für ein Guiding brauchen die Teams eigentlich. Wenn du irgendwie 20, 25 Product Teams hast, zwischen B2C, B2B interne, dann kann ich Discovery als Prozess nicht standardisieren. Ich kann sicherstellen, dass ich die Qualität von Methodenwissen standardisieren kann. Alle sollten das Gleiche, alle sollten kapieren, was ich in Interviews nicht fragen sollte oder wie ich einen AB-Test aufsetze. Aber wie es angewendet wird, in welcher Reihenfolge, ist so kontextuell, dass ich glaube, das geht nicht, das zu standardisieren.

Jan: Ja, hast du da mal so ein ganz konkretes Beispiel, das zeigt, wie das falsch laufen kann?

Tim: Ja, ich glaube, mein Lieblingsbeispiel ist es ist nicht mehr so, es kam ja jahrelang, weil Design Sprint so der heiße Scheiße in Produktmanagement. Alles muss ein Design Sprint sein. Und ich glaube, was viele vergessen haben ist, worin mündet ein Design Sprint? Ein Design Sprint mündet, wenn wir es mal ehrlich sagen, in Prototypen-Tests. Das heißt, ich interview, ich zeige 5-6 Leuten einen Klick-Bahn-Prototypen und hol mir Feedback davon. Wenn ich jetzt aber mal sage, wenn ich mal Usability-Testing als Methode extrapoliere und sage, was sagt mir das denn? Das sagt mir, wie gut diese Leute ungestützt eine Aufgabe in diesen Prototypen erledigen können. Das ist das also im Prinzip der Kern, die mir das sagen kann. Natürlich kann ich auch sowas hören wie, wie mögen die das, gefällt ihnen die Farbe orange, womit struggeln die, bla bla bla. Diese Sachen sind aber von sechs Leuten gar nicht ableitbar. Es gibt ja diese Nielsen-Statistik, dass ich natürlich Visibility-Issues mit 5-6 super rekrutierten Leuten abdecken kann. In Klammern, dafür muss ich aber eben auch gut rekrutiert haben und nicht Mundesspektrum aller verschiedenen Leute haben. Aber um so etwas rauszukriegen wie, wollen die das wirklich? Können die das besser bedienen als ein anderes Produkt? Ist der Preispunkt der Richtige oder was auch immer? Dafür ist ein Designs-Print gar nicht die richtige Methode. Und das würde ich eben sagen, komm wir zurück, was können wir diese Methode eigentlich sagen? Und dann muss man glaube ich verstehen, gibt es ja diese verschiedenen Dimensionen, Quantitativ, Qualitativ, Attitude, Behavioral. Wo fällt die Methode eigentlich rein? Und welche Frage können wir dir helfen zu beantworten?

Jan: Ja, ich glaube, das ist sehr wichtig, darüber Klarheit zu haben. Also ich hab, ich würde sogar noch weitergehen, auch das ist ja immer noch alles Risiko auf Seiten des Nutzers. Wie siehst du es, Discovery in Richtung Feasibility auch auszuweiten und ähnliches. Also ich hab schon Discovery Prozesse erlebt, wo man Click-Dummies erstellt hat, die eine super Lösung für ein Problem war, das viele Leute hatten, die sich aber technisch überhaupt nicht umsetzen ließ. In dem Moment hast du das oft erlebt oder ist das eher ein Einzelfall?

Tim: Also mir ist das einmal richtig dolle passiert bei einer großen Discovery, wo es sich am Ende oder meine Gegenkrise ist die, ich glaube fast nie daran, dass es irgendwann wirklich an der Feasibility scheitert, im Sinne von es geht wirklich nicht technisch. Ich glaube, das gibt es fast nicht. Es ist immer eine Frage von Zeit und Geld. Ich würde sagen, es ist nicht feasible in den Rahmenbedingungen, die wir haben. Stichwort Zeit und Geld. Ich glaube, das ist wichtig zu verstehen, an welchem Aufwand ist das möglich oder machbar. Und natürlich auch sagen, was für ein Produkt habe ich, habe ich ein API-Produkt oder ist natürlich das technische Risiko viel, viel größer als bei einem Customer-Facing. Ich persönlich glaube wirklich, dass Desirability das kritischste Risiko ist. Also wollen es die Leute wirklich, weil Usability und Feasibility kann man iterieren. Desirability ist viel schwieriger zu iterieren. Und ganz zu schweigen von Viability, also sollte es als Firma machen, das ist die größte Frage, die ist aber auch am schwierigsten zu testen. Ich glaube, das ist dann eher eine Inform-Gut-Feeling, weil ich kann einen Markteintritt schwerer A, B testen. Zum sehr begrenzten Faktor.

Jan: Okay, got it. Also eine gewisse Klarheit darüber, welche Art ist die Hypothese, die ich hier eigentlich vertesten will oder beziehungsweise das Risiko, um in deinen Worten zu bleiben, dass wir hier vertesten wollen. Was kann ich denn als einzelne Produktpersonen tun, um die Discovery Praxis in meinem Unternehmen gleich morgen zu stärken?

Tim: Also ich glaube, da komme ich dann wieder schließlich zu der Kreis zu meiner Anfangsfrage zurück. Und so versuche ich auch Leute zu entlassen, zum Beispiel aus dem internen Vortrag. Was können sie morgen machen? Was können sie nächste Woche machen? Was können sie nächsten Monat machen? Ich glaube, was jede Person morgen machen kann, ist sich eine aktuelle Initiative, Projekt, Epic, wie auch immer man es nennen will, anzugucken und zu sagen, was sind eigentlich die Annahmen dahinter? Was glauben wir, ist wahr, damit dieses Produkt fliegt? Und da mal zu sagen, welche dieser Annahmen sind bewiesen und welche sind nicht bewiesen. Und bewiesen heißt nie 100 Prozent. Aber wo gibt es irgendeinen Datenpunkt? Wenn der Datenpunkt ist, der CEO mag das, ist das ein schwächerer Datenpunkt als 500 Nutzer haben Pre-Order gemacht. Das muss man auch verstehen, die Gewichtung von Beweisen und Insights. Also ich habe dieses Verständnis, wo ist die unbewiesene Annahme? Und diese Annahme kann ich vielleicht nicht alleine testen. Gerade in größeren Firmen geht es wahrscheinlich nicht. Das heißt, der nächste Schritt muss eigentlich sein, diese Annahme sichtbar zu machen gegenüber Stakeholdern, Chefs, dem Team, wer auch immer das ist. Und erst dazu sagen, sind wir alle uns darüber im Klaren, dass wir dieses Investment machen, ohne diese Annahme validiert zu haben? Und manchmal ist das so. Manchmal kann ich es nicht weiter validieren. Ich habe darüber gesprochen, ich sage alle, ja, machen wir trotzdem. Dann ist es aber immerhin eine informierte Entscheidung. Und wenn ich sage, na guter Punkt, sollten wir vielleicht noch mal rauskriegen, kann ich sagen, ich glaube, gib mir zwei Wochen, unter diesen zwei Wochen würde ich versuchen, diese Annahme wie folgt zu testen. Und dann sind wir mindestens schlauer. Und dann können wir immer, das heißt ja nicht, wenn das fail, dann machen wir es gar nicht, aber wir können eine nächste informierte, hoffentlich noch besser informierte Entscheidung treffen. Und ich habe das immer wieder zu reduzieren. Und wenn irgendwann das ein Automatismus ist, zu sagen, wenn jemand mir eine Lösung zeigt oder irgendeine Priorität, zu sagen, wo ist die Unsicherheit? Wo ist die größte Unsicherheit? Was können wir tun, die zu reduzieren? Bevor wir uns dazu oder dagegen kümmern. Das ist wie so ein Muskel, wenn der eintrainiert ist und wirkt. Das Gute ist daran, damit muss ich nicht Frameworks einführen oder betonen oder Leuten sagen, jetzt machen wir diesen Prozess. Das ist eigentlich nur Deutsch, klare Sprache.

Jan: Hast du einen wissenschaftlichen Prozess? Welche Hypothesen stehen dahinter? Wie kann ich es testen? Ja. Und dann testen, wenn man es denn will. Cool, spannend und vielleicht, um da auch mal die Brücke zu unserem nächsten Thema, den OKRs heute zu schlagen. Discoveren tut man ja im Idealfall nicht einfach irgendetwas, sondern häufig hat man ja einen gewissen Zielsetzungsprozess, der vorhergegangen ist und das Thema OKRs, Objectives und Key Results ist ja seit, ich würde bestimmt sagen fünf Jahren, vier, fünf Jahren inzwischen, doch immer präsenter und in immer mehr Firmen auch in der Dachregion im Einsatz. Hast du Lust, uns einmal zu erklären, worum handelt es sich dann bei OKRs und warum sind die gerade so erfolgreich?

Tim: So erfolgreich sind ist glaube ich die richtig spannende Frage. Sind sie überhaupt erfolgreich ist glaube ich die spannende Frage. Aber der Kurzabriss ist für mich so wie ich es immer, es gibt natürlich, es gibt glaube ich zwei Schienen. Es gibt die religiöse Schiene, im Sinne von ja Google hat das so oder Intel gerettet und Google, die ganze Story ist überlassig, Leute können die Bücher, guckt euch Wikipedia, wenn ihr wollt. Wenn ich das für immer erkläre, versuche ich es immer auch hier, wie mit Discovery, aufs Wesentliche zu reduzieren. Für mich sind OKRs eine konkrete Art, Metriken zum Zielsetzen einzusetzen. So würde ich es immer sagen. Es ist am Ende, es basiert auf Metriken. Es ist eine bestimmte Art. Es ist keine Magie, es ist kein Voodoo, es ist kein Feenstaub drüber. Es ist einfach eine bestimmte Art Metriken zum Ziele setzen und zum Ziele erreichen einzusetzen. Und es kommt eben in diesem bestimmten Format, wie du schon gesagt hast, der OKRs besteht aus der qualitativen, der quantitativen Komponente. Also ich hab eine qualitative Komponente, die ist das Objective. Christina Wotke nennt das passenderweise immer eine Mini-Mission. Ich finde, das ist sehr gut, kann man gut greifen. Also ich sag, was ist meine Mission für die nächsten drei Monate qualitativ? Und dann gucke ich, welche zwei bis fünf Metriken kann ich benutzen, um zu messen, ob ich diese Mission erreicht habe. Weil das Objective an sich ist eben relativ fluffy, wenn ich sage, Mobile-Nutzer lieben uns wieder. Als Objective sag ich, ja, was heißt denn das jetzt? Dann sag ich, okay, das heißt irgendwie, das heißt eine Customer Effort Score von Y, das bedeutet eine Download Registration Rate von B und das bedeutet vielleicht so und so viele Upsells aus der App raus. Und das ist eigentlich das Prinzip, wo aus UKRs bestehen. Und genau, Punkt.

Jan: Ja, im Prinzip auch fast wieder ein Prozess, in dem es einmal darum geht, sich zu überlegen, was wollen wir eigentlich und dann ein paar Hypothesen dahinter zu formulieren indirekt, richtig? Also weil zu dem Zeitpunkt, wo ich mir überlege, was messe ich, habe ich ja schon gewisse Hypothesen darüber, was mein Ziel überhaupt bedeutet.

Tim: Genau. Und ich würde auch sagen, dass es ist schön, dass du es so sagst, weil ich sehe auch so, dass die Key Results, die ich benutze, die Metriken, die ich einsetze für diese Zielsetzung durch UKRs sind mehr oder weniger wahr. Im Sinne von, wenn ich ein richtig krasses Verständnis vom Problem habe oder ich bin vielleicht nur iterativ und sage, ich muss die Conversion Rate im Funnel von 5 auf 10 % heben, dann ist das so. Dann muss das Team rauskriegen, wie erlebe ich das? Versus, wenn ich es noch ein bisschen gröber rauskriegen muss, so was wie, ich will, dass Nutzer leichter ihre Rechnung hochladen können, ohne sie manuell einzutippen. Dann muss ich noch ein bisschen mehr überlegen, wie gestalte ich mehr Nutzerprobleme ausgerichtet. Aber ja, entweder mit mehr oder weniger Verständnis des Problemraums vorher.

Jan: Und ich hab vorhin einleitend so am Rande erwähnt, dass OKRs so erfolgreich sind. Wie erfolgreich sie dann im Ergebnis sind, ist tatsächlich eine Fragestellung. Aber eine Sache ist ja schon gegeben, dass die sind schon sehr in aller Munde, von Konzern über Mittelständler bis Start-up.

Tim: Die sind sehr populär.

Jan: Haben auf einmal alle angefangen, das zu machen. Genau, super populär als Konzept. Wie erklärst du dir, dass ausgerechnet dieses Format der Zielsetzung so einen Boom erfahren hat in den letzten 5, 6 Jahren?

Tim: Ich glaube, es ist zwar, meine Annahme ist zweigeteilt. A, es ist einfach das bekannteste Zielsetzungssystem aufgrund seiner Geschichte, seiner Popularität, aufgrund der Bücher, die darüber geschrieben wurden. Also von den Anfängen mit Andy Grove, High Output Management bis hin zu, ich finde für mich immer noch das eins der besten Bücher rund um OKRs, als ich damals gelesen habe. Radical Focus von Christina Wotke bis hin zu wiederum mehr die Google Brille, Measure What Matters von John Doerr. Meine Erfahrung ist, das John Doerr-Buch spricht sehr gut High Level Management an. Die finden das gut. Die wollen auch so sein wie die ganzen Silicon Valley High Growth Firmen und wollen das dann einführen. Und ich glaube auch viele ProduktmanagerInnen denken halt ja okay das machen andere Firmen auch so, das kann auch für uns auch gut sein. Ich glaube es gibt so dieses Top Down oder Bottom Up einführen wieder oder nehmen davon. Also ich glaube ein Teil ist wirklich dieser Appeal von anderen Firmen, so dieses Shiny Object Syndrom und zum anderen glaube ich trotzdem halt auch, dass sie eben auch Wert erfüllen können. Und natürlich komme ich, wie ich zu diesem Weg komme ist dann die spannende Frage. Meine Beobachtung ist, ich komme nicht zum Wert von OKRs, indem ich sie by the book einsetze, wie Google sie definiert hat. Das ist auf jeden Fall mein großes Take away.

Jan: Okay, erzähl uns mehr, da bin ich gespannt.

Tim: Das Problem daran ist, wie ich finde ist, dass Firmen sich zu sehr Gedanken drüber machen, ob sie OKRs korrekt gemacht haben. Und korrekt heißt dann so, es gibt ja vielerlei Richtlinien, wie OKRs zu sein haben. Wie ein Objective zu schreiben ist. Es gibt natürlich die Grundambition, dass meine Key Results immer Outcomes sein sollten. Und das ist so sag ich mal so was wie die, ich nenne das mal die technische Korrektheit von OKRs, die formale Korrektheit. Und die kann ich natürlich erreichen, indem ich ins Buch gucke und das abschreibe und interpretiere. Und für manche Teams ist das dann auch, sind diese OKRs auch nützlich? Ich glaube, was da aber fehlt, ist so ein bisschen der Kontext davon. Was heißt Kontext? Das heißt für mich, ist dieses Team überhaupt in der Lage, Outcomes zu beeinflussen? Sind die Outcomes überhaupt echt oder sind das Wünsche? Sind das überhaupt Nutzer-Outcomes oder Business-Ziele? Bin ich überhaupt in der Lage oder anderswo sind, was ich eigentlich sage, ich finde überhaupt 50% aller Issues mit OKRs haben nichts mit OKRs in Firmen zu tun. Was ich damit meine ist so was wie, wenn ich ein Quartal brauche, wenn ich mindestens 90 Tage brauche, um ein Feature zu schippen, kann ich per Definition schon mal nicht mit Quartalsweisen zielen arbeiten. Weil ich setze ein Ziel am Anfang des Quartals, um das Ziel zu erreichen, muss ich das Feature konzeptionieren, validieren oder hab ich vielleicht schon, bauen, ausrollen, iterieren und so weiter und so fort. Das geht schon mal technisch gesehen gar nicht. Dann bist du bei, okay, brauche ich einen längeren OKR-Zyklus oder sollte ich vielleicht, das ist die schmerzhafte Frage, sollte ich nicht die Art und Weise, wie ich Produkte release überdenke. Und das deswegen sage ich immer gerne OKRs lösen eigentlich fast keine Probleme, sondern sie machen die Probleme eigentlich nur sichtbar, schmerzhaft sichtbarer. Das Problem ist, dass viele Firmen es dann trotzdem auf OKRs schieben und sagen OKRs funktioniert nicht für uns versus wir haben die Rahmenbedingungen nicht geändert, die OKRs eigentlich brauchen nützlich zu sein.

Jan: Sind wir da auch gleich bei dem größten Antipattern, dass wir in der Einführung von OKRs finden, dass Firmen das einmal ausprobieren, über andere Probleme stolpern, die eigentlich nicht die Kernmethodologie sind und dann aber sagen, die Methodologie hat nicht funktioniert?

Tim: Ich würde sagen, es ist ja, es ist eins. Fairerweise die meisten Firmen, auch hier wieder ist ein Preis, die meisten Firmen, denen ich arbeite, haben schon irgendeine Form von OKR-Nutzung am Start und versuchen eher diese zu verbessern, was sie immerhin schon mal eher hat. Dass sie merken, okay, das nur by the book bringt uns erst mal nicht weiter. Wir brauchen irgendwie einen anderen Ansatz. Meistens ein angepassterer und pragmatischerer Ansatz. Für ein anderes Antipattern ist auch zu sagen, ich versuche das, auch ein bisschen wie mit Discovery, ich versuche das sehr gleich zu schalten. Ich versuche, dass alle Teams genau gleich Art von OKRs machen und versuche auch alles auf einmal zu ändern. Ich will das, ich habe irgendwie 40 Teams, ich will das alle auf einmal anders OKRs machen. Und ich glaube, es funktioniert nicht. Das ist so ein schönes Quote von einer Operations Managerin, der ich mal bei StepStone arbeiten durfte auf der Kundenseite, dass man Arbeitsweisen mehr wie Produkte und MVPs behandeln sollte. Und das würde ich machen. Ich würde die kritischste Annahme rausfinden. Ich würde einen kleinen Prototypen machen. Ich würde den Prototypen machen. Ich würde messen, ob der was getan hat und daraus basierend iterieren. Und das ist bei Arbeitsweisen glaube ich genauso anwendbar. Zum Beispiel bei OKRs, wenn ich nicht sage, ich rolle das auf 40 Teams gleichzeitig aus, sondern wir machen erst mal zwei Teams und gucken von da weiter.

Jan: Haben OKR-Prozesse denn, wenn man sie einführt neu in einem Unternehmen, Sachen, wo du immer beobachtest, dass kriegen den Aspekt von OKRs, kriegen eigentlich die meisten erst mal gut hin?

Tim: Ich würde sagen, vielleicht ist es zynisch. Ich glaube, dass du den kriegen die meisten gut hin. Also ich glaube, es ist auch genauso schnell leicht, sich zu einem Shiny Object-Syndrom zu verfangen, ich brauch mal ein OKR-Tool. Meine Antwort ist immer, nein brauchst du nicht. Google Sheets und Excel können dich sehr weit bringen, bevor du ein DNA-Tool brauchst. Ich glaube grundsätzlich, was schon viele verstehen können, ist die Power, die OKRs für eine Firma haben kann. Also okay, dass sie sich auch, was ich viel Wert lege, ist, eine Klarheit zu schaffen, was wollen wir mit OKRs erreichen. OKRs kann ganz viel bewirken, aber was soll OKRs für unsere Firma bewirken? Und das muss klar sein, weil ich glaube nur so kann man das auch in der Firma kommunizieren und wirklich auch die Leute mitnehmen, wieder so ein Passwort, dass sie auch verstehen, warum machen wir das denn? Und auch nur so kann ich ja bewerten, ob OKRs für uns funktioniert. Also wenn dieser Spruch kommt, OKRs funktioniert nicht für uns, würde ich verstehen, was heißt das denn? Was heißt denn nicht funktioniert? Was wollt ihr denn damit erreichen? Und dann stoss ich ihr darüber, okay, es ist gar nicht klar, was erreicht werden sollte. Und OKRs hat nicht funktioniert, heißt einfach nur, kein Team nutzt das.

Jan: Das Reporting wird einmal im Quartal ausgefüllt, vergessen und dann am Ende des Quartals, im besten Fall schreibt man nochmal 70%, 80% hinter die Ziele, aber lernt nichts draus. Ja, also ich muss sagen, ich hab's tatsächlich sogar immer mal wieder erlebt, dass wenn OKRs eingeführt wurden, dass das erste Problem, das man damit gelöst hat, ist sich überhaupt mal Gedanken darüber zu machen, welche Ziele geben wir unseren Product- und Engineering-Teams? Weil in vielen Umfeldern, die ich gesehen hab, ist es relativ klar, was die Ziele für das Sales-Team sind und auch das Marketing-Team kriegt klare Ziele mit. Aber speziell vor so sieben, acht Jahren ging das so los, wo viele Firmen verstanden haben, ah ja, unsere Product- und Engineering-Teams müssen empowered arbeiten, so arbeiten auch die besten Firmen, die dann aber überhaupt keine Idee davon hatten, wie führen wir diese Teams dann eigentlich in die richtigere Richtung. Und dass es dafür auch so eine Lösung war, hatte ich so wahrgenommen, wo ich dann aber auch gesehen hab, in vielen dieser Unternehmen hätte es schon gereicht, überhaupt mal ein Ziel aufzuschreiben. Also der ganze Rest von OKRs brauchst du gar nicht, sondern einfach mal zu sagen, dieses Quartal sollt ihr euch darum kümmern, das wäre schon ein Riesenschritt nach vorne gewesen. Ohne das ganze extra.

Tim: Ich finde, das spricht zu einem schönen Punkt an von, ich hab ja gesagt, OKRs sind eine Art, Metriken und Ziele zu benutzen. Ich glaube, OKRs werden auch immer ein Abbild davon sein, wie gut die Firma mit Zielen und Metriken umgehen kann. Wenn mir das schwerfällt, dann werden mir OKRs auch immer schwerfallen. Ich weiß auch mal, bei Xing war das so, stellte sich dann rückwärts raus, dass der VP von der Business Unit in Derch war, der hat im Prinzip OKRs gemacht mit uns. Er hat eine qualitative Überschrift genommen, die ein bisschen inspirierend war und vier Metriken definiert, die sich auf die verschiedenen Produkt-Teams verteilt haben. Nicht so formell und alles so, aber das Prinzip war das Gleiche. Und deswegen war es auch, ich fand es schon auch resonierend und klar, man konnte es gut drüber bringen, ohne diese ganze OKR-Formalität Folge zu leisten, was auch Sinn gemacht hat. Aber es hat trotzdem funktioniert. Das ist glaube ich das Ding, wie du schon gut gesagt findest, dieses, überhaupt erst mal das Ziel zu benennen, ist der Schritt eins, in welchem Format ich das dann nutze, ist dann eine andere Übung, die ich mir aussuchen kann.

Jan: Ja und vielleicht an den Gedanken einmal anschließend, viele entscheiden sich dann für das Format OKRs und ich hab ehrlich gesagt noch nie ein Team gesehen, das im ersten OKR-Zyklus erfolgreich damit gearbeitet hat. Es hat immer zwei, drei Versuche gebraucht, bis so ein Modus drin war. Hast du es einmal erlebt, dass man das wirklich beim ersten Mal, erstes Quartal durch und alle hatten einen Mehrwert draus gezogen?

Tim: Nee, auch nicht. Also es ist immer eine Reise.

Jan: Wie viele Zyklen brauchen denn die durchschnittlichen Teams, bis sie richtig in der Routine sind?

Tim: Es kann schon sein. Also es ist natürlich, das kann ich über die Lieblings Project Management Excuse machen, it depends. Aber gleichzeitig würde ich sagen, also die Frage, was heißt das? Aber zwei, drei Zyklen glaube ich ist schon realistisch. Wie auf dem Fall, wo ich starte, wenn ich von einem Ort starte, wo ich wenig mit Charity hab, wenig Daten, Access, wenig Analytics, wenig Discovery, wenig outcome-orientiertes Denken, vielleicht noch länger, weil das erst die ganze Firma bewegen muss, bevor ich den Mehrwert kriege. Wenn ich in der Umgebung das mache, wo die Firma gut geölt ist, was solche Praktiken angeht, dann vielleicht auch schneller. Aber ich glaube, dass wirklich dieses, es ist ja wie ein, ich glaube, wenn du jemanden sagst, der fängst morgen ans Fitnessstudio zu gehen, wann wirst du erst Ergebnisse sehen? Ja, vielleicht, wenn du das erste Mal warst, von krassen Muskelkater. Aber die richtige Veränderung, halt erst in sechs bis neun Monaten, wenn du jede Woche am Mist sammeln gegangen bist. Und so ein bisschen ähnlich ist es ehrlich gesagt damit auch.

Jan: Die Anarchologie zum Muskelbauen finde ich da auch ziemlich stimmig. Den muss man erst mal aufbauen. Was kann ich denn als einzelner Contributor in einem Team tun, wenn man Unternehmen vielleicht gerade im zweiten Zyklus mit OKRs ist, wir sind nicht mehr ganz frisch dabei, aber so richtig rund läuft es noch nicht. Was ist denn eine individuelle Sache, die ich angehen kann, um den Prozess zu stärken?

Tim: Ist eine gute Frage. Auch hier, ich bin ein Freund von in den Unterhaltungen, eher mit framework-agnostischen Fragen zu arbeiten. Also zum Beispiel gar nicht zu sagen, wie können wir unsere OKRs verbessern? Sondern eher zu fragen, zwei Lieblingsfragen, die ich habe in dem Kontext ist A, was wollen wir denn im nächsten Quartal anders machen? Oder Quartal oder Jahr, je nach Zykluslänge. Sagen wir mal Quartal. Weil darum geht es eigentlich bei OKRs. Es geht nicht darum, dass ich meine ganze Arbeit überall in ein anderes Format übersetze, sondern das als ein Tool benutze, um mich auf die Dinge zu fokussieren, die neben dem alltäglichen Business wirklich extra passieren sollen. Also Sachen, die ich eh machen würde, da brauch ich nicht einen OKRs packen. Also diese Frage aufzubringen, was wollen wir eigentlich anders machen? Weil auch das, wie du schon gesagt hast, das ist eigentlich die Frage, wo es geht, dass diese Unterhaltung stattfindet. Und dann sozusagen, welche Metriken können wir denn wirklich beeinflussen, die zu diesem, wir machen das anders passen? Weil das ist wiederum eine Beobachtung, eine der Hauptgründe, oder andersrum. Wenn es heißt Teams benutzen OKRs nicht, dann ist ein Teil davon, dass die Teams keinen Wert darin sehen, OKRs zu benutzen. Und dass sie keinen Wert daraus benutzen, kann einige Gründe haben, aber ein Grund ist eben auch, wenn die OKRs, die sie aufgeschrieben haben, ihnen gar nicht dabei helfen, Entscheidungen zu treffen oder zu priorisieren. Und das wiederum kommt daher, dass Teams Metriken in ihren OKRs haben, die sie gar nicht beeinflussen können. Und diesen Check mal zu machen. Diese Metriken können wir die eigentlich beeinflussen als Team mit dem, was wir tun. Wenn wir das nicht können, ist die Chance, dass die OKRs gar nicht nützlich sind für uns ziemlich hoch.

Jan: Okay, das heißt auch da wieder Klarheit herstellen über das Warum. Ich finde es eigentlich eine ganz schöne Analogie zu dem, was du uns vorher in dem Product Discovery Thema erzählt hast. Also immer wieder das Klären Warum und dann schauen, macht der rote Faden, warum das Tooling hier eingesetzt wird und wofür ich jetzt hier verwenden kann überhaupt Sinn. Oder besprechen wir hier ganz andere Zahlen und das Framework führt am Ziel vorbei.

Tim: Genau. Ja, das ist ganz gute Kombination. Zurück zum Why.

Jan: Ja cool und vielleicht kommen wir damit dann auch mal zu dem dritten Thema, das du ja viel bearbeitest. Wir kamen gerade über die Product Discovery, jetzt haben wir gerade über Objectives und Key Results geredet. Beides, also sowohl meine Discovery-Aufwände als auch meine Objectives und Key Results, lassen sich ja hoffentlich mit einer Product Strategy klammern, in dem Sinne, dass alle drei einem roten Faden folgen. Aber bevor wir einsteigen, wie definierst du persönlich denn Product Strategy?

Tim: Ja, der Product Strategy ist glaube ich der Begriff, wo ich mir am meisten von den ganzen anderen schlauen Leuten aus dem Internet das einfach wiedergebe, was die haben. Ich merke für mich funktioniert die Definition von Roger Martin, der How to Win geschrieben hat, am besten, der sagt, Strategie ist im Prinzip die integrierte Set an Entscheidungen, was mir dabei hilft, in dem Markt, in dem ich mich bewege, zu gewinnen. Und ich mag das, weil auch hier wieder es ist eine relativ kontextuelle Definition. Weil was mein Markt ist, kann so unterschiedlich sein. Für ein internes Produkt Team ist mein Markt vielleicht das Sales Department. Für ein externes Team ist es eine B2C-Gruppe, für ein B2B-Team ist es eine B2B-Gruppe. Mein Markt ist kontextuell und Gewinn heißt auch so viele Sachen. Gewinn kann bedeuten, einen Markteintritt und einen Wettbewerber abzulösen. Gewinn kann aber auch bedeuten, Effizienzen zu heben für ein internes Team. Und was ich eben daran mag, ist diese integrierte Entscheidung, wo es quasi die verschiedenen Aspekte meiner Arbeit, von Segmenten über Differenzierung, über Distribution, dass die auch in sich schlüssig sind und kohärent sind. Also so definiere ich das und auch da wahrscheinlich bin ich immer wieder in der Brücke. Es gibt so viele Wege, die dem in Service of sein können. Also so viele Dinge, die ich benutzen kann, um das zu erreichen, je nachdem wie ich als Team funktioniere, wo ich stehe oder welchen Weg ich gehen will.

Jan: Und vielleicht kannst du uns mal ein Beispiel nennen von einer besonders gelungenen Produktstrategie, dass es ein bisschen greifbar macht.

Tim: Ein Beispiel, was ich gerne erzähle, das hat Ravi Mehta geschildert in seinem Artikel, den Product Strategy Stack, was ich so als meiner Lieblingsstrategievisualisierung finde. Das ist nicht unbedingt ein Framework, aber Ansätze. Und da vergleicht er so ein bisschen Slack und Discord. Und ich finde es spannend, was Slack und Discord ist, dass sie so ein Funktional gemeinsam Länder haben, das Branding wegstreist, beides 1 zu 1 und 1 zu n Chatprodukte und die sich auf verschiedene Märkte ausgesucht haben. Slack hat irgendwann mal sehr bewusst gesagt, Community machen wir nicht. Sie werden zwar genutzt im Community Space ganz oft, aber wir machen das nicht. Das ist nicht unsere Zielgruppe. Sie gehen auf Professionals. Und was bedeutet das? Sie müssen quasi andere Wettbewerber im Professional-Kontext. Sie haben auf einmal Teams, früher noch HipChat, Outlook. Das sind die Wettbewerber, die Slack hatte dadurch durch den Professional-Kontext. Sie brauchen ein Pricing, was auf Ende auf Firmen ausgerichtet ist. So ein Pro-Seat-Modell statt ein Pro-Account-Modell. Sie müssen als ihrer Value Proposition auch Sachen wie Sicherheit und Integration und Cross-Contact-Kompatibilität drin haben und müssen sich eben auch anders differenzieren können. Das ist Discord, das sagt, wir gehen eben auf Community Spaces mehr oder weniger, also von Gaming bis in anderen Communities. Das heißt, es macht keinen Sinn nach einem Pro-Seat-Modell zu gehen, weil dann haben die Leute ja gar kein Incentive mehr Leute einzuladen. Und wir müssen andere Integration anbinden. Und wir haben nicht Teams als Wettbewerber, sondern wir haben vielleicht WhatsApp oder Facebook-Gruppen als Wettbewerber. Und wir müssen uns von diesen Wettbewerbern anders differenzieren. Also ich finde, das ist ein ganz schönes Beispiel, das sagt, du musst nicht eine einzigartige Grundfunktion haben als Produkt. Und das hat glaube ich dann mal Michael Porter gesagt, bei Strategie geht es nicht um besser, es geht um anders. Ich muss nicht versuchen, besser zu sein, sondern wie kann ich diese Kernfunktion, die ich habe, anders rüberbringen und in anderen Markt bringen, als meine Wettbewerber zu vermeiden, dass ich da verliere.

Jan: Kann man Product-Strategy von Marketing-Strategy trennen in so einem Fall?

Tim: Wie viel Zeit hast du? Ich glaube, trennen kannst du es nicht. Auch hier ist es wahrscheinlich eine Frage von, wie ist man Funktional in der Firma aufgestellt? Ich glaube, es gibt eine Schnittmenge. Nämlich, wenn ich mir Aspekte vom Produktschritt hier angucke, dann sollte ich auch meine Zielgruppe definieren, das Problem, was ich löse und meine Distributionskanäle, wie ich sie erreiche, sei es interne Produktoberflächen oder wirklich Marketing-Kanäle. Und das natürlich muss ich ganz stark mit der Marketingstrategie decken, im Sinne von, für welche Nutzergruppen entwicke ich Materialien, welche Pain Points kommuniziere ich und welche Marketing-Kanäle sind geplant. Das ist dann wiederum die Rolle der Company Strategy, die oben drüber sitzt, um den beiden genug mitzugeben. Und was das ist und jetzt weiß ich nicht, wie du das siehst oder deine Erfahrung ist, aber ich würde auch wieder sagen, ab einer gewissen Größe, meistens vor Product Market Fit, gibt es einfach glaube ich diese Begriffe nicht. Da gibt es nicht Company Product Marketing Strategie, sondern es gibt eine Strategie und die machen wir jetzt bitte an.

Jan: Ja, genauso habe ich das in Start-ups beobachtet und das ist da auch vollkommen richtig, weil zum einen muss man eh gucken, was kleben bleibt. Also wie viele Unternehmen laufen los und sagen wir sind ein B2B-Tool für X, wir machen Y, nur um zwei, drei Monate später festzustellen ach so, ne wir sind doch ein B2C-Tool, aber halt auch einfach, weil man das zufällig herausgefunden hat, dass eine gewisse Zielgruppe darauf gut anspringt. Das heißt da ist man sehr viel induktiver, sehr viel explorativer in seiner Produktstrategie und Unternehmenstrategie unterwegs. Und das alles aufzuschlüsseln, wenn sich das einerseits ständig überholt und andererseits da in vielen Fällen, sagen wir mal ehrlich, auch nur vier Leute insgesamt in dem Unternehmen arbeiten. Das ist ja vom Arbeitsaufwand her überhaupt nicht sinnvoll, aber die Beispiele, die du gerade im Kopf hast, das sind natürlich auch größere Firmen, wo auch mehr Leute an dieser Entscheidung für und gegen welche Struktur, gegen welche Strategie man da arbeitet, da mehr Leute dran abhängen.

Tim: Ich hab mal so ein schönes Beispiel, ich glaube das war im einem von Lenny's Podcasts vor ein oder zwei Jahren, da hatte er den Head of Product, damaligen Head of Product und VP Product von Substack zu Gast. Damals noch nicht das Produkt, was es heute ist. Und der hat erzählt, da gab es diesen Inflection Point bei ihnen, als die so zwischen 50 und 60 auf 100 Leute hochgegangen sind. Und dass sie dann wirklich angefangen haben, wie haben sie in Produkten gedacht? Und damals gab es eben, es gab ein Leserprodukt, ein Autorenprodukt und ein Infrastrukturprodukt sozusagen, Produktteams. Und das glaube ich ist dann ganz spannend, wenn man dann merkt, okay, wir müssen, auch hier, die müssen natürlich allein sein. Ja, also gerade das Leser und das Autorenprodukt muss natürlich allein sein. Auf eine gewisse Art und Weise und das Infrastrukturprodukt mit beiden anderen auch. Ich glaube, es gibt so diesen Punkt, wo man sagt, okay, jetzt haben wir verschiedene Produkte und die werden alle gemeinsam Länder haben. Sowas wie der Kernmarkt wird der gleiche sein. Das sagt die Firma immer noch vor. Aber die individuellen Entscheidungen, die jedes Produkt treffen muss, um zu gewinnen und diese Analogie und dieses Wort wieder rauszuholen, sind dann eben doch vielleicht individueller.

Jan: Ja, individuelle Entscheidung leitet mich fast auf meine nächste Frage. Du hast mit vielen Firmen an Themen der Produktstrategie gearbeitet. Was fällt den Firmen denn immer leicht und über welche Aspekte stolpern sie alle?

Tim: Ich würde auch dazu sagen, für mich ist bei Produktstrategie ist es so, ich habe Produktstrategie ist von den drei Feldern der Bereich, in dem ich am meisten implizit arbeite, im Sinne von es ist dann meistens gar nicht das Mandat, sondern es kommt eher hoch durch die anderen Themen. Was auch total Sinn macht, weil Produktstrategie ist halt, es ist so nebulös im Vergleich zu OKRs und Discoverys auch und es ist auch selten, dieser einmalige Aufwand, sondern es ist so, eigentlich was einen Vorteil auf dem begleitet, um diese Entscheidung auch zu übertragen. Vielleicht kommt es immer wieder so implizit hoch und ich würde sagen, die Sachen, die mir da war auffallend, ist a, diesen Mut zum Andersmachen. Also dieses, was machen wir denn jetzt anders als der Wettbewerber oder die anderen Wettbewerber? Und diesen schmerzlichen Zustimmung zu machen von, was machen wir denn deswegen aber auch nicht? Statt ich mache alles. Also statt alles aufzuschreiben, was mache ich denn anders? Das würde ich sagen, ist das eine große Ding. Und das andere auch hier finde ich, ist oft dieses, diese Balance zwischen dem Scrappy erstellen von strategischen Denken. Ich würde vielleicht gar nicht immer von der Produktstrategie sprechen, sondern eher von strategischem Denken und strategischen Entscheidungen. Dieses Scrappiness und dann aber zu sagen, wie spitze ich es denn zu? Also was ist denn jetzt wirklich, sag ich mal, das Format oder der Weg, mit dem ich es kommuniziere und die Leuten es am nächsten bringe. Und dann aber auch übersetzen die Umsetzung. Das Stichwort überführe ich dann auch in Ziele. Wie passt es zu meinen anderen Aktivitäten? Also dieses Wohlnebulöse auf der einen Seite, dieses Wahrende. Und okay, jetzt manifestiere ich es aber in diesem einen Format und stelle sicher, dass es auch umgesetzt wird.

Jan: Ja, spannend. Wie siehst du da bei dem Punkt, das ja dann doch Nein zu sagen, auch zu Sachen, die nicht Teil der Strategie sind? Hast du das immer mal beobachtet, dass das Leuten schwerfällt oder?

Tim: Also ich krieg das dann wiederum nur im Workshop-Kontext mit, fairerweise. Nicht im Doing, weil ich da nicht mit drin sitze sicherlich, aber dieser Schmerz, teilweise physische Schmerzen in den Gesichtern von Leuten, wenn ich dann so was sage wie, das heißt, dieses Segment priorisiert ihr nicht richtig. Ja, nein.

Jan: Wir sind auch wichtig.

Tim: Und das finde ich ist ganz spannend mit, das ist glaube ich eigentlich so der größte Brücke zu OKRs im Sinne von die Power, die sie haben können, ist, Strategie unnassbar zu machen, zu sagen, nur weil es nicht in der Strategie ist, heißt ja nicht, dass ihr den Leuten Zugang zum Tool versperrt. Es heißt doch nur, dass ihr dieses Segment priorisiert über die anderen. Genauso wie ich sage, nur weil es nicht in OKRs drinne steht, heißt nicht, dass es nicht gemacht wird. Die Wahrscheinlichkeit, dass es gemacht wird, wenn es einen Trail-off gibt, ist nur geringer. Und die Wahrscheinlichkeit, dass es nicht gemacht wird, ist höher. Das ist glaube ich dann so ein übergreifendes Antipattern, vielleicht noch rückwirkend zu OKRs. Dieses alles, was ich haben muss, sind OKRs abgebildet sein, sonst passiert es nicht.

Jan: Ja, übergreifendes Antipattern ist vielleicht ein ganz gutes Stichwort um zu unserem Hauptthemen-Komplex, in dem wir jetzt einmal über Discovery, Objectives and Key Results und Product Strategy geredet haben, um da nochmal so eine Klammer zu finden, bevor wir gleich in unsere schnellen Schlussfragen übergehen. Aus deiner Arbeit, das waren jetzt sieben Jahre beraten oder sieben Jahre plus sogar, wenn man da die angestellte Zeit da mit rein nimmt. Was würdest du so ganzheitlich aus deiner Arbeit mitnehmen? Was kann man unseren Zuhörerinnen und Zuhörern mitgeben?

Tim: Ja, wahrscheinlich wenig überraschend ist es für mich, dass die einzelnen Taktiken oder Methoden immer gegen das, was ich eigentlich erreichen will, zu halten. Sei es im ganz Kleinen von Experiment zur Annahme, aber auch grundsätzlich zu, ich führe diese Art des Arbeitens ein, was soll mir das eigentlich bewirken? Also der Kniff, den ich immer manchmal implizit einsetze, ist wirklich, kann man eine Art Value Proposition Statement, wie ich es für ein Produkt machen würde, auch für eine Arbeitsweise machen. Also für wen soll diese Arbeitsweise welches Problem lösen und wann wissen wir, dass wir es gelöst haben. Das muss nicht so formell sein, aber implizit diese Frage mal zu stellen, ist das, zu dem ich immer wieder zurückkomme, weil es eben die Konversation von der Methode, die wir schon gesagt haben, niemand braucht mehr Methoden, schifft zu wertvolleres oder wertstiftenderes Arbeiten.

Jan: Also immer wieder die Frage stellen, habe ich das richtige Werkzeug zur Hand, in anderen Worten, für das Problem, das ich hier hab.

Tim: Genau. Und ist das Problem auch das, was ich wirklich lösen will? Ja, das ist das Problem, glaube ich, sozusagen.

Jan: Siehst du in den letzten Jahren da eine gewisse Majority, die aufkommt bei den verschiedenen Firmen, mit denen du arbeitest oder ähneln sich die Probleme über die Jahre?

Tim: Stand heute würde ich sagen, die Probleme ähneln sich doch sehr. Das ist glaube ich die kurze Antwort.

Jan: Okay, dann ist das ja ein großer Appell an jeden Einzelnen hier, sich genau die Frage einmal zu stellen. Wir lösen die Tools, die ich habe, die wichtigen Problemen meines Unternehmens gerade.

Tim: Das wäre gut, dann würde ich mich freuen, mehr von zu sehen.

Jan: Cool. Wollen wir in die schnellen Schlussfragen übergehen?

Tim: Unbedingt.

Jan: Okay, erste Frage. Welches Produkt, digital oder physisch, hat dich zuletzt so richtig begeistert?

Tim: Wir haben es ja schon, wir haben es schon vorweg gesagt, ich finde digital fast zu langweilig. Das Physische, was mich, es ist gar nicht so in letzter Zeit, es ist einfach sofort laufend. Ich bin so ein großer Filter-Café-Nerd und hab mir vor letztes Jahr den Traum erfüllt und hab mir eine Kommandante C40 gekauft. Und jetzt die Nerds wissen es, das ist so der Goldstandard von Hand-Cafemühlen, handgefertigt in Bayern. Und da ich mir jeden Tag einen Filter-Café mache, ist das jedes Mal eine Freude, diese Mühle zu befüllen und zu bewegen. Das wäre ich nicht wühlig.

Jan: Ist dein Leben jeden Tag bereichert?

Tim: Auf jeden Fall.

Jan: Nächste Frage. Welcher private Aspekt deines Lebens wurde durch die Produktarbeit am stärksten beeinflusst?

Tim: Eine der sehr relevant ist, muss man für den Kontext sagen, meine Frau hat sich 2017 selbstständig gemacht und macht auch immer viel OKR-Beratung. Das ist ja immer als Familienkrankheit. Und wir haben tatsächlich, wir sind 2018 von Hamburg nach Erfurt gezogen in ihrer Heimatstadt. Und wir haben uns OKRs für den Umzug geschrieben. Für die Lebensplätze, was wir hier erreichen sozusagen, um zu bewerten, ob wir hier bleiben oder nicht. Das glaube ich so, as nerdy as it gets, ist wahrscheinlich sehr präsent.

Jan: Okay. Aber ihr brauchtet keine OKRs, um festzustellen, dass 100% eurer Möbel angekommen sind?

Tim: Nee, das hat Gott sei Dank direkt geklappt. Wir haben das dann auch aufgehört, das war wirklich für diese ersten zwei Jahre Ankommensperiode, wie es uns hier gefällt.

Jan: Cool. Was war das beste Fachbuch, das du je gelesen hast?

Tim: Das beste Fachbuch ist für mich tatsächlich, komme ich eigentlich immer wieder zu Relic the Focus zurück, weil die erste Edition, ich hab die ab 2015 gelesen, 2016, 2015, weil ich finde Christina, ich weiß gar nicht, wie es in der zweiten Edition ist, ich liebe diese Kombination aus, die Hälfte des Buchs ist eigentlich eine Geschichte und die andere Hälfte sind die Hard Facts über OPRs. Das ist wirklich ein genialer Weg, die Methode rüberzubringen.

Jan: Wie steigt man heute am besten ans Produktmanagement ein?

Tim: Das ist eine super gute Frage. Ich hab es gewünscht, wenn du jetzt so ein paar von den ganzen Product Guru LinkedIn AI Bros hättest, die könnten dir ihre Cheatsheets verkaufen, wenn du in die FPM-Karriere einkommst. Ich würde aber behaupten, heutzutage, was wichtiger ist denn je, ist eben weniger das PM-Betotische Fachwissen, sondern eher die ganzheitliche Denke, auch das steht heute Business-Ganzheitlichkeit. Also kann ich auch Business-minded denken und komme nicht überromantisiert rüber von Hauptsache Nutzerprobleme lösen. Also ich glaube dieser ganzheitliche Pragmatismus im Kontext einer Firma, würde ich sagen, das zu verstehen. Deswegen muss man jetzt vielleicht nicht Bilanzen lesen können, aber dieses ökonomische Verständnis. Plus, ich glaube auch ein unfairer Advantage ist, ich glaube wir werden ja viel darüber gedrillt, Empathie für unsere Nutzerinnen aufzubauen. Ich glaube aber, bin ich in der Lage Empathie den verschiedenen, vielleicht auch komplizierten Rollen und Stakeholdern meiner Firma gegenüber aufzubauen und zu zeigen. Es ist jetzt gar nicht so, was ist der konkrete Einstieg, darüber habe ich glaube ich gar keine qualifizierte Meinung. Aber ich glaube, so skillmäßig in diese Richtung zu gehen und überlegen, wie kann ich die demonstrieren auch in einem Bewerbungsgespräch oder Bewerbungsprozess.

Jan: Leitet ja fast in die nächste Frage, was kann ich als einzelner Produktmanager machen, als einzelne Produktmanagerinnen machen, um erfolgreicher in meiner Rolle zu werden?

Tim: Genau, wahrscheinlich diese beiden Sachen sind gut. Aber auch da wieder, ich glaube was extrem relevant ist, irgendwann habe ich den Spruch auch mal gesehen, wieso die eigene Karriere wie ein Produkt zu behandeln und so wie wir es vorhin über Arbeitsweisen gemacht haben, könnt ihr Erfolg quantifizieren. Also könnt ihr klären, wann denkst du, lieber Chef, Chefin, bin ich erfolgreich in meiner Rolle, was muss ich verändert haben? Sei es Metriken oder subjektive Wahrnehmung. Aber ich glaube, das zu objektivieren und quantifizieren, kann helfen viele Missverständnisse auszuräumen.

Jan: Welche Entwicklung in dem ganzen Fach des Produktmanagements erwartest du in den nächsten paar Jahren?

Tim: Jetzt kommt die Glaskugel. Ich persönlich, ich weiß gar nicht auf welchem Zeithorizont. Ich glaube, wir sind natürlich schon gerade in diesem großen Modus von AI, Efficiency, AI Supercharging von Aktivitäten. Ich hoffe, das Pendel wird noch weiter extrem ausschlagen. Und gleichzeitig denke ich, dass ab einem gewissen Punkt diese nicht Rückbesinnung, aber Wertschätzung von dem, was außerhalb von AI passiert, wiederum eine größere Bedeutung kriegt. Also von, okay, wir treffen uns für ein Workation-Retreat zusammen und sind einfach Menschen im gleichen Raum und gucken uns an. Also ich glaube, die nicht künstlichen Interaktionen, dass die mehr Raum kriegen. Und ich hab das wiederum auch oft mit Kunden schon mittlerweile, wenn man auch wieder Produktdenker anlegt. Ich glaube, so etwas wie Workshops haben eben nicht nur einen funktionalen Job, sondern auch einen emotionalen und einen sozialen Job. Und deswegen geht es nicht nur darum, wie viel lernen die Leute in den Workshops, sondern auch, wie viel Spaß haben sie miteinander, wie sehr haben sie sich miteinander verbinden können. Und ich glaube, dass die Aufmerksamkeit davon stärker werden wird, sobald das AI-Noise nicht weggeht logischerweise, aber vielleicht ein bisschen nachlässt.

Jan: Okay, vorletzte Frage. Was ist der beste Ratschlag, den du je bekommen hast?

Tim: Nicht immer zu denken, das Gras ist grüner auf der anderen Seite. Hat immer ein Chef mitgenommen. Vor allem auf Karriereentscheidungen bezogen, aber sehr universell anwendbar, finde ich.

Jan: Ja, sehr richtig. Man hört immer die besseren Geschichten häufiger als die schlechten. Und letzte Frage. Was möchtest du unseren Hörer und Hörerinnen heute noch mitgeben, was ich dich noch nicht gefragt habe?

Tim: Oh, was du mich noch nicht gefragt hast, das Demontrist habe ich nicht gerechnet. Ich glaube, ich würde sagen, was ich mitgeben würde ist, geht raus und erzählt eure Geschichten, weil ich finde, wir haben zu viel glorifizierte Beispiele und zu wenig so ist es wirklich. Und das kann so einfach sein, wie sprecht man bei einem lokalen Product Tank oder bewerbt euch auf einer Konferenz. Ich möchte mehr Leute hören, die einfach Bock haben zu erzählen, so war es bei uns für ein breiteres realistisches Abbild der Product Management Praxis in der Öffentlichkeit.

Jan: Finde ich einen sehr schönen Ratschlag und ich finde, du hast deinen Teil ja auch heute dazu beigetragen, indem du ein bisschen Realität aus der Dachregion geteilt hast. Vielen lieben Dank, Tim.

Tim: Sehr gerne Jan, hat mir viel Spaß gemacht.

Jan: Und damit sind wir auch schon am Ende der fünften Produktkraft Folge. Vielen Dank an unseren Gast Tim Herbig. Und wo wir gerade bei Tim sind, vielen Dank auch an Tim Nippert, der das Audio Engineering für diesen Podcast übernimmt. Kleiner Tipp, Tim macht das mit dem Audio Engineering auch freiberuflich. Meldet euch also gerne bei ihm, wenn ihr Support für ein eigenes Projekt braucht. Link in den Show Notes. Und wo wir gerade beim Thema freiberuflich sind, ich mache freiberufliche Produktarbeit und unterstütze euch bei Bedarf gerne. Meldet euch einfach via LinkedIn oder per jan at productkraft.com und wir schauen, ob und wie wir zusammenkommen. Macht's gut.