In dieser Podcastfolge sind Tim Klein und Julia Wissel im Gespräch und beschäftigen sich mit der Frage, wie Produktmanagerinnen und Produktmanager führen können, obwohl sie im Grunde oft keine formale Macht besitzen. Der Blick richtet sich auf den Alltag jenseits von Organigrammen – dort, wo Entscheidungen entstehen, beeinflusst werden oder auch blockiert bleiben, obwohl niemand offiziell zuständig zu sein scheint.

„Ohne Macht“ heißt nicht „ohne Einfluss“

Ohne Macht zu führen bedeutet in diesem Kontext jedoch nicht, ohne Einfluss zu sein. Im Gegenteil. Produktmanagement ist von Natur aus eine Führungsrolle, weil Produkte Orientierung brauchen und Entscheidungen verlangen. Wer Verantwortung für ein Produkt trägt, führt Teams, Stakeholder und Organisationen, auch wenn keine disziplinarische Linie existiert. Führung entsteht hier über Haltung, Klarheit und die Fähigkeit, andere mitzunehmen. Wer glaubt, ohne formale Macht handlungsunfähig zu sein, reduziert die eigene Rolle auf Verwaltung und verliert Gestaltungsspielraum.

Ein zentraler Hebel liegt in Beziehungen. Entscheidungen entstehen selten dort, wo sie im Organigramm verortet sind. Einfluss verläuft über Vertrauen, persönliche Verbindungen und informelle Netzwerke. Wer versteht, wer wessen Meinung hört und wen welche Themen wirklich treiben, gewinnt Handlungsspielraum. Ohne Macht führen heißt deshalb, Zeit in Beziehungspflege zu investieren und diese bewusst als Infrastruktur für Entscheidungen zu begreifen. Gespräche außerhalb formaler Meetings, echtes Interesse an den Herausforderungen anderer und kontinuierlicher Austausch verändern die eigene Wirksamkeit spürbar.

Gleichzeitig braucht Führung ohne Macht eine klare inhaltliche Position. Produktmanagerinnen und -manager können sich nicht darauf verlassen, dass gute Ideen sich von selbst durchsetzen. Sie müssen argumentieren, Prioritäten begründen und zeigen, welchen Beitrag Entscheidungen zum Unternehmenserfolg leisten. Daten, Nutzerfeedback und strategische Einordnung schaffen Glaubwürdigkeit. Wer klar benennen kann, welches Problem gelöst wird und warum das relevant ist, wird gehört, auch ohne formale Autorität.

Macht durch Klarheit, Vertrauen und Konsequenz

Ein weiterer Aspekt ist der bewusste Umgang mit Hierarchie. Hierarchie verschwindet nicht dadurch, dass man sie ignoriert. Sie kann Orientierung geben, wenn sie transparent genutzt wird. Führung ohne Macht bedeutet nicht, Hierarchie zu bekämpfen, sondern sie zu verstehen. Wer weiß, welche Themen auf welcher Ebene entschieden werden und welche Zeithorizonte dort relevant sind, kann seine Anliegen besser platzieren. Gespräche auf Augenhöhe entstehen, wenn man die Perspektive des Gegenübers ernst nimmt und dessen Kontext berücksichtigt.

Ohne Macht zu führen, fordert aber auch Mut. Konflikte lassen sich nicht vermeiden, wenn Produktverantwortung ernst genommen wird. Wer immer ausweicht, um Harmonie zu bewahren, verzichtet auf Wirkung. Führung zeigt sich darin, unbequeme Themen anzusprechen, Entscheidungen einzufordern und Verantwortung nicht nach oben abzugeben. Gleichzeitig bleibt es wichtig, offen für Feedback zu sein und eigene Annahmen zu hinterfragen.

Der Blick auf diese Form der Führung zeigt, dass Macht im Produktmanagement weniger aus Positionen entsteht als aus Klarheit, Vertrauen und Konsequenz. Wer bereit ist, Verantwortung zu übernehmen, Beziehungen aufzubauen und Entscheidungen fundiert vorzubereiten, führt bereits. Ohne Macht führen heißt nicht, weniger Einfluss zu haben, sondern Einfluss anders zu gestalten und bewusst einzusetzen.

Wer noch weitere Fragen an Julia Wissel hat oder direkt mit ihr in Kontakt kommen möchte, erreicht sie am besten über ihr LinkedIn-Profil.

Weiterführende Links

Auf folgende Episoden des Produktwerker-Podcasts nimmt Tim Klein im Gespräch Bezug beziehungsweise passen sie zum Kontext:

Weitere Quellen:

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Als Produktmanager ohne Macht führen – jenseits vom Organigramm“.

(mai)

