Wieviel Tech muss ich als Produktmanager:in verstehen?

Wie viel Tech-Wissen sollte ich als Produktmanager oder technischer Produktmanager haben?

Räumen wir einmal mit den Erwartungen auf, die man an uns als PMs stellt. Wir sollen Marketing & Sales können und gerne auch Research & UX. Ach ja, und vollwertige Coder:innen sollten wir auch noch sein. Klar. Aber mal Spaß beiseite. Was ist tatsächlich sinnvoll für uns als PMs? Zu unseren Aufgaben gehört es, die Anforderungen der Stakeholder zu verstehen, die Entwicklungsteams zu koordinieren und die Kommunikation mit dem höheren Management zu pflegen.

Muss ich als Produktmanger:in coden können?Nein. Wenn es dir Spaß macht, dann lerne es gerne. Es schadet nicht. Ein Must-have ist es aber nicht.

Muss ich Code verstehen?Überlegen wir einmal: Was wäre der Vorteil? Du könntest in den Code des Entwicklungsteams schauen und mitdiskutieren. Ist das deine Aufgabe? Nein – und damit musst du auch keinen Code verstehen. Auch hier gilt: Wenn es dir Spaß macht, lerne es gerne.

Muss ich als PM SQL oder eine andere Query-Sprache beherrschen?Es kommt darauf an. Wenn du ein stark Daten-lastiges Produkt hast oder dir oft eigene Daten aus deinem Data Warehouse zusammensuchen musst, dann kann es sinnvoll sein. Ansonsten gilt wieder: Das ist nicht unbedingt notwendig.

Sollte ich verstehen, aus welchen Komponenten ein technisches Produkt besteht?Frontend, Backend, Datenbanken, Load-Balancer… Ja, das wäre gut. Ansonsten findest du keine gemeinsame Sprache mit deinem Entwicklungsteam. Das ist deine Aufgabe als Produktmanger:in. Du kommunizierst, bringst Stakeholder zusammen und steuerst damit zum Produkterfolg bei. Zu den notwendigen Fähigkeiten eines Produktmanagers gehört es, sowohl technische als auch strategische Kompetenzen zu besitzen, um effektiv mit allen Beteiligten zu kommunizieren.

Muss ich als PM verstehen, auf welchem Tech-Stack ich sitze?Das ist mit einem klaren Ja zu beantworten. Du musst kein Experte sein, solltest jedoch auf jeden Fall wissen, mit welchen Technologien du & dein Team arbeiten und wie die grundlegende Architektur aussieht. Ein tiefes Verständnis der Entwicklung ist entscheidend, um die Produktqualität zu maximieren und die Anforderungen der Stakeholder zu erfüllen.

Warum ist es wichtig zu verstehen, auf welchem Stack ich in der Produktentwicklung sitze?

Jetzt denkst du dir vielleicht: Aber ich bin doch kein Developer! Ja, das nicht. Allerdings willst du als gute:r Produktmanager:in hervorstechen. Wenn du verstehst, wie dein Tech-Stack grundsätzlich funktioniert, wirst du in folgenden Bereichen besser werden:

• Besseres Sparing mit Developern: Du wirst die technischen Probleme besser verstehen und dadurch zu einem besseren Sparringspartner für dein Team.
• Kompetenterer Ansprechpartner für Stakeholder: Du kannst die Machbarkeit besser einschätzen und wirst dadurch zum besseren Ansprechpartner für deine Stakeholder und zum besseren Filter für dein Team. ACHTUNG: Im Zweifel solltest du trotzdem immer das Team fragen und auf keinen Fall Deadlines ohne Rücksprache zusagen.
• Deine Requirements werden besser: Weil dir die Vorzüge und Restriktionen deines Stacks bekannt sind, kannst du bessere Requirements schreiben.

Ein:e Produktmanager:in trägt die Verantwortung dafür, dass der Tech-Stack mit den Geschäftszielen übereinstimmt und die Effektivität des Teams gesteigert wird.

Diese Tech Themen musst du als Produktmanager:in verstehen

Als Produktmanager:in musst du nicht zwangsweise wirklich Coden können. Allerdings musst du in der Lage sein, mit deinem Tech Team, also den Softwareentwickler:innen effektiv zu kommunizieren. Dazu helfen diese 4 Themen:

• Daten & Datenflüsse: Auf welche Daten haben wir Zugriff an welcher Stelle? Das hilft schon im Vorfeld enorm, die Machbarkeit von Featuren zu validieren und zu verstehen, wie ihr Daten behandelt. Klingt für jemanden, der noch nicht im Produktmanagement arbeitet komplex, aber es ist eigentlich relativ einfach. Wo sind die Daten, bedeutet in welchem System oder Tabelle die Daten gespeichert sind. Die Datenflüsse beschreiben, von wo welches System Daten bekommen und wem Daten bereitgestellt werden.
• Systeme & Anbindungen: Welche Systeme gibt es und wie sind sie angebunden (externe/interne Systeme wie ERP oder externe/interne APIs etwa zur Authentifizierung)? Wer verwaltet diese Systeme? Die Zusammenarbeit zwischen Product Managern und den Entwicklungsteams ist hier entscheidend, um ein gemeinsames Verständnis der Produktziele zu gewährleisten.
• Systemische Besonderheiten: Alle Systeme haben ihre Besonderheiten. Diese Besonderheiten beeinflussen, was wir mit ihnen machen können, was schnell geht, was lange dauert… Frage dich auch: Wo haben wir technische Schulden? Vereinfacht gesagt, frag deine Entwickler welche Systeme vielleicht veraltet sind, für Verzögerung sorgen etc. Hier kommst du mit etwas Techverständnis schnell ins Thema?
• Der Stack: Welche Technologie nutzen wir und was ist ihre Besonderheit? Können wir z. B. besonders schnell Daten in die Datenbank schreiben, aber ist das Lesen für komplexe Daten langsam? Wie bei den anderen Fragen gilt auch hier: in Absprache mit deinen Softwareentwicklern wirst du die Zusammenhänge schnell verstehen, wenn auch nur auf abstrakter Ebene.

Fazit: Als Produktmanager musst du nicht unbedingt Programmieren können.

Musst du als Produktmanager Code schreiben oder lesen können? Diese Fragen musst du nicht allein beantworten. Vielmehr solltest du sie mit deiner/m Entwickler:in oder Architekt:in besprechen. Unsere Erfahrung zeigt, dass Entwicklungsteams dich hier gerne unterstützen.

In der Regel ist es wichtiger als Produktmanager die Themen auf abstrakter Ebene zu verstehen. Aber keine Regel ohne Ausnahme. Von Firma zu Firma und Team zu Team sind die Anforderungen verschieden. Du kannst diese Themen auch im Bewerbungsgespäch offen ansprechen.

Zudem ist wichtig zu verstehten, dass es verschiedene Rollen im Produkt gibt, die unterschiedlich nahe an der Technik sind. Product Owner arbeiten typischerweise direkt mit Softwareentwickler:innen zusammen. Ein Projektmanager hingegen arbeitet oft in einer übergeordneten Rolle und koordiniert verschiedene Teams, ohne direkt in die technischen Entscheidungen involviert zu sein.

‍