Welche Rollen gibt es in Product Teams?

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 geht es mal wieder um das Thema Product und Tech. Ihr erinnert euch vielleicht, ich hatte ja vor kurzem den lieben Till Reiter und den guten Björn Wagner zu Gast. Die kommen regelmäßig jetzt zu uns, weil wir fleißig über Product- und Tech-Themen reden wollen. So, und die beiden sind bei SAP Signavio. Das kennt ihr auch, wenn ihr fleißig unseren Podcast mit dem guten Gero hört und machen da richtig coole Sachen. Und wir wollen, wie gesagt, regelmäßig über Product- und Tech-Themen reden. Und heute gehen wir mal in medias res, nämlich darüber werden wir reden, welche Rollen es eigentlich in Product-Teams gibt. Vielleicht erinnert ihr euch, beim letzten Mal haben wir darüber gesprochen, hört euch das sonst gerne nochmal an, was eigentlich das perfekte Product-Team ausmacht. Kurzzusammenfassung, Customer Obsession und Cross-Functional Collaboration. Hört da gerne nochmal rein. Und heute wollen wir das vertiefen in die Richtung, dass wir nämlich mal auseinandernehmen, welche Menschen braucht es dafür? Und wenn ich Menschen sage, meine ich natürlich die Rollen. Die werden wir alle durchdeklinieren. Wir werden also bei jeder Rolle immer sagen, was sind eigentlich die Erwartungen an die? Welche Ausbildung sollten die so haben? Welche Seniorität sollte ich vielleicht anstreben? Und was für Ausprägungen gibt es da eigentlich? Und dann auch noch so ein bisschen Big Picture, wie diese Rollen ins Team passen. That being said, lieber Björn, moin, schön, dass du nochmal da bist.

Björn Wagner: Hallo.

Joel Kaczmarek: Cool, ja, fangen wir mal basic an. Also wir haben ja schon gesagt, das letzte Mal, als Till und du hier waren, da haben wir über das perfekte Product Team geredet und heute nehmen wir das mal ein Stück weit auseinander. Fangen wir mal als Einleitung vielleicht mit der Größe an. Was sagst du, was ist denn so eine typische perfekte Größe für ein Product Team?

Björn Wagner: Ja, sehr gute Frage. Die perfekte Größe aus meiner Sicht sind immer zehn Leute. Es gibt auch so eine Anekdote aus frühen Amazon-Zeiten, wo es hieß, two pizza sizes, das heißt ein Team kann immer von zwei großen amerikanischen Pizzen zum Lunch oder zum Dinner gefüttert werden. Sobald es größer wird, sollte man es teilen.

Joel Kaczmarek: Was ist der Hintergrund, dass man es in der Größe hält, weil dann die Abstimmungsschleifen zu groß werden? oder die Vielfalt? oder wie muss man das vorstellen?

Björn Wagner: Genau. Je kleiner ein Team ist, desto besser funktionieren halt Abstimmungen, desto effizienter sind Kommunikationswege und desto weniger Meetings und Overhead hat man am Ende des Tages.

Joel Kaczmarek: Cool. Und ich sag mal so von der Verteilung her, ortsweise ist es wichtig, dass man zusammensitzt oder ist es mittlerweile eigentlich total remote? Ich würde sagen, in eurem Bereich wahrscheinlich so das remoteste, wo geht, ne?

Björn Wagner: Ja, hier streiten sich auch die Geister auf der einen Seite. Das Minimum, was man haben sollte, ist glaube ich dieselbe Zeitzone. Das heißt, dass man zumindest über digitale Wege effizient miteinander kommunizieren kann. Es hat auch viele, ich sag mal, weichere Aspekte, wenn das Team zumindest ein, zwei, dreimal die Woche zusammenkommen kann. Das hilft auf jeden Fall bei der Teambildung, ist auch ein wichtiger Kulturaspekt. Wenn man nur von zu Hause aus arbeitet, kann es sonst eher schwieriger sein und dieses Teamgefühl kann auch außen vor gehen, aber unterschiedliche Unternehmen gestalten das sehr, sehr unterschiedlich. Es gibt Leute oder Firmen, die halt auch in verschiedenen Ländern schon ziemlich früh die Leute wieder ins Büro zurückgebracht haben. Wir bei SAP Signavio haben eigentlich immer noch einen Ansatz Remote First aktuell. Das heißt, Leute, denen ist freigestellt, ob sie aus dem Büro oder von zu Hause aus arbeiten.

Joel Kaczmarek: Dann werde ich Till mal gleich eine SMS schreiben, dass er sich seinen Umzug nach Thailand abschminken kann, aber macht Sinn, was du sagst. Und dann lass uns mal durchdeklinieren. Also wir fangen mal mit der ersten Rolle an, der Klassiker eigentlich, der Software-Engineer. Was sind so die wesentlichen Erwartungen, die du an so eine Rolle stellst, wenn dir so jemand bei euch ins Team holt?