Das ReactOS-Projekt feiert seinen 30. Geburtstag. Ende Januar 1996 gab es den ersten Commit zum ReactOS-Quellcode. In einem Blog-Beitrag würdigen die derzeitigen Projekt-Maintainer das Ereignis. Sie überreißen grob die Entwicklungsgeschichte des Windows-XP-kompatiblen Betriebssystems.

ReactOS-Geschichte: Aus Windows-95-Alternative entstanden

Zwischen 1996 und 2003 begannen die Entwickler, aus dem nicht so richtig vorwärtskommenden „FreeWin95“-Projekt ReactOS zu schmieden, das als Ziel keine DOS-Erweiterung, sondern die Binärkompatibilität für Apps zum Windows-NT-Kernel hat. Das zog sich allerdings hin, da sie zunächst einen NT-artigen Kernel entwickeln mussten, bevor sie Treiber programmieren konnten. Am 1. Februar 2003 veröffentlichte das Projekt schließlich ReactOS 0.1.0. Das war die erste Version, die von einer CD starten konnte. Allerdings beschränkte die sich noch auf eine Eingabeaufforderung, es gab keinen Desktop.

Zwischen 2003 und 2006 nahm die Entwicklung von ReactOS 0.2.x rapide an Fahrt auf. „Ständig wurden neue Treiber entwickelt, ein einfacher Desktop gebaut und ReactOS wurde zunehmend stabil und benutzbar“, schreiben die Entwickler. Ende 2005 trat der bis dahin amtierende Projekt-Koordinator Jason Filby zurück und übergab an Steven Edwards. Im Dezember 2005 erschien ReactOS 0.2.9, über das heise online erstmals berichtete. Anfang 2006 gab es jedoch Befürchtungen, einige Projektbeteiligte könnten Zugriff auf geleakten, originalen Windows-Quellcode gehabt und diesen für ihre Beiträge zum ReactOS-Code genutzt haben. Ein „Kriegsrat“ entschied daraufhin, die Entwicklung einzufrieren und mit dem Team den bestehenden Code zu überprüfen.

Zwischen 2006 und 2016 lief die Entwicklung an ReactOS 0.3.x. Die andauernde Code-Prüfung und der Stopp von neuen Code-Beiträgen gegen Ende der ReactOS 0.2.x-Ära haben der Entwicklung deutlich Schwung entzogen. Steven Edwards trat im August 2006 als Projekt-Koordinator zurück und übergab an Aleksey Bragin. Ende desselben Monats erschien dann ReactOS 0.3.0, dessen erster Release-Kandidat Mitte Juni verfügbar wurde, und brachte Netzwerkunterstützung und einen Paketmanager namens „Download!“ mit.

Seit 2016 findet die Entwicklung am ReactOS-0.4.x-Zweig statt. Im Februar 2016 verbesserte ReactOS 0.4.0 etwa die 16-Bit-Emulation für DOS-Anwendungen, ergänzte aber auch Unterstützung für NTFS und das Ext2-Dateisystem. Die eingeführte Unterstützung für den Kernel-Debugger WinDbg hat die Entwicklung spürbar vorangetrieben. Seit März vergangenen Jahres stellt ReactOS 0.4.15 den derzeit aktuellen Stand der Entwicklung dar.

Aber auch zur Zukunft des Projekts äußern sich die derzeitigen Projekt-Entwickler. „Hinter dem Vorhang befinden sich einige Projekte jenseits des offiziellen Software-Zweigs in Entwicklung“, schreiben sie, etwa eine neue Build-Umgebung, ein neuer NTFS-Treiber, ebenso neue ATA-Treiber sowie Multi-Prozessor-Unterstützung (SMP). Auch Klasse-3-UEFI-Systeme sollen unterstützt werden, also solche, die keine Kompatibilität mit altem BIOS mehr anbieten. Adress Space Layout Randomization (ASLR) zum Erschweren des Missbrauchs von Speicherfehlern zum Schadcodeschmuggel befindet sich ebenfalls in Entwicklung. Wichtig ist zudem die kommende Unterstützung moderner Grafikkartentreiber, basierend auf WDDM.

(dmk)

Viele ältere Anwendungen profitieren deutlich von einer Modernisierung zu einer Cloud‑Native‑Architektur. Dieser Ansatz löst bestehende Probleme durch neue Technologien, bietet Entwicklerinnen und Entwicklern eine moderne Arbeitsumgebung und eröffnet neue Absatzchancen als Software‑as‑a‑Service. Verschiedenen Studien zufolge ist Modernisierung bei einer Mehrheit der Unternehmen unvermeidlich, weil deren Altanwendungen geschäftskritisch sind (siehe Lünendonk: Unternehmen ringen mit der IT-Modernisierung und Thinkwise: Legacy-Modernisierung – Warnsignale ernst nehmen). Daher wächst das Interesse, bestehende Kernsysteme zu modernisieren und fit für die Cloud zu machen.

