Im Team-Kontext

"Ich arbeite in einem Team von 50 Leuten. Wie soll ich da End-to-End Ownership haben?"

Berechtigte Frage. Die radikale Vision – du allein, von Idee bis Deployment – funktioniert nicht in jeder Konstellation. Aber das bedeutet nicht, dass Product Engineer nur für Solo-Gründer gilt.

Es gibt ein Spektrum. Und auf diesem Spektrum kannst du dich bewegen – egal wo du heute stehst.

Das Spektrum

Je größer die Organisation, desto kleiner dein Ownership-Scope. Aber: desto größer auch der potenzielle Impact. Ein Product Engineer bei Stripe, der ein Payment-Feature verbessert, erreicht Millionen von Nutzern. Der Solo-Gründer erreicht vielleicht hundert.

Der entscheidende Punkt: Die Kernkompetenzen – Product Sense, Technical Depth, AI Piloting, Decision-Making – bleiben dieselben. Nur der Radius, in dem du sie anwendest, ändert sich.

Was progressive Teams anders machen

Nicht jedes Team ist gleich. Es gibt Unternehmen, die verstanden haben, dass die alte Trennung nicht mehr funktioniert. Sie bauen Strukturen, in denen Engineers mehr sein können als Ticket-Abarbeiter.

Linear hat keine Product Manager. Für 60 Mitarbeiter gibt es einen Head of Product – der Rest ist auf Engineering und Design verteilt. Entscheidungen basieren auf "Taste and Opinions", nicht auf endlosen Stakeholder-Meetings.

PostHog bringt es auf den Punkt: "When the person talking to users is the same one writing the code, less time gets spent on handoff and ambiguity." Die Person, die mit Usern spricht, schreibt auch den Code. Keine Stille Post.

Fly.io ist "ruthless about working on stuff users see and care about." Keine internen Tools-Teams, keine Infrastruktur-Projekte ohne User-Impact.

Das sind keine Ausnahmen mehr. Das ist die Richtung, in die sich die Industrie bewegt – wenn auch langsam.

Woran du es erkennst

Wenn du eine Stelle evaluierst oder dein aktuelles Team einschätzen willst, achte auf diese Signale:

Dein Weg – auch im Team

Du musst nicht kündigen und Solo-Gründer werden. Der Shift zum Product Engineer kann innerhalb deines aktuellen Teams beginnen. Aber er erfordert Initiative.

Erster Schritt: Näher an die User. Frag deinen PM, ob du beim nächsten User-Interview dabei sein kannst. Die meisten sagen ja – sie freuen sich über Interesse. Nach zwei, drei Interviews siehst du Features anders. Du verstehst das Warum hinter dem Was.

Zweiter Schritt: Hinterfrage Specs. Nicht um zu blockieren, sondern um zu verstehen. "Was ist das eigentliche Problem, das wir lösen?" Manchmal stellt sich heraus, dass die vorgeschlagene Lösung nicht die beste ist. Wenn du eine Alternative vorschlägst, zeigst du Product Sense.

Dritter Schritt: Nutze AI als Multiplikator. Auch wenn dein Team noch skeptisch ist. Wenn du mit Claude Code in zwei Tagen schaffst, was vorher eine Woche dauerte, fällt das auf. Nicht prahlen – einfach liefern.

Die unbequeme Wahrheit

Je weiter rechts du auf dem Spektrum bist – Enterprise, große Teams, viele Handoffs – desto mehr Widerstand wirst du spüren. Das liegt nicht daran, dass die Leute böse sind. Es liegt daran, dass Strukturen sich selbst erhalten.

Aber Strukturen ändern sich. Langsam, aber sie ändern sich. Und sie ändern sich durch Menschen, die zeigen, dass es anders geht. Menschen, die nicht fragen "Darf ich?", sondern einfach besser liefern und dann erklären, wie.

Der beste Weg, dein Team zu verändern, ist nicht PowerPoint. Es ist ein Feature, das Nutzer lieben, das du schneller geliefert hast als erwartet, weil du das Problem wirklich verstanden hast.