Björn Wagner: Also ich versuche es immer vereinfacht auf drei Punkte runterzubrechen. Das erste ist, Kundenprobleme zu verstehen, also wirklich nicht nur einen Input zu bekommen, bitte lieber Entwickler, baue jetzt diesen Screen, baue diesen Button, sondern im Detail zu verstehen, was ist das Problem des Kunden und gemeinsam an der Lösung, an der Gestaltung der Lösung auch mitzuarbeiten. Und dort hat der Entwickler dann in der Regel die Aufgabe, immer die Feasibility, das heißt die Umsetzbarkeit im Kopf zu haben. Das heißt zu sagen, auf der einen Seite, wenn man zum Beispiel mit den anderen Rollen im Design, einem Product Owner im Brainstorming ist, ja die Idee ist super, aber das kriegen wir technologisch nicht realistisch umgesetzt in dem Zeitraum, den wir uns vorstellen. Oder andersrum, hey die Idee ist gut, aber technisch haben wir da zum Beispiel noch schon ganz andere Möglichkeiten und wir könnten eine viel, viel bessere Lösung entwickeln. Das ist so Punkt Nummer eins. Punkt Nummer zwei ist dann Themen, häufig wenn man in Scrum Teams arbeitet, sind das dann User Stories, die in der gewünschten Qualität, in der gewünschten Zeit und auch im gewünschten Scope umzusetzen. Das heißt so Sachen auch über einen längeren Zeitraum richtig runterzubrechen, richtig planbar zu machen und dann halt auch in der Qualität, die der Kunde wünscht, abliefern zu können. Der letzte Punkt kommt dann aus dem Bereich DevOps. Da geht es immer darum, you build it, you run it. Das heißt, sobald Kundenprobleme auftreten, sobald es Bugs gibt oder Incidents, dass man dann möglichst schnell und effektiv dem Kunden die Fehler beheben kann und halt auch eine, sag ich mal, saubere Kommunikation mit dem Kunden hat.

Joel Kaczmarek: Okay, verstanden. Also im Prinzip höre ich dabei raus, es geht halt auch viel um Eigenverantwortung. Man kennt ja so manchmal die Classics aus dem Management, dass man sagt, die Strategie wird vorgegeben, aber die Taktik im Gefecht kannst du selbst entscheiden. Also höre ich da raus, dass bei so einer Software-Engineer-Rolle eigentlich wichtig ist, Problem verstehen, aber den Weg dahin, zusammen mit dem Faktor Feasibility, was du gerade gesagt hast, kann man selbst approximieren und selbst wahrscheinlich trotzdem in Kommunikation. sich erarbeiten und dann aber auch im Blick zu haben, okay, alles klar, das dann mal zu vertieft denken, ich muss mich drum kümmern, wie es gebaut wird und dann mich drum um die Pflege und was du eben noch meintest mit den User-Stories, da dann halt auch zu gucken. Cool, was ist denn so die Ausbildungsrichtung, nach der ihr zum Beispiel schaut? Also sind das so klassische Informatiker oder sind das speziellere Sachen? Was ist so das kleine Einmaleins der Ausbildung für einen Software-Ingenieur?

Björn Wagner: Genau, also ausbildungsspezifisch gibt es natürlich den Klassiker Informatik. Es gibt auch Neurostudiengänge, sowas wie Software Engineering und natürlich mehr und mehr auch Quereinsteiger. Das Thema Quereinsteiger ist sehr technologieabhängig. Ich sage, in Bereichen, wo es viel um Frontend-Mobile-Entwicklung geht, da ist es kein Problem, als Quereinsteiger zu arbeiten. Wenn es jetzt aber um komplexere Systeme, Datenbanksysteme, verteilte Systeme geht dann ist häufig ein Studium doch angebrachter, um dann halt die, sage ich mal, deutlich komplexeren Algorithmen, Probleme, an denen man arbeitet, halt auch entsprechend bearbeiten zu können.

Joel Kaczmarek: Ist denn eigentlich mittlerweile so ein Studiengang sehr spezifisch geworden? Also ist es zum Beispiel so, dass man sagt, keine Ahnung, wenn du Ruby magst oder PHP oder whatsoever, Dass du dann bestimmte Ecken dir anguckst und dass du sowas vorweist oder erzieht man diese Leute eher generisch?

Björn Wagner: Grundsätzlich ist das eher generisch. Das heißt im Studium werden auch, zumindest bei mir war das auch so, ich habe Software Engineering studiert, mehrere Programmiersprachen gelernt. Also es geht weniger darum, sich auf eine bestimmte Technologie, eine Programmiersprache zu spezialisieren. Es geht mehr darum, die abstrakten Konzepte dahinter zu verstehen. Und Technologie ändert sich natürlich sehr schnell. Es kommen neue Programmiersprachen raus, neue Technologien, neue Frameworks und es geht eher darum, diese dann auch zu verstehen und weiterentwickeln und adaptieren zu können, aber weniger sich im Studium schon relativ früh auf eine Sache einzuschränken. Später im Master kann man dann schon in verschiedene Richtungen gehen meistens. Können wir gerne später auch nochmal drauf eingehen.

Joel Kaczmarek: Und sag mal, jetzt haben wir ja das Thema Ausbildung sehr klassisch betrachtet. Ist es nicht vielleicht eher so, dass es manchmal auch so ist, dass du einen Software-Ingenieur vielleicht einstellst, der so mit 14 schon mal irgendwie das FBI gehackt hat und sich irgendwie selber Computerspiele programmiert hat? So Selbstlerner gibt es ja auch viele in dem Bereich. oder ist es eher schwierig, sowas halt, sag ich mal, messbar zu machen?

Björn Wagner: Es gibt natürlich auch viele, eher so im Bereich Quereinsteiger, Leute, die sich das selbst beigebracht haben, Leute, die das selbst gelernt haben und keinen Studienabschluss haben. Habe ich auch schon in einigen Teams gehabt und sehr, sehr positive Ergebnisse erzielt. Das macht auf jeden Fall Sinn. Ich glaube, man muss halt immer individuell schauen, was macht Sinn, welche Anforderungen hat das Team, welche Technologien werden auch verwendet. Und je nachdem dann halt entscheiden, ob es Sinn macht, halt mit Quereinsteigern zu arbeiten oder nicht. Ein anderer Punkt ist natürlich noch zum Thema Seniorität. Es macht natürlich Sinn, gerade Quereinsteiger auch im Juniorbereich zu haben und Leute in der Firma weiterzuentwickeln. Es ist grundsätzlich, egal wo man weltweit heilt, sehr, sehr schwierig, Leute zu finden im Bereich Software Engineering Entwicklung. Das heißt, wenn man Leute auch Quereinsteiger relativ früh einstellt und sie dann gemeinsam im Unternehmen durch die verschiedenen Senioritätsstufen entwickelt, kann man halt auch eine langfristige Bindung erzeugen und quasi seine Senior-Leute selbst entwickeln.

