Wie sieht das perfekte Product Team aus?

**Intro: **Digital kompakt. Heute aus dem Bereich Tech mit deinem Moderator Joel Kaczmarek. Los geht's.

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek.

Ich bin der Geschäftsführer von Digitalkompakt und heute startet etwas Neues, Tolles für mich und auch für euch da draußen, denn wir werden hier mehr über Product-Themen reden. Es ist mir nämlich aufgegangen, wenn man über Digitalisierung und Digitalwirtschaft und die Unternehmen darin spricht, dann ist Product ein total zentrales Thema.

Und die Entstehung dessen von heute war, dass ich mit Gero zusammensaß, den kennt ihr aus unserem Sales-Podcast, Gero Decker von SAP Signavio, und der meinte, ey, ich hab da super Jungs fürs Thema Product, das wär doch was. So, gesagt, getan, haben wir uns zusammen telefoniert, getroffen, waren essen. Es war sehr lecker, kann ich sagen. Und jetzt nehmen wir uns vor, regelmäßig und öfter über Product-Themen zu reden. Wenn ich sage wir, dann sind das drei glatzköpfige alte weiße Männer, wie sich das divers gehört heutzutage. Nämlich einmal der liebe Till Reiter, der macht Product bei SAP Signavio und der gute Björn Wagner, der macht Engineering. Stellen sich beide gleich nochmal vor. Und wir machen heute den Auftakt, indem wir mal darüber reden, was macht eigentlich das perfekte Product-Team aus. Wir haben acht Faktoren identifiziert, von denen die beiden sagen, hey, wenn ihr die alle gut macht, dann seid ihr wirklich perfekt. Wir werden hinten raus sicherlich lernen, perfekt gibt es gar nicht, aber zumindest seid ihr sehr, sehr gut, wenn ihr viele von diesen richtig macht. Um euch mal so ein, zwei schon mal als Sneak Preview zu geben. Wir werden über sowas wie Customer Obsession reden, über Cross-Functional Collaboration oder auch über schöne Dinge wie Continuous Learning, Diversity. Also heute eine spannende Folge rund um den Aufbau des perfekten Product Teams. That being said, weiß man schon, worauf man sich heute freuen kann, aber noch nicht auf wen. Stellt euch das mal ganz kurz vor. Till, wir machen mit dir mal an.

Till Reiter: Ja, hallo Joel, freue mich hier zu sein. Till Reiter mein Name. Bin aktuell bei SAP Signavio als Vice President für Product Management. Für unsere Suite verantwortlich. War schon länger bei Signavio am Start, damals als Mitarbeiter Nummer 30 oder so vor acht Jahren. Das haben wir dann hochskaliert auf jetzt circa 1000 Leute und habe da die Skalierung aus Produktsicht mit vorantreiben dürfen.

Joel Kaczmarek: Mega, Björn, fehlst du noch?

Björn Wagner: Björn Wagner, ich bin bei SAP Signavio als Vice President Engineering für unser Process Mining Produkt zuständig und das trifft auch sehr gut eigentlich meine Hauptleidenschaft. Ich entwickle gerne Produkte, die komplexe Technologien vereinfacht und einer großen Menge an Nutzern zur Verfügung stellt und dort dann auch Wert schafft.

Joel Kaczmarek: Ja, guck, viele Leute wollen gerne Präsident werden. Ihr habt es geschafft. Sehr gut. Du bist weiß. Vielleicht mach doch den Hauptpräsidenten. Nein, Spaß beiseite. Ich glaube, man merkt schon, das Coole ist ja, wenn ihr beide da seid, dass man so einen gewissen Mix hat. Also der eine aus Product-Sicht, der andere aus Engineering. Wir werden es bestimmt auch mal machen, dass mal nur einer von euch da ist. Vielleicht noch Gäste. Gero hat auch schon angedroht. Er schaut mal vorbei. Und heute, wie gesagt, das Thema perfektes Product-Team. Dicklehnen wir mal durch. Fangen wir mal an. Also ich habe schon gelernt, das Erste, was ein perfektes Product-Team ausmacht, ist Customer-Obsession. Also auf den Kunden fokussiert sein. Wer von euch fängt an? Auf wessen Mist ist das gewachsen?

Till Reiter: Ja, das ist eigentlich auf unserem gemeinsamen Mist gewachsen. Also was meinen wir mit Customer Obsession? Das heißt wirklich, dass bestimmte Personen aus dem Produktteam sich tief damit beschäftigen, okay, was sind die Probleme von unseren Kunden, was sind deren Pain Points und aufgrund dessen Lösungen bauen. Amazon taugt immer gut so für die Intro. Die haben das schon immer so als eine ihrer Core-Prinzipien auch in ihren Annual Letters etc. veröffentlicht. Der Kunde kommt zuerst und der ihre Bedürfnisse, Jeff Bezos hat ja auch solche Dinge gesagt wie, es wird nie einen Kunden geben, der sich darüber beschwert, dass die Produkte zu billig sind, er zu viel Auswahl hat oder die zu schnell geliefert werden. Und du kannst andere Akzente setzen, aber ich denke, für ein erfolgreiches Produktteam muss das zumindest für Leute, die sich mit der Product Roadmap beschäftigen und das Backlog priorisieren, einer der Kernthemen sein, mit denen die sich Tag ein, Tag aus beschäftigen.

Joel Kaczmarek: Wie sieht denn das aus, mal blöd gefragt? Müssen die dann irgendwelche Design Thinking Sprints machen? Müssen die Customer Interviews führen? Müssen die irgendwie Feedback Reviews lesen? Wie sieht das denn aus, wenn man wirklich dem Kunden zuhört und der Kundin?