Vorbereitung: Konzeptionsphase

Einer Modernisierung geht meist ein Konzept voraus. Dieses analysiert alte und neue Anforderungen und beschreibt, wie sie umgesetzt werden sollen. Es benennt betriebliche Anpassungen und konzipiert neue Teamstrukturen. Auf dieser Basis erstellt das Unternehmen Schulungspläne für die beteiligten Mitarbeitenden. Alle Änderungen fließen in eine Roadmap ein, die sowohl verpflichtende als auch optionale Schritte mit ihren jeweiligen Kosten abbildet.

Frühe Aufwandsschätzung

Oft ist schon vor dem Modernisierungskonzept eine erste Aufwandsschätzung nötig, etwa für die Budgetplanung. Diese Schätzung ist schwierig, weil Anwendungen komplex sind und sich konkrete Änderungen erst nach einer Analyse bestimmen lassen. Manchmal stehen mehrere Systeme zur Auswahl. Dann müssen Architektinnen und Architekten den geeignetsten Kandidaten identifizieren und eine grobe Kostenschätzung für die kommenden Jahre entwickeln. Unternehmen erwarten in dieser Phase häufig eine schnelle Einschätzung mit nachvollziehbaren Zahlen – quasi ein fundiertes Bauchgefühl.

Zur Veranschaulichung dient ein reales Beispielprojekt. Das Produkt läuft seit acht Jahren und umfasst ein Team aus einem Frontend-Entwickler, einem Backend-Entwickler und einem Architekten, die sich um die Weiterentwicklung kümmern – alle in Vollzeit. Pro Jahr entstehen rund 600 Personentage an Aufwand; über acht Jahre summiert sich das auf 4800 Personentage. Das Team war zu Beginn möglicherweise größer, dieser Effekt ist über die lange Laufzeit jedoch vernachlässigbar. Der Projektleiter bzw. Product Owner ist in dieser Betrachtung nicht enthalten, da der Fokus für die Berechnung auf den Entwicklungsaufwänden liegen soll.

Aufwandsschätzung Reifegrad 1 – Faustformel

Erfahrungen der vergangenen Jahre zeigen im Allgemeinen, dass für eine minimale Modernisierung und Cloud‑Readiness etwa 10 bis 30 Prozent der ursprünglichen Entwicklungskosten anfallen. Dieser Aufwand umfasst Änderungen an Konfigurationen, den Austausch einzelner Komponenten durch höherwertige Dienste sowie die Anpassung von Querschnittsthemen. Er gilt nicht für reine Lift‑and‑Shift‑Szenarien oder vollständige Neuimplementierungen, da jene deutlich weniger beziehungsweise diese erheblich mehr Aufwand erfordern.

Die Berechnungen setzen voraus, dass das bestehende Team die Modernisierung eigenständig durchführt – ohne externe Unterstützung und zusätzlichen Schulungsbedarf. Für das Beispielprodukt ergibt sich ein Aufwand zwischen 480 und 1440 Personentagen. Diese Spanne ist groß, insbesondere bei älteren Produkten. Je länger ein System läuft, desto größer ist der Anteil der Wartungsphase, die keine neuen Funktionen schafft und dadurch die ursprünglichen Entwicklungsaufwände verwässert. Zudem bleibt unklar, welche Softwareteile konkret angepasst oder modernisiert werden müssen. Der nächste Abschnitt zeigt, wie sich diese Werte genauer herleiten lassen, und nennt die wichtigsten Kostentreiber.

Aufwandsschätzung Reifegrad 2 – Entwickleraufwände

Mehrere Studien haben untersucht, wie sich Ressourcen im Lebenszyklus eines Softwareprojekts verteilen. Sie zeigen ähnliche Ergebnisse, setzen jedoch unterschiedliche Schwerpunkte. Ein bekanntes Beispiel ist „The Staged Model of the Software Lifecycle: A New Perspective on Software Evolution“.

Es gliedert den Lebenszyklus in folgende Phasen (siehe Abbildung unten):

• Initial Development
• Evolution
• Servicing
• Phase‑Out
• Close‑Down

Das Modell unterscheidet zwischen aktiver (Evolution) und passiver Wartung (Servicing). Aktive Wartung gilt als Entwicklungsaufwand, da sie Erweiterungen durch neue Features, regulatorische Anforderungen oder Mandantenanpassungen umfasst. Passive Wartung betrifft ausschließlich erhaltende Maßnahmen wie Bugfixes oder Bibliotheksupdates und fließt nicht in die Modernisierungskosten ein. Weitergehende Informationen zu Modellen, die unter anderem auch die mit der Zeit steigenden Wartungskosten berücksichtigen, finden sich in: How much does software development cost? In-depth guide for 2025; Lebenszyklus-Kosten von IT Produkten und IT Project Outsourcing In 2025 – A Comprehensive Guide.