Joel Kaczmarek: Vertieft doch gerne mal den Faktor Seniorität. Also du hast jetzt schon gesagt, es gibt eigentlich diesen einen Track, der eher Junior ist, aber dann gibt es auch noch so Intermediates. Wie guckt ihr denn auf das Thema?

Björn Wagner: Wichtig ist ein guter Mix. Das heißt, im Team of Ten sind ja in der Regel so sechs, sieben, acht Softwareentwickler wirklich drin, die sich voll auf die Entwicklung fokussieren. Und hier ist es halt wichtig, einen Mix zu haben. Man hat in der Regel eine Person, die sehr, sehr senior ist. In der Industrie heißt das dann häufig einen Staff Engineer oder Tech Lead, der dann auch ein bisschen mehr Verantwortung hat, zum Beispiel strategischere Technologieentscheidungen für das Team zu treffen. Dann die meisten Engineers sind in der Regel Senior Engineers, das heißt ein sehr erfahrenes Level, Leute, die eigenständig auch komplexe Probleme lösen können. und das Team wird dann komplementiert mit Junior oder Intermediate Leveln, Leute, Quereinsteiger oder Leute frisch von der Universität. Die dann sehr, sehr eng zum Beispiel mit so einem Senior Engineer zusammenarbeiten können und dann halt auch lernen können. Es gibt ja auch sehr häufig Ansätze, sowas wie Pair Programming. Das heißt, Leute, man sitzt gleichzeitig vor einem Bildschirm oder virtuell vor zwei Bildschirmen. Einer schreibt den Code, der andere unterstützt. Hilft, kommentiert, googelt vielleicht nebenbei oder researcht gewisse Problemstellungen. Die Wissenschaft hat vermehrt gezeigt, dass das halt zu deutlich besseren qualitativen Ergebnissen führt und ist natürlich auch eine tolle Möglichkeit, Juniorleuten direktes Coaching on the job zu bieten sozusagen.

Joel Kaczmarek: Cool. Letzter Punkt, weil wir ja gesagt haben, wir deklinieren immer vier Sachen durch. Also wir hatten jetzt Erwartungen, Ausbildung, Seniorität. Welche Ausprägung gibt es denn so bei Software-Engineeren?

Björn Wagner: Da gibt es sehr, sehr viele. Hauptsächlich technologisch betrachtet. Auf der einen Seite gibt es so Frontend-Web-Entwickler. Es gibt dann sehr viele Leute, die sich auf mobile Entwicklung spezialisieren. Da gibt es dann wieder Unterbereiche. Entweder Leute, die sowohl, sage ich mal, für die Google-Plattform und für die Apple-Plattform beide Technologien bedienen können oder es gibt spezielle Frameworks, die hybride sind. Da muss man immer schauen, welche Technologie hat man im Team, welche Technologie macht auch strategisch Sinn und wie passen die Leute zusammen. Klassischerweise gibt es dann auch noch Backend-Entwickler, einige Teams schwören auch auf Frontend-Entwickler, das ist quasi Frontend und Backend-Entwickler. von einer Person gleichzeitig betreut werden kann. Es gibt dann noch speziellere Rollen, Database Engineering, Data Scientist im weitesten Sinne, das ist auch gerade ein sehr spannendes Feld, was sich entwickelt, würde ich auch unter der Engineer-Kategorie häufig einteilen. Da gibt es dann noch ein paar speziellere Ausprägungen. Also die Hauptsachen, die man eigentlich findet, aktuell ist so Frontend-Web-Entwicklung, mobile Entwicklung oder halt Backend-Entwicklung. Cool.

Joel Kaczmarek: Kommen wir mal zur zweiten Rolle und das werden wir glaube ich auch ein bisschen abgrenzen müssen, den Product Owner, weil es ja auch noch den Product Manager gibt. Wir fangen mit dem Owner aber mal an. Welche Erwartungen stellst du an einen erfolgreichen Product Owner?

Björn Wagner: Vielleicht bevor wir kurz auf die Erwartungen eingehen, dort gibt es sehr, sehr viele verschiedene Meinungen in der Industrie. Also ich würde jetzt nicht sagen, dass meine Meinung quasi das Vorherrschende ist. Ich glaube, wir haben ein sehr gutes Modell gefunden, wo wir quasi Product Owner und Product Manager Rolle trennen. Da würde ich heute mal im Detail drauf eingehen, möchte aber vorab gesagt haben, es gibt auch viele andere Ansätze, die erfolgreich in Organisationen funktionieren können. Aber wir haben halt auch bei SAP Signavio, wie auch in anderen Firmen, hatte ich häufig eine Trennung zwischen beiden Positionen. Angefangen beim Product Owner. Ein wichtiges Thema ist Stakeholder Management. Mit Leuten reden, mit Kunden reden, mit internen Leuten reden, verstehen einfach, was sind die Anforderungen, was sind die Probleme der Leute, um am Ende dann die richtigen Entscheidungen in Bezug auf Priorisierung zu treffen. In der Regel, wenn man mit zehn Kunden redet, haben die 20 Wünsche vereinfacht gesagt und die sich mitunter auch widersprechen. und dann muss man herauskristallisieren, was sind die wichtigsten, welche Richtung möchte ich auch vorgeben und was steht sozusagen auf meiner Prioritätenliste ganz oben, mit dem ich nächste Woche anfange, in die Entwicklung zu gehen. Zweiter Punkt natürlich ist, bei der Lösungsentwicklung hat der Product Owner dann in der Regel einen Fokus auf die Viability, das heißt, inwieweit macht das Feature aus einer wirtschaftlichen Sicht Sinn für die Firma, für das Produkt. Last but not least, der dritte Punkt, dort geht es darum um Planung, das heißt klassisch mit dem Team agile Zeremonien wie Planning, Demos durchzuführen, es geht dann auch darum, Delivery über längere Zeiträume zu planen, Roadmaps zu managen und am Ende auch den Release erfolgreich zu machen, denn das heißt ja nur, wenn man den Code geschrieben hat, ist das Feature noch lange nicht beim Kunden angekommen, da geht es dann sowas um Dokumentation, um Promotion-Material, Videos, erklären, was die Features eigentlich sind, was die können, das ist auch alles in der Regel im Rahmen beim Product Owner.

