Von Umsetzung zu Ownership: meine Entwicklung im OTTO-PDP-Team

Ich kam zu OTTO als Fullstack-Entwickler in ein cross-funktionales E-Commerce-Team. Meine Aufgaben lagen zunächst breit verteilt zwischen Frontend, Backend, Infrastruktur und DevOps. Ich war technisch nah an vielen Teilen der Umsetzung. Gleichzeitig war das Umfeld von Anfang an stark business-relevant: Die Produktdetailseite ist im E-Commerce nicht einfach eine technische Seite, sondern einer der wichtigsten Orte für Kaufentscheidung, Conversion, SEO, Performance und Nutzerführung.

Eine Änderung an der PDP ist selten eine isolierte Aufgabe. Je nach Vorhaben sind Product, UX, SEO, Analytics, Engineering, Backend-Services und Performance-Anforderungen gleichzeitig betroffen. Hinzu kommen A/B-Testing, Messbarkeit, Release-Planung und Abnahmeprozesse. Wer an der PDP arbeitet, arbeitet im Schnittpunkt vieler Interessen. Technische Entscheidungen haben immer auch fachliche, messbezogene und kaufmännische Konsequenzen. Diese Verbindungen zu sehen und kommunizierbar zu machen ist ein wesentlicher Teil der Arbeit.

Mit der Zeit habe ich gemerkt, dass mein Beitrag nicht nur darin lag, Tickets umzusetzen. Durch meine Vorerfahrung in Conversion-Rate-Optimierung, Onpage-SEO, Page Performance Optimierung und technischer Umsetzung konnte ich Anforderungen früh einordnen: Was ist fachlich gemeint? Welche technischen Abhängigkeiten gibt es? Welche Teams müssen eingebunden werden? Wie lässt sich ein Thema sinnvoll schneiden? Welche Hypothese soll ein A/B-Test eigentlich prüfen? Formal war ich als Entwickler im Team. Praktisch verschob sich mein Beitrag zunehmend von reiner Umsetzung hin zu technischer Einordnung, Stakeholder-Abstimmung und Delivery-Verantwortung. Nicht weil ich das so geplant hatte, sondern weil Lücken entstanden, die ich füllen konnte und wollte.

Besonders prägend war das PDP-Redesign. Dort ging es nicht nur um technische Umsetzung, sondern um iteratives Arbeiten mit vielen Beteiligten: Anforderungen klären, technische Abhängigkeiten sichtbar machen, Umsetzungsschritte priorisieren, Entwickler auf passende Aufgaben setzen, Feedback und Abnahmen koordinieren, Iterationen planen und Go-Live-Fähigkeit herstellen. Ich war formal nicht als Projektleiter eingestellt, habe aber in der Praxis zunehmend Verantwortung für Struktur, Abstimmung und Delivery einzelner PDP-Initiativen übernommen. Und ich habe dabei gelernt: Die wichtigste Arbeit passiert oft nicht im Ticket selbst, sondern zwischen den Tickets: offene Fragen klären, Abhängigkeiten lösen, Entscheidungen vorbereiten, Risiken sichtbar machen.

Eine meiner stärksten Erfahrungen bei OTTO war die Qualität der Zusammenarbeit. In einem grossen Konzern gibt es viele Stakeholder, viele Abhängigkeiten und viele Interessen. Ich habe erlebt, wie effizient Kommunikation sein kann, wenn Rollen klar sind und Menschen wissen, wovon sie sprechen. Besonders wertvoll war die Zusammenarbeit mit Personen aus Product, SEO, Analytics und Engineering, die fachlich stark waren und klar kommuniziert haben. Gute Stakeholder bremsen nicht, sie beschleunigen, weil sie Anforderungen klar formulieren, Entscheidungen treffen und Feedback geben können. Komplexität ist nicht das Problem. Unklare Kommunikation und Halbwissen ist das Problem.

Eine der wichtigsten Erkenntnisse aus dieser Zeit: Personen in planenden, steuernden oder managementnahen Rollen müssen nicht täglich entwickeln. Aber technisches Verständnis verändert die Qualität der Zusammenarbeit grundlegend. Wer technische Zusammenhänge selbst einordnen kann, ist weniger abhängig von Einzelmeinungen, kann bessere Fragen stellen und kommuniziert mit Engineering auf Augenhöhe. Gerade bei Themen wie SEO, Analytics, Performance und A/B-Testing reicht es nicht, fachliche Wünsche zu äußern. Man muss verstehen, was technisch machbar ist und welche Auswirkungen Änderungen auf Rendering, Caching, Tracking oder Core Web Vitals haben. Technisches Verständnis ist kein Ersatz für gute Führung. Aber es macht Führung in IT- und Plattformumfeldern deutlich effizienter.

Ownership entsteht nicht erst dann, wenn jemand offiziell Lead genannt wird. Ownership zeigt sich darin, dass jemand Verantwortung für das Ergebnis übernimmt. Für mich bedeutete das, nicht nur auf Tickets zu warten, offene Punkte aktiv zu klären, Stakeholder zusammenzubringen, Risiken anzusprechen, Abnahmen nachzuhalten und Vorhaben bis zum Go-Live zu begleiten. Gerade in komplexen Umfeldern ist diese Haltung oft wichtiger als die formale Rollenbeschreibung. E-Commerce-Delivery ist immer auch Business-Delivery: Eine PDP beeinflusst Conversion, Umsatz, Sichtbarkeit und Nutzervertrauen. Dadurch bekommt technische Arbeit einen unmittelbaren Business-Kontext.

Meine Zeit bei OTTO hat meine berufliche Richtung nachhaltig geprägt. Ich habe dort gelernt, dass meine Stärke nicht nur in der technischen Umsetzung liegt, sondern in der Verbindung von Technik, Business, Stakeholdern und Delivery. Bei OTTO habe ich verstanden, dass technische Projektführung dort beginnt, wo Code, Anforderungen, Abhängigkeiten und Business-Ziele zusammenkommen.