Die Reibung zwischen Produktmanagern und Ingenieuren ist eines der vorhersehbarsten Probleme in Softwareteams und eines der am häufigsten falsch gehandhabten.
PMs hat das Gefühl, dass Ingenieure alles zurückdrängen, ohne Alternativen anzubieten. Ingenieure haben das Gefühl, dass sich PMs an Fristen und Umfang bindet, ohne die technische Komplexität zu verstehen. Beide Seiten haben in der Regel recht, was die blinden Flecken der anderen Seite angeht, und beide liegen in der Regel falsch, wenn es um die Absichten der anderen Seite geht.
Standard-Sprint-Retrospektiven beheben dieses Problem selten, da sie in der Regel innerhalb der Teamgrenzen bleiben. Engineers retro with engineers. PMs debrief with PMs. Die funktionsübergreifenden Spannungen häufen sich, bis sie in einer Planungsbesprechung oder einer verpassten Frist ausbrechen.
Eine spezielle Produktentwicklungs-Retrospektive bringt beide Perspektiven in einen Raum mit einer Struktur, die das Gespräch produktiv statt kämpferisch macht.
Die vier wiederkehrenden Reibungspunkte
Bevor man die Retrospektive gestaltet, hilft es, die Spannungen ehrlich zu benennen. In den meisten Teams gruppieren sie sich in vier Kategorien.
1. Anforderungen, die klar erscheinen, es aber nicht sind
Ein PM schreibt eine Spezifikation, die er für gründlich hält. Ein Ingenieur liest es und hat fünfzehn Fragen. Beim PM fühlt es sich an, als ob der Ingenieur pingelig ist. Der Ingenieur hat das Gefühl, dass der PM die Randfälle nicht durchdacht hat.
Das Grundproblem ist selten Faulheit auf beiden Seiten. PMs und Ingenieure denken anders über Produkte. PMs denkt in User Journeys und Geschäftsergebnissen. Ingenieure denken in Datenflüssen, Zustandsverwaltung und Fehlermodi. Eine Spezifikation, die aus einer Perspektive vollständig ist, ist aus der anderen Perspektive voller Lücken.
2. Geschwindigkeit vs. Qualität
PMs ist für den pünktlichen Versand verantwortlich. Ingenieure sind verantwortlich, wenn in der Produktion etwas kaputt geht. Diese Anreize wirken in entgegengesetzte Richtungen, und keiner von beiden ist falsch.
Der Konflikt zeigt sich in Debatten über die Einschränkung des Umfangs, die Testabdeckung, die Gründlichkeit der Code-Review und die Frage, ob technische Abkürzungen übernommen werden sollen. Ohne explizite Gespräche über diese Kompromisse gehen beide Seiten davon aus, dass es der anderen egal ist, worauf es ankommt.
3. Technische Schulden
Ingenieure sehen, dass sich die Schulden anhäufen, und wollen Zeit, um sie anzugehen. PMs sieht einen Rückstand bei benutzerorientierten Funktionen und hat Schwierigkeiten, Arbeiten zu rechtfertigen, die für Kunden unsichtbar sind. Das Ergebnis: Schulden werden so lange aufgeschoben, bis es zu Zwischenfällen kommt, und dann sind sich alle einig, dass sie früher hätten bearbeitet werden sollen.
4. Schätzungen und Vorhersehbarkeit
PMs muss den Stakeholdern Zeitpläne mitteilen. Ingenieure weigern sich, Schätzungen abzugeben, weil sie wissen, wie groß die Unsicherheit ist. Der PM hört „Ich möchte mich nicht festlegen“ und der Techniker hört „Sagen Sie mir einfach, was ich hören möchte.“ Keine der Interpretationen ist korrekt.
Die Retrospektive einrichten
Führen Sie dies vierteljährlich oder nach Hauptversionen aus. Monatlich ist zu häufig – die Muster brauchen Zeit, um sich zu entwickeln.
Wer nimmt teil: Produktmanager, technische Leiter und leitende Ingenieure. Beschränken Sie die Gruppe auf 6-10 Personen. Ist die Gruppe größer, wird das Gespräch performativ.
Dauer: 90 Minuten. Funktionsübergreifende Retrospektiven dauern länger als Retrospektiven im selben Team, da Sie Zeit brauchen, um ein gemeinsames Verständnis aufzubauen, und nicht nur Probleme an die Oberfläche bringen.
Moderation: Nutzen Sie einen neutralen Moderator, idealerweise jemanden, der kein PM oder kein Ingenieur im Team ist. Ein technischer Leiter, ein Scrum Master oder jemand aus einem anderen Team arbeitet gut. Die Aufgabe des Moderators besteht darin, zu verhindern, dass das Gespräch zu einer Debatte wird, und dafür zu sorgen, dass beide Seiten das Gefühl haben, gehört zu werden.
Eine Struktur, die funktioniert
Teil 1: Dual-Perspective Collection (20 Minuten)
Lassen Sie PMs und Ingenieure unabhängig voneinander Karten schreiben, die dieselben drei Fragen beantworten:
- Was hat in unserer Zusammenarbeit in diesem Quartal gut funktioniert?
- Wo hat uns die Reibung ausgebremst?
- Was wünschen Sie sich, dass die Gegenseite besser verstanden wird?
Die dritte Aufforderung ist die wichtige. Es bringt Annahmen und Frustrationen zum Vorschein, die normalerweise unausgesprochen bleiben.
Sammeln Sie alle Karten anonym. Das ist wichtig – Menschen schreiben ehrlicher, wenn ihr Name nicht erwähnt wird, insbesondere wenn es um funktionsübergreifende Spannungen geht.
Teil 2: Themendiskussion (40 Minuten)
Gruppieren Sie die Karten nach Themen. Zu den häufigsten gehören: Klarheit der Anforderungen, Schätzprozess, Priorisierungsentscheidungen, Kommunikationslücken und technischer Schuldenmanagement.
Vermeiden Sie bei jedem Thema die Versuchung, darüber zu diskutieren, wer Recht hat. Fragen Sie stattdessen:
- Wofür optimiert jede Seite? (Normalerweise haben beide Seiten legitime Ziele, die unter Spannung stehen.)
- Wo bricht die Übergabe zusammen? (Die meisten Reibungen passieren an den Grenzen zwischen den Rollen, nicht innerhalb dieser.)
- Welche Informationen fehlen beiden Seiten? (Viele Konflikte sind eigentlich verdeckte Informationsasymmetrien.)
Teil 3: Spezifische Vereinbarungen (30 Minuten)
Gehen Sie nicht mit vagen Absichten weg. Gehen Sie mit konkreten Arbeitsvereinbarungen, zu denen sich beide Seiten verpflichten.
Gute Arbeitsvereinbarungen sind:
- Observable – Sie können erkennen, ob sie passieren oder nicht.
- Bilateral – Beide Seiten verändern etwas, nicht nur, dass eine Seite Forderungen an die andere stellt.
- Time-boxed – Probieren Sie sie ein Viertel lang aus und bewerten Sie sie.
Hier sind Beispiele für Vereinbarungen, die in der Regel funktionieren:
Zur Klarheit der Anforderungen: „PMs und die technischen Leiter verbringen 30 Minuten zusammen, bevor eine Funktionsspezifikation mit dem größeren Team geteilt wird, insbesondere um Randfälle und technische Einschränkungen zu identifizieren.“
Zur Schätzung: „Ingenieure werden Bereichsschätzungen (bester Fall / wahrscheinlicher / schlechtester Fall) anstelle von Einzelpunktschätzungen bereitstellen, und PMs wird den Stakeholdern den Bereich mitteilen, anstatt nur den besten Fall.“
Für technische Schulden: „20 % der Kapazität jedes Sprints sind für ingenieurtechnisch priorisierte Arbeiten reserviert. PMs weist diese Kapazität nicht zu und Ingenieure müssen keine einzelnen Elemente begründen, aber Ingenieure teilen vierteljährlich eine Zusammenfassung darüber, wofür die Zeit aufgewendet wurde.“
Für Oszilloskopdiskussionen: „Wenn das Oszilloskop gekürzt werden muss, schlägt der PM vor, was gekürzt werden soll, und der Ingenieur schlägt vor, wie man es vereinfachen kann. Beide Optionen werden vor der Entscheidung besprochen.“
Umgang mit schwierigen Gesprächen
Einige Themen entgleisen funktionsübergreifende Retrospektiven immer wieder. Hier erfahren Sie, wie Sie damit umgehen.
„Wir haben nie Zeit für technische Schulden.“ Diskutieren Sie nicht darüber, ob technische Schulden wichtig sind. Fragen Sie stattdessen: Wie hoch sind die Kosten der aktuellen Schulden? Wenn Ingenieure auf bestimmte Vorfälle, Verlangsamungen oder Entwicklerprobleme hinweisen können, die durch Schulden verursacht werden, verlagert sich das Gespräch vom Abstrakten zum Konkreten. PMs reagiert auf Auswirkungsdaten, nicht auf abstrakte Appelle zur Codequalität.
„Anforderungen ändern sich ständig.“ Anforderungen ändern sich, weil sich der Markt verändert, Benutzerfeedback eintrifft und Stakeholder ihre Prioritäten verschieben. Die Frage ist nicht, ob sich Anforderungen ändern werden, sondern wie Änderungen kommuniziert werden und wie spät sie im Prozess eintreten. Konzentrieren Sie sich auf den Prozess: An welchem Punkt der Entwicklung sollte der Umfang als eingefroren gelten? Was ist der Eskalationspfad für Änderungen nach diesem Zeitpunkt?
„Technik unterschätzt immer.“ Drehen Sie dies um: Verfolgt das Team die Schätzgenauigkeit im Laufe der Zeit? Wenn nicht, beginnen Sie. Nach ein paar Datensprints geht das Gespräch von Vorwürfen zu Mustern über. Möglicherweise unterschätzt das Team ständig eine bestimmte Art von Arbeit (Integrationen, Migrationen) und ist bei anderen genau. Das ist umsetzbar.
„PMs versteht nicht, wie komplex das ist.“ Das trifft oft zu, und es ist auch die Aufgabe des Ingenieurs, Komplexität sichtbar zu machen. Wenn ein Techniker „Das ist schwer“ sagt und der PM „Das ist schwer“ hört, ändert sich nichts. Wenn der Ingenieur sagt: „Dies erfordert Änderungen an drei Diensten, eine Datenbankmigration und birgt das Risiko von Ausfallzeiten, wenn die Migration fehlschlägt“, kann der PM tatsächlich über den Kompromiss nachdenken.
Wie im Laufe der Zeit Gutes aussieht
Nach drei oder vier dieser Retrospektiven sollten Sie konkrete Veränderungen erkennen:
- Weniger Überraschungen bei der Sprintplanung, da PMs und technische Leiter früher aufeinander abgestimmt sind
- Ehrlichere Gespräche über Kompromisse statt passiv-aggressiver Pattsituationen
- Weniger Nacharbeit, da Anforderungen vor Beginn der Entwicklung aus beiden Perspektiven untersucht werden
- Technische Schulden werden schrittweise angegangen, anstatt aufgeschoben zu werden, bis sie eine Krise auslösen
- Schätzungen werden genauer, da das Team anhand der bisherigen Leistung kalibriert
Das Ziel besteht nicht darin, Spannungen zwischen Produkt und Technik zu beseitigen. Eine gewisse Spannung ist gesund – sie bedeutet, dass sich beide Seiten für das Wesentliche einsetzen. Das Ziel besteht darin, diese Spannung produktiv statt zersetzend zu machen.
Probieren Sie NextRetro kostenlos aus – Ermöglichen Sie funktionsübergreifende Retrospektiven mit anonymer Kartensammlung und strukturierten Diskussionsabläufen.
Letzte Aktualisierung: Februar 2026
Lesezeit: 7 Minuten