Joel Kaczmarek: Okay, das ist ja relativ plain vanilla. Wie ist es mit der Ausbildung? Weil ich mich gerade frage, das wirst du ja über das Studium wahrscheinlich schwer steuern können. Also Product Owner ist mir jetzt nicht so bekannt, dass man das studieren kann, vielleicht auch doch, dann korrigiere mich, aber worauf guckt ihr bei der Ausbildung?

Björn Wagner: Ja, das ist eine sehr gute Frage. Einige Universitäten fangen langsam an im Bereich Product Management und wie gesagt, da gibt es in der Regel einen größeren Overlap mit den Product Ownern. Studiengänge speziell dafür anzubieten. In der Regel haben die Leute aber ganz verschiedene Hintergründe. Die können sowohl aus einem, sage ich mal, technischen Informatikbereich kommen, die können aber auch aus einem Businessbereich kommen, früher zum Beispiel im Consulting gearbeitet haben, im Post Sales. Es gibt dann viel eher Trainings- und Zertifizierungssachen im Internet, verschiedenste Angebote verschiedenster Organisationen, die dort halt Weiterbildung anbieten, um halt die Anforderungen so ein bisschen zu standardisieren an der Stelle.

Joel Kaczmarek: Und welche Seniorität erwartet ihr von so einer Rolle?

Björn Wagner: Hier erwarten wir eher eine höhere Seniorität. Also ja, es gibt auch Juniorrollen. Wir haben ja in der Regel im Team of Ten wieder ein Product Owner und der muss schon komplette Verantwortung für das Team übernehmen können. Das heißt, wenn man jemanden hat, der sehr juniorisch ist der ist dann in der Regel nicht dazu in der Lage von Anfang an, zum Beispiel schwierige Priorisierungsentscheidungen mit großen Kunden oder Senior Management selbstständig machen zu können. Das heißt, in der Regel fangen wir beim Product Owner eher auf so mittleren Senioritätslevel an und dann besetzt man vorher halt andere Positionen. Das heißt, entweder man ist so Support als Junior Product Owner für ein anderes Team und dann so als zweite Person mit drin oder man macht halt ähnliche Analystenrollen vorher vorher. Um quasi dieses Senioritätslevel zu erreichen. Aber im Team of Ten in der Regel gibt es nur einen Product Owner in unseren Setups. Das heißt, hier braucht man schon ein gewisses Level an Seniorität, um dann halt auch die Verantwortung für das Team übernehmen zu können. Ja, cool.

Joel Kaczmarek: Und als letztes, lass uns auch da nochmal über Ausprägungen sprechen. Gibt es viele verschiedene Ausprägungen bei Product Ownern?

Björn Wagner: Ja, man kann sich zum Beispiel die Frage stellen, ob man Product Owner überhaupt braucht. Es gibt zum Beispiel Produktorganisationen, die vor allem eher technische Produkte anbieten, wo die Koordinierung und Backlog-Entscheidung halt von sehr seniorigen Software-Entwicklern auch übernommen wird. Ich hatte schon mal kurz angesprochen, das sind dann sowas wie Staff Engineers oder Principal Engineers in der Regel. Das heißt, die haben gar keine Product Owner, das heißt, das braucht man nicht. Hier hängt es wieder vom Produkt, von der Organisation ab, von der Seniorität der Leute, was für die Organisation am meisten Sinn macht. Und sonst hatte ich ja schon gesagt, die Herausforderung ist immer so ein bisschen die gesamte Teamverantwortung, aber auch es gibt einige Ausprägungen, einige Firmen haben technische Product Owner, die dann nochmal einen stärkeren Fokus auch auf sowas wie Technik, Architektur in der Planung haben.

Joel Kaczmarek: Jetzt bin ich mal gespannt auf die Abgrenzung, weil wir hatten jetzt den Product Owner als zweite Rolle und die dritte wäre der Product Manager. Wie unterscheiden die sich und welche Erwartungen stelle ich an die Rolle?

Björn Wagner: Ja, also hier gibt es, wie gesagt, verschiedene Denkmodelle. Wie wir das häufig definieren, ist, dass Product Manager hauptsächlich für die Perspektive, wir nennen das Outside-In, das heißt die Perspektive vom Markt auf das Produkt, auf die Firma zuständig sind. Das heißt, die beschäftigen sich zum Beispiel damit, wie positioniert man denn das Produkt im Markt, das heißt einen starken Fokus auf, wie positioniert sich die Konkurrenz, welche Features hat die, welche Strategien verfolgt die. Und kümmert sich dann, entwickelt basierend auf den Analysen dann halt eine Value Proposition. Das heißt, was ist wirklich den Value, der Fokus des Werts, den man dem Kunden zur Verfügung stehen möchte und wie entwickelt er sich auch. Das heißt, sehr, sehr zukunftsgerichtet. Wenn man gerade komplexe Produkte weiterentwickeln möchte, dann braucht man ja für größere Änderungen mehrere Jahre. Das heißt, man schaut auch, drei, vier, fünf, sechs Jahre in die Zukunft und schaut, wie sich das Produkt weiterentwickeln muss und fasst das Ganze dann eigentlich in so einer Produktstrategie zusammen, die halt, wie gesagt, nicht nur, wo ich sage, wo der Product Owner arbeitet, meistens auf so einem Horizont von vielleicht einem Jahr und sehr, sehr Problem- und Lösungsgetrieben, während der Product Manager eher marktgetrieben arbeitet und sich halt überlegt, was ist die Value Proposition, wie sieht die Produktstrategie aus, wo wollen wir uns langfristig hinzuentwickeln, wie ist sowas wie Pricing gelöst für die Kunden, für die verschiedenen Bereiche, Das sind halt Bereiche, die dann bei uns zumindest eher im Bereich von den Product Managern oder Product Leads, wie wir sie am Ende nennen, liegen.