Björn Wagner: Ich würde sagen, es gibt immer drei Hauptbestandteile, die wichtig sind. Zum einen Daten, so viel wie möglich in den Produkten messen, um zu verstehen, wie nutzen die Kunden die Daten wirklich oder das Produkt wirklich. Der zweite Punkt ist eine gute Beziehung zu Key-Kunden zu haben, um mit denen halt qualitativ Interviews zu führen. Also es gibt User Research, ist eine eigene Disziplin, gibt sehr, sehr viele verschiedene Techniken, die man dort einsetzen kann. Grundsätzlich wichtig, eine gute Beziehung zu den Kunden haben, um halt genau zu verstehen, was sind wirklich deren Probleme, auch genau in die Tiefe gehen zu können. Und Beweggründe dort hinter zu verstehen. Und der dritte Punkt ist, wenn möglich, das hängt natürlich stark vom Produkt ab, dass man sein eigener Kunde ist. Das hilft, glaube ich, sehr, sehr stark dem Produktverständnis, wenn man auch selber sein Produkt nutzen kann.

Joel Kaczmarek: Ist das eher ein Produktthema oder ein Engineering oder in beiden Bereichen?

Björn Wagner: Beides auf jeden Fall. Produktmanager, Designer, Engineers, die Daten verstehen und nach Möglichkeit halt auch ihr eigenes Produkt benutzen.

Joel Kaczmarek: Und jetzt helfe mir mal, ich erinnere mich, ich habe einen alten Bekannten, der macht seit Jahrzehnten schon Usability. und dann habe ich immer bei EmoScout, gab es glaube ich diese Labs, da haben die immer, ich stelle mir das mal vor wie in so einem Psychologie-Kurs, hast du so einen Raum, wo die Leute vom Computer sitzen, haben irgendwelche Brillen auf, wo du siehst, so Eye-Tracking-mäßig, wo die hingucken und dann, wir haben so eine Scheibe, die war verspiegelt, da guckt die dann zu, ich stelle mir das mal vor mit so einem Klemmbrett, so Wissenschaftler, macht man sowas heutzutage noch, dass man auch wirklich Customer-Observation macht, die den Kunden dabei zuguckt?

Till Reiter: Wir machen das auch noch ganz intensiv. Wichtiger Unterschied hier ist, so klassisch kann man unterscheiden zwischen Business-to-Consumer-Modellen und Business-to-Business. SAP Signavio ist jetzt eher ein B2B-Modell, wo der Kunde etwas weiter weg ist und man teilweise den Kundenkontakt aufbaut über seine Customer Success. oder Support-Funktionen sehr dezidiert Sessions aufsetzen muss, zum Beispiel wenn man sowas wie Shadowing machen muss. Also wir haben es auch gemacht, dass wir zum Beispiel Usability-Breakfasts haben, wo wir Kunden einladen und sagen, ihr kriegt ein gratis Frühstück. Wir wollen euch dabei zugucken, wie ihr eure Probleme mit unserem Tool löst. Und da gibt es natürlich dann auch sehr breit gefächerte Customer- beziehungsweise User-Basis. Wir haben auch Customer, das sind die IT-Administratoren, die nur die Nutzer verwalten. Und wenn du jetzt von einem Immo-Scout sprichst oder von einem Facebook etc., da ist es sehr oft viel direkter, wo der Endnutzer direkt die App benutzt und man sehr oft einen direkten Draht hat und oft einfach bei einem Starbucks oder sonst wo sagen kann, hey, ich habe hier ein Interview, ich will das untersuchen etc. Also da gibt es unterschiedliche Wege, die Kunden zu interviewen, kennenzulernen, wo wir auch gerne mal in einer anderen Folge tiefer drauf eingehen können.

Joel Kaczmarek: So, jetzt bin ich natürlich ein bisschen abgebogen in den Inhalt, was Customer Obsession bedeutet. Die Frage ist ja aber vor allem bei einem Team, wie messe ich das? Wie erkenne ich, ob ein Team Customer Obsessiv quasi ist? Wie macht ihr das bei euch?

Björn Wagner: Wichtig ist eigentlich, wie viel Kundenkontakt die Teams haben. Wie gut die Teams mit Metriken an sich arbeiten. Also verstehen die Teams quasi anhand von Nutzerdaten, die sie haben, wie gut das Produkt in der Realität funktioniert. Und natürlich auch kann man sehr einfach messen, wie stark nutzen die Teams wirklich selbst die Produkte, um Probleme zu nutzen.

Till Reiter: Und vielleicht da noch hinzuzufügen, jetzt aus dem Nähkästchen zu sprechen, wie wir es zum Beispiel bei uns machen. Wir haben ein Konstrukt, das nennen wir die Integrated User Flows. Was sind bestimmte Jobs oder Jobs to be done? Nennen das auch mehrere Leute, die unsere Kunden oder User bewerkstelligen wollen oder müssen? Darauf definieren wir auch Metriken. Wie lange brauchen die, um diesen Job zu kompletieren? Wie zufrieden sind sie damit? Weil man kann sich natürlich nicht nur ganz darauf verlassen, dass jetzt jeder Ingenieur und Designer regelmäßig mit Kunden spricht. Teilweise muss man das halt über solche Modelle auch zentralisieren und messfähig machen.

Björn Wagner: Was natürlich auch noch wichtig ist, die richtigen Tools einzusetzen. Also du hast gerade schon Eye-Tracking angesprochen. Das ist ja was, was sehr mächtig ist, aber auch sehr aufwendig und sehr teuer am Ende. Es gibt ja ein riesiges Toolkit, wie man User Research macht. Und das fängt von ganz einfachen Methoden bis zu ganz komplexen Methoden. Das hat natürlich großen Einfluss auf die Kosten und Timelines. Um mal ein konkretes Beispiel zu geben, wir haben zum Beispiel auch Teams, die sich wirklich nur auf User Research fokussieren. Wir hatten ein Team, acht Wochen gearbeitet, wirklich perfekte Arbeit abgeliefert, abgeliefert. Aber wenn man sich die Ergebnisse anschaut und ich das Produkt selber genutzt habe, wäre ich zu ähnlichen Erkenntnissen in vielleicht einer Stunde gekommen statt in acht Wochen. Natürlich nicht in dem Detailgrad, aber es hätte halt geholfen, vielleicht schon schneller zu ersten Erkenntnissen zu kommen und dann halt auch natürlich schneller und agiler im Markt zu sein. am Ende. Das heißt, es gibt einen großen Zoo und es ist immer wichtig, quasi für die richtige Situation die richtigen Tools dann zu verwenden.

