Hauptgedanke

Zwischen Product Managern mit technischem Werdegang und den anderen tut sich ein Fähigkeitsgefälle auf. Es betrifft weder das Verständnis des Marktes noch die Qualität des Urteils noch die Fähigkeit, ein Problem zu benennen — die Felder, auf denen sich der Beruf gewöhnlich entscheidet.

Es betrifft einen Zugang. Wer ein Repository lesen, Merge Requests verfolgen und eine Commit-Historie befragen kann, kann direkt an der Substanz des Produkts arbeiten: ein Artefakt daraus erzeugen, prüfen, ob ein Dokument die Wahrheit sagt, einer Behauptung widersprechen, indem er den Code zeigt. Wer es nicht kann, muss über jemand anderen gehen, und der Umweg kostet so viel, dass er in den meisten Fällen darauf verzichtet.

Das Gefälle betrifft also die Ausstattung, nicht den Wert. Die Unterscheidung ist wichtig, denn beides verlangt entgegengesetzte Gegenmittel: Einen Mangel an Begabung behebt man durch Einstellung, einen Mangel an Zugang durch Lernen oder Werkzeuge.

Ebene beigetragen von „PM, Entwickler und KI: Die Rollen verschwimmen, die Verantwortung bleibt“ (2026-08-01). Das Gefälle beim Zugang vertieft sich weiter, sobald der Product Manager selbst zu bauen beginnt. Ein Repository lesen, einen Fehler verstehen, mit einem Coding-Agenten sprechen, eine Absurdität im Generierten erkennen und das richtige technische Review anfragen — davon hängt alles ab, was über das Mockup hinausgeht: Solange die Werkzeuge fehlbar bleiben, kann man nicht ignorieren, was unter der Haube passiert. Die Grenze ist zeitgebunden, und sie kann sich umkehren — werden die Agenten deutlich verlässlicher, könnten Profile aus Psychologie, Literatur, Design oder Forschung wieder im Vorteil sein, weil sie eine menschliche und fachliche Wirklichkeit fein ausdrücken können.

Warum das wichtig ist

Das vermeidet die identitäre Lesart — „technische PMs sind besser“ —, die die Diskussion beendet, und setzt an ihre Stelle eine bearbeitbare Frage: Welchen Zugang braucht ein nicht-technischer PM, und zu welchem Preis kann er ihn erwerben?

Es sagt auch, was passiert, wenn nichts unternommen wird: Das Gefälle schließt sich nicht von selbst, weil es sich aufschaukelt. Jede direkt durchgeführte Prüfung schärft das Verständnis des Produkts, was die nächste Prüfung schneller macht.

Nuancen und Grenzen

Der Zugang ist kein Vorteil ohne Kehrseite: Der technische PM kann anfangen, die Probleme zu bearbeiten, die er mit Code lösen kann, auf Kosten derer, die den Markt betreffen.

Und die Grenze verschiebt sich. Werkzeuge, die ein Repository in natürlicher Sprache befragbar machen, senken die Kosten des Zugangs, ohne sie zu beseitigen — technische Kultur bleibt nötig, um zu wissen, was man fragen soll, und um die Antwort zu beurteilen.

Offene Fragen

• Wer entscheidet, ob ein Product Manager im Repository eingreifen darf, und mit welcher Begründung wird ihm dieses Recht verweigert, wenn es verweigert wird?