Joel Kaczmarek: Spannend. Und bei der Ausbildung hast du ja eben beim Product Owner schon angedeutet, dass es Universitäten gibt, die das Thema Product Management in den Mittelpunkt stellen oder da schon was tun. Wie ist denn das in der Rolle?

Björn Wagner: Ja, es gibt einige Angebote, es gibt auch so ein MBA in der Regel, gerade in Amerika schon an einigen Universitäten, aber auch hier gibt es nicht, sage ich mal, den Standardweg, die Standardlaufbahn jetzt, um halt am Ende Produktmanager zu werden. Aus Produktmanager ist es sehr, sehr wichtig, halt. zusätzlich noch, gerade im Bereich B2B, wenn ich ein B2B bin, das ist im B2C-Bereich halt anders, aber im B2B-Bereich auch, den Rest der Organisation zu verstehen. B2B-Produkte werden ja in der Regel dann über große Sales-Organisationen im Direktvertrieb vertrieben, dann gibt es eine Pre-Sales-Organisation, dann gibt es eine Post-Sales-Organisation, wo dann Consultants, Customer-Success-Manager sich auch weiter um das Produkt beim Kunden kümmern. und die Idee ist so ein bisschen beide Perspektiven zusammenzubringen, sowohl die Go-to-Market-Perspektive als auch die technische, die Engineering-Perspektive, die miteinander zu verknüpfen, dort Brücken zu bauen Und halt nicht nur denken, was sind die Probleme des Kunden, sondern auch, wie wird das denn organisatorisch oder bei der Ausführung beim Kunden vor Ort ausgeführt. Also wenn ich ein komplexes Produkt habe, kaufe ich in der Regel nicht nur das Produkt, sondern ich kaufe auch Consulting-Dienstleistungen zu. Dann brauche ich vielleicht ein Partner-Netzwerk, um diese Consulting-Dienstleistungen, wenn die nicht nur selber angeboten werden, halt auszuführen. Das heißt, um diese ganzen Themen kümmert sich dann auch, die mehr marktbezogen sind, der Produktmanager. Und führt natürlich darüber hinaus auch noch, sehr großes und eine sehr enge Beziehung zu den Kunden, vielleicht kann man es auch so bezeichnen, gerade im B2B-Bereich, der Produktmanager fokussiert sich häufiger auf die Buyer-Persona, das heißt die Person, die am Ende die Kaufentscheidung trifft, während der Product-Owner und auch der Designer, auf den wir gleich noch kommen, sich eher darauf fokussieren, wie das Produkt für die Nutzer, was ja in der Regel zwei sehr verschiedene Personen sind am Ende, wie das Produkt für den Endnutzer optimiert werden kann.

Joel Kaczmarek: Und was die Seniorität angeht, hat man da eine ähnliche Anforderung wie in den Product Owner, dass das also Leute mit mittlerem bis hohem Niveau sein müssen oder vielleicht sogar noch höher, weil sie eine längere und eine marktgetriebene Perspektive haben?

Björn Wagner: Ich würde sagen auf jeden Fall, es ist sogar nicht unüblich einen Karriereschritt zu haben, dass man sagt quasi, man fängt als Product Owner an und entwickelt sich dann weiter in die Position Product Manager, groß in Unternehmen dann auch VP, Vice President Product Manager. Das heißt, dass quasi der Product Owner so eine Art Stepping Stone ist. Es gibt aber auch Karrierepfade, die eher aus dem Bereich Go-to-Market, Sales oder Customer Success Management kommen und dann in die Rolle Produkt reingehen, weil die ja dann auch ein sehr, sehr starkes Marktverständnis einfach aus ihrer vorherigen Rolle mitbringen.

Joel Kaczmarek: Wie ist es mit den Ausprägungen?

Björn Wagner: Ja, hier gibt es, glaube ich, zwei verschiedene Richtungen. Zum einen das Thema B2B und B2C. Das sind sehr, sehr verschiedene Produkte und sehr, sehr verschiedene Probleme, die man dort als Produktmanager trifft. Das heißt sowohl was Entwicklungszyklen, was Kundenverhalten angeht, wie man Kundenresearch macht, wie man mit den Kunden umgeht. Ich hatte es schon angesprochen, im B2B-Bereich ja häufig, dass die Buyer-Persona jemand ganz anderes ist, als er das Produkt am Ende nutzt. Der CFO kauft zum Beispiel oder der CIO eine neue CM- oder ERP-Lösung für das Unternehmen, aber wird das selber nie benutzen. Das heißt, man muss dann schauen, wie kann man zum einen natürlich das Produkt positionieren, dass der Buyer-Persona schmackhaft machen, während man gleichzeitig dafür sorgt, dass die Nutzer natürlich auch ihren Wert bekommen. Und auf der anderen Seite, im B2C-Bereich gibt es das halt nicht. Das heißt, hier arbeitet man dann auch im Bereich Marktforschung, im Bereich Marketing, mit Research, zum Beispiel in Bezug auf Pricing, mit ganz, ganz anderen Methoden oder Vorgehensweisen, wie das im B2B der Fall ist.

Joel Kaczmarek: Cool, du hast ja eben auch schon die vierte und letzte große Rolle, die wir besprechen wollen heute, thematisiert, nämlich den oder die Designer, Designerin. Beschreib doch mal, was mit dieser Rolle so verbunden wird und welche Erwartungen man da hegt.