Joel Kaczmarek: Kommen wir mal zum zweiten Thema, haben wir auch, glaube ich, ein Stück weit fast schon angerissen. Data-Driven. Also ihr sagt, ein gutes Product Team ist auch immer datengetrieben.

Björn Wagner: Warum? Daten helfen einem, die Realität zu verstehen. Wie genau verwenden die Kunden, die Nutzer das Produkt? Ist der Wert, den wir von unseren Funktionalitäten quasi haben, ist der da? Auf der anderen Seite gibt es gerade im technischen Engineering-Bereich gerade ziemlich der Hype um so DORA-Metriken. Da geht es dann darum, das sind so vier Standardmetriken, die sehr, sehr nah an der Entwicklung sind. Dort gibt es sehr gute Benchmarks. Das heißt, man kann wirklich schauen, diesen Standardmetriken vergleichen und halt sehen, wie gut ist man denn im Vergleich zu anderen Firmen. Es gibt da jede Menge Datenpunkte, die dann auch zeigen, je besser die Teams in den DORA-Metriken sind, je erfolgreicher sind häufig auch Unternehmen im Markt. Das ist schon sehr stark korreliert. Und das ist halt zum einen Kundenverständnis, zum anderen aber auch Verständnis der Prozesse und Optimierung der Prozesse. Dafür sind halt Metriken und Daten sehr, sehr wichtig.

Joel Kaczmarek: Ich glaube, wir können über Daten wahrscheinlich zwei Folgen machen, so über Data Warehousing und wie man so Data Lake anlegt, Rohdatenverarbeitung etc. pp. Vielleicht könnt ihr ja nur mal so ein grobes Big Picture geben. Wie handhabt ihr das? Also muss Datengetriebenheit eine Eigenschaft auch jeder einzelnen Person sein? Verankert man das in Zielen, in Incentives? Löst man das über Tooling? Machen das nur bestimmte Rollen? Wie ist es bei euch grob aufgebaut?

Björn Wagner: Von meiner Seite aus sehe ich immer zwei Hauptsachen. Zum einen natürlich die technische Seite. Also dass man eine einfache Plattform hat, ist Leuten einfach möglich, Daten zu erfassen, Daten auszuwerten. So ein typisches Anti-Pattern an der Stelle wäre, man hat ein eigenes Team und jedes Mal, wenn ich halt ein Dashboard anlegen möchte, muss ich zu dem Team gehen. Das hat einen Backlog und dann warte ich zwei Monate, bis ich mein Dashboard oder die Zahlen habe. Also es muss irgendwie zum einen technisch eine einfache Plattform sein, um Daten erfassen zu können, um Daten auszuwerten zu können. Und vielleicht der viel wichtigere Anteil ist aber noch die zweite Seite und das ist die Teams quasi zu enablen. Also Statistiken, kann ich den Daten trauen, wie werte ich die Daten aus, bis hin zu welche Algorithmen, vielleicht sogar Machine Learning Anwendung kann ich auf den Daten machen, um halt das auch in den täglichen Arbeitsablauf mit reinzubringen. Also technisch sehr wichtig, aber halt auch die Leute zu enablen und quasi dort ein Verständnis zu schaffen, wo Daten Sinn machen und wie man das verwenden kann.

Till Reiter: Vor unserem Podcast war ich in unserer Quarterly Business Review. Es gibt zum Beispiel bekannte Frameworks, wie zum Beispiel das Heart Framework von Google. Es ist dann Happiness, Engagement, Adoption, Retention und Task Success, wo wir bestimmte Metriken für jede Dimension definieren und dann auch wirklich vierteljährlich tracken. Aber jetzt zum Beispiel im B2B-Kontext, da musst du drauf achten. Wie entwickelt sich unser Revenue? Für uns eine Core-Metric ist der Net Promoter Score und davon kannst du eben ableiten, okay, wenn du kundengetrieben arbeitest, was müssen wir anpassen, damit die entweder gut bleiben oder wieder nach oben gehen.

Joel Kaczmarek: Ich überlege gerade fast, man müsste eigentlich mal fast umdrehen. Es gab doch dieses Buch, ich glaube Paul Watzlawick war das, Anleitung zum Unglücklichsein. Du musst dich nur nicht dran halten und bist glücklich. Wie wird es denn bei Daten getrieben? Ich frage mich, gibt es eigentlich noch viele Unternehmen, die nicht datengetrieben sind? Das muss doch eigentlich fast der Standard sein, oder?

Björn Wagner: Ich würde sagen, da ist noch sehr viel Raum für Verbesserung. Also nur weil man Daten hat, heißt noch nicht, dass man mit Daten arbeitet, dass man Daten versteht. Auch gibt es sehr verschiedene Ansätze, wie Daten organisatorisch einfach in Unternehmen eingebunden werden. Es gibt Ansätze, wo mehr zentrale Teams zum Beispiel für Daten zuständig sind. Da gibt es Ansätze, wo man mehr in die Teams, in die verschiedenen Business Units, in die Teams rein, die Datenexperten, Data Scientists, Data Analysts setzt. Ja, es ist stark im Kommen, aber ich würde sagen, es ist auch noch viel Luft nach oben und auch viel zu lernen, auf jeden Fall, wie man dateneffizient einsetzt.

Till Reiter: Datengetrieben zu arbeiten ist am Ende des Tages meistens sehr viel Arbeit. Unter uns, wir sehen das auch, du hast dann unterschiedliche Systeme, du musst dann die Daten aufbereiten, crunchen, verstehen etc. Das richtig und intensiv zu betreiben, sehe ich nicht, auch in den Startups, mit denen ich zusammenarbeite und so, überall perfekt implementiert.

