Auf Visitenkarten klingt „Product Engineer“ nach einem Full-Stack-Entwickler mit besserem Marketing. In der Praxis ist der Unterschied größer – und unangenehmer. Es geht nicht darum, mehr zu können. Es geht darum, Verantwortung für das Ergebnis zu übernehmen, nicht nur für den Code.
Der Unterschied liegt nicht im Stack
Ein Entwickler bekommt ein Ticket: „Baue einen Filter für die Projektliste.“ Ein Product Engineer fragt: „Welche Entscheidung soll die Person nach dem Filtern treffen?“ Vielleicht braucht sie gar keinen Filter, sondern eine bessere Sortierung. Vielleicht ist die Liste zu lang, weil die Inhalte nicht kuratiert sind. Vielleicht ist das eigentliche Problem, dass niemand weiß, welche Projekte relevant sind.
Das ist keine Arroganz gegenüber dem Ticket. Es ist die Frage, ob das Ticket das richtige Problem beschreibt. Manchmal lautet die Antwort ja. Dann wird der Filter gebaut – schnell und gut. Manchmal lautet sie nein. Dann ist die wichtigste Arbeit, das zu sagen.
Drei Fragen, die alles verändern
Bevor ich eine technische Entscheidung treffe, stelle ich drei Fragen:
- Warum jetzt? Was passiert, wenn wir es nicht bauen? Welche Entscheidung oder welcher Ablauf hängt davon ab?
- Für wen? Wer nutzt das Ergebnis, in welcher Situation, mit welchem Vorwissen?
- Was ist der kleinste nützliche Schritt? Welche Version löst das Problem, ohne die nächsten drei Probleme mitzubauen?
Diese Fragen verlangsamen den Start um zehn Minuten und sparen oft Wochen. Sie sind auch der Grund, warum Product Engineering ohne Kommunikation nicht funktioniert. Wer nur den Code sieht, kann diese Fragen nicht beantworten.
Ein Beispiel: die Funktion, die wir nicht gebaut haben
Ein Kunde wünschte sich eine „automatische Erinnerung“ für offene Aufgaben. Die Anforderung war klar, das Ticket war klein. Im Gespräch stellte sich heraus, dass die Erinnerungen nicht fehlten – die Aufgaben waren einfach nicht eindeutig zugewiesen. Jeden Morgen suchte das Team von Hand, wer was übernehmen sollte.
Wir haben keine Benachrichtigungslogik gebaut. Wir haben die Aufgabenliste um eine klare Zuständigkeit und eine tägliche Kurzansicht ergänzt. Die Zahl der offenen Aufgaben sank, weil die Übergabe sichtbar wurde. Die ursprünglich gewünschte Funktion wäre technisch einfach gewesen – und hätte das eigentliche Problem nur lauter gemacht.
Das ist keine Heldengeschichte. Es ist die normale Arbeit, wenn man den Kontext ernst nimmt.
Entscheidungen sichtbar machen
Product Engineering heißt auch, Entscheidungen nachvollziehbar zu machen. Ein kurzes Entscheidungslog reicht:
## Entscheidung: Aufgabenliste statt Erinnerungen
- Kontext: Offene Aufgaben ohne klare Zuständigkeit
- Optionen: automatische Erinnerungen, tägliche Kurzansicht, beides
- Entscheidung: Kurzansicht mit Zuständigkeit
- Grund: Das Problem war Sichtbarkeit, nicht Aufmerksamkeit
- Überprüfung: nach zwei WochenDas Log ist keine Bürokratie. Es schützt vor dem stillen Wiederaufleben von verworfenen Ideen und macht es neuen Teammitgliedern leichter, die Gründe zu verstehen. Gute Entscheidungen sind selten selbsterklärend.
Was Product Engineering nicht ist
Es ist nicht „Designer und Entwickler in einer Person“. Gute Produkte entstehen selten allein. Es ist auch nicht „Product Manager mit Programmierkenntnissen“. Die Rolle ersetzt keine Produktstrategie und keine Designentscheidung.
Was sie ausmacht, ist die Verbindung: technische Tiefe, Verständnis für den Nutzungskontext und die Bereitschaft, beides in Entscheidungen zu übersetzen. Manchmal bedeutet das, einen Prototyp zu bauen, um eine Annahme zu testen. Manchmal bedeutet es, eine Funktion nicht zu bauen. Und manchmal bedeutet es, den Code zu schreiben, der genau das tut, was vereinbart wurde – ohne Drama.
Fazit
Product Engineering ist keine Stellenbezeichnung, die man sich gibt. Es ist die Entscheidung, nicht nur Code abzuliefern, sondern Verantwortung für das Ergebnis zu übernehmen. Der Stack ist dabei das kleinste Problem.