Björn Wagner: Genau, auch Designer gibt es sehr, sehr verschiedene Interpretationen. Wie ich das hauptsächlich sehe, ist zum einen, ist immer die Erwartung verknüpft, sich schnell in die Probleme und die Domäne des Nutzers einarbeiten zu können. Das heißt, schnell in die Schuhe des Nutzers quasi schlüpfen zu können und zu verstehen, wo sind wirklich die Probleme, wie arbeitet der Nutzer, wie würde er arbeiten. die Software einsetzen. Da gibt es auch ein sehr interessantes Konzept, das heißt also natürlich Persona, das haben wir schon drüber gesprochen, so eine abstrakte Personenbeschreibung. und dann gibt es, was heißt das, das nennt sich Jobs to be done, das heißt man möchte verstehen, was ist denn wirklich der Job, für den der Nutzer das Produkt heiert sozusagen, ja. Und dann geht es natürlich darauf zu schauen, okay, in der Regel wird nicht der gesamte Job-Tipp dann vom Produkt nur abgedeckt, sondern da gibt es auch noch Lücken. und dann kann man halt verstehen, okay, welche Lücken möchte man entfüllen? und wie möchte man dem Nutzer eine gute und Ende-zu-Ende auch verständliche User-Experience, was dann der zweite Punkt wäre. wirklich schon Sachen testen zu können, validieren zu können mit dem Nutzer, zu schauen, ob Userflows, ob Screens, egal ob Web oder Mobile, halt so funktionieren, wie man sie hofft, sie funktionieren, bevor man eigentlich die erste Zeile Code schreibt. Und der dritte Punkt, dann geht es so eher um auch den visuellen Aspekt. Das ist jetzt sehr, sehr unterschiedlich. Häufig, gerade in größeren Unternehmen, hat man dort fest ausgeprägte Designsysteme. Das heißt, da entscheidet dann der Designer in der Regel gerade bei Standardkomponenten gar nichts mehr. Das ist quasi alles ein Portfolio, aus dem man sich bedienen kann. Natürlich gibt es, gerade wenn man Produkte bauen möchte, die nicht nur aussehen wie Template 17 in allen Screens, gibt es dann immer noch Möglichkeiten oder sage ich mal gerade so für Schlüsselinteraktionen, dass man halt dort auch schaut, hey, jetzt wirklich eine tolle visuelle Experience oder auch eine gute Interaktions-Experience dem Nutzer zu bieten. und das war so der große Teil. Also zum einen Research, verstehen, was will der Nutzer eigentlich? Was ist ein Job to be done? Dann über verschiedene Iterationen und Tiefen hinweg eine gute User Experience zu entwickeln und dann halt auch am Ende ein gutes visuelles und Interaktionsdesign zu haben, was die Bedürfnisse des Nutzers erfüllt. Das sind so die drei Hauptpunkte.

Joel Kaczmarek: Und kannst du nochmal spezifizieren, also auch auf die Gefahr, dass das eine dumme Frage jetzt ist, bei Designern denken ja die meisten Leute an schöne Dinge zeichnen, malen, also fast so in Richtung Grafik. Ist Designer im Bereich Product auch ein Programmierer? Also programmiert der selber zum Beispiel Frontend? Oder ist das eher jemand, der UX, UI macht? Kann es Verschiedenes sein? Vielleicht kannst du da nochmal so eine kleine Basic geben sozusagen.

Björn Wagner: Genau, also in der Regel programmieren Designer nicht. Die arbeiten dann eher mit Tools wie Figma, früher war es vielleicht Photoshop oder andere Tools, InDesign, um halt die verschiedenen, sage ich mal, Screens, Prototypen, Mockups, Das heißt, ein guter Hintergrund ist sowas wie Product Design, wo es dann wirklich auch darum geht, jetzt nicht nur um Formen oder verschiedene Aspekte, sondern auch nochmal das Produkt dahinter zu verstehen und auch wie das Produkt dann im Kontext oder in der Umgebung des Nutzers mit dem Nutzer interagiert an der Stelle.

Joel Kaczmarek: Ist Product Design dann auch die Ausbildung, die ich genießen muss, um sowas in einem erfolgreichen Unternehmen werden zu können oder gibt es noch andere Ausbildungspfade?

Björn Wagner: Ja, hier gibt es auch ganz verschiedene Möglichkeiten. Ich hatte schon gesagt, also häufig Product Design ist auf jeden Fall ein sehr guter und auch häufiger. Man kann ja aber auch aus verschiedensten Richtungen kommen. Also da gibt es auch nicht den einen Pfad, wo ich sagen würde, man muss jetzt das studieren. Es gibt auch Quereinsteiger. Hier ist natürlich, wie gesagt, je nach Ausprägung dann sowohl Kreativität ist halt wichtig, als halt auch gutes Verständnis, sich wie gesagt in neue, unbekannte Felder einarbeiten zu können, möglichst schnell.

Joel Kaczmarek: Wie ist es mit der Seniorität? Ich würde mal tippen, da ist man beim Designer eher wieder dabei, dass man wahrscheinlich von einem relativ Juniorigen bis hin zu einem Seniorigen alles abbildet. Oder ist das eine falsche Annahme?

Björn Wagner: Ja, absolut. Wir arbeiten mit Modellen, wo wir häufig einen Seniorigen-Designer mindestens in einem Team haben und dann auch noch einen Designer, zum Beispiel der gerade frisch von der Uni kommt, mit dazunehmen, einfach als zweiten Designer in dieses Team of Ten. Aber ja, auch hier gibt es quasi von Super-Junior bis halt sehr Senior. Das geht dann bis zum Head of Design hoch, der dann quasi So, Designverantwortung hat über ein ganzes Portfolio an Produkten, gibt es eigentlich einen sehr, sehr großen Karrierepfad an der Stelle.