Joel Kaczmarek: Merkmal Nummer drei eines perfekten Product Teams. Agile war euer Buzzword, wo man ja, glaube ich, genauso viel reden könnte. Noch mal zwei Folgen. Also man kann, glaube ich, schon applizieren, was wir hier noch alles so besprechen werden. Deswegen lasst uns vielleicht nur so Big Picture machen zu dem Thema. Ich glaube, vielen ein Begriff, gerade auch Scrum war ja bei vielen so über eine gewisse Zeit sehr stark auf dem Radar. Was ist so euer kleines Einmaleins, wo ihr sagt, okay, ein perfektes Product Team aus Sicht von Agile muss Folgendes können.

Till Reiter: Für mich als agiles Produktteam, man kann es ja zum Beispiel erst mal an einem Beispiel aufmachen. Ich glaube, Corona war eine spannende Zeit zu sehen, welche Company irgendwie sich schnell bewegen kann, schnell anpassen kann. Also jetzt mittlerweile schon wieder abgestürzt, aber damals Lieblingsbeispiel war zum Beispiel Zoom, die dann wirklich sehr schnell Features umgesetzt haben für den Homeoffice-Bereich, sei es irgendwelche Backgrounds, um die Babys im Hintergrund oder die Unordnung wegzufiltern etc., Das ist für mich so der Hauptbestandteil von Agile zu sein. Du kannst dich im wechselnden Umfeld sehr schnell anpassen und Änderungen umsetzen.

Joel Kaczmarek: So, okay. Til war der Effekt. Björn muss dann erklären, was das kleine mal eins ist.

Björn Wagner: Der wichtigste Punkt bei Agile ist, dass man möglichst schnell iterieren kann und möglichst schnell kleine Verbesserungen des Produkts, kleine Inkrements auch in den Markt bekommt. Es gibt ja Kanban- oder Scrum-Ansätze, wo es sehr viel, sage ich mal, Lehrbuch zugibt. Wo ich aber finde, die jedes Team für sich selbst definieren muss, um halt dann das auch auf die Bedürfnisse des Teams oder des Produktes zuzuschneiden. Aber der Kern ist immer, möglichst schnell in kurzen Iterationen zu entwickeln und halt nicht in dieses Anti-Pattern wieder zu verfallen, dass man ein halbes Jahr, ein Jahr an einem Feature arbeitet, groß released und dann vielleicht merkt, das funktioniert ja gar nicht wie gedacht. Und deshalb, da helfen dann natürlich auch wieder Daten, dass man möglichst früh erkennt, auch anhand der Metriken, häufig auch den Minimum Viable Product, MVP. Bei uns, wir haben so einen schönen Begriff, Minimum Lovable Product, um nochmal so ein bisschen mehr die Customer Obsession da reinzubringen. Das heißt, möglichst klein anzufangen, früh in den Markt zu gehen, frühes Feedback einzusammeln und dann das Produkt Stück für Stück weiterzuentwickeln. Was man nicht vergessen darf, gerade wir haben es angesprochen im B2B-Bereich, die Kunden mitnehmen, gerade große Enterprise-Kunden, Enterprise-Anwendungen freuen sich halt nicht, wenn die gerade hunderte Anwender haben, wenn man plötzlich alle zwei Wochen das User-Interface umbaut und die hunderte Anwender neu schulen müssen. Das heißt dann, auch wenn man technisch vielleicht Releases alle zwei Wochen in Inkrements machen kann, dass man denn dort häufiger auch auf Fatalsweise-Zyklen geht, einfach weil man die Kunden und die Mitarbeiter der Kunden und halt auch die gesamte Go-to-Market-Organisation erst nochmal mitnehmen muss und auch über die, sage ich mal, neuen Features informieren muss, trainieren muss zum gewissen Teil. Hängt halt stark vom Produkt ab, glaube ich, große Unterschiede, B2B, B2C, wie schnell man denn wirklich iterieren kann. Genau, deshalb muss dann halt, wie ich gesagt habe, agil halt immer richtig ausgelegt werden.

Till Reiter: Agile heißt nicht keinen Plan haben und keine Roadmaps haben, sondern auf wechselndes Environment zu reagieren.

Björn Wagner: Die Roadmap-Diskussion, ja nein, ich glaube, das ist wie Apple versus Microsoft oder so. Da gibt es sehr, sehr verschiedene Positionen zu. Aber ja, also ich habe es auch häufig gesehen, dass Teams das Verständnis haben, ja wir wissen noch gar nicht, was wir machen. Wir fangen einfach mal an und dann sagen, ja wir sind ja agil. Aber das ist eigentlich genau nicht der Plan dahinter. Also der Plan ist einfach nur, dass man in kleinen Inkrementen sehr, sehr schnell vorankommt, aber halt nicht planlos agiert unbedingt.

Till Reiter: Joel, wie du hier raushörst, findest du ein natürliches Spannungsfeld zwischen Engineering und Product, wo Björn und ich auch schon des Öfteren drüber diskutiert haben, wie wir das lösen.

Joel Kaczmarek: Sehr gut, davon wird das hier leben, ich sehe schon. Wir vertiefen das mal an anderer Stelle und vielleicht verlinke ich auch mal in den Shownotes noch das eine oder andere, was wir zu Azure schon mal hatten. und kommen zum vierten Merkmal eines erfolgreichen Product Teams, nämlich cross-funktionale Kollaboration.

Björn Wagner: Wenn man sich anschaut, Design-Thinking-Ansätze, User-Centered-Design-Ansätze, dort steckt ja immer dahinter, dass man cross-funktional arbeitet, Leute aus verschiedenen Backgrounds mit verschiedenen Erfahrungen zusammenbringt und dort dann halt Methoden, Formate entwickelt, wie die miteinander kollaborieren können. Das einfachste ist, man nimmt einen Block, das heißt Crazy 8, ein Stück Papier, man faltet das so. Und dann muss jeder einfach mal acht Lösungen skizzieren. Dann macht man das ein paar Runden, baut auf den Ideen von anderen auf. Man hält sich am Anfang mit Kritik zurück an der Stelle. Diese Kollaboration erlaubt am Ende, dass man bessere Lösungen für die Probleme der Kunden entwickelt, als wenn man den Designer wieder zwei Wochen lang arbeiten lässt, der Product Owner dann die Lösung abhakt und dass man dann so dem Engineering Team, liebe Entwickler, über den Zaun wirft und sagt, jetzt macht mal bitte, weil dann fehlt A, das Verständnis, der Kontext. Es ist viel, viel effizienter, viel schneller. und die Lösungen werden auch besser, wenn man von Anfang an mit Engineers, mit Designern, mit Product Ownern effizient zusammenarbeitet und halt wahre Real-Time-Kollaboration hat an einem Whiteboard. Die Lösungen werden einfach besser durch die verschiedenen Perspektiven, durch die verschiedenen Erfahrungen am Ende.

