Wenn der Produktmanager zu viel vorgibt – oder: Wer spielt hier eigentlich die erste Geige?
In vielen Entwicklungsprojekten kracht es früher oder später zwischen Produktmanagement und Entwicklung. Die einen sagen: „Wir müssen genau wissen, was gebaut wird!“ – die anderen kontern: „Lasst uns erstmal herausfinden, wie wir’s am besten lösen!“
Ein klassischer Zielkonflikt, der mit ein wenig Systemdenken deutlich entspannter gelöst werden kann.
Auftraggeber vs. Auftragnehmer – ein eingespieltes Duo
Stell dir das Zusammenspiel zwischen Produktmanagement und Entwicklung wie eine gute Band vor: Der Produktmanager gibt den Rhythmus und die Tonart vor – also das, was der Markt verlangt, welche Probleme gelöst werden sollen und welchen Nutzen das Produkt haben muss.
Die Entwicklung dagegen improvisiert innerhalb dieser Leitlinie und bringt ihre technische Virtuosität ein, um aus der Idee ein reales System zu machen.
In der Sprache des Systems Engineering:
Das Produktmanagement ist Auftraggeber und definiert das „Was“.
Die Entwicklung ist Auftragnehmer und legt fest, „Wie“ es umgesetzt wird.
Dieses „Was“ wird typischerweise im Lastenheft beschrieben – also den funktionalen und nutzerbezogenen Anforderungen. Die technische Umsetzung, das „Wie“, wird dann in der Entwicklung im Pflichtenheft konkretisiert.
Der Zweck ist der Star, nicht die Technik
Ein guter Produktmanager beschreibt, welchen Zweck das Produkt erfüllen und welchen Nutzen es dem Kunden bieten soll.
Der Fokus liegt auf den Funktionen – nicht auf konkreten technischen Lösungen.
Beispiel: „Das System soll Personen unterschiedlicher Größe zuverlässig erkennen“ ist eine funktionale Anforderung.
„Das System soll mit Prozessor XY arbeiten“ ist dagegen eine technische Vorgabe – und meist eine Bremse für Innovation.
Denn was heute Stand der Technik ist, kann morgen schon veraltet oder abgekündigt sein. Eine zu konkrete technische Festlegung nimmt der Entwicklung die Luft zum Atmen – und kann langfristig sogar die Produktstrategie blockieren.
Gute Vorgaben sind kontextbezogen
Was dagegen sehr wohl in die Verantwortung des Produktmanagements fällt, sind Rahmenbedingungen und Kontexte:
-
In welchen Ländern soll das Produkt verkauft werden? (Zulassungen, Normen, Regularien)
-
Wer sind die Nutzergruppen? (z. B. Bedienbarkeit für verschiedene Körpergrößen oder Einschränkungen)
-
Welche Funktionen sind für den Markt wirklich entscheidend?
Diese Informationen ermöglichen es der Entwicklung, Anforderungen sauber abzuleiten – ohne dass schon Lösungen vorweggenommen werden.
Finger weg vom „Wie“
Wenig hilfreich (und in der Praxis leider oft anzutreffen) sind technische Festlegungen wie:
-
„Das System muss Prozessor XY verwenden.“
-
„Die Software muss in Sprache Z programmiert sein.“
Solche Vorgaben engen den Lösungsraum massiv ein und verhindern, dass Entwicklungsteams alternative – vielleicht sogar kostengünstigere oder zukunftsfähigere – Ansätze prüfen können.
Ein erfahrener Systemingenieur oder Hardwareentwickler weiß sehr genau, wie die gewünschte Performance erreicht werden kann – ohne dass jemand von außen vorgibt, welcher Prozessor oder welche Sprache zum Einsatz kommen muss.
Fazit: Fokus auf das „Was“, nicht auf das „Wie“
Wenn das Produktmanagement die Funktion und den Nutzen klar beschreibt, bleibt der Entwicklung die Freiheit, kreativ und technisch exzellent zu arbeiten.
So entsteht ein gesundes Zusammenspiel:
-
Der Produktmanager sorgt dafür, dass der Markt das bekommt, was er braucht.
-
Die Entwicklung sorgt dafür, dass es technisch klug, effizient und nachhaltig umgesetzt wird.
Und genau das ist Systems Engineering in der Praxis – kein Solo, sondern ein Zusammenspiel aufeinander abgestimmter Akteure.
Oder anders gesagt:
Wer im Engineering wirklich rocken will, der kennt seinen Part – und spielt ihn so, dass das ganze Stück harmonisch klingt.