Joel Kaczmarek: Und last but not least, lass uns doch auch nochmal ganz kurz über Ausprägungen bei Designern sprechen, weil du ja eben auch schon bei den Erwartungen, an die man diese Rolle stellt, gesagt hast, dass da eigentlich drei Sachen zum Tragen kommen, nämlich Research, Experience und Visual. Wie ist es da, welche Ausprägungen gibt es in dieser Rolle?

Björn Wagner: Ja, hier gibt es auch sehr viele, ein bisschen vereinfacht gesagt, häufig so die Product-Designer, die bei uns zum Beispiel in den verschiedenen Teams arbeiten. Das heißt, sie sind immer einem Team zugewiesen, können sich dann halt auch auf den Bereich des Teams spezialisieren. Einige unterscheiden explizit nochmal, auch zwischen Experience-Designern oder Interaction- und Visual-Designern. In der Regel, ehrlicherweise einfach aus Kostengründen, haben wir dann häufig eine Person pro Team, die aber ein breiteres Spektrum abdeckt, was wir dann Produktentwickler nennen. Wir haben dann zusätzlich noch Leute, die sind jetzt nicht in den Teams of 10 drin, sondern die unterstützen meistens eine große Anzahl von Teams of 10. Das sind sowas wie User Researcher, die dann sehr stark darauf spezialisiert sind, vor allem Research Tasks zu machen. Das heißt, bevor es überhaupt in Konzeption und Entwicklung geht. Es gibt ja im Designsystem, Schritt Nummer 1 ist immer das Problem zu verstehen, bevor man überhaupt in den Lösungsraum geht. Das heißt, die sich sehr, sehr auf den Anfang des Discovery Prozesses fokussieren. Das sind dann User Researcher. Es gibt dann noch sowas wie Strategic Designer, die so ein bisschen an dieser Vision arbeiten. Ich habe ja schon gesagt, der Product Manager arbeitet halt auch häufig daran, quasi weiter in die Zukunft zu schauen und natürlich möchte man das auch greifbar machen. So ein bisschen vielleicht ein Vergleich mit dem, was man in der Automobilindustrie hat, wenn man so ein Konzept-Car hat, wo man sieht, okay, so wird das vielleicht nie wirklich aussehen, aber das ist so eine Richtung, wo wir uns in drei bis fünf Jahren hin entwickeln können. Das machen dann so Strategic Designer. Und zusätzlich gibt es noch ein paar Spezialisierungen, Leute, die sich dann, ich habe die Designsysteme angesprochen, ja dieser Baukasten, aus dem man quasi dann Screens zusammenbauen kann, die müssen natürlich auch entwickelt werden. Da gibt es halt auch Leute, die sich dann, das sind dann quasi interne Teams, die allen anderen Teams dieses Designsystem zur Verfügung stellen und hier gibt es dann auch Designer, die sich dann darauf spezialisieren, halt diese möglichst standardisierte, aber sehr gute User Experience den Leuten zur Verfügung stellen zu können.

Joel Kaczmarek: Gut, wir haben jetzt also vier Rollen durchdekliniert, den Software-Engineer, den Product-Owner, den Product-Manager und den Designer. Wenn ich den sage, meine ich natürlich immer Unisex, also können auch die sein jeweils. Und jetzt gibt es ja noch eine Reihe von weiteren Rollen, die vielleicht jetzt, sagen wir mal, ein bisschen schneller abhandeln können. Was ist da wichtig noch auf dem Schirm zu haben?

Björn Wagner: Absolut. Es hängt immer von der Größe der Firma ab oder von der Größe des Teams, von der Größe des Produktes. Grundsätzlich haben viele Teams noch einen Scrum Master, das heißt, der ist ja auch im so Scrum agilen Setup sehr, sehr häufig. Was wir in der Regel machen, ist, wir haben nicht einen Scrum Master pro Team, sondern die Scrum Master teilen sich immer zwei Teams, also man ist als Scrum Master für zwei Teams verantwortlich und unterstützt halt das Team im agilen Arbeiten. Das heißt, es geht dann wirklich darum, wie kann man dauerhaft, das ist ja auch eins der Hauptmantras vom agilen Arbeiten, wie kann man halt dauerhaft besser werden, wie kann man dauerhaft lernen, verstehen, wie arbeiten wir, was funktioniert nicht und wie können wir halt durch die verschiedenen Zeremonien besser werden und der Scrum Master kann halt dabei helfen zu organisieren, versteht halt Blocker im Team und kann das Team halt einfach unterstützen, besser, effizienter zu arbeiten. Ich habe es dann nochmal extra aufgenommen. Ein weiterer Punkt ist so Data Scientists. Das Thema AI ist ja gerade in aller Munde. Ist natürlich auch sehr, sehr spannend, wie man Data Scientists im Unternehmen aufhängt. Also es sollte in der Regel nicht nur ein Team sein, was sich irgendwie nur um AI kümmert, sondern man möchte ja die AI-Funktionalitäten möglichst nah an die Produkte reinbringen. Das heißt, was man vermehrt sieht, ist auch, dass auf verschiedenen Ebenen, auch in den Teams of Ten teilweise, dann Data Scientists drin sind, die dann quasi mit ihrer Expertise unterstützen können. Da kann man, glaube ich, eine eigene Folge drüber machen von den verschiedenen Ausprägungen, die es da gibt. Ich würde es für heute mal dabei belassen. Noch zwei andere kurz erwähnen. Das ist ein Product Analyst, der auch nochmal unterstützt, zum Beispiel Wettbewerbsanalysen zu machen oder verschiedene andere Unterstützungsaufgaben für einen Product Owner, für einen Product Manager zu lösen. Man hat, wenn man mehrere Teams hat, dann ab einer gewissen Größe auch immer noch zusätzlich den bedarfenden Release Manager zu haben, gerade wenn man halt den Release vieler Teams synchronisieren möchte. Natürlich, einen Bereich haben wir heute komplett ausgeklammert, das ist der Bereich Manager und Leadership, aber das ist ein sehr spannendes Thema, ist vielleicht auch eine eigene Folge wert, da würde ich heute nicht mehr im Detail drauf eingehen.