Joel Kaczmarek: Also ich kenne das auch. Ich war in der School of Design Thinking im ersten Jahrgang, lustigerweise. Und die Aufgabe war, how might we make private households safe energy? Und dann haben wir so einen Energiezähler entwickelt. Und das Lustige war, in meinem Team war ein Softwareentwickler. Das heißt, der konnte den Softwaretat angucken. Ich war irgendwie so der Media Guide, das Frontend. Dann hatten wir eine Architektin, die wusste so Bescheid, okay, wo verbaut man die Dinger. Und ein BWLer, der sich über das Geschäftsmodell Gedanken machen kann. Also da ist es so plain vanilla. Ist es bei euch wirklich so im Product Team, dass ihr dann so vorleset, völlig andere Disziplinen habt? Oder ist es eher so, dass man sich das mal inputmäßig reinholt und dann damit arbeitet und die Leute aber wieder rausschiebt?

Till Reiter: Naja, es ist schon so, dass du dir die inputmäßig reinholst. Natürlich, wenn so eine Organisation skaliert, läufst du Gefahr, dass du bestimmte Silos hast. Du musst natürlich dann irgendwann mehrere Engineering Teams aufbauen, die an spezifischen Problemen arbeiten. Was wir immer stärker benutzen, ist so entlang der Customer Journey zu denken. Also wie tut das Produkt, an dem wir gerade arbeiten, die overarching Customer Journey beeinflussen? Und was hängt da noch mit dran? Das Lustige ist, wir haben auch mit einer Versicherung zusammengearbeitet. Die haben die Digitalisierung gerade durchgemacht. Und üblicherweise, das war so eine Versicherung, wo du halt dann, um einen Claim abzuschließen, hat dann der Kunde am Ende des Tages 20 E-Mails erhalten. Weil jede Abteilung dachte, okay, für die Frage kann ich denen eine Nachricht schicken und für die andere wieder und dann muss er das und das beantworten. Und da ging dann völlig verloren, okay, was ist eigentlich die Customer Journey und was wollen wir am Ende erreichen? Und deswegen hilft es in so Produkt- und Engineering-Organisationen, das auch irgendwie als overarching Prinzip immer wieder im Auge zu behalten. Und dann sieht man auch anhand dieser Journey, welche Funktionen und Bereiche wo involviert sind.

Joel Kaczmarek: Cool, also wir haben die Halbzeit jetzt hinter uns. Jetzt kommt Punkt 5 für das perfekte Product Team. Ownership. Was genau meint ihr damit?

Björn Wagner: Ownership ist ein Punkt, der auch den Teams hilft, zum einen einen gewissen Teil des Produktes komplett Ende zu Ende zu verantworten. In modernen Ansätzen hat man zum Beispiel keine QA-Engineers mehr, das heißt Leute, die nur für Qualität zuständig sind, sondern es gibt dieses Mantra, you build it, you run it. Das heißt, jedes Feature, was wir bauen, testen wir, also der Engineer, der das baut, entwickelt, der testet das bis zum Ende durch, deployt das und die Engineers sind dann häufig auch in On-Call eingebunden. Das heißt, wenn in der Nacht der Service nicht funktioniert, dann klingelt das Telefon und dann kümmert man sich darum. Und das sorgt halt dann dafür inhärent natürlich, dass dann jeder auch inzentiviert ist, quasi zum Beispiel die Qualität zu ownen und halt von Anfang an hochqualitative Software zu bauen. Zum einen gibt es natürlich auch dem Team gewisse Freiheiten. ja, also wenn man quasi für ein Produkt zuständig ist oder für einen Teil des Produktes, dann ist ja die Frage, wie steuert man das Team, ja, also sagt man dem Team, bitte baue diese Lösung. oder sagt man dem Team, hier ist ein Problem, finde eine gute Lösung gemeinsam mit den Kunden raus. oder geht man sogar so hin, dass man sagt, das Team, das hat nur eine Anzahl an Zielen, ja, Objectives, OKRs, Objective and Key Results sind gute Frameworks. und dann hat das Team halt quasi selber Lösungen erarbeiten, um diese Ziele zu erreichen, ist dann aber auch halt verantwortlich, accountable, wie man so schön sagt, dass diese Ziele erreicht werden, ja, Okay, dann habe ich es ja sogar richtig verstanden.

Joel Kaczmarek: Also es geht in die Richtung, dass man auch Themen wirklich besitzt und sich verantwortlich fühlt. Das kennt ja jeder so, ne? Wenn irgendwie, wie wenn man in die Kaffeeküche geht und da steht das schmutzige Geschirr, dann kann man die auch mal in die Spülmaschine holen, man kann Arbeit sehen. End-to-End ist dann vielleicht so das richtige Wort. Sechster Punkt für ein perfektes Product Team, Innovationen. Also innovativ will ja eigentlich jeder sein, aber was meint das spezifisch in eurem Bereich?

