ROLLEN

Product Engineer

Ein Entwickler, dem das Ergebnis gehört, nicht das Ticket: Er spricht mit Nutzern, entscheidet, was gebaut wird, und baut es selbst. Eine Person, die die Schleife zwischen Problem und Code schließt.

Zuletzt geprüft: vonKevin Riedl wiki ↗

Ein Product Engineer ist ein Softwareentwickler, dem das Problem gehört, nicht nur die Umsetzung. Ein normaler Entwickler bekommt eine Spezifikation und baut sie gut. Ein Product Engineer fragt, ob die Spezifikation überhaupt das Richtige ist, spricht mit den Nutzern, die das Problem haben, entscheidet, was tatsächlich ausgeliefert wird, und schreibt dann den Code. Er führt den Product Manager und den Entwickler in einem Kopf zusammen. Das Ergebnis ist nicht “das Feature wie spezifiziert”, sondern “das Problem des Nutzers, gelöst”.

Die Rolle existiert, weil Produkte an der Übergabe sterben. Ein PM schreibt eine Spezifikation, ein Entwickler baut genau das, und drei Wochen später nutzt niemand das Feature, weil die Spezifikation ein Detail übersehen hat, das nur die Person am Code oder der Nutzer selbst bemerkt hätte. Ein Product Engineer fängt das mitten im Bauen ab, weil ihm beide Enden gehören. Er ist nicht per Definition erfahrener als ein normaler Entwickler. Er ist anders verdrahtet: Ihm geht es darum, dass die Kennzahl sich bewegt, nicht darum, dass das Ticket geschlossen wird.

Worked Example, warum die Verschmelzung gewinnt: Ein SaaS-Team liefert einen Onboarding-Flow exakt wie entworfen. Die Aktivierung bewegt sich nicht. Der PM gibt dem Bauen die Schuld, das Engineering der Spezifikation, und ein Monat ist weg, bevor irgendwer die eigentliche Hypothese testet. Ein Product Engineer hätte in drei Tagen eine dünnere Version ausgeliefert, fünf echten Nutzern dabei zugesehen, wie sie an Schritt zwei hängen bleiben, und Schritt zwei vor Sprintende neu gebaut. Gleiche Personalstärke, ein Zehntel der Durchlaufzeit, weil es keine Übergabe und keine Schuldzuweisungsschleife gab. Der Weg von “Nutzer hängen fest” zu “in Produktion behoben” lief in einem einzigen Kopf ab.

Das ist ein guter Teil dessen, was Wavect tatsächlich tut. Die meisten unserer Fractional-Co-Founder- und CTPO-Engagements sind Product Engineering unter anderem Namen: ein Operator, der das MVP scopt, mit euren Nutzern spricht und den Code ausliefert, statt eines PMs, eines Designers und dreier Dienstleister, die stille Post spielen. Der ehrliche Trade-off: Ein Product Engineer ist schwer zu finden und skaliert nicht linear. Man kann nicht zwanzig davon auf ein Produkt setzen, und die, die es gibt, sind teuer, weil die Kombination selten ist. Der Fehler, den Gründer machen: einen brillanten Coder ohne Interesse am Nutzer einstellen und sich dann wundern, warum die Roadmap voller eleganter Features ist, nach denen niemand gefragt hat. Die Lösung ist keine dickere PM-Schicht obendrauf, sondern ein Entwickler, der lieber mit einem Kunden spricht als eine Build-Pipeline zu tunen. Verwandt: Full-Stack Software-Entwicklung.

// FAQ

Häufige Fragen

Ein Softwareentwickler, dem das Ergebnis gehört statt des Tickets. Er spricht mit Nutzern, entscheidet, was gebaut wird, und schreibt den Code selbst, und führt damit Product Manager und Entwickler in einer Person zusammen. Er optimiert darauf, dass die Kennzahl sich bewegt, nicht darauf, dass die Spezifikation erfüllt ist.
Ein Softwareentwickler baut die Spezifikation gut. Ein Product Engineer hinterfragt, ob die Spezifikation das Richtige ist, validiert sie mit echten Nutzern und ändert sie mitten im Bauen, wenn die Evidenz das sagt. Gleiches Coding-Können, andere Verdrahtung: Der eine verantwortet die Umsetzung, der andere das Problem.
Ein Product Manager entscheidet, was gebaut wird und warum, und übergibt es dann ans Engineering. Ein Product Engineer macht beides in einem Kopf: entscheiden und bauen. In einem kleinen Team ist diese Verschmelzung schneller, weil es keine Übergabe und keinen Übersetzungsverlust gibt. Im Großen teilen sich die Rollen, weil das Entscheiden für ein großes Produkt zu einem Vollzeitjob wird.