Joel Kaczmarek: Cool, so, wir fassen jetzt also nochmal ganz kurz zusammen. Wir haben gesprochen über den Software-Ingenieur, gesagt, was da für Erwartungen an ihn gestellt werden, also Kundenprobleme verstehen, kreative Lösungen entwickeln, haben die Ausbildung klar gemacht, also Richtung Informatik, Software-Ingenieur oder auch mal Quereinsteiger, relativ breit in der Seniorität und halt in verschiedenen Ausprägungen zugegen. Dann den Product Owner, wo im Prinzip die Aufgabe ist, Problem- und Lösungsgetrieben, Features zu priorisieren, Stakeholder-Management zu betreiben und einfach auch die Kundenprobleme zu verstehen und Planung und Delivery zu machen. Mit dem Ausbildung, wo wir gesagt haben, okay, Product Management ist eigentlich was, was beide Rollen so als Ausbildungsfahrt haben können. Und beide Rollen, der Product Manager wie der Product Owner, teilen sich auch, dass das Senioritätslevel eher hochgelagert ist. Und in Abgrenzung dazu wäre jetzt der Product Manager, also jemand, der eher marktgetrieben schaut, outside-in, fünf Jahre Perspektive. Und die beiden Ausprägungen hat es ja auch schon genannt mit B2B versus B2C und diese Doshi-Types. Und last but not least hatten wir den Designer, der drei Aufgaben hatte, Research, Experience und Visual. Und wo man eigentlich sagt, es kann ruhig auch von juniorisch bis seniorisch gehen. So. Jetzt ist die Frage, die ich noch abschließend an dich hätte. Du hast ja gesagt, es gibt diese Teams of 10. Ist es so, dass ich mir das so vorstellen muss, wenn ich jetzt ein komplexes, großes Produkt wie ihr baue, dass ich wirklich mehrere von diesen 10er-Teams habe und dass es dann immer diese vier Rollen plus noch die weiteren Add-ons, die wir hatten, also Scrum Master, Data Scientist, Product Analyst und Release Manager in diesen Teams hat? Und ist es immer gleich? Also es ist meinetwegen immer sowas wie sechs Engineer, ein Product Owner, ein Product Manager, ein Designer. Wie muss ich mir das vorstellen, wie so der Aufbau da ist?

Björn Wagner: Genau, wir haben sehr, sehr viele Teams. Ich glaube insgesamt, ich kenne die Zahl gar nicht, aber ich glaube deutlich über 20 Teams. Die sind alle sehr, sehr ähnlich aufgebaut. Bei mir in der Organisation haben wir sozusagen den Tech-Lead, den ich angesprochen habe, das heißt den seniorigsten Manager, der Designer und der Product-Owner, das nennen wir das, das Power-Trio, die arbeiten sehr, sehr eng zusammen. Und das setzen wir auch in allen Teams voraus. Das heißt, das sind alle Teams gleich und sogar wenn wir neue Teams aufbauen, sagen wir, das Team kann nicht anfangen zu arbeiten, wenn wir nicht alle drei Rollen haben, weil dann halt eine Perspektive fehlt. Die drei sind sozusagen der Kern des Powertrio. Natürlich werden dann externe Leute, andere Engineers noch mit dazugenommen, aber das ist so der Kern des Teams. Der ist halt gleich. Wo sich die Teams dann ein bisschen unterscheiden, ich hatte schon gesagt, manche Teams haben sogar zwei Designer, gerade wenn es seniorige Designer ist. Was sich häufig unterscheidet, denn je nach Fokus des Teams, die Zusammensetzung an Engineers, vor allem in Sachen Spezialisierung. Also wenn es ein Team ist, was zum Beispiel nur Backend-Services baut, dann kann es sein dass dieses Team halt vielleicht auch gar keinen Designer hat, das wäre eine Ausnahme, aber halt auch nur Backend-Engineers hat. Wenn es aber ein Team ist, was hauptsächlich an Frontend-Themen arbeitet, dann ist es halt ein Team, was zum Beispiel hauptsächlich Frontend-Entwickler hat. Oder wenn es ein Team ist, was mobile Anwendungen entwickelt, kann auch ein Team sein, was nur aus mobilen Engineers besteht. Das heißt, an der Ausprägung der Engineers gibt es dann halt häufig Unterschiede, je nach Fokusbereich. Aber sonst zumindest Product Owner, Tech Lead müssen da sein und sobald halt UI im Spiel ist, halt auch ein Product Designer.

Joel Kaczmarek: Ja, cool Björn. Also in einer knackigen halben Stunde mal alle Rollen des Product Teams irgendwie durchdekliniert. Kannst du schon eine kleine Sneak Preview geben, was so als nächstes oder nächste Themen kommen werden, was du dir schon vorgenommen hast für uns, wenn wir Product und Tech ein bisschen besser verstehen wollen?

Björn Wagner: Ja, wir haben jetzt sehr viel über Teams, Rollen und Leute gesprochen. Als nächstes würde ich dann nochmal das Thema Technologie, ich glaube da warten vielleicht einige schon drauf. Wir reden ja viel über Produkt und Technologie, aber haben uns jetzt sehr stark auf die Rollen und die Eigenschaften der Teams bezogen, dass wir wirklich ein bisschen Deep Dive machen in Technologie. Wie treffe ich Technologieentscheidungen? Das Thema Technologieassets vielleicht auch beleuchten und dort mal tiefer einsteigen.

Joel Kaczmarek: Ja, cool. Das wird auch spannend. Dann danke ich dir ganz herzlich. Bin gespannt, wann der liebe Till auch mal wieder dazu stößt. Freuen wir uns auch schon drauf. Und ja, für den Moment vielen, vielen Dank.

Björn Wagner: Gerne. Tschüss.

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.