KI macht das Bauen von Software schneller. Prototypen in Stunden statt Wochen, Code-Generierung in Minuten statt Tagen. Aber die Frage, WAS gebaut werden soll, wird nicht schneller beantwortet, weil sie keine technische Frage ist. Sie ist eine Beziehungsfrage: Stakeholder-Alignment, konkurrierende Prioritäten navigieren, gemeinsames Verständnis schaffen. Teresa Torres und Petra Wille bringen es auf den Punkt: Product Work Is Relationship Work. Und Beziehungsarbeit lässt sich nicht automatisieren.

Transaktional versus relational

In vielen Organisationen funktioniert die Zusammenarbeit zwischen PM, Design und Engineering transaktional: PM schreibt Spec, Design liefert Mockup, Engineering baut. Handoff-Kultur. Das funktioniert, solange die Anforderungen klar sind und sich nicht ändern. Aber Produktentwicklung unter Unsicherheit (also der Normalfall) erfordert kontinuierlichen Dialog, gemeinsames Lernen und die Fähigkeit, Richtungswechsel als Team zu absorbieren.

Chris Argyris hat in seiner Forschung zu organisationalem Lernen zwischen Single-Loop und Double-Loop Learning unterschieden. Single-Loop korrigiert Fehler innerhalb bestehender Regeln (das Spec war falsch, wir passen es an). Double-Loop hinterfragt die Regeln selbst (bauen wir das Richtige?). Double-Loop Learning erfordert psychologische Sicherheit, Offenheit und Beziehungen, in denen Widerspruch möglich ist. Peter Senge beschreibt in "The Fifth Discipline" dieselbe Dynamik: Lernende Organisationen brauchen Dialog, nicht Diskussion. Dialog sucht Verständnis, Diskussion sucht Überzeugung.

Curiosity als Product Skill

Torres und Wille betonen eine Fähigkeit, die in PM-Stellenanzeigen selten auftaucht: Neugier. Nicht die oberflächliche Art ("Ich interessiere mich für alles"), sondern die disziplinierte Neugier, die fragt: "Was weisst du, das ich nicht weiss?" und "Was sehe ich nicht?". Das Improv-Prinzip "Yes, and" transportiert dieselbe Haltung: Statt Ideen zu bewerten, baut man auf ihnen auf. Das schafft Räume, in denen bessere Lösungen entstehen können als in einem Prozess, der auf Filtration optimiert ist.

Diese Haltung ist schwer zu automatisieren, weil sie auf Vertrauen basiert. Menschen teilen ihre besten Ideen und ihre ehrlichsten Bedenken nicht mit einer KI und nicht in einem Jira-Ticket. Sie teilen sie in Gesprächen, in denen sie sich gehört fühlen. Das ist der Kern von Beziehungsarbeit: ein Umfeld schaffen, in dem Ehrlichkeit produktiv ist.

Was sich mit KI verändert (und was nicht)

Das Bauen wird schneller. Ein PM kann einen Prototyp in Stunden erstellen, statt wochenlang auf Design-Ressourcen zu warten. Code-Generierung komprimiert die Umsetzung. Analyse-Tools beschleunigen Research. Aber das Alignment wird nicht schneller. Stakeholder haben weiterhin unterschiedliche Prioritäten. Teams brauchen weiterhin gemeinsames Verständnis, bevor sie effektiv bauen können. Und die Frage "Bauen wir das Richtige?" erfordert weiterhin Gespräche, nicht Tickets.

Die Konsequenz: PMs, die ihre Rolle als "Feature-Spezifikation" verstehen, werden tatsächlich ersetzt, weil KI Specs schneller schreiben kann. PMs, die ihre Rolle als Beziehungsarbeit verstehen (Alignment schaffen, Prioritäten navigieren, gemeinsames Lernen ermöglichen), werden wichtiger. Weil die schnellere Umsetzung mehr Entscheidungspunkte erzeugt und jeder Entscheidungspunkt Alignment erfordert.

Was ich mir vornehme

Meine PM-Arbeit war immer relationship-first: Stakeholder-Management, crossfunktionale Abstimmung, das Schaffen gemeinsamer Zielbilder. Aber ich glaube, ich habe unterschätzt, wie bewusst diese Arbeit sein muss. Seit ich KI-Tools für das Bauen nutze, fällt mir auf, dass die gesparte Bauzeit in Alignment-Arbeit fliessen sollte, nicht in noch mehr Features. Schnelleres Bauen ohne besseres Alignment erzeugt vermutlich mehr Output, aber nicht mehr Impact. Ich möchte künftig explizit Zeit in "Pre-Alignment" investieren: bevor ich einen Prototyp zeige, die Frage klären, die der Prototyp beantworten soll. Ob das in der Praxis so funktioniert, muss ich erst ausprobieren. Denn gleichzeitig gilt auch: Schnell ein Ergebnis wie einen Prototyp zu zeigen, hilft dabei, den Wert einer Idee zu diskutieren und herauszufinden, ob das Problem ausreichend verstanden ist. Daher versuche ich, das Pre-Alignment sauber zu gestalten, ohne zu viel Zeit zu verlieren.

Kritische Einordnung

Die These "Product Work Is Relationship Work" kann auch als Schutzbehauptung gelesen werden: PMs, die ihre Relevanz verteidigen, indem sie den nicht-automatisierbaren Teil betonen. Ein berechtigter Einwand. Die Forschung (Argyris, Senge, Edmondson zu psychologischer Sicherheit) stützt die These zwar unabhängig von der PM-Rolle — aber ob sich das in der eigenen Organisation umsetzen lässt, hängt stark von der Kultur ab. In Organisationen mit stark hierarchischer Handoff-Kultur könnte der Ansatz ins Leere laufen. Und nicht jeder PM muss Beziehungsarbeiter sein. In hochstrukturierten Umgebungen ist Prozesstreue möglicherweise wertvoller als Dialog. Ob der Fokus auf Beziehungsarbeit wirklich den Unterschied macht, wird sich im konkreten Kontext zeigen müssen.