# AWS Product Management Strategy and AI Impact

**Podcast:** Engineering Kiosk
**Published:** 2026-02-03

## Transcript

Willkommen zu einer neuen Episode des Engineering Kiosk Podcasts.
Heute wird es mal Zeit an eine Lücke zu schließen, die wir viel zu lange ignoriert haben.
Wir reden gefühlt in jeder zweiten Folge über Product Owner, Backlogs und Prioritäten.
Aber eine echte Episode zum Thema Produktmanagement?
Fehlanzeige.
Bis jetzt.
Durch Zufall sind wir an einen Kontakt zu Michael Gasch gekommen.
Michael ist Produktmanager bei AWS im Serverless Umfeld.
Amazon selbst gilt als eine Art Vorreiterorganisation, was das Thema Produktmanagement angeht.
Zwei Pizzateams, 5 Fragen-Dokument und Working Backwards, indem man als erste Aktivität eine Pressemitteilung über das neue Feature schreibt, sind nur wenige Buzzwords aus dem Amazon-Kosmos.
Mit Michael steigen wir tief ins Produktmanagement ein.
Was ist Produktmanagement eigentlich und was ist es definitiv nicht?
Warum ist Projektmanagement nicht einfach nur ein anderes Word for Productmanagement?
Wo ist der Unterschied zwischen Produktmanagement bei BMW, Booking.com und einem Produkt mit technischer Kundschaft wie AWS.
Ist jeder in irgendeiner Art und Weise ein Produktmanager?
Inwieweit macht AI den Job obsolet oder stärkt diesen Genf sogar?
Is Productmanager eine glorifizierte Rolle als Jira Backlog Maintainer?
Und was können SoftwareentwicklerInnen tun, um mehr in Produktentscheidungen involviert zu sein?
Und wir behandeln noch viele weitere Themen wie Metriken, Priorisierung unter Dauerbeschuss, Disagree and Commit und wie ein Feature wie Durable Functions in Lambda von der Idee bis zum Launch kommt.
Ich sag einfach mal, lass uns direkt loslegen.
Viel Spaß!
Wir haben jetzt im Engineering Kiosk schon über 250 Episoden produziert.
And we sprechen ja immer über viele technische Dinge in der Softwareentwicklung.
Und unser Credo ist ja auch, dass wir über alles rundherum auch sprechen und sprechen wollen.
Ich habe mal in unsere Transkripte geschaut und habe eine kurze Suche angeworfen und habe mal geschaut, wie often we product manager, Product Owner or Product Management or sound.
And we have been in ungefec 450s given in unsere Transkripte.
That is the Product Owner Seite or man muss argument with the Product Owner.
And we have noch nieubling gemacht.
We had an episode, the 108 episode, da ging es aber eher um Projektmanagement mit Stefan Strack in Teams, also with sehr vielen Teams and Personen, but not the concrete entwickling of Product.
And now this site wollen wir mal heute updecken.
And there are glücklicherweise jemanden gefunden, der in einer Firma arbeitet, which productmanagement sehr, sehr gross geschrieben und die auch sehr viele Produkte have.
Daher bin ich sehr glücklich, heute den Michael willkommen zu heißen.
Also hi Michael bei uns im Engineering Kiosk.
Hi, und danke für die Einladung.
Wolfgang, du lügst hier schon wieder rum.
Also, wir haben den Michael nicht gefunden.
Der Michael has uns über Umwege gefunden.
Und zwar ist die Story we follow.
The Wolfgang Veranstaltet ja das Meetup in Innsbruck, the Engineering Kiosk Alps Meetup.
And there gab es einen Talk to Multi-Tenet-Architecture from Maximilian Shellhorn.
Ebenfalls AWS Amazon Webservice-Mitarbeiter.
Und da haben wir sozusagen Sourcing betrieben.
Ich sag mal, aus dem Meetup-Talk eine Podcast-Episode gemacht.
Und natürlich macht man auch so ein bisschen auf gut Deutsch Chit-Chat, nach dem Motto, hey, dies und das und so weiter und so fort.
Und da kamen wir dann irgendwie auf eine Empfehlung von Michael.
Das bedeutet, Wolfgang, wir wurden gefunden und nicht wir haben gefunden.
Also genauer gesagt ist Max mit mir bei einem Café gesessen.
Café, Andi, Kaffee.
Und da spricht man ja über viele Dinge und da hat er gemeint, ich kenne jemanden, der ist extrem guter Product Manager und der ist super gut im Produkt, mit dem ich zusammenarbeite.
Ich könnte euch da vielleicht vermitteln und ihr könnt ihn mal fragen, ob er Lust dazu hat.
Und in dem Fall hat er Lust dazu.
Also danke, Michael, für deine Lust in dem Fall.
Alles gut.
Max hat da gar nicht viel überzeugen müssen.
Der hat nur Positives von eurem Podcast berichtet, auch seine Erfahrung natürlich.
Aber bevor wir jetzt zu rot werden, Andi, fang mal mit Michaels Erfahrung an.
Genau.
Meine Aufgabe in diesem Podcast ist immer die Interview-Gäste auch vorzustellen.
Und da habe ich eine kleine Recherche betrieben.
Du hast 2018 schon ein paar Artikel über Kubernetes auf entwickler.de veröffentlicht.
Ich war erstaunt, dass in 2026 die Entwickler.de-Plattform noch existiert.
Aber ja, und was mich auch erstaunt hat, in 2018 hattest du da, ich glaube, ein Einstieg in Container und Kubernetes gemacht.
Das ist natürlich dann jetzt schon wieder acht Jahre her.
Denkt man so, wow, wann wurde Kubernetes eigentlich released?
Kubernetes wurde irgendwie Mitte 2024 Released.
Das bedeutet, du warst ja schon relativ früh dabei.
Damals warst du noch bei VMware, wo du eigentlich zwei Stationen abgearbeitet hast: einmal als Solution Architect and später als Staff Engineer Office of the CTO.
Musst du mir gleich auch nochmal erklären, was das im Detail is.
But that is not dein actual arbeiteger.
Aktuell bist du als Senior Project Product Manager und nicht Project Manager.
I think über diese Stolperfile werde ich heute noch ein bisschen mehr fallen.
Bei Amazon Web Service bei AWS, bei einem sehr, sehr großen Hyperscaler unterwegs für das Thema AWS Serverless.
And meine erste Frage ist: Wenn ich AWS Serverless lese, sprechen wir da über Lambda-Functions.
Interessant, dass du das diese Serverless und Lambda-Assoziation hast, die sicherlich viele haben, aber es ist mehr.
Und wenn man genau hinguckt anders, ist Serverless fing mit S3 und SQS an, also vor mehr als über 20 Jahren.
In unserem Serverless Team sprechen wir aber über die Services Lambda, Event Bridge und Step Functions.
Das ist so unser Bereich im Serverless, aber das ist je nach Auffassung von dem Begriff den Bau.
Färbung.
Auch wenn Frachtwerk ein Telematik-System für alle Baumaschinen der deutschen Bahn in ihrem eigenen Cluster betreibt, handelt es sich hierbei nicht um einen Bahnunternehmen, sondern um einen IT-Unternehmen für Beratung und Softwareentwicklung.
Remote sowie an zwei Standorten.
In Berlin und in Karlsruhe arbeiten derzeit vier Entwickler und Beraterteams an Software-Transformations- und Data Analytics-Projekten.
Zudem betreuen sie den automatisierten Betrieb von 300 Systemen in Zero Trust Model with über 1000 Containers for unterschiedliche Kunden.
Schau dir doch einmal Frachtwerk genauer an.
Denn es wird Verstärkung gesucht.
Speciell SoftwareentwicklerInnen mit dem Schwerpunkt Java and DevOps EngineerInnen mit dem Schwerpunkt Kubernetes.
Alle Infos unter engineerkios.dev slash frachtwerk oder in den Shownotes.
Jetzt hat Andi schon erwähnt, wo du überall so stationation gehabt hast.
Wie kommt man denn in dieses Projektmanagement überhaupt rein?
Kannst du mal kurz umreißen, von welcher Ecke du eigentlich kommst und wie du dann in das Produktmanagement oder Product Ownership, was bevorzugst du eigentlich was für ein Begriff?
Tatsächlich wird ich PM, also Product Management und nicht Project Management.
Das ist also wirklich, werden wir bestimmt noch ganz viel heute darüber sprechen, über PO, PM, Projektmanagement.
Aber in unserem Fall ist die Rolle auch bezeichnet als Product Manager.
Sogar mit einem Zusatz Tech, also PMT, ist die offizielle Rollenbeschreibung bei AWS und da werden wir bestimmt noch ein bisschen drüber sprechen, wo die Unterschiede liegen.
Und wie bist du hineingekommen?
Also was, weil man kann ja nicht Produktmanagement so richtig studieren.
Ist ja kein klassisches Informatikstudium oder sowas.
Also wie kommt man, wie kommt man in diesen Bereich rein?
Ich glaube, wenn du mich vor fünf oder zehn Jahren gefragt hättest, ob ich mal Produktmanagement machen würde oder ob ich überhaupt verstehe, was Produktmanagement ist, hätte ich noch gar keine richtige Ahnung gehabt.
Ich bin da so ein bisschen reingeklitten.
Jetzt mit meiner Erfahrung mit fast vier Jahren in der Rolle bei AWS, glaube ich, dass in jedem von uns so ein bisschen Produktmanagement steckt, wenn nicht sogar mehr.
Und ich hatte es auch zu Andi im Vorgespräch schon erwähnt, dass ich glaube, jeder kann Produktmanagement.
So ein bisschen wie in dem Film Ratatoui, jeder kann kochen.
Viele haben es vielleicht nicht in sich entdeckt, machen es vielleicht sogar schon, wissen noch gar nicht, dass sie eigentlich schon Produktmanagement machen.
Und bei mir war es ein bisschen ähnlich.
Wenn du meinen Werdegang anschaust, sogar noch vor VMware, ich habe sehr viel im technischen Sales, Pre-Sales gearbeitet, war vorher noch bei Dell, also dem Hardware-Anbieter.
War also immer sehr nah am Kunden dran, aber dafür eher weit weg vom klassischen Engineering, Software Development und demzufolge auch Productmanagement.
Aber der Kunde verbindet das irgendwie alles, ja, weil wir machen ja nicht Productmanagement oder Software Engineering aus zum Selbstzweck, sondern da gibt es ja immer irgendein Grund, einen Ansporn, warum wir das machen.
Und das ist in der Regel ein Kunde oder ein User, wenn es jetzt irgendwie vielleicht ein Open Source-Projekt ist.
Durch meinen damaligen Wechsel von Dell zu VMware, wo ich zunächst die Rolle als Solution Architect hatte, also auch im Field da mit Kunden viel gemacht hatte, aber später zu Kubernetes gekommen bin.
Andi, und da muss ich dich leider korrigieren, das war nicht Mitte 2024, ich glaube, du wolltest auch Mitte der 2010er.
Denn Kubernetes, genau, das erste, ich glaube, der erste Commit war 14, das erste Release, Stable war 15, 2015.
Da bin ich tatsächlich schon reingerutscht, weil das bei VMware natürlich auch ein Thema war.
VMware als Hersteller von Hypervisoren.
Und jetzt kommen da die Container daher.
Was macht man mit denen?
Und viele Kunden haben gesagt, oh, brauche ich gar kein Hypervisor mehr, wenn ich alles mit Container machen kann.
Und diese technische Differenzierung zu machen und auch zu verstehen, was überhaupt Kubernetes ist, insbesondere wenn man gerade nicht in diesem Seattle-Speckgürtel ist, wo da die damalige Erfindung halt oder Innovation stattgefunden hat, hat mich da tiefer in dieses Rabbit-Hole, dieses technische Rabbit-Hole, reingetrieben.
Also von der Ausbildung her bin ich auch als Informatiker ausgebildet, aber nicht studiert, sondern nee, klassische IHK-Ausbildung gemacht.
Und da gibt es zwei Profile auch.
Es gibt ein Systemadministrationsprofil.
Das ist also sehr stark so Integration, Netzwerke, Systeme.
Und dann gibt es ein Anwendungsprofil.
Und Anwendung habe ich nicht gemacht, weil damals war das alles Java und hatte ich kein Interesse daran, irgendwie Java zu lernen.
Die Sprache hat mich überhaupt nicht gereizt.
Und bin dann leider, also da gibt es auch Gutes und Schlechtes, bin dann leider so ein bisschen von diesem Software-Entworkpfad abgedriftet, der mich dann aber später eingeholt hat.
Denn bei Kubernetes 2015, da gab es ein bisschen Dokumentation, aber die eigentliche Dokumentation war das Source-Code.
Und der Kubernetes ist ein Go-Projekt, also es war eines der ersten großen Go-Projekte nach Docker.
Und das hieß, also du musstest den Source-Code lesen, um zu verstehen, wie das Ding funktioniert.
Es war halt neugierig, also Neugier, da ist auch so eine, ich glaube, einer meiner Eigenschaften oder Haupteigenschaften und sicherlich nicht einzigartig.
Und die hat mich dann tiefer in dieses technische Rapper-Hole reingetrieben, wo ich mir dann die Programmiersprache angeeignet habe im Selbststudium.
Das war ja alles noch vor KI, da musstest du halt noch klassisch Bücher wälzen und so.
Bin dann ins Research reingekommen und habe dann aber festgestellt, dass alle Dinge, die ich da bei VMware auch schon gemacht hatte, immer irgendwie in den Kundenbezug.
Ich wollte immer irgendwas für einen Kunden bauen.
Ich wollte immer User-Feedback direkt haben.
Und bin dann durch einen Zufall in Kontakt gekommen mit einem AWS-Productmanager, der den Service Event Bridge verantwortet.
Denn ich habe so ein paar Integrationen bei VMware gebaut, Thema Multicloud, Integration.
Und eine der Integrationen war mit AWS.
Und in dieser Integration habe ich so ein paar technische Hürden oder User Experience-Issues ausgemacht in dem Eventbridge-Service.
Ich habe dann das Team kennengelernt als User.
Also da war ich in der genau gegen Rolle.
Da hat der PM mit mir gesprochen und hat sich gefreut, dass dein User gebrannt hat für den Service, also Feedback gebracht hat.
Und dadurch ist diese Verbindung hergestellt worden.
Und später hat dann jemand auf Twitter, glaube ich, gepostet.
Oh, we are hiring.
Und ich dachte, ich probiere das einfach mal und hatte mich eigentlich für eine Engineeringstelle beworben, weil in dem Zeitraum war ich schon im Office of the CTO Stuff Engineer und habe auch Research gemacht, also war sehr tief im Engineering, sogar drin.
Und Engineering wurde da aber nicht als Remote gesucht und da wurde mir eine Produktmanager-Rolle angeboten, weil man mich vorher kannte, gesehen hat, dass ich sehr stark produktorientiert bin.
Ich selber aber nie auf die Idee gekommen wäre, mich als Produktmanager dort zu bewerben, weil ich keine klassischer Ausgebildeter, wie auch immer man das definiert, Produktmanager bin.
So, da bin ich in die Rolle reingerutscht.
Sorry, das war jetzt ein ganz lange, ein ganz langer Exkurs, aber ich wollte so ein bisschen Hintergrund geben, dass ich auch kein klassischer Produktmanager bin.
Und ich glaube, jeder, auch der Zuhörer hier, kann PM.
Gleich noch eine Frage nachgeschossen.
Du hast jetzt einen sehr technischen Background und natürlich auch ein sehr technisches Produkt in dem Fall.
Habt ihr bei AWS grundsätzlich die Regel, dass irgendwie die PMs sehr technisch sein müssen und auch dieses technischen Verständnis mitbringen müssen?
Oder könnt ihr jetzt jemand, der einfach, keine Ahnung, Wirtschaft studiert hat, auch PM werden?
Oder ist das bei euch schon sehr hart?
Ja und ja, das waren ja jetzt zwei Fragen.
Die Rollenbezeichnung ist tatsächlich Product Manager Tech, also PMT.
Und dieses Tech ist sehr stark bewertet.
Und das war sicherlich auch einer der Gründe, warum man mir diese Rolle zugetraut hat, weil ich zwar nicht die klassische Product Manager-Erfahrung mitgebracht habe bei meinem Wechsel zu AWS, aber ein extrem tieftechnisches Verständnis hatte.
Und das hat man höher bewertet.
Hat man gesagt, dass es in der Regel schwieriger für einen nicht-technischen Produktmanager ist, die Technik, die Technologie zu erlernen.
Das dauert viel länger.
Insbesondere wenn du wie bei AWS sehr viel mit Entwicklern zu tun hast.
Entwicklerprozesse, wie arbeiten Entwickler.
Was stört die, sich in diese Rolle reinzuversetzen.
Und aus der Rolle kam ich ja schon, sodass es für mich nicht ganz einfach war, Produktmanagement zu lernen, also das Ganze drumherum.
Aber doch einfacher, als für einen nicht-technischen Produktmanager die ganze Technologie zu erfahren.
Trotzdem ist es so, dass viele der Produktmanager-Kollegen, die ich habe, klassische MBA oder also Business-Ausbildung haben und einfach eine technische Affinität und dann dadurch halt quasi ihre technischen Gaps einfach aufholen mussten.
Und so trifft man sich irgendwo in der Mitte und lernt gegen voneinander.
Bevor wir jetzt in die Definition von Produktmanagement einsteigen, denn ich bin immer so ein Freund davon, gib mir mal den ersten Paragraph von Wikipedia.
Also ich weiß ja nicht, wie ihr Wikipedia lest.
Ich mache meist irgendwie so erster Paragraf und dann klicke ich den Tabscher wieder weg.
Ja, dass du grundsätzlich aufhörst zu lesen nach dem ersten Paragrafen, ist mir bewusst, ja.
Ja, aber du musst man ja auch korrigieren, weil du bist ja immer noch auf dem Stand von 2020.
Inzwischen gibt es Bachelor-Studien-Gänge zum Thema Produktmanagement, möchte ich Ihnen hier kurz hinweisen.
Ja, natürlich, es gibt alles, ja.
Speziell von der Code University und von der IU University.
Also das gibt es inzwischen.
Jetzt kann ich dir natürlich nicht sagen, und das werden wir gleich in diesem Podcast auch noch lernen, ob Produktmanagement gleich Produktmanagement ist.
Denn Software-Entwickler ist ja nicht gleich Software-Entwickler geführt.
Also IT ist ja, oder jedes Spezialfeld der IT ist ja schon irgendwie so ein bisschen speziell und man kann sich, glaube ich, sehr tief da rein nörden, dass Rabbit Hall runtergehen.
Deswegen, Michael, wenn ich dich jetzt fragen würde, du kommst jetzt bei mir Weihnachten an den Familien-Tisch.
Du hast jetzt mal die Aufgabe für im ersten Schritt für Nicht-Techniker und dann im zweiten Schritt vielleicht für Software-Engineers zu erklären, was ist denn überhaupt Produktmanagement?
Warum muss ein Produkt gemanagt werden?
Aus meiner Erfahrung und vielleicht ein bisschen allgemeiner gesprochen, würde ich sagen, Produktmanagement ist, wenn du evaluierst, was benötigt wird, der Markt, der Kunde, was auch immer deine Zielgruppe ist.
Und dass du dann in der Lage bist, das zu übersetzen in einem Produkt, in ein Service, in einer Dienstleistung, kann ja auch sein.
Und das wiederum dann auf die Straße bringst.
Also die Ausführung, Delivery von einem Produkt oder einer Erfahrung.
Dieses Dreigespann aus Analyse, Umsetzung und Shippen oder Delivern.
Ich weiß, mir fällt jetzt gerade das bessere deutsche Wort nicht ein.
Abliefern, würde ich sagen, ist der Kern von Produktmanagement.
Was würdest du sagen, ist in der Industrie weit verbreitet, was Productmanagement nicht ist?
Das war auch vielleicht so ein Frage, die ich vorher hatte, bevor ich in die Rolle reingeschlüpft bin.
Ich hatte auch natürlich keine so richtig gute Vorstellung, was mich da erwartet bei AWS.
Aber was es nicht ist, ist Projektmanagement.
Und diese, also PMs und PMs, und das war auch in meiner Rolle bei vorhergehenden Arbeitgebern, hatte ich sehr viel mit Projektmanagement zu tun.
Dienstleistungen, die ausgerollt werden, größere Projekte.
Also Produktmanagement ist nicht Projektmanagement.
Das heißt, wir sind in der Regel nicht, vielleicht mit einer kleinen Differenzierung, je nach Unternehmensgröße bei Startups, sind da die Grenzen ein bisschen fließender, aber bei größeren Unternehmen wie AWS sind wir nicht zuständig für Ressourcenplanung, zum Beispiel im Engineering oder für gewisse Zeitplanung, was für ein typische Projektmanagement.
Eines der größten Mythen, die man ja immer hört, oder beziehungsweise, das ist jetzt eine gute Frage.
Produktmanagement, Projektmanagement, die haben leider dieselbe Abkürzung.
Bei euch wird es vielleicht jetzt anders gehandhabt, PM, PMT, hattest du gerade gesagt.
Aber eins der Mythen bzw.
Vorurteile, die ich immer höre, wer verwaltet denn das Jira-Backlog?
Jetzt wollen wir davon auch BG ran nutzt, aber ihr versteht schon, ihr versteht schon, was ich meine.
Würdest du sagen, das ist jetzt PM-Aufgabe, also PMT-Aufgabe oder Projektmanagement-Aufgabe?
Oder wie ist das bei euch gelebt?
Bei uns sogar weder noch.
Denn es gibt noch eine ganz wichtige Rolle bei uns im Engineering.
Und da die Zusammenarbeit zwischen dem Produktmanager und dem Engineering ist bei uns auch ganz klar geregelt.
Mein Counterpart im Engineering, und wir sitzen sehr eng mit diesen Teams, ist der Service oder Software Delivery Manager, der SDM.
Und der verwaltet tatsächlich den Backlog, das Grooming, das Picken, die Sprints.
Das macht der SDM.
Es gibt manchmal Rollen bei uns, die machen dann: Das ist der TPM, der Technical Project Manager.
Der macht bei größeren Campaigns oder Service-Übergreifenden Sachen, übernimmt eine Steuerungsaufgabe.
Aber in den meisten Fällen ist das Paar PM SDM oder ein PM mehrere SDMs in the Engineering Org rein.
Und als ich damals noch im Feld im Sales gearbeitet habe, also auf der anderen Seite, wollte ich natürlich auch viel verändern.
Der Kunde erzählt dir irgendwas und du sagst, cool, genau das machen wir, den Bug habe ich auch schon irgendwie festgestellt, oder das Feature würde ich gerne implementieren.
Aber du triffst dann meistens auf so eine Wall, so eine Wand, denn du musst dann den Produktmanager überzeugen davon, dass das, was dein Kunde da, dieser eine kleine Kunde in irgendeinem Hinterdorf möchte, unbedingt wichtig ist und das Produkt rein muss.
Und der Produktmanager hört das tausendmal am Tag von ganz vielen verschiedenen Leuten und muss natürlich priorisieren, abwägen und so weiter.
Und da war ich immer ein bisschen frustriert, dass warum das nicht, dieses Feature immer noch nicht implementiert ist, obwohl es seit zwei Jahren im Backlog, vielleicht sogar ein Jira-Ticket oder so.
Wie ist dann der Kontakt zu den Engineers?
Hast du dann da irgendwie direkt einen Kontakt?
Sitzen da dann diese Rollen, die du erwähnt hast, dazwischen oder wie schaut es dann wirklich in der Realität aus?
Oder wie oft hast du überhaupt Kontakt mit den Engineers?
Bist du für ein Team verantwortlich für viele Teams?
Also, wie ist da die Connection bei euch?
Genau, in meinem Fall habe ich tatsächlich mehrere SDMs.
In der Regel ist es so ein 1 zu 1-Pairing, je nachdem, wie groß das Team ist, die Entwickler, die der SDM verwaltet.
Und auch wie was deine Seniorität im Level des Produktmanagers angeht.
Also es gibt natürlich da auch verschiedene Stufen.
Bei Amazon sind sogenannte L-Levels, also L1, 2,3,4 und so weiter hoch.
Andere Firmen haben da andere Klassifizierungen.
Und je seniorer du bist, desto größer ist natürlich dein Scope.
Demzufolge arbeitest du auch mit mehreren SDMs.
Vielleicht sogar Serviceübergreifend zusammen.
Und einer meiner letzten Launches, den ich gemacht habe, war nämlich genau so ein Cross-Service-Launch, das bedeutet, du arbeitest über mehrere Services hinweg, um eine Lösung für einen Kunden zu entwickeln.
Und die STMs, die sind wirklich technische Rollen.
Also die haben, die kommen aus dem oder sind auch im Engineering eingehängt von der Organisation.
Genau.
Ob das jetzt tatsächlich dann so ist, dass du einen eigenen Engineering-Track hast und ein Product-Track, da habe ich verschiedene Modelle gesehen, das ist eigentlich irrelevant.
Also, dass die PMs tatsächlich mit den Engineering-Teams zusammensitzen in der Organisation oder getrennte Tracks haben.
Beides ist üblich.
Die SDMs selber sind aber üblicherweise Engineers, die entweder zu SDMs wachsen, reifen, in den Manager-Track dann übergehen, oder von extern gekommen sind, schon als SDM rein, weil sie Management-Erfahrung haben.
Und das geht dann höher in VP of Engineering und so weiter.
Okay, das heißt aber, dass du keinen direkten Kontakt jetzt mit Engineers hast im Daily Business sozusagen.
Entschuldigung?
Nee, genau, doch, jeden Tag.
Das habe ich vorgeführt.
Du hattest vorhin die Frage.
Ich habe jeden Tag Kontakt mit dem Engineering.
Und das ist dieses T in PMT bei AWS, dieses Product Manager Tech.
Es ist ein ganz großes T, größer als diese PM wahrscheinlich.
Also der Prozess auch, wie AWS Productmanagement macht und warum AWS oder wie auch AWS einige Sachen anders macht, weshalb ich auch dankbar bin, die die Erfahrung dazu machen, ist sehr stark verzahnt mit der Delivery dann und der Anforderungsanalyse.
Und das ist manchmal Wasserfallmäßig, aber manchmal auch eher so ein Kreislauf, wo du ganz lange iterierst zusammen mit Engineering, bevor bevor das Service dann oder das Feature geboren wird.
Und ich habe mich täglich tatsächlich mit den Engineers zu tun.
Das sind ganz enge Verzahnungen.
Du hattest jetzt verschiedene Rollen, wie ein Software, eine SDM, Technical Program Manager.
Ich frage mich gerade, okay, was macht denn der Engineering Manager dann?
Also, wie ist denn da die Verantwortungsverteilung?
Wer hat welche Aufgabe?
Das hört sich jetzt, also jetzt von außen, und mir fehlt der Kontext, hört sich das echt schon Wasserkopf-technisch an.
Oder habe ich da ein komplettes falsches Bild gerade?
Nee, das kommt also Wasserkopf nicht, im Gegenteil, denn AWS ist da bekannt für diese Two-Pizza-Team-Modelle.
Das heißt, Teamgröße bis hin, dass sie irgendwie satt werden von zwei Pizzen.
Ganz so streng darf man das jetzt nicht nehmen.
Der eine ist ein bisschen mehr als der andere.
Aber da kommt ja diese Philosophie her und ganz stark Service-orientierte Gedanken, deswegen auch ganz viele Services, die du siehst in so einem Baukasten, der dann über die Jahre größer geworden ist bei AWS.
Du hast Engineering Manager gesagt, also ist gleichzusetzen mit SDM in dem Fall.
Der SDM hat eine Gruppe von Engineers über dir verantwortet.
Dort eben diese Backlog, das Grooming, die Roadmaps zusammen mit dem Product Management, Operational Themen, Service Optimierung verantworten.
Okay, die Info Info hat mir jetzt gerade gefehlt, dass der SDM mehr oder weniger in der in der globalen Industrie dann gleichzusetzen ist mit dem Engineering Manager.
Macht der SDM dann auch das People Management und die Karriereweiterentwicklung mit den Engineers?
Korrekt.
Jetzt sprechen wir natürlich über Produktmanagement und dann natürlich jetzt mit diesem speziellen Fokus auf AWS.
Aber Produktmanagement gibt es ja auch bei BMW.
Produktmanagement gibt es ja auch für B2C-Webseiten wie Booking.com.
Wie würdest du sagen, unterscheidet sich Produktmanagement je nach Produkt?
Also kann ich mir vorstellen, dass du jetzt durch deine Erfahrung bei AWS auch einfach Produktmanager bei BMW werden kannst für ein neues Elektroauto oder sagst du, oh nee, Anni, das ist das sind komplett andere Nischen.
Das ist genauso wie nur, weil du einen Gartenhaus bauen kannst, heißt das nicht, dass du ein ganzes Wohnhaus bauen kannst.
Elektro-Arte ist eh doch nur wie ein Handy, oder mit Rädern.
Also es ist dasselbe.
Zur ersten Frage, wie sich das unterscheidet, die PM-Rolle bei AWS zu einer anderen Rolle in einer anderen Branche, vielleicht sogar.
Ich kann da nur so ein bisschen vom Hören sagen, von Freunden, die ich habe, die in solchen Organisationen arbeiten, sprechen.
Vielleicht hört der eine oder andere sogar gerade zu.
Was ich gehört habe, zum Beispiel bei BMW oder bei einem Auto zulieferer, wird oftmals die Bezeichnung Product Owner verwendet.
Wobei das vielleicht sich auch alles gerade ändert.
Grenzen sind ja immer fließend, ne?
Da ist meine Erfahrung, was mir da so berichtet wurde, dass diese Rolle an ein sehr starkes Wissen über die Prozesse in so einem Unternehmen voraussetzt, um überhaupt in der Lage sein, eine Innovation voranzutreiben.
Wobei gleichermaßen müsste man vielleicht sagen, was vereint alle diese, du hast Booking angesprochen, BMW und AWS, was vereint alle diese Produktmanager oder Product Owner.
Am Ende sind sie immer für ein bestimmtes Problemfeld, Vertical oder Kundenset verantwortlich, was sie verbessern, wo sie Innovation treiben müssen.
Der Unterschied, den ich aber jetzt vielleicht nehmen würde bei AWS, ist, dass wir nicht ein Kunden oder eine Zielgruppe haben, den Autofahrer oder einen Autokäufer, sondern eine extreme Breite an unterschiedlichen Kunden, Regionen, Stichwort, Governments, bestimmter Regionen wie China, die ganz andere regulatorische Anforderungen haben.
Jetzt vor kurzem haben wir die europäische Cloud von AWS hier veröffentlicht.
Und dann diese zig hunderte Services, die es da auch noch gibt.
Weshalb, ich glaube, dass dieses T, PMT, diese technische Anforderungen bei AWS schon sehr besonders sind.
Du musst halt also sehr tief, aber trotzdem sehr breit auch sein.
Wohingegen, ich glaube, dass ich jetzt nicht einfach zu BMW gehen könnte und sagen, oh, ich mache jetzt hier mal bei euch Product Owner.
Denn da fehlt mir sehr viel Background, Kontext.
Was ich aber glaube, ist, dass sehr viele Unternehmen, und das sehen wir natürlich, ich habe es Elektromobilität gerade angesprochen, sehr viele Unternehmen immer technischer werden, wo früher Technologie eine ganz kleine Rolle oder gar nicht gespielt hat, spielt sie mindestens die Hälfte, wenn nicht sogar mehr in Zukunft.
Das sieht man an den chinesischen Autoherstellern, da ist ja das Auto mehr ein Handy oder Software als das eigentliche Auto, der Baukasten rundherum.
Und deswegen glaube ich auch, dass, wenn du mich vielleicht in fünf Jahren fragst, genauso wie ich vor fünf Jahren nicht gedacht hätte, bei AWS mal Produktmanager zu werden als Engineer, dass man vielleicht schon in der Lage ist, in fünf Jahren mit einem sehr technischen Produktmanagement-Hintergrund von einem Cloud Provider, durchaus auch Produktmanagement in einem anderen Vertical machen könnte.
Ganz kurz nochmal auf die Verantwortungen, die wir zuerst gesprochen haben.
Also, wenn ich dich richtig verstehe, du bist ja für das Produkt an sich verantwortlich, aber der STM ist für Backlog verantwortlich.
Aber das heißt, die Priorisierung des Backlogs ist dann auf deiner Seite oder macht die da STM oder du machst übergeordnete Priorisierung und der STM dann wirklich die Sprints oder wie man es dann auch immer nennt.
Also, wo sind da genau die Grenzen, wer was entscheiden darf und soll, bei euch, aber vielleicht auch ganz, keine Ahnung, ob man es ganz allgemein beantworten kann für die Industrie, aber was so vielleicht üblich ist.
Ich glaube, das ist tatsächlich unterschiedlich in Unternehmen, wie das gelebt wird, wie stark die Rolle des Product Managers auch ausgeprägt ist, also welche Wichtigkeit er hat.
Ich glaube, POs sind vielleicht tatsächlich mehr in den Sprints und Backlog und Scrum-Mechanismen mit drin, als wir als Product Manager.
Nichtsdestotrotz, also zumindest bei AWS ist es so, dass der SDM oder das Engineering-Team und der Product Manager sehr stark da auch da zusammenarbeiten bei der Roadmap-Planung und Feature-Priorisierung.
Und das ist auch nicht so, dass man das irgendwie einmal im Jahr festmacht und dann wird das so gemacht.
Denn das ist extrem dynamisch, so ein Markt, insbesondere jetzt, ja, mit all den neuen Themen, die da so hochkommen.
Und der Product Manager ist verantwortlich dafür, erstmal Informationen auf darzulegen, warum überhaupt gewisse Sachen in eine Roadmap rein sollten, auf welche Datenbasis das passiert ist.
Vielleicht gibt es auch ein gewisses Projekt, ein Commitment, was man zu gewissen Kunden gemacht hat, oder man möchte in den Markt rein, da gibt es regulatorische Anforderungen.
Also diese Datenbasis erstmal aufzuarbeiten und dann in Zusammenarbeit mit dem Engineering-Team zu priorisieren, wo das Engineering-Team in der Lage ist, einzuschätzen, das ist der Aufwand, für das und das Feature.
Hinzu kommen zu den täglichen Aufgaben, die die Engineers haben, weil AWS als Cloud Service Provider, das heißt, du musst permanent sowieso deine ganze Flotte überwachen, optimieren, du hast vielleicht Incidents, die reinkommen, die nicht geplant sind.
Das ist so eine Grundlast, die auch noch mit dazukommt.
Diese Planung liegt auf der Engineering-Seite bei dem SDM.
Und dann ist das so ein Spiel zwischen geben und nehmen, wo man sich abstimmt und auf eine Roadmap einigt.
Also es ist nicht so, dass der PM sagt, das ist die Roadmap und Engineering exekutiert, sondern es ist eine sehr auch enge Abstimmung hier, wie auch bei jedem anderen Projekt, wenn man eine Feature-Entwicklung bei uns macht.
Und wie entscheidest dann du über die Priorisierung?
Also, du hast ja schon erwähnt, da kommen die ganzen Sales-Leute und Customer Success Manager und keine Ahnung, was es als vier Rollen gibt, die alle bei dir irgendwas einkippen.
Jetzt musst du irgendwie etwas entscheiden.
Wie machst du das?
Genau.
Und da will ich vielleicht noch dazu sagen, dass ich da meine Rolle als Produktmanager nicht nur sehe, dass ich irgendwie durch die Feature-Requests gehe oder meine E-Mails, die ich den ganzen Tag bekomme.
Die sind natürlich eine sehr wichtige Datenbasis.
Aber mein Anspruch an mich selber ist auch Innovation zu treiben, Dinge zu sehen, die vielleicht noch keiner sagt.
Und intern verwende ich gerne so diese Henry Ford-Analogie, der gesagt hätte, wenn gefragt hätte, meine Kunden, was sie gerne hätten, hätten sie gesagt, ich hätte gerne schnellere Pferde gehabt.
Manchmal musst du auch anders denken und auch eine Wette auf den Markt machen.
Auch das ist eine Roadmap, ein neues Feature, ein neues Service, den du vielleicht etablieren möchtest, weil du ein Bauchgefühl hast.
Und das musst du aber dann natürlich mit Daten unterm Augen, so gut wie möglich.
Und die Datenbasis da kann sein, Feature Requests, wo du so Pad-Muster siehst, ja.
Das muss ja nicht sein, dass du einen Feature-Request hast und das sind 100 Klicks drauf.
Das kann so, das kann so gescattert sein und du musst dann das Muster erkennen.
Ach, ach guck mal, der sagt, das ist ein bisschen schwierig dort und der sagt, ich würde gerne, wenn das ein bisschen so gehen würde, würde ich noch besser.
Und diese dieses Clustering, diese Datenanalyse ist eigentlich eine Grundvoraussetzung bei AWS als Product Manager.
Also es ist auch nicht debattiert.
Und hilft mir dann aber in den Gesprächen mit Engineering, wo wir sprechen über technische Innovationen, aber auch Papercuts nennen wir die.
So Sachen, die irgendwie, wo jeder Kunde sich irgendwie dran stößt oder schneidet, die wir verbessern wollen.
Und die sind meistens aber so kleine Sachen, wo man so, ah, klingt jetzt nicht so super spannend.
Müssen wir das wirklich machen, können wir das nicht nächstes Jahr machen.
Und da aber die Datenbasis zu haben und auch den Willen, das durchzusetzen mit Engineering, das ist auch eine PM-Rolle.
Und wie sieht es aus mit solchen Feature-Requests, wo einfach ein fetter Kunde dran hängt?
Also ich vermute, weil wenn dann irgendwie Netflix um die Ecke kommt, dann wird vielleicht irgendwas höher priorisiert, als wenn das ich bin als Privatkunde.
Glaubt man, habe ich tatsächlich so noch nicht bei AWS gesehen.
Also zum einen ist AWS so groß, dass es nicht nur eine Netflix dann gibt, sondern tatsächlich mehrere.
Es kann ja irgendein großer Kunde sein, muss ja jetzt nicht ein Netflix sein, aber.
Ich meine jetzt, dass es nur an einem festgemacht wird.
Es ist tatsächlich so, weil dann, du hast natürlich auch das Risiko bei einem dieser Kunden als Cloud-Provider, dass du eine sehr spezielle Lösung baust.
Und das ist nicht der AWS-Ansatz da.
Aber es ist im Prinzip der gegengesetzte Ansatz.
Tools, Utility-Provider.
Da kommt man ja her.
Deswegen gibt es auch so viele Services da, die sich teilweise auch ähneln.
Aber der Ansatz ist eher zu gucken, was braucht die Masse.
Wie kann ich diese Skaleneffekte erzeugen?
Was auch wichtig ist für die Effizienz von einem Unternehmen.
Weil wenn du für jeden Netflix dieser Welt so eine kleine Sonderlocke baust, hängst du am Ende des Tages an deren Schicksal, die bestimmen quasi diktieren können, können dann quasi deine Roadmap diktieren.
Und zum anderen kannst du skalierst du damit nicht.
Es sei denn, das, was eine Netflix braucht, und da können die dann Gradmesser sein.
Stichwort, CICD, Chaos Engineering, die Themen, die eine Netflix getrieben hat, die dann in der Masse für die Kunden auszuholen.
Aber trotzdem hast du ja diese ganzen Personen, die mit dem Kunden zusammenarbeiten und die dann natürlich extremen Druck aufbauen können.
Ist es so in der Kultur verankert, dass man das argumentieren kann oder sind es auch tägliche Fights, die man einfach austragen muss als Produktmanager, um da eben irgendwie dagegen zu anzukämpfen, damit man eben nicht in diese Hölle der Feature Requests oder Features oder ja eben diese Einzellösungen, die da nur einem Kunden was womöglich bringen, rein tappt.
Das ist einer der täglichen Fights, die man in so einem großen Unternehmen wie AWS.
Das ist jetzt ja nicht auch irgendein Cloud-Anbieter.
Es nutzen ja wirklich so viele Kunden weltweit rund um die Uhr.
Und du hast eher das Problem, dass du zu viel Informationen bekommst.
Dass du einfach zu viele Requests bekommst als Product Manager, wo du den ganzen Tag 24x7 arbeiten könntest und würdest die Arbeit trotzdem nicht schaffen.
Das heißt, du musst auch, du musst in der Lage sein zu sein, zu filtern und zu priorisieren.
Und du priorisierst nicht immer richtig.
Wenn du priorisierst, musst du das tun auf einer gewissen Datenbasis, um eine Entscheidungsgrundlage zu haben.
Und AWS ist eine Firma, eine sehr starke Kultur im Niederschreiben von Informationen, um sich auszutauschen.
Also es ist auch ganz anders, habe ich nur in keinem Unternehmen so erlebt, wie AWS-Meetings macht, wie AWS kommuniziert.
Und ich glaube auch, das ist einer der Erfolgsrezepte, warum man, warum AWS auch so erfolgreich geworden ist oder Amazon, vieles wurde auch von Amazon übernommen.
Das ist also ein bisschen fließend.
Wenn du nicht richtig priorisierst, du hast deine Aufgabe gemacht, aber du hast einen Blindspot gehabt, oder ist es tatsächlich so, dass dieser große Kunde ganz unbedingt wichtig ist, dann, und das ist auch Standard bei uns, und das ist in Deutschland immer so ein bisschen ein schwieriges Thema, Eskalation.
Dann wird eskaliert.
Und wenn du mit deinem Peer, mit deinem Sales-Peer, dann vielleicht nicht im Einklang bist, dann wird eskaliert und dann wird eine gemeinsame Entscheidung getroffen.
Manchmal ist es so, dass die Entscheidung vielleicht aus meiner Sicht nicht die richtige ist oder aus des Sales-Teams nicht die richtige Entscheidung ist.
Und da ist es ganz wichtig, dass es Leitlinien gibt.
Eine Kultur im Unternehmen, an der sich alle ausrichten können.
Und es gibt eine Philosophie oder eine Leitlinie bei AWS, die nennt sich Disagree and Commit.
Das bedeutet, auch wenn ich nicht der Meinung bin, die da entschieden werden soll, ich unblocke quasi diese Entscheidung.
Ich mache ein Disagree, aber committe mich dazu.
Das heißt, in den nächsten Meetings, wenn es da weitergeht, komme ich nicht wieder drauf zurück und sage, hab ich's euch doch gesagt, sondern ich commit und unterstütze denjenigen.
Das ist ganz wichtig, weil du brauchst einen Tiebreaker.
Und manchmal ist nicht dieser Tiebreaker extern, sondern du oder dein Gegenüber muss der Tiebreaker sein.
Und dann, wenn ich disagree and committee, erwarte ich aber, dass mein Gegenüber die Ownership wieder und so ein anderes Leitlinien-Thema übernimmt und in der Lage ist, das Thema zu exekutieren.
Ob er das dann auch richtig oder falsch macht, ist ein Schicksal.
Manchmal kannst du nicht alles beeinflussen.
Aber das zwingt den Owner noch tiefer, noch granular reinzuschauen und zu analysieren, ob diese Entscheidung, die da jetzt erwirkt worden ist, auch die richtige ist an der Stelle.
Also Leitlinien spielen eine ganz große Rolle bei diesen Themen.
Ja, ich glaube, da muss man wirklich auf die Kultur vertrauen, denn ich denke, oft kann sowas, so eine Eskalation ja auch sehr persönlich genommen werden.
And that can natürlich dann negative Effekte für die zukünftige Arbeit zusammen, jetzt in diesem Fall mit deinem Salespeer.
We have gerade schon so ein bisschen über diese, ich sag mal, wie soll man sagen, Product Management Pipeline.
We come new Features, großer Kunde, ich musste gerade einmal grinsen, it wurde gerade erwähnt, die Netflix dieser Welt, also Plural, da habe ich mich gefragt, wie viele Netflix in dieser Welt gibt es, also in dieser Größe, wahrscheinlich nicht so viele, die dann auch noch AWS nutzen, bla bla bla.
Und zwar habe ich in der Recherche festgestellt, dass ihr vor kurzem ein neues Feature gelauncht habt, oder an dem du maßgeblich beteiligt warst, durable Functions in AWS Lambda.
Kannst du mal grob, ich sag mal, die Struktur skizzieren, was alles in deiner Verantwortung lag, in der Produktmanagement-Verantwortung und wie lange ihr an dem Feature gearbeitet habt und was da alles notwendig war hinten dran von der Produktmanagement-Seite, um jetzt zum Beispiel das Feature Durable Functions in AWS Lambda als Beispiel irgendwie zu launchen.
Also wann ging das los, Zeithorizont und welche Hürden hat man da?
Also kurz um, wie hat der Fokus auf diese spezifische Feature irgendwie dein Tag bestimmt?
Ja, an dem Feature habe ich tatsächlich länger gearbeitet, also sehr intensiv über das letzte Jahr.
Aber die eigentliche Entwicklung begann bei mir im Kopf schon viel länger, noch vor AWS.
Denn mit dem Thema, was durable Functions ausmacht, wir müssen vielleicht kurz mal ausholen, was ist Durable Functions, was ist Lambda.
Lambda ist ein Compute-Service bei AWS.
Haben vielleicht einige schon gehört.
Stichwort Functions as a Service, also Event getrieben, schickst du kurz was rein, macht irgendwas, kommt irgendwas raus, ist so ein bisschen angelehnt, dann auch so wie JavaScript-Node funktioniert mit einem Event Loop.
Heißt aber auch, dass es stateless ist, also massiv skalierbar, wird immer gern so als Supercomputer bezeichnet.
Ist aber stateless, so eine Function.
Das bedeutet, und in den meisten Fällen sind ja unsere Anwendungen stateful, haben irgendwo eine gewisse Information, da brauchst du zusätzlich Dienste.
Und so eine Funktion macht ja immer nur so eine kleine Sache.
Das heißt, du brauchst viele von diesen Funktionen zusammen, die dieses Ding abbilden.
Und das hat man in der Vergangenheit bei AWS mit mehreren Services gemacht.
Und als ich zu AWS gekommen bin, hat mich das auch so ein bisschen erschlagen, diese tatsächlich Komplexität mit welchem Service nehme ich jetzt, wie baue ich das alles zusammen, wie mache ich diese Verfügbarkeit?
Also, ich war ja selber der Kunde an der Stelle.
Und hab dann ein bisschen rausgezoomt, und das kommen wir wieder zur Henry Ford zurück.
Wenn ich jetzt meine Kunden gefragt hätte, was wollt ihr, hätten die bestimmt nicht gesagt, ich will durable functions.
Die haben gesagt, Local Testing ist schwierig mit all diesen ganzen Services.
Lambda-Funktionen, also State, brauche ich immer irgendwie andere Dienste dazu.
Was ich damit sagen will, meine Rolle als PM war da extrem wichtig, aus den Signalen, die ganz verrauscht verschieden waren, zu extrapolieren, dass wir Durable Functions brauchen an der Stelle.
Meine Rolle war da quasi der Verantwortliche von der Ideengebung bis hin zum Launch.
Der Launch war jetzt letztes Jahr auf der ReInvent im Dezember.
Und da sind ganz viele Meilensteine dazwischen.
Und der erste wichtigste Meilenstein nach der Ideensammlung, nach den Informationen, nach den ganzen Signalen, damit ich überhaupt zu dem Entschluss komme, ich glaube, wir brauchen sowas wie Durable Functions.
Der erste ist dann, die Stakeholder in unserem Unternehmen zu überzeugen, dass wir das bauen sollen, dass wir das brauchen.
Und da kommen Mechanismen zum Spiel, die bei AWS, das ist eben diese Kultur des Schreibens.
Ich weiß nicht, ob vielleicht einer der Zuhörer schon mal von dem PR FAG, also PRFAQ-Ansatz gehört haben.
Das ist im Prinzip ein Press Release und ein Frequently Asked Questions.
Ein Dokument, was aussieht wie ein Zeitungsartikel, also so ein Press Release, ne?
Und dazu FAQs hat, Fragen und Antworten.
Es ist auch public, kann man nachlesen, diese Amazon Working Backwards PRFA-Approach.
Und das war unfassbar schwierig, als ich bei AWS angefangen habe, meine Idee in dieses Format reinzudrücken.
Denn jeder hat eine unterschiedliche Art zu schreiben.
Das Problem nur in so einer großen Organisation wie AWS ist, dass jeder Leser einen anderen Kontext hat, andere Informationen aufnimmt.
Und der PR-Fac-Ansatz, also dieses Standard-Template von einem Dokument hilft allen Stakeholdern auf, also mein direkter Vorgesetzter, sein Vorgesetzter, bis hin zum CEO hoch, relativ schnell zu erfahren und zu erfassen, was das Problem, die vorgeschlagenen Lösung, die Erfahrung und typische Fragen sind.
Und also dieses PR-Fact is die Essenz, mit der PM arbeitet anders quasi Idee formed, um zu communizieren.
Und das habe ich tatsächlich noch kein anderen Unternehmen so kennengelernt.
And this Artefact wird dann genommen später von Engineering als Anforderungsanalyse.
Also das sind auch sehr viele technische Fragen schon drin zu dem jeweiligen Projekt.
Kurze Zwischenfrage, weil du Stakeholder erwähnt hast.
Kannst du da mal Beispiele nehmen by so einem Feature?
Also, wen muss man da überzeugen?
Wer entscheidet dann am Ende, ob so ein Feature wirklich entwickelt wird?
Weil das entscheidest du, wie es klingt nicht du alleine in dem Feature.
Richtig.
Genau.
Der Product Manager, der schlägt das dann vor in Form dieses PR-Fact-Dokuments.
Und dann hängt es ein bisschen von der Komplexität, dem Scope up von dem Feature.
Kleinere Sachen werden innerhalb des Service-Teams entschieden.
Weil man da jetzt die Autonomie, hat man sehr hohe Autonomie.
Bei größeren wichtigen Prestige-Trächtigen Features and Launches nutzt man, geht man meistens bewusst die nächste Stufe hoch, um die Wichtigkeit des Projekts nach oben zu signalisieren und auch Sponsorship zu bekommen.
Bei in Leadership beihin.
Das hilft halt auch, man weiß natürlich gar nicht, was auf höheren Ebenen gerade besprochen wird.
Und so erreicht man eine höhere Visibilität und verbindet auch andere Launches, die da alle passieren, zu einer größeren Gesamtstory, die dann rauskommt.
Also, das ist so ein bisschen abhängig vom Scope des Projekts.
In unserem Fall sind wir fast bis zum CEO hochgegangen.
Und dann ist in die nächsten Stufen nach so einem PRFAC, da kommen ja weitere Stufen, zum Beispiel das Pricing zu machen.
Also brauche ich ein Pricing überhaupt dafür?
Das Naming, wie benennt man das, was man da irgendwie hat?
Oftmals nutzt man ja ein Projektname.
Das heißt, Marketing kommt dann sehr stark mit rein.
Und immer dann gibt es gewisse Stufen, die man durch muss.
Und das entscheidet man auch gesamt mit der Leadership Chain, wie hoch das sollte oder muss.
Jetzt habt ihr den Launch gemacht.
Oder vielleicht noch nicht generally available, GA, vielleicht irgendwie mit ein paar Kunden getestet.
Wie evaluiert ihr Erfolg?
Also wie sieht Erfolg in der Rolle des Projekt, Projekt, äh, Projekt, Entschuldigung, siehst du?
Jetzt habe ich schon wieder den Mythos gestärkt, ja, PM.
Wie sieht Erfolg in der Rolle des Produktmanagements aus und wie misst man zum Beispiel jetzt Erfolg nach einem Feature Launch, um zu gucken, okay, war das jetzt das Richtige?
Habe ich gute Arbeit gemacht?
Weil du hast ja gerade sehr viel gesagt, du hast sehr viel Zeit darauf aufgewendet.
Das bedeutet, Zeit ist immer ein Geldinvestment der Firma.
Also auf welche Metriken schaut ihr?
Ist das eine rein subjektive Thematik auf Basis von Kundenfeedback oder habt ihr harte quantitative Metriks, wo ihr sagt, dieser Graph geht nach oben und wenn dieser Schwellenwert überreicht, überschritten ist, dann war es ein erfolgreicher Produktlaunch.
Kurz zum GE, nicht GE.
Also es ist tatsächlich so, dass wir versuchen, jedes neue Feature oder Produkt direkt GE zu machen, also General Availability.
Was auch eine höhere Hürde dann für den Produktmanager und das ganze Team ist, weil die Anforderungen auch höher sind.
In wie viele Regions gehst du raus, was ist das Service-Level und so weiter.
Der Grund, GA zu sein, ist einfach, dass die meisten Kunden erwarten, dass das Feature GE ist stable.
Ansonsten hast du vielleicht ein Prototyp und dann hast du nämlich genau das Thema nach dem Launch.
Wie erfolgreich sind wir?
Ja, wir werden erfolgreicher beim WGA, weil wir nur in einer Preview-Phase zum Beispiel sind.
Also deswegen ist es tatsächlich das Ziel, immer ein GE zu machen.
Da gibt es auch Abweichungen davon.
In unserem Fall sind wir aber GA gegangen.
Das heißt, jetzt kann ich ganz anders evaluieren, weil meine Kunden, es gibt zumindest nicht die Ausrede, ja, weil wir Preview sind, haben wir nicht so viele Kunden oder so.
Sondern die KPIs, also die Messbarkeit von Erfolg, wird auch schon viel vorher, weil er hat er vorher festgelegt.
Das startet quasi nicht nach dem Projekt, sondern vorher schon an verschiedenen Metriken.
Wir haben so Core-Metriken, wie jedes Unternehmen sicherlich auch.
Adoption, Usage, so klassische Sachen.
Dann natürlich das, was du gerade sagtest, das Kundenfeedback, was reinkommt.
Wenn irgendwie, wenn ich mit zehn Kunden spreche und zehn sagen, ich kann es nicht nutzen, weil, dann ist es sicherlich nicht erfolgreich.
Dann habe ich irgendwo ein Miss an der Stelle.
Was haben wir übersehen?
Und dann geht man wieder zurück an dieses Peer-Reffact-Dokument.
Warum war das da nicht drin?
Was haben wir?
Also, man versucht immer in so einem kontinuierlichen Loop auch zu verbessern.
Nicht alles perfekt machen.
Aber man versucht ganz viele Blindspots über Messbarkeit rauszunehmen.
Und da muss ich noch eine ganz kurze Detour machen, ich komme gleich wieder zurück auf deine Frage.
Es gibt so eine schöne Anekdote von Jeff Bezos, der gesagt hat, es stehen zwei Leute im Raum und der eine sagt, du, was glaubst du, wie hoch der Raum ist?
Das ist deine, weiß ich nicht, 15 Meter, sagt der andere, ich denke 17.
Okay, einigen wir uns.
Machen wir 16.
Die Philosophie bei AWS ist, wir messen.
Wir machen nicht eine Bauchentscheidung halt raus.
Vielleicht waren es 30 und beide lagen irgendwie komplett falsch.
Also Messbarkeit, Datenbasis, ist unfassbar wichtig.
Und dadurch kommen wir dann auch wieder zurück zum Projekt Erfolg.
Wir haben sehr viele Instrumente oder Metriken auch, um zu erkennen, wie das in Feature genutzt wird.
Viel Telemetrie auch.
Natürlich im Einklang mit Datenschutz und so weiter und so fort.
Aber da haben wir ganz viele Instrumente.
Wir haben eine riesengroße Partner- und Kundenbasis.
Also, der Vorteil bei AWS, es gibt natürlich auch Nachteile bei so einem großen Unternehmen, aber einer der Vorteile bei AWS ist, ich habe ganz viel Feedback, fast schon zu viel.
Ich habe ganz viele Signale.
Also an Feedback mangelt es mir nicht.
Die Messbarkeit ist dann natürlich auch Revenue, wenn jetzt ein Produkt rauskommt, was irgendwie ein Revenue-Ensatz hat oder Deployments, Open Source, Stars, unterschiedlich, aber wir haben ganz viele Instrumente zu messen.
Und das wird auch ganz genau gemessen.
Regelmäßig.
Und wann legt ihr diese Metriken fest?
Also, ist es dann schon in dem FAQ-Dokument ganz am Anfang?
Stehen da auch schon Metriken drin?
Genau.
Okay.
Und wie detailliert sie?
Oder wie groß ist denn so ein Dokument?
Weil wenn da schon Metriken und so drin stehen, das klingt ja schon nach 20 Seiten irgendwie.
Ach, das ist viel länger.
Es gibt auch tatsächlich, es wurde vor kurzem das Lambda, das originale Lambda PR-Fact, veröffentlicht.
Das ist ein ganz gutes Peer-Effect, was man sich mal durchlesen sollte, weil Lambda schon so ein bisschen auch die Industrie damals vor zehn Jahren revolutioniert hat mit Functions as a Service und Computing.
Das ist natürlich gekürzt, da sind ein paar interne Sachen rausgenommen aus dem, was man veröffentlicht hat, aber allein das ist, glaube ich, locker 15 Seiten.
In der Regel, meine sind immer so 30, 40 Seiten, weil was da auch drin ist, sind schon mal API-Designs, sind schon drin.
Auch da wieder die Verzahnung mit Engineering zusammen.
Konsole, Mox, das Deployment, wie arbeitet der Kunde damit?
Das ist auch schon mit drin.
Deswegen, da hast du einen ganz großen Appendix hinten dran.
Und eine der Fragen in den FAQs ist auch, wie messen wir denn Success?
Wie definieren wir den Success von dem Produkt?
Das ist da auch mit drin.
Das wird also ganz viel, 99,99 Prozent, wird versucht im Vorfeld zu adressieren über Fragen über Reviews.
Deswegen ist dieser Prozess auch sehr langwierig.
Aber bei der Scale auch wie eine AWS-Arbeitet notwendig.
Jetzt hast du schon erwähnt, du bekommst sehr viel Feedback.
Also, du hast die, wie nennt es jetzt mal quantitativ, die Metriken, die wirklich die Hardcore-Effect und dann hast du ganz viel Feedback, qualitativ ist Feedback hoffentlich.
Wie ordnest du das dann ein?
Oder wie wird das überhaupt?
Kommt es mal zu dir oder wird es im Vorfeld schon zusammengefasst und du probierst es dann irgendwie nochmal zu kommunizieren, zu funneln.
Wie schauen da die Stages aus, wo so ein Feedback von dem Kunden durchläuft?
Da muss auch glaube ich jeder Produktmanager so ein bisschen selber für sich lernen.
Wie die Quellen anzapft.
Es gibt sehr viel Feedback öffentlich auf Blogs.
Mittlerweile nutze ich Tools, Spots, die so Reddit, Hacker News, Blogs abgrasen, mir jede Woche so ein Digits zusammenstellen.
Was so die Community über das Feature sagen oder sagt.
Dann interne Kommunikation.
Slack-E-Mails, Product-Feature Requests, direkte Pings, die wir bekommen.
Und wo man dann als PM aufpassen muss, ist, dass man das alles auch strukturiert und niederschreibt.
Weil es ist bei so vielen Signalen und Quellen, die man hat, muss man halt, fragt man sich dann, oh, wo wurde das nochmal?
Wann hat er das gesagt?
Also man muss relativ stringent auch sich organisieren.
Das habe ich auch erst lernen müssen.
Klingt jetzt trivial, ist aber bei so vielen Quellen und auch so viel Durchsatz, den man hat am Tag in der Firma, wichtig.
Also dieses Feedback zu kategorisieren, weil das wiederum mir hilft als Produktmanager, dann meine Stakeholder zu überzeugen, dass wir ein neues Feature bauen sollten oder hier was priorisieren müssen und da helfen Daten.
Das PA-FAQ-Dokument zu Lambda habe ich gerade auch mal in die Show Notes gepackt.
Sehr interessanter Read.
Wurde im November 24 von Werner Vogels auf seinem Alldistributed.com vor Blog veröffentlicht.
Sehr guter Block, meines Erachtens nach, aber ich bin auch ein kleiner Fanboy, wie Wolfgang mich beschreiben würde.
Jetzt hattest du schon gesagt, du organisierst auch sehr viel Communication mit den Stakeholdern und disagree and commit und all die all die Kultur.
Meine Frage ist jetzt: Ich trifft denn am Ende eigentlich die finale Entscheidung?
Natürlich.
Die simple Antwort ist ja wahrscheinlich der CEO.
Weil der hat ja den Hut auf und der nimmt auch das Risiko auf sich und alle Büro dran.
Aber wer trifft am Ende die wirklich finale Entscheidung über einen Produkt, über einen Produkt Launch und Flippfrage natürlich dann, wo endet der Einfluss eines Produktmanagers?
Jetzt in diesem Falle im Spezifischen bei AWS, weil du arbeitest da und deswegen kannst du wahrscheinlich jetzt nicht für Booking.com oder für BMW sprechen.
Also ich hatte es vorhin schon gesagt, eine der Leitlinien bei ABS ist ja dieses Thema Ownership.
Das heißt, auch ein Engineer oder ein Solution Architect aus dem Feld kann ein gewisses Feature entwickeln.
Also du musst ja nicht immer irgendwo in einem Service-Team arbeiten, wenn du einen Open Source-Projekt hast, wo du dafür brennst und glaubst, damit eine Kundenlösung zu treffen.
Du musst halt nur jemanden überzeugen davon.
Und ob das jetzt ein PRFA immer sein muss oder ein kleineres Design-Doc oder Working Backwards-Document, was wir so haben.
Es gibt eine formale Entscheidung und eine, ich will mal sagen, so eine inhaltliche Entscheidung.
Die inhaltliche Entscheidung wird individuell getroffen.
Entweder von einem PM oder in der Regel von einem PM oder von einem Owner, von einem oder vielen Owner innerhalb des Unternehmens.
Wenn der in der Lage ist, seine Stakeholder zu überzeugen, dann gibt es nur noch dieses formale Approval.
Gibt es Approval Chains, je nach Scope und Impact.
Also deswegen würde ich sagen, die Entscheidung ist tatsächlich bei dir selbst, indem du auch selber anfängst, die Entscheidung zu treffen, dass du irgendwas verbessern willst.
Wenn ich dann mal weitergehe, gibt es Produktentscheidungen, die du vertreten musst, weil du so viel Einfluss hast, wo du innerlich zweifelst, wo du sagst, da habe ich vielleicht nicht eine ordentliche Datenbasis.
Oder vielleicht lehnst du dich mal ein bisschen weit aus dem Fenster.
Kann ja auch sein.
Oder irgendjemand hat halt overruled oder einfach deutlich bessere Argumente, disagree and commit, wo du mal disagreed muss in dieser Hinsicht, wo du sagst, oh, ich habe innerliche Zweifel.
Und dann die andere Frage, wie oft würdest du dann im Nachhinein vom Gegenteil überzeugt?
So nach dem Motto, dass es dann intuitiv vielleicht richtig war, das zu vertreten, obwohl du innerliche Zweifel hast.
Das sind auch, glaube ich, zwei, drei Fragen jetzt drin gewesen.
Lass mich die mal auspacken.
Also die erste, also Disagreeing Commit hast du ja schon mal genannt.
Es gibt aber noch ein anderes Leitprinzip.
Und es ist auch nicht so, dass die sind zwar so gerankt von 1 bis 15 sind es, glaube ich, gerade, aber das ist nicht so, dass eins höher ist als 15.
Die können stehen auch im Konflikt miteinander.
Und eines der anderen Leitlinien ist auch Bias for Action.
Also im Zweifel entscheidet dich auf einer gut genug Datenbasis.
Wenn du, wenn deine Entscheidung eine Two-Way-Door Decision ist.
Also sehr viele Anglizismen hier drin.
Also, also wenn deine Entscheidung reversibel ist oder keine Konsequenz hat, dass du sie, also du kannst es halt immer noch fixen.
Bei One-Way-Door Decisions und was ist eine One-Way-Door Decision?
Klassische One-Way-Door Decision is Pricing.
Du setzt einen Preis fest, sehr schwer den Preis nach oben.
Nach unten geht immer, ja.
Aber sehr schwer, den Preis nach oben zu setzen.
Pricing, naming.
Das sind ganz starke One-Way-Decissions, wo ganz, ganz lange iteriert wird und diskutiert wird.
Die meisten Entscheidungen, die ein Produktmanager trifft, sind aber hoffentlich Two-Way-Dor-Discisions, wo er mit einer gut genug Datenbasis und seiner Erfahrung einfach in Aktion treten kann und Dinge entscheiden kann.
So, also das wollte ich bloß mal so ein bisschen einordnen.
Es ist nicht immer nur Disagreeing Commit.
In der Regel ist es also wahrscheinlich 90% Bice for Action.
Dann hast du hoffentlich wenige One-Way-Doors, wo du ganz viel umdrehen musst und dann hast du diese Disagreeing Commits.
Wurde ich überruled in meinen Projekten noch nicht.
Da geht es eher so, da gibt es weniger ein Disagree Commit, das ist eher so die Priorisierung.
Wir schaffen das nicht.
Guck mal, hier ist noch was ganz anderes.
Und dann passt man sich an.
Also, das würde ich mal so sagen, das würde ich jetzt nicht unter Overruled verstehen, weil ich natürlich dann selber auch ein Agreement gefunden habe, im Sinne des Kunden, im Sinne des Teams.
Aber es gab auch Disagreeing Commits, die ich gegeben habe.
Das waren aber auch, das sind in der Regel Projekte von anderen, PMs, Kollegen, wo ich Feedback hatte, wo ich glaube, dass man es vielleicht hätte eine andere Entscheidung treffen sollen oder nicht ganz dahinter stand.
Aber dann habe ich Disagreeing Commit gemacht und das ist auch okay.
Habe ich jetzt alle beantwortet.
Ich glaube schon.
Wenn nicht, ist es mein Fehler als Interviewer, dass ich zu komplexe und zu verschaffelte Fragen stelle.
Lass uns mal, lass uns mal ein bisschen ein bisschen weg von Produktmanagement bei AWS im Spezifischen gehen, sondern zu einem Clickbite-Claim, den du im Vorgespräch rausgehauen hast.
Und zwar sagtest du, im Zeitalter von AI wird die Rolle des Produktmanagers wichtiger, nicht unwichtiger.
Aber zeitgleich auch sagtest du, dass im Zeitalter von AI viele Knowledge worker oder viele Knowledge Work redundant wird.
Und dann ist natürlich die offensichtliche Frage, warum trifft es Produktmanagement nicht zuerst?
Sehr gut.
Waren auch wieder ein paar verschachtelte Fragen da drin jetzt.
Es ist immer super, du kannst dir dann aussuchen, was du, was du beantworten willst.
Du kannst es so Politiker-like machen.
Ein kleines Teil rauspicken und sonst nichts beantworten.
Und hoffen, dass Andi vergessen hat, was er gefragt hat.
Ja, das vergisst du so, wieso ist es okay.
Genau.
Also, genau, das habe ich gesagt im Vorgespräch, Andi.
Wenn man sich so ein bisschen anguckt, wie Industrialisierung, diese Blue Collar, also Leute im Blau Mann.
Ich will nicht sagen, ersetzt hat, aber umgekrempelt hat, glaube ich, passiert was ähnliches gerade für die White Collar, also die Labor-weiße Umhänge tragen.
Also die Knowledge Worker.
Denn du hast halt in deiner Hosentasche den Supercomputer drin, der die jegliche Frage beantworten kann.
Man sieht ja Benchmarks permanent, dass die besser in Mathe-Olympiaden werden, sowieso alle Unitests schon parsen.
Also es ist sehr schwierig, überhaupt noch ein Feld zu finden, wo ein Individuum besser ist, smarter ist als die KI.
Und weiß ich nicht, wie es euch ging, aber über Weihnachten, über die Feiertage war extrem viel in den Social Netzwerken, aber ganz viel Vibe-Coding und was Leute alles gebaut haben.
Und das Thema da war, die waren alle nicht technisch.
Es waren alle keine, vielleicht waren sie Backendentwickler, aber keine Frontend Entwickler oder waren überhaupt keine Entwickler und haben unfassbar gute Ideen umgesetzt, was sie so vorher ohne KI nicht konnten, weil sie immer in Abhängigkeit waren von irgendeinem Service Provider oder irgendeinem Engineer oder irgendeinem Produktmanager.
Und das hat für mich nochmal so ein bisschen das Thema forciert, wie bahnbrechend oder umbrechend KI ist, auch für unsere Jobs and unserem Jobumfeld.
Vielleicht ähnlich wie das Internet.
Vor dem Internet war ja Information gar nicht so frei zugänglich.
Das Internet hat Informationen frei zugänglicher gemacht.
Jetzt macht es KI noch einfacher, Informationen zu verarbeiten oder Dinge halt zu ermöglichen.
Das sagen auch schon viele, dass so klassisches Software Development, ich will nicht sagen Software Engineering, weil Software Engineering, das ist ein kleiner Unterschied zum klassischen Software Development.
Aber klassisches Software Development, wo ich Coach schreibe, den ganzen Tag irgendein Ticket nehme und irgendwas mache, da würde ich mir schon Gedanken machen über meine Zukunft.
Weniger, ob ich den Job morgen noch habe, mehr über kriege ich überhaupt noch das Jobangebot, die Umgebung, die Bezahlung, die ich heute habe.
Das haben wir ja auch gesehen bei Systemadministratoren, als die Cloud gekommen ist.
Braucht ein viel weniger Systemadministratoren.
Du musstest dich als höher höher qualifizieren, wurdest du auf einmal Cloud-Architekt, sowas.
Also es wird sich sehr viel verändern.
Auf der anderen Seite habe ich aber, sehe ich auch die Power, die KI mir gibt in meinem täglichen Doing als Produktmanager.
Jetzt wollte ich schon fast Projektmanager sagen, Andy.
Hab's aber nicht gesagt.
Und zwar, dass ich selber ganz viel Prototypen bauen kann.
Ich habe natürlich als Engineer konnte ich sowieso schon sehr viel bauen, aber natürlich nicht in der Geschwindigkeit, die ich es jetzt mit KI machen kann.
Frontend Mox, Figma, überall da, wo ich abhängig bin von anderen Leuten, die mich bremsen, weil die Leute andere Prioritäten haben in einem Unternehmen, wir wissen alle, wie das ist, kann ich jetzt mehr quasi so self-sufficient.
Also ich bin unabhängig von anderen, primär und kann viel schneller Innovation betreiben, Entscheidungen, Dokumente schreiben.
Also ich sehe ein absolutes Riesenpotenzial von diesen Tools für Produktmanager, auch Engineers, aber auch eine gewisse Vorsicht von sich zu hinterfragen, ob meine Rolle noch relevant ist.
Aber bedeutet dies nicht im Umkehrschluss, dass deine Rolle doch gefährdeter ist, weil jetzt natürlich jeder die Möglichkeiten hat und deswegen natürlich auch mehr Konkurrenz auf dem Markt ist und Leute, also eine Produktmanagementstelle wird ausgeschrieben und die doppelte dreifache, vierfache Anzahl an Leuten, dass das du hier trotzdem mehr gefährdet bist, weil jeder halt ja diese Möglichkeit.
Korrekt.
Und das gleiche, ersätze PM mit Engineer oder Software-Developer und so weiter.
Wenn du siehst, wie heute Software-Engineers mit den Tools schon arbeiten, wie schnell die sind, welche Projekte sie vorweisen können im Vergleich zu jemandem, der die Tools nicht nutzt.
Das gleiche gilt für PM.
Jemand, der sich in einer Firma bewirbt, und das sieht man ja auch bei offenen Stellen bei Firmen, die halt sagen, zeig mir, was du gemacht hast.
Erzähl mir nicht, ich brauche dein Lebenslauf nicht.
Zeig mir einfach, was du gemacht hast, zeig eine Webseite oder ein Service oder irgendeinem Produkt, irgendwas, was du entwickelt hast.
Also Show and Tell.
Natürlich muss man dann immer noch gucken, wie viel Wahrheit ist drin.
Das erfährt man dann im Interviewprozess wahrscheinlich.
Aber erstmal ist es für viele viel einfacher geworden, zu zeigen, irgendwas zu prototypisieren, zu bauen.
Das heißt natürlich auch, dass ich mich weiterentwickeln muss.
Deswegen setze ich mich auch mit den Tools auseinander und sehe auch dieses Potenzial und den Effekt auf mich selber, um mich zu differenzieren.
Also ja, ich auch am Ende des Tages ist wahrscheinlich jeder gefährdet, wenn er stehen bleibt, aber genau deswegen tue ich das nicht.
Weil man könnte ja auch argumentieren, weil du jetzt sagst, PMs sind dann noch wichtiger oder wichtig.
Weil wenn ihr das jetzt einfach paraphrassiert, dann kann er ja auch dich jetzt in einen Agent stecken.
Und Werner Vogels hat irgendwann eine Idee und fragt dann diesen Agent, meinem PM-Agent, jetzt mach mir mal dieses Faktdokument und stell mir da mal alles zusammen mit den Metriken und hol dir die Infos und dann zwei Tage später kommst du wieder vorbei, Agent, und sage nochmal Thumbs Up oder Thumbs Down und dann geht es an die Agents von den Entwicklern.
Und dann brauche ich eigentlich kaum mehr irgendein PM, weil wie du ja sagst, umso datengetriebener mal ist, umso vielleicht einfacher ist es auch für jetzt irgendeine AI daraus, irgendwie was rauszuziehen oder weiterzuarbeiten, weil dann gibt es ja klare Metriken und klare Facts und es ist weniger irgendwie eine Bauchentscheidung oder so irgendwie ein Gefühl oder sowas in der Richtung.
Das heißt ja dann, dass die PMs schon auch dementsprechend vielleicht nicht mehr gebracht werden.
Genau, könnte man provokativ meinen.
Und haben wir intern natürlich auch gesehen, als so die ersten Leute angefangen haben, PRFX mit LLMs zu schreiben.
Ich habe diese Idee in One Zeiler, One-Prompt, schreibt mir ein P-R-Fack.
Da kann man sich, glaube ich, vorstellen, was dabei rauskommt, weil es nicht genau spezifiziert ist.
Und das sehen wir halt gerade auch bei Coding, ja, Spec-Driven Development, spezifizieren vorher.
Der Code, der rausputzelt, ist genauso gut wie die Anforderungen oder der Input, den ich vorne reinstecke.
Und ich hatte es letztens mit einem guten Kumpel auch länger besprochen über ein Bierchen, dass Anforderungsmanagement und Anforderungsanalyse umso wichtiger wird im Zeitalter von KI, weil die Agents so mächtig sind, aber sie brauchen Steuerung.
Und diese Anforderungen, jetzt könnte man auch sagen, gut, dann können ja die Agents, dann hast du einfach so ein Anforderungen, Analyse-Agent.
Das Problem an KI stand heute noch, ist, wenn diese virtuelle Welt auf die reelle Welt trifft.
Noch sind wir quasi, wir leben als Menschen in so einer realen Welt hier drin, verhalten uns anders, kommunizieren anders.
Und deswegen glaube ich, Menschen, die an dieser Schnittstelle sitzen, sehr stark mit Kunden jeden Tag interagieren, sind, wenn es noch ein bisschen sich gegen KI wehren können, als das komplett quasi in die Hände von KI geben zu können.
Man hört es ja auch aus dem Handwerk und in der Pflege.
Also das sind ja so diese Jobs, die sicher sind vor KI, sagt man ja heute.
Deswegen glaube ich auch, dass Produktmanagement gar nicht so ersetzbar ist, genauso wie Sales.
Weil am Ende das immer noch ein People-Business ist.
Und so hat jeder seine Wichtigkeit und das glaube ich, kann man über kurze Zeit auch nicht mit KI ersetzen.
Ja, ich bin, ich bin gespannt, wie sich die ganze Thematik entwickelt.
Und du hattest auch schon diesen, ich sag mal, Switch jetzt über die Feiertage 25 angesprochen und mich hat der auch komplett gehittet.
Ich war sehr, sehr lange AI-Kritiker, weiß ich nicht, ob Kritiker vielleicht schon ein bisschen zu viel ist.
Doch, doch, das bestimmt schon.
Konservativ, weil die Ergebnisse, weil jeder hat es auf LinkedIn so hochgehypt und ich habe die Ergebnisse einfach nicht gesehen.
Und das hat sich jetzt über die Feiertage geändert.
Bin ich auch offen und es hat mich positiv überrascht.
Aber vorher, ich bin auch ehrlich, da ist einfach nur zu viel Scheiße im Markt.
Jeder hypt sich hoch und jeder versucht irgendwie auf den Waggon aufzuspringen.
Und ich finde, das hat sich jetzt erst richtig geändert.
Tolle Technologie, gar keine Frage.
Aber manche haben es ein bisschen Overhype zuvor.
Aber deswegen bin ich sehr gespannt, was die Zukunft bringt, denn wir wissen alle, Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen.
Also fokussieren wir uns auf den Menschen, oder Andi.
Ich, wir sind immer People first.
Auf die Kommunikation.
Immer People First, ja.
Ich meine, das ist vielleicht auch der Grund, warum Leute AI-Slop oder warum Leute wirklich so einen großen Hass auf AI-Slot haben.
Und von daher.
Ich habe die Tage noch einen schönen Blogpost gelesen von Matthias Endler.
Grüße gehen raus, dass er auch, ich sag mal, ihm nervt es hart, dass jetzt nur noch AI-basierte Blogposts rauskommen und er hat dann dafür gewotet, dass wir doch wieder mehr menschlich geschriebene Blogposts produzieren.
Fand ich auch sehr schön.
Aber wir haben auch einen Lehrauftrag in diesem Podcast.
Und wir haben auch einen Auftrag, dass Leute neue Ideen mitnehmen, was sie zum Beispiel selbst besser machen können.
Und da wollen wir jetzt mal dein Wissen anzapfen, Michael.
Und zwar geht es um die Zusammenarbeit zwischen Entwickler und den EntwicklerInnen mit dem Produktmanagement.
Deswegen würde ich gerne mal von dir wissen, welche Tipps kannst du mitgeben, was eine Entwicklerin oder Entwickler konkret tun kann, um dir als Produktmanager, ich sag mal, das Leben einfacher zu machen, um dich sag mal, zu unterstützen.
Genau, das ist auch so eine Mentorrolle, die ich gerade habe für unsere, also insbesondere Junior Engineers bei uns.
Denn die kommen typischerweise von der Uni oder haben so ein paar Jahre Erfahrung in der Softwareentwicklung und haben dieses Jira-implementieren fertig.
Und ich, das wird sich verändern und das will ich auch, dass so ein Engineer einfach nicht mal so ein einfach nur Jira-Ticket nimmt und irgendwas machen muss.
Sondern ich möchte, dass unsere Entwickler, also gerade die Juniors, mehr zu ownern, halt hin entwickeln.
Und das bedeutet, dass anstatt dass ich evaluiere, was ein Kunde braucht, aus den Signalen, die weiter haben.
Und das muss ja jetzt nicht ein neuer Service sein, das können kleine Features oder Optimierung sein, dass der Engineer selber quasi sich diese Information zieht aus unseren Quellen.
Und das ist in jedem Unternehmen, jedes Unternehmen hat ja sicherlich irgendwelche Informationen und Datenbasis da.
Und dann eine Dokumentation schreibt, ein Dokument schreibt, indem man sagt, okay, this is my problem, das ist das Problemfeld, was ich angehe, hier ist eine Lösung, hier ist die Erfahrung, hier ist die API, hier sind die offenen Fragen, die ich habe.
Das ist ein Großteil der Aufgabe, die ich als PM auch machen muss.
Und das hatten wir vorhin schon besprochen mit Field Solution Architects.
Wenn jetzt hier Leute dabei sind, die nicht aus der Entwicklung kommen, sondern vielleicht im Feld unterwegs sind.
Genau das hilft den PMs.
Weil diese Anforderungsanalyse und das Kristallisieren, vielleicht skizzieren von einer Lösung, muss ansonsten ich übernehmen.
Und dann muss ich priorisieren.
Und je mehr du oder der Engineer oder der Feldkollege dafür schon macht, desto einfacher habe ich es natürlich sagen, okay, das klingt ja echt spannend.
Und tatsächlich haben viele Kunden dieses Problem.
Ja, das ist schon die Hälfte der Aufgabe gemacht und jetzt können wir das durch exekutieren.
Also jemanden zu einem Champion machen, zu einem Champion und Owner zu entwickeln, and nicht zu sagen, okay, PM, was bauen wir mal.
Daran sehe ich meine Aufgabe gerade.
Also eigentlich, dass die Developer mehr zum PM werden, or zumindest ein Steile.
Korrect.
Weil ich als PM werde auch immer mehr als Engineer.
Weil ich mit den LLM-Tools kann die RPIs bauen.
Ich habe natürlich gute Erfahrungen oder Wissen aus dem Hintergrund von früher, aber das hilft ja auch den Engineers.
Here's eine API, ich habe mir schon Gedanken darüber gemacht, ich habe schon mit Kunden drüber gesprochen.
Da brauche ich kein Engineer im Call.
Kann ich mit den Kunden einfach die RPI schon mal oder die CLI oder was auch immer durchsprechen.
Also die Grenzen sind da ein bisschen fließend.
Ich will nicht sagen, dass PM oder Engineering irgendwann nur noch eine Rolle ist.
Vielleicht in kleineren Unternehmen, in größeren nicht.
Aber trotzdem nähern sie sich an.
Aber allgemein zusammenfassend könnte man ja sagen, dass du gerade Proaktivität beschrieben hast, oder?
Ich meine, nicht darauf warten, dass der Produktmanager sagt, okay, bau das, sondern dass man wirklich proaktiv vorgeht, wirklich, ich sag mal, versucht mitzudenken und Pipa Pro wie sagt, du hast gerade Champion genannt.
Das ist ja auch so ein Wort im Vertrieb.
Da kenne ich es zumindest ja, Solutionarchitekt, ja, wer ist mein Champion auf der Kundenseite, wer drückt meine Firma intern durch und so, da kenne ich es her.
Ist das richtig?
Klar, und am Ende, viele der Hörer werden vielleicht jetzt sagen, das ist ja alles trivial und mache ich ja eh schon.
Sehr gut.
Aber also gerade bei Junior Engineers sehe ich es halt nicht, woher auch, ja.
Und die möchte ich natürlich dahin entwickeln.
Schneller als sonst.
Wir erwähnen das immer öfter.
Natürlich ist es trivial.
Kanban, die Anwendung von Kanban ist auch trivial.
Es geht aber darum, dass es konstant Energie kostet und dadurch sehr anstrengend wird.
Beispiel, und das überrascht ziemlich viele Leute bei Kanban, so habe ich es zumindest gelernt.
Dein Ziel ist es, Tickets von Tickets, ja, jetzt nehmen wir die nicht die Toyota-Thematik, aber von links nach rechts möglichst schnell zu kriegen.
Das bedeutet auch, hast du keine Arbeit, fängst du von rechts an und schaust nach, kannst du deinen Kollegen helfen, bevor du dir selbst ein neues Ticket holst.
Und allein diese Erkenntnis, dass das Teamwork ist und so weiter, überrascht ziemlich viele.
Und das zeigt mir auch, dass die simpelsten Techniken, ich meine, kann man halt fünf Regeln oder so, die schwierigsten sind zu implementieren.
Und ich denke, das gleiche trifft auf Proaktivität zu.
Wenn wir jetzt aber mal nicht davon ausgehen, dass jeder als Entwickler in der gleichen Rolle bleiben möchte, um zum Beispiel den Produktmanager dazuzuarbeiten oder die Zusammenarbeit zu verbessern, sondern wenn man sagt, okay, ich war jetzt zehn Jahre in dem Entwicklertum, ich möchte jetzt gerne auch mal die Rolle des PMs einnehmen.
Was würdest du jemandem beraten, der mal reinschnuppern möchte, ohne direkt Produktmanager zu werden?
Oder wenn man sich doch schon entschieden hat, wenn man sich mit der Thematik schon länger beschäftigt hat, was würdest du vorschlagen, dass jemand tun sollte, um den Weg mal zu explorieren und sich vielleicht sogar auf eine PM-Rolle zu bewerben.
Also als Mentor für interne Kollegen sehe ich das auch regelmäßig, dass Kollegen aus unterschiedlichen, nicht nur aus dem Software-Entwicklung bei uns in der PM-Rolle bewegen wollen, weil die PM-Rolle auch eine sehr starke, also prestigeträchtige Rolle bei AWS ist.
Wenn man sich auch so ein paar VP oder CEOs bei Amazon und AWS anguckt, viele kommen aus dem PM.
Also der PM ist tatsächlich eine sehr mächtig, klingt jetzt vielleicht übertrieben, aber eine sehr mächtige Rolle innerhalb des Unternehmens.
Und deswegen wollen auch viele PM werden.
Das, wo ich so ein bisschen Erfolg gesehen habe mit meinen Menties, ist zum einen das, was wir gerade schon besprochen haben, such dir einfach ein kleines Projekt, vielleicht ein Open Source-Projekt oder irgendwas internes in Optimierung und exerziere einmal diesen Loop von Anforderungsanalyse, warum sollen wir das bauen, dieses Distillieren dieser Informationen in den Dokument, diese Reviews dazu, die auch teilweise brutal sein können, weil das Feedback ist sehr direkt oft in den Reviews.
Das ist auch eine Erfahrung.
Exerziere den einfach mal in einer Komfortzone für dich durch.
Zum anderen such dir einen Mentor, also so wie ich jetzt Mentor für interne Kollegen sind, die dir auf dem Pfad helfen können, die die Türen öffnen können, die dich mit den Teams verknüpfen können, die dir Meetings geben können.
Und wenn jemand das vielleicht schon länger macht oder sagt, jetzt will ich es mal in einem anderen Unternehmen versuchen, was mir sehr geholfen hat, ist die Vorbereitung auf den AWS-Interview-Prozess.
Und wir haben vorhin gerade über KI gesprochen und grundsätzliche Marktdynamiken.
Ich glaube, es wird nicht einfacher, sich zu bewerben heute am Markt und sich gegen durchzusetzen.
Was mir geholfen hat bei dem AWS-Prozess war, der sich auch der Loop nennt, weil du da über mehrere Stufen durchgehst, gibt es so eine Methodik, die einem empfohlen wird, weil diese, so wird man auch interviewt, die nennt sich die Star-Methodik.
Es gibt auch verschiedene und Star bedeutet Situation, Task, Assignment oder Action und Result.
Wenn man sich das einmal verinnerlicht, wenn du gefragt wirst, okay, erzähl mir mal über XY-Z, was du gemacht hast.
Und dann verfieseln wir uns irgendwo im Lebenslauf und erzählen irgendwas, aber wir sind nicht präzise genug.
Und diese Star-Methode hilft zu sagen, okay, ich war in der in der Situation, das war meine Aufgabe, was und das habe ich gemacht und das war das Outcome.
Ist unfassbar mächtig in Überzeugung, also wenn man in so einem Interview überzeugen möchte.
Und dieser AWS-Interview-Prozess, der ist öffentlich dokumentiert, weil kann sich ja jeder irgendwie mal drauf bewerben.
Das heißt, da kann man vielleicht mal so theoretisch durchexerzieren.
Andere Unternehmen haben sicherlich ähnliche.
Es gibt Bücher drüber.
Das kann ich nur empfehlen, sich da vorzubereiten, weil es sehr schwierig ist, glaube ich, heutzutage, sich durchzusetzen.
Michael, sag mir mal kurz, wie ich dich jetzt über die Videostream küsse, denn verhaltensbezogene Interviewfragen und die Star-Methode habe ich am 8.
Dezember im Engineer Cures Adventskalender 2024 ebenfalls durch exersiert.
Ich bin ein mega Fan davon.
Auch als Interviewer kriegt man da sehr, sehr viele Insights.
Und es ist wirklich eine, meines Erachtens nach, es ist eine einfache Thematik, wenn man sie einmal verstanden hat und sie erzeugt so viel Value.
Und auch, weil ich jetzt wieder sehr viel im Recruiting-Prozess unterwegs bin, ich merke einfach, wie wenig Leute eine solche strukturierte Antwortart und Weise anwenden.
Und es ist faszinierend.
Jetzt ist es nun mal so, und das ist auch meine letzte Frage, es ist nun mal so, dass leider nicht jeder Job immer super viel Spaß macht.
Jeder Job hat irgendwie Elemente, wo man sagt, komm, gut, da muss ich jetzt durch.
Passiert halt.
Sei es dem Dachdecker, der jetzt gerade kein Kran zur Verfügung hat und deswegen die Dachpfannen alleine aufs Dach schleppen muss.
Ich denke nicht, dass ein Dachdecker darauf wirklich Bock hat, sondern ich glaube, dass jeder sagt, okay, ein Kran wäre schon cool.
Was würdest du sagen, sind die Elemente im Produktmanagement, die dir nicht so Spaß machen oder vielleicht andersrum, was sind die unbequem, was ist die unbequeme Wahrheit über PMs, die zu selten ausgesprochen haben.
Allgemein ausgedrückt kann man sagen, der Stressfaktor.
Ich weiß nicht, ob das vielleicht an dieser hohen Dynamik in so einem Technologieunternehmen wie AWS liegt, aber es ist, glaube ich, kein Geheimnis, dass du insbesondere als PM mit so vielen Verantwortungen sehr hohen Stress hast.
Und der wird nicht weniger, je erfolgreicher du bist, weil dein Scope immer größer wird, der Impact, die Verantwortung und so weiter.
Das muss man schon ab können und auch da Mechanismen finden, wie man das in Balance halt mit seinem Leben, Familie, was auch immer.
Das vielleicht jetzt allgemein ausgedrückt für die PM-Rolle.
Es gibt auch ganz viele andere Jobs, wo mindestens genauso viel Stress und mehr ist, aber ich glaube, das wird nicht ganz so oft gesagt, oder das ist nicht das erste, was man über einen PM hört.
Persönlich aus meiner Erfahrung, weil ich ja auch eher einen Engineering-Hintergrund hatte, bevor ich in die Rolle gewechselt bin, was mir, wo ich sehr lange Schwierigkeiten hatte, viel lernen musste, ist das ganze Pricing, Profit and Loss, Financial Analysis, das, was man als Engineer jetzt nicht so jeden Tag macht, da musste ich ganz viel lernen.
Haben Leute, die mit einem Wirtschaftsstudium daherkommen, in die Rolle reingehen, sicherlich.
Und sehe ich auch, dass meine Kollegen mit dem Hintergrund dem Feld das deutlich einfacher.
Das ist einfach nur persönlich, mein Profil, ne?
Da würde ich jetzt nicht verallgemeinern.
Andi, super Frage.
Ending on a positive note.
Du stellst so eine stelle negative Frage noch am Ende, was ist alles schlecht und auch im Position so?
Da musst du dich jetzt rausretten, Andi.
Nein, muss ich nicht, muss ich nicht.
Ja, bleibt mal bei euch, eure Floskeln.
Ich denke, ich sehe der Realität richtig ins Auge.
Ich denke, die Realität und das Leben ist hart.
Soll man sich nicht verstecken.
Ja, ich bin jetzt hier kein, ich packe dich nicht in Watter ein, Wolfgang, ja, tut mir leid.
Es ist die Duisburger Herangehensweise, da hat man ein hartes Leben ja nicht.
Ja, pass auf, wenn wir wenn wir weichen Stahl machen würden, ja, dann wären wir auch nicht erfolgreich gewesen.
Also von daher.
Da kommen die.
Ja, Karl Schee vor der Tür, würde ich sagen.
Michael, vielen lieben Dank für deine Zeit.
Es war für mich unglaublich spannend, mal diese ganzen AWS-Mythen, Rumors, Gerüchte aus erster Hand zu hören.
Wie wird dieses Five-Question-Dokument oder diese FAQs weggemacht, dieses Working Backwards, dieses wird wirklich erst eine Pressemitteilung geschrieben.
Und co.
Super interessant.
Auch der Einfluss von Produktmanagement in dieser Organisation.
Ich denke, ein paar Organisationen können davon lernen.
Ich bin sehr froh, dass dieses Interview klappt hat.
Ich bin sehr froh, dass du die Zeit genommen hast.
In den Shownotes haben wir eigentlich ziemlich viel Material zusammengeführt.
Wie zum Beispiel natürlich auch das LinkedIn-Profil von Michael, falls nochmal wer eine Frage hat.
Aber auch die ganze Produktmanagement-Thematik, wie zum Beispiel ein Exzerpt von dem Buch Working Backwards, dann das FAQ-Dokument von Aduis Lander, was vor kurzem veröffentlicht wurde, wer das mal in Praxis sehen möchte.
Aber natürlich auch etliche Funktionen und Dokumentation sein zu Step Functions Event Bridge, was ist Serverless Computing und so weiter und so fort.
Und wer sich vielleicht auf die nächste Interview vorbereiten möchte, kann sich auch nochmal eine 10-Minuten-Episode zur Star-Methode anhören.
Das war's von uns.
Vielen lieben Dank.
Wenn ihr Feedback habt, kommt gerne in unsere Discord-Community auch zu dieser Episode.
Das Feedback leiten wir natürlich alles sehr, sehr gerne an den Michael weiter.
Wolfgang, was ist das letzte Wort von dir?
Und Michael, was ist das letzte Wort von dir für unsere Hörer am Hörgerät?
Ja, ich bin ja unwichtig in diesem Podcast.
Also von mir braucht es kein Wort.
Darum übergebe ich das direkt an den Michael.
Danke.
Also ich kann nur allen Hörern empfehlen, dass wenn sie eine Idee haben oder irgendwas teilen möchten, euch unbedingt für diesen Podcast zu bewerben.
Ich kriege ja dafür keine Werbung oder Geld.
Hat mir super Spaß gemacht.
Danke euch.
Vielen, vielen Dank.
War super spannend.
Echt vor allem diese tiefen Einblick in AWS.
Vor allem von der Product-Seite.
Und du hast mit uns jetzt die erste Episode zum Produktmanagement eingeläutet.
Und ich hoffe, es wird nicht die letzte Episode bleiben bei uns, weil es ein wichtiger Teil ist.
Und wie wir jetzt gelernt haben, auf der Developer-Seite müssen wir ja viel mehr PMs werden.
Insofern müssen wir da jetzt fast ein paar Episoden nachliefern.
Also vielen, vielen Dank auch von meiner Seite.
Danke.
Das war's von uns drei.
Wir hören uns in der nächsten Podcast-Episode und tschüss.
Ciao.
Ciao.