Aus der Erfahrung haben sich folgende, in der Abbildung hervorgehobenen Werte bewährt:

• Initial Development ≈ 15 Prozent
• Evolution ≈ 25 Prozent

Die Phasen Phase‑Out, Close‑Down und Servicing bleiben unberücksichtigt, da sie keine relevante Entwicklungstätigkeit enthalten. Der Entwicklungsanteil der Software beträgt (inklusive etwa 5 Prozent für die zu Beginn häufig erhöhte Lernkurve und eventuell benötigte Proof-of-Concepts) somit 40 Prozent von 4800 Personentagen, also 1920 Personentage. Davon entfallen 10 bis 30 Prozent auf die Modernisierung, also 192 bis 576 Personentage. Diese Werte sind realistisch, doch bleibt die Bandbreite groß. Um sie zu verfeinern, müssen die größten Aufwandstreiber identifiziert werden.

Aufwandsschätzung Reifegrad 3 – Apokalyptische Reiter

Je gründlicher die Analyse einer Modernisierung, desto genauer wird die Schätzung. Für eine solide Näherung genügt es, die zentralen Aufwandstreiber zu erkennen und zu prüfen, ob sie im Projekt relevant sind. Einige Basisbausteine müssen bei jeder Modernisierung angepasst werden, etwa CI/CD‑Pipelines oder Logging‑Mechanismen. Solche Arbeiten lassen sich pauschal mit rund 5 Prozent der Entwicklungsaufwände veranschlagen.

Daneben existieren optionale Basisbausteine, die den Aufwand erheblich steigern können. Diese entscheidenden Faktoren werden sinnbildlich als apokalyptische Reiter bezeichnet. Jeder dieser vier Treiber kann mit etwa 5 Prozent der Entwickleraufwände bewertet werden:

Architektur der Geschäftslogik

Häufig erfolgt eine Umstellung auf Microservices oder Self‑Contained Systems. Dadurch entstehen neue System‑Schnitte, Kommunikationswege und Skalierungsmechanismen, während die Business‑Logik selbst unverändert bleibt.

Architektur des Speicherkonzepts

Ein Wechsel von relationalen Datenbanken zu Dokumenten‑ oder Graphenmodellen oder die Einführung von Event Sourcing/CQRS erfordert umfassende Anpassungen an Persistenz, Migration und Nachrichtenverarbeitung.

Mandantenkonzept

SaaS‑Lösungen verlangen Multi‑Tenant‑Fähigkeit. Altanwendungen nutzen häufig getrennte Installationen je Mandant und sind nicht auf zentrale Datenhaltung oder gemeinsame Berechtigungsmodelle ausgelegt.

Authentifizierung und Autorisierung (AuthN/AuthZ)

Viele Systeme verwenden noch eine eigene Benutzerverwaltung oder veraltete Identity‑Provider. Die Migration zu Cloud‑Providern (z. B. Azure Entra ID) sowie die Einführung verschlüsselter Kommunikation und zentraler Token‑Validierung erhöhen den Aufwand deutlich.

Selten umfasst die Modernisierung zusätzlich ein Redesign des GUI‑Konzepts oder den Wechsel zu einem neuen Frontend‑Framework. Auch dafür kann ein pauschaler Mehraufwand von 5 Prozent angesetzt werden. Darüber hinaus entstehen gelegentlich parallele Projekte für Infrastruktur und Governance (Landing Zones), um die modernisierte Lösung sicher betreiben zu können.

Im Beispielprojekt greifen drei dieser Reiter: die Umstellung auf Microservices (+ 5 %), die Einführung eines Mandantenkonzepts (+ 5 %) und die Modernisierung des Security‑Konzepts (+ 5 %). Zusammen mit der Basisanpassung ergibt sich ein Gesamtaufwand von 20 Prozent der 1920 Entwicklungs‑Personentage, also etwa 384 Personentage.

Fazit: Eine gute Schätzung ersetzt kein Konzept – aber sie zeigt, wo sich Aufwand wirklich lohnt

Die Kombination aus Entwicklungsaufwandsanalyse und Bewertung einzelner Änderungsbausteine liefert eine ausreichend präzise Schätzung. Da genaue Prozentwerte schwer festzulegen sind, empfiehlt sich eine Unterteilung in Fünf‑Prozent‑Schritte, sofern keine detaillierteren Informationen vorliegen. Eine Schätzung bleibt jedoch stets eine Annäherung.

Vor jeder Modernisierung ist deshalb ein detailliertes Konzept unverzichtbar. Es identifiziert obligatorische und optionale Änderungen, bewertet deren Aufwand und legt einen konkreten Umsetzungsplan fest. Fehlt dieses Konzept, scheitert die Modernisierung oft schon vor dem Projektstart.

(map)