Björn Wagner: Mein Mantra ist immer, Innovation muss in der gesamten Organisation verantwortet werden. Das heißt, jedes Team ist für Innovation in dem Bereich zuständig. Das heißt, innovative Ideen entwickeln heißt, Lösungen für die Kunden zu finden, die es vielleicht vorher am Markt noch nicht gegeben hat, die besser sind als bestehende Lösungen und die vielleicht auch besser sind als die Konkurrenz. Ein Anti-Pattern, was man sehr häufig sieht, gerade bei größeren Organisationen, wie ich finde, sind Innovationsteams. Das hat irgendwie den Vorteil, damit sendet man dann an die Organisation die Nachricht, es gibt hier ein paar Leute, die machen Innovation und ihr macht nur den Rest. Das ist, glaube ich, ganz gefährlich. Ich glaube, es macht Sinn, Research-Teams zu haben, also die sich wirklich darauf spezialisieren. Vielleicht nicht, was man in den nächsten sechs oder zwölf Monaten macht, sondern eher das, was man vielleicht in den nächsten 24 bis 48 Monaten macht. Dort zu verstehen, was ist eigentlich möglich, wie kann man Risiken minimieren, was möchte der Markt eigentlich. und das sind so mehr Research-Themen, die man ein bisschen getrennt lagern kann, bevor man sie in die Produktentwicklung gibt. Aber sonst muss Innovation sowohl von der Verantwortung als auch von Mindset eigentlich in allen Teams liegen.

Joel Kaczmarek: Das finde ich einen guten Input, weil ich könnte mir vorstellen, dass viele das so machen, so nach dem Motto, da gibt es die eine Digitaleinheit, die einen, die innovativ sind, die Speerspitze und alle anderen, weil dann hat man auch ganz schnell diesen Effekt mit, die da drüben geben das Geld aus, was wir hier irgendwie verdienen und die dürfen Spaß, die Sachen machen wir nicht, kann ich total verstehen.

Björn Wagner: Und ganz wichtig, ganz viel Innovation stirbt dann einfach in dem Übergang. Also irgendwie jemand baut einen fancy Prototypen und sagt, das ist ganz toll, dann wird das irgendwie dem Board oder CEO präsentiert und dann hat man aber kein Buy-in, sage ich mal, von den Leuten, die das dann auch spannend finden, weil die eine fertige Lösung vorgesetzt bekommen, das dann jetzt auch wirklich ins Produkt, in die Realität reinzubringen. Das sieht man ganz häufig gerade in großen Organisationen auch.

Joel Kaczmarek: Ja, habe ich auch gedacht, da hast du quasi keine Ownership auf der Seite, die es machen, ne?

Till Reiter: Ja, und dann ist es teilweise auf einem anderen Tech-Stack gebaut etc. Und im Innovation-Team sieht alles ganz schnell ganz toll aus. Es gibt sehr schnell super Designs und Prototypen. Und dann denkt man, jetzt werfen wir es nur noch über den Zaun und dann wird das richtig gebaut. Und das ist, wie Björn sagt, auch bei uns schon öfter auf der Strecke geblieben. Deswegen muss man da die richtige Balance finden. Es gehört ein gewisses Mindset dazu, so ein innovatives Produktteam zu haben, weil die Innovationen lauern überall. Kann sein, du gehst auf den Kundentag, sprichst mit Kunden, kannst dann Input mit ins Team reinnehmen, du hast irgendwas Neues von der Konkurrenz gelernt etc. Da muss man die Augen offen halten und sehen, wie passt das jetzt in meine Ziele und generiert das Mehrwert für den Kunden.

Joel Kaczmarek: Könnt ihr mich aber nochmal abholen, wie messe ich denn das? Also wie merke ich denn, ob etwas eine Innovation ist und ob ein Teammitglied sozusagen auch innovativ denkt? Was sind so Merkmale? oder was ist der Benchmark? So müsste man ja fast denken.

Till Reiter: Innovation messen ist wahrscheinlich wirklich nicht so einfach. Wie ich gerade gesagt habe, es kann von überall her kommen. Eine Geschichte, die ich jetzt mag, was wir bei SAP Signavio gemacht haben, war noch bevor SAP uns gekauft hat, haben wir gesehen, wie SAP eins unserer Produkte in einer Art benutzt hat, wie es wirklich nicht gedacht war. Und dann hat halt ein Findinger-Ingenieur sich das genauer angeguckt und gesagt, hey, eigentlich wollen die das Problem lösen. Wenn wir die zwei, drei Sachen an dem Produkt anpassen, dann können wir das als neue Capability im Markt ausrollen. Und mittlerweile ist das bei über 500 Kunden im Einsatz und war sozusagen eine Low-Level, undefinierte Ko-Innovation mit dem Kunden.

Joel Kaczmarek: Unser vorletzter Punkt wird wahrscheinlich auch sehr stark ein Mindset-Thema sein, nämlich Continuous Learning. Also ist damit gemeint, dass das ganze Team diese Eigenschaft haben muss, lernen zu wollen oder verbindet sich noch mehr? Vielleicht könnt ihr das mal ein bisschen ausführen.

Till Reiter: Mittlerweile trifft das auf jedem Bereich zu. Tech ist vielleicht noch ein bisschen schneller wie woanders, aber das Umfeld ändert sich so wahnsinnig schnell. Ja, jetzt haben wir die letzte Welle mit JGBT und den Entwicklungen im AI-Bereich allgemein, die, glaube ich, große Veränderungen wieder mit sich bringt. Und da sieht man jetzt schon, Ja, wer sind hier? die findigen Jünger, die alles sofort ausprobieren wollen, die Lust haben etc. Aber du musst konstant am Ball bleiben. Ja, jetzt natürlich Björn wird mehr dazu sagen können als Ingenieur, die Libraries ändern sich, Technologien ändern sich. Und wenn du sagst, nö, ich habe das jetzt gelernt, das war das aus der Uni, dann bist du, glaube ich, nach 10, 15 Jahren kaum noch einsetzbar und lieferst auch nicht den Mehrwert im Produktteam. Google hat ja mal dieses 20%-Learning-Modell, dass man irgendwie jeden Freitag in bestimmte Moonshot-Projekte investieren konnte oder ins Lernen. Das hatten wir damals bei Signavio uns ein bisschen abgeguckt für ein paar Teams. Hat aber ehrlich gesagt nicht so toll funktioniert. Wir haben das damals die Gold Card genannt. Dann konntest du sagen, nee, nächsten Freitag lese ich ein Buch über Agile. Und dann hat es dazu geführt, dass im Büro Leute nachmittags auf der Couch saßen und gelesen haben. Das hat dann nicht den Effekt, den du willst. Also es muss schon mehr so ein Mindset der Leute integriert sein und ein kontinuierlicher Bestandteil von deinem Job sein. Aber klar kannst du es als Manager oder als Teamlead etc. fördern, indem du sagst, hey, wir machen heute einen Brown Bag Lunch oder wie auch immer man das nennt, wo wir eine neue Technologie vorstellen oder ein neues Thema diskutieren. Es ist ein Muskel, der konstant trainiert werden muss.

