From implementation to ownership: my growth in the OTTO PDP team

I joined OTTO as a fullstack developer on a cross-functional e-commerce team. My responsibilities were initially spread broadly across frontend, backend, infrastructure and DevOps — I was technically close to many parts of the implementation. At the same time, the environment was business-critical from the start: the product detail page in e-commerce is not simply a technical page, but one of the most important places for purchase decisions, conversion, SEO, performance and user guidance. That shifted my perspective on technical work early on.

A change to the PDP is rarely an isolated task. Depending on the initiative, product, UX, SEO, analytics, engineering, backend services and performance requirements are all affected simultaneously. On top of that come A/B testing, measurability, release planning and sign-off processes. Working on the PDP means working at the intersection of many interests. Technical decisions always carry functional, measurement-related and commercial consequences. Being able to see those connections and make them communicable is an essential part of the work.

Over time I noticed that my contribution was not limited to implementing tickets. Drawing on prior experience in conversion rate optimisation, on-page SEO and technical implementation, I could assess requirements early on: what is actually meant from a business perspective, which technical dependencies exist, which teams need to be involved, how a topic can be sensibly scoped, and which hypothesis an A/B test is actually supposed to validate. Formally I was a developer on the team. In practice, my contribution gradually shifted from pure implementation towards technical assessment, stakeholder alignment and delivery responsibility. Not because I had planned it that way, but because gaps appeared that I was able and willing to fill.

The PDP redesign was a particularly formative experience. It was not purely a technical implementation project, but iterative work with many stakeholders: clarifying requirements, making technical dependencies visible, prioritising implementation steps, assigning developers to suitable tasks, coordinating feedback and sign-offs, planning iterations and establishing readiness for go-live. I was not hired as a project lead, but in practice I took on increasing responsibility for structure, alignment and delivery of individual PDP initiatives. And I learned that the most important work often happens not in the ticket itself, but between tickets: resolving open questions, untangling dependencies, preparing decisions, surfacing risks.

One of my strongest experiences at OTTO was the quality of collaboration. In a large organisation there are many stakeholders, many dependencies and many competing interests. I saw how efficient communication can be when roles are clear and people know what they are talking about. Particularly valuable was working alongside people from product, SEO, analytics and engineering who were strong in their domain and communicated clearly. Good stakeholders do not slow things down — they actually accelerate delivery, because they can articulate requirements, make decisions and provide feedback. Complexity is not the problem. Unclear communication is the problem.

One of the most important insights from that period: people in planning, steering or management-adjacent roles do not need to write code every day. But technical understanding fundamentally changes the quality of collaboration. Those who can assess technical contexts themselves are less dependent on individual opinions, can ask better questions and communicate with engineering as peers. Especially with topics like SEO, analytics, performance and A/B testing, it is not enough to collect business wishes. You need to understand what is technically feasible and what the implications of changes are for rendering, caching, tracking or Core Web Vitals. Technical understanding is not a substitute for good leadership. But it makes leadership in technology and platform environments significantly more effective.

Ownership does not start the moment someone is officially called a lead. Ownership shows itself in taking responsibility for the outcome. For me that meant not waiting for tickets, actively resolving open questions, bringing stakeholders together, raising risks, following up on sign-offs and accompanying initiatives through to go-live. In complex environments this mindset is often more important than the formal job description. E-commerce delivery is always business delivery: a PDP influences conversion, revenue, visibility and user trust. That gives technical work a direct business context — one that you need to know and keep in mind.

My time at OTTO had a lasting influence on my professional direction. I learned that my strength lies not only in technical implementation, but in the connection between technology, business, stakeholders and delivery. At OTTO I understood that technical project leadership begins where code, requirements, dependencies and business goals meet.