„Product Engineer“ klingt wie eine neue Bezeichnung für einen alten Beruf, doch der Unterschied ist real. Klassische Engineers werden an ihrem Output gemessen: geschlossenen Tickets und Funktionen nach Spezifikation. Product Engineers am Ergebnis: Haben Nutzer die Handlung tatsächlich abgeschlossen? Hat sich die Kennzahl bewegt? Hat das Unternehmen bekommen, wofür es bezahlt hat? Der Code ist derselbe; die Frage vor dem Schreiben ist eine andere.
In der Praxis gehen Product Engineers manches anders an. Sie fragen zuerst „Warum?“ und dann „Wie?“: Welches Problem lösen wir, für wen und woran erkennen wir den Erfolg? Sie hinterfragen eine Spezifikation, wenn eine einfachere Lösung denselben Nutzen in einem Drittel der Zeit liefert. Sie betrachten den gesamten Nutzerweg – einschließlich Lade-, Fehler- und Leerzuständen – und nicht nur den Happy Path im Mockup. Nach dem Release prüfen sie Analytics, Support-Tickets und Sitzungsaufzeichnungen statt nur das grüne CI-Abzeichen.
Die Rolle verlangt Breite. Man muss weder der beste Datenbankexperte noch der beste Designer sein, aber den ganzen Weg sicher beherrschen: Datenmodell, API, UI, Deployment, Analytics und inzwischen auch KI. Deshalb entwickeln sich Full-Stack-Engineers oft zu Product Engineers: Wer eine Funktion Ende zu Ende verantwortet, kann das „Warum“ niemandem weiterreichen. Bei mir geht das vom Postgres-Schema über den Next.js-Bildschirm bis zum Event, das zeigt, ob jemand die Funktion genutzt hat.
Product Engineers liefern kleine Schritte aus und lernen schnell. Die erste Version ist eine messbare Handlung im Produktivbetrieb hinter einem Feature Flag – keine Plattform, die erst in sechs Monaten startet. Sie wissen, wo Abstriche vertretbar sind (ein Admin-Panel darf hässlich sein, ein manueller Schritt einen Monat manuell bleiben) und wo nicht (Zahlungen, Berechtigungen, Datenintegrität). Dieses Urteilsvermögen macht den Großteil der Arbeit aus und entsteht nur, wenn man mit den Folgen der eigenen Entscheidungen lebt.
Zur Rolle gehört auch Kommunikation. Product Engineers sprechen mit Gründern über Risiken, Kosten und Zeit, nicht über Frameworks. Mit Designern besprechen sie, was teuer zu bauen ist, und schlagen günstigere Alternativen vor. Mit Nutzern sprechen sie, wann immer es möglich ist. Und sie halten Entscheidungen fest: Eine kurze Notiz zum Grund einer Entscheidung ist sechs Monate später oft mehr wert als der Code selbst.
Ich nenne mich Product Engineer, weil mir genau dieser Teil der Arbeit am wichtigsten ist: nicht der Pull Request, sondern der Moment, in dem ein echter Mensch unser Produkt nutzt und es funktioniert. Deshalb bevorzuge ich langfristige Zusammenarbeit gegenüber einer Übergabe nach zwei Wochen – für ein Ergebnis kann man nicht verantwortlich sein, wenn man seine Wirkung nicht mehr miterlebt. Wenn Sie einen Engineer suchen, der unbequeme Fragen stellt und danach die passende Lösung ausliefert, schreiben Sie mir.
Geben Sie dem nächsten Produkt jemanden, der bleibt.
Bereit für den Start? Schreiben Sie mir – ich kann sofort beginnen und bleiben. Langfristige Mandate statt Übergabe nach zwei Wochen. Lassen Sie uns über Ihr Projekt, die Anforderungen und den besten Weg nach vorn sprechen.