Joel Kaczmarek: Wie incentiviert man denn sowas? Also wie baut ihr Incentives, dass Leute auch Lust haben, sich mit neuen Dingen zu beschäftigen?

Björn Wagner: So eine gewisse Neugier ist, glaube ich, grundsätzlich da im Tech-Bereich vor allem. Incentivieren muss man das nicht. Es gibt natürlich Möglichkeiten durch irgendwie Hackathons oder so, was denn in der Entwicklung häufig passiert. Es gibt ja auch im Agilitätsbereich. dieses Konzept von Spikes, was explizit dafür gedacht ist, auch mal neue Sachen auszuprobieren, neue Technologien zu verstehen. Bei uns fängt das auch an, sogar schon beim Anstellungsprozess. Das heißt, die Frage ist so ein bisschen, sucht man Leute, die perfekt auf diese Jobbeschreibung, auf die Erfahrung, auf die Erwartung passen? Oder schaut man eigentlich vielmehr darauf, dass die Leute, man nennt es im Englischen so schön, einen Growth Mindset haben? Also, dass sie quasi sich schnell weiterentwickeln können, denn es ist gar nicht so wichtig, ob sie jetzt die genauen Skills haben, sondern sie können sich irgendwie schnell anpassen an neue Umgebungen, an Änderungen in den Produkten, Änderungen der Technologie. Das heißt auch schon beim Aufsetzen der Teams ist es wichtig, dass man sich darüber Gedanken macht und halt auch die Leute holt, die dort leicht für zu begeistern sind.

Till Reiter: Ja und auch als jetzt aus der Management Perspektive, die du gerade angeschnitten hast. Wir haben es auch über 50 Engineering Teams. Du kennst ja dann bestimmte Leute, wo du weißt, gut, die sind immer mit vorne dabei. Dann musst du halt gucken, dass die Team Komposition so aufgebaut ist, dass du Ambassadors über die Teams gut verteilst.

Björn Wagner: Man muss auch von der Kultur her den Raum geben, Fehler zu machen einfach. Also wenn man quasi eine Kultur hat, die Fehler sehr stark bestraft, dann hält man die Leute davon ab, zu lernen, neue Sachen auszuprobieren. Das Mantra ist immer, es ist okay, wenn wir Fehler machen, wenn wir davon lernen und dann auch strukturiert lernen. Da gibt es ja jede Menge Ansätze, Postmortems und dass man dann halt aber davon lernt und halt dort auch dieses Mindset hat, das braucht auch sehr viel Unterstützung aus dem Leadership Management und das ist nicht immer einfach umzusetzen in den Organisationen.

Joel Kaczmarek: Gut, unser letzter Punkt, der erschließt sich, glaube ich, sehr schnell. Ist vielleicht auch ein bisschen ähnlich wie die Cross-Functional Collaboration, nämlich Diversity. Also wahrscheinlich werdet ihr mir jetzt sagen, es ist wichtig, diverse Teams zu haben, damit man bessere Produkte baut, weil die sich mehr auf Bedürfnisse der KundInnen einstellen können. Ist es in die Richtung zu denken?

Till Reiter: Ja, also mir hat letztens einer, fand ich ganz lustig, eine Quote gesagt, Diversity ist ein bisschen wie Obstsalat. Wenn du nur Äpfel und Orangen verwendest, ist es ziemlich langweilig. Deswegen brauchst du da auch Trauben und Ananas oder wo auch immer man steht. Aber ich denke, das trifft auch auf Produktteams zu. Du kannst relativ schnell zu eintönig werden. Es heißt auch nicht, Diversity heißt, du brauchst jetzt die richtige Männer-Frauen-Quote oder so eine bestimmte Quote, sondern vor allem auch in den Denkansätzen. Deswegen, wir haben vorhin über Customer Obsession gesagt, divers ist auch, du hast auf jeden Fall einen in dem Team drin, der sich mehr damit beschäftigt, okay, das Produkt soll zum Beispiel sehr schön sein, es soll kundenausgerichtet sein etc. Und dass da unterschiedliche Denkansätze auch teilweise im Konflikt stehen, sodass man zusammen die beste Lösung findet.

Björn Wagner: Ein Beispiel kann ich aus meiner Zeit vorher im SAP Signavio bringen. Als App-Entwicklung ganz frisch war, es war so 2014, 2015, haben wir einen Fashion-App-Prototypen gebaut aus einem rein männlichen Team, was komplett an allen Zielen und Erwartungen vorbeigeschossen ist. Hier hätte halt ein diverseres Team bessere Produktentscheidungen getroffen und vielleicht auch dem am Ende zum Erfolg verholfen.

Joel Kaczmarek: Ich glaube, da gibt es ganz viele Beispiele. Ich habe mal von Christoph Werner erzählt bekommen, von DM, der Chef. Die DM-Märkte, das ist jetzt kein Software-Thema, aber ich glaube, da macht man die Denke mal so auf, dass die die DM-Märkte irgendwann umgebaut haben, weil früher war es ja immer so, man hatte diese Drehkreuze, kam in die Läden rein, damit kein Diebstahl zustande kam. Dann gab es halt zwei Punkte. Das eine war halt, okay, das ist halt irgendwie, wirkt ein bisschen unfreundlich und Menschen mit Behinderung kamen aber schwer in diese Märkte rein. und gleichzeitig musstest du auch die Gänge breiter machen. Was war der Effekt? Sie waren, glaube ich, der erste Mark oder einer der ersten, die diese Drehkreuze weggenommen haben. Auf einmal ist jeder, der viel lieber reingegangen, weil die Gänge waren breiter, die haben die Lichter heller gemacht, damit auch alte Menschen die Zettel gut lesen konnten. Und jetzt würdest du ja denken, okay, die Angst war ursprünglich, da könnte jemand klauen. War schon so, dass mehr Diebstahl zustande kam, aber es gab auch viel mehr Umsatz, weil viel mehr Leute gerne da gekauft haben. Das fand ich irgendwie so ein Beispiel, das mir unterkam. Gut, und jetzt machen wir mal ein kleines Summary. Also, wir haben gesagt, perfekte Product Team besteht aus acht Faktoren. Erstens, Customer Obsession. Zweitens, es ist datengetrieben. Drittens, es arbeitet agile. Viertens, es ist cross-funktionale Kollaboration. Ownership ist genauso wichtig wie Innovation und Continuous Learning. Und last but not least, Diversity. Bevor ich euch jetzt gleich frage, welches für euch die wichtigsten dieser Punkte sind, habe ich ja nochmal eine irgendwie flapsige Frage. Wir haben ja nirgends über Technologie geredet. Würdet ihr sagen, dass bald vielleicht das perfekte Product Team nicht mal nur aus Menschen besteht? Weil du hast ja auch ChatGPT so ein bisschen erwähnt gerade. Muss ich mich darauf einstellen, dass bald auch irgendwie KI das perfekte Product Team ergänzt? Oder ist das sowieso bei so Sachen subsummiert wie Innovation, Continuous Learning, dass ihr sagt, ja okay, Tech Adoption ist so Standard?

Till Reiter: Ja, du hast glaube ich schon das richtige Wort gesagt. Ergänzen ist schon in vollem Schwung. Ich habe schon vielen Präsentationen beigewohnt oder E-Mails gelesen, wo ich danach erfahren habe, das habe ich gar nicht gemacht oder mit Unterstützung. Ich glaube, das ist in Full Swing und die Engineers nutzen natürlich auch die Technologien, die ihnen zur Verfügung stehen, produktiver zu arbeiten. Replacement ist die größere Diskussion. To be figured out, aber als Bearing Partner ist die AI schon bei uns.

Joel Kaczmarek: Na gut, machen wir da vielleicht auch mal was demnächst. Und jetzt, wenn wir die acht Sachen uns nochmal angucken, was sind so eure beiden wichtigsten, die ihr sagt? Da lege ich ganz viel Wert drauf.

Till Reiter: Also für mich als Produktmanager ist die Customer Obsession die klare Nummer eins, die Foundation legt für gute Produkte und wo ich auch im Einstellungsprozess etc. am meisten drauf gucke.

Björn Wagner: Für mich ist es Customer Obsession auf der Seite, um die Probleme des Kunden genau zu verstehen und dann Cross-Functional Teams, um die besten Lösungen für diese Probleme zu entwickeln.

Joel Kaczmarek: Und wenn ihr euch jetzt nochmal die Art anguckt, was würdet ihr sagen, wo haben die meisten Unternehmen da draußen, wer vielleicht auch manchmal so ein bisschen an den verkrusteten Mittelstand denkt, Probleme und wo stellen sich die meisten Leute gut an?

Björn Wagner: Ich würde sagen, Customer Obsession ist häufig ein Thema, auch weil der Zugang zu Kunden schwierig ist. Typischerweise haben ja Go-To-Market-Organisationen Kundenkontakt, dass dann die Angst da ist, man nimmt jetzt die Engineers mit, die Product Owner und die erzählen halt irgendwas Falsches dem Kunden oder die stellen irgendwie die falschen Fragen. Das heißt, dort glaube ich, gibt es sehr, sehr viele Hürden.

Till Reiter: Du hast den Mittelstand angesprochen. Ich glaube, viele schmücken sich mit dem Agil-Wort. Wobei, glaube ich, in der Tech-Community schon oft der Witz gemacht wird, wenn du das in Job-Ausschreibungen siehst, dann halte ich lieber fern. Also da gibt es sicher Aufholbedarf. Ich glaube, Diversity ist so ein Thema, was gesellschaftlich bedingt aktuell einen sehr großen Aufschwung hat, glücklicherweise. Und ich denke, das geht in die richtige Richtung.

Joel Kaczmarek: Und jetzt muss ja die abschließende Frage lauten, kann man denn alle diese acht Punkte perfekt machen und muss man sie auch perfekt machen?

Till Reiter: Ja, ich habe mit Björn im Vorfeld diskutiert, habe auch gesagt, perfekt gibt es eigentlich nicht. Aber du hast natürlich immer Human Limitations. Menschen haben einen bestimmten Bias etc. Vergangenheit. Du hast strukturelle Limitations. Wie viel Budget hast du? Wann musst du ein bestimmtes Produkt liefern? Aber ich glaube, es ist gut als Zielvorgabe es anzustreben und immer daran zu arbeiten, die Faktoren, wo man gerade nicht so stark ausgeprägt ist, auszubügeln. Das ist natürlich dann auch für die Teamleads und Manager ein Punkt, wo sie darauf fokussieren sollten.

Joel Kaczmarek: Sehr gut. Dann hoffe ich doch, dass wir nach heute mehr perfekte Product Teams da draußen sehen. Man merkt, glaube ich, was für ein Auftakt einer Reise das hier ist. Also wir haben ja hier schon mal gefühlt acht Themen, die noch kommen können, wenn nicht mehr. Und da freue ich mich drauf. Also vielen, vielen Dank euch beiden schon mal und auf mehr, auf bald.

Björn Wagner: Bis dann. Danke.

Outro: Danke fürs Zuhören beim Digital Kompakt Podcast. Du merkst, hier ziehst du massig Wissen für dich und dein Unternehmen heraus. Wenn du mit uns noch erfolgreicher werden möchtest, abonniere uns auf den gängigen Podcast Plattformen. Und hey, je größer wir werden, desto mehr Menschen können wir helfen. Also erzähl doch auch deinen Kolleginnen und Kollegen von uns. Bis zum nächsten Mal.