Growing a Product Area at Zalando

The six month journey of the customer inbox multi-disciplinary team

The customer inbox multi-disciplinary area operates in the Fashion Store pillar of the Zalando platform organization. The purpose of the Customer Inbox Unit is to serve customers personal and practical fashion messages, through multiple channels, i.e. “Target the customers at the right time, at the right place.”

In this post, we share how the Customer Inbox area simplified and transformed from four delivery teams having a component focus and complicated structures, to a performing unit with a business focus able to grow simple structures healthily.

Complicated structures do not scale. Healthy organizations tackle the complexity of product development by growing simple practices and simple structures. Simplicity allows complex mechanisms – like face to face conversation, individual interactions, continuous improvement –  to emerge and it takes complexity to handle complexity.

Customer centric teams The multidisciplinary delivery teams had a strong technical component focus with certain benefits and also pitfalls: “It is not our component responsibility” was often given as a reply to the product managers during product feature discussions. As a result, product was writing technical requirements fitting the narrow technical teams’ purposes and a lot of time was spent on organizing dependencies.

Together with the Head of Engineering, we triggered a team workshop, where all of the four teams’ members realized the waste generated by component-focused teams, and decided to shift to business-focused teams. The realization happened using the easter egg simulation (that we tweaked a little to illustrate component vs business-focused teams).

Teams are now conducting end-to-end business initiatives, stretching across various components, and innersource (or manage themselves) the dependencies. Product managers write business initiatives with a customer focus (as opposed to tickets with narrow technical focus). The amount of overhead to manage dependencies is reduced. Customer centric structures can grow.

An exemplary situation to illustrate the behavioral changes happened shortly after the workshop. In order to differentiate between customers with and without commercial consent in the email templates, the product team asked our Smart Communication Team for a corresponding data enrichment feature. The feature turned out to require API changes in a service that is owned by the Communication Channels Team. Now the product team didn’t need to manage dependencies anymore since the Smart Communication Team innersourced the API changes.

Single source of information Each team was using their components’ github repositories as a place for long term plans. The 400 issues distributed in the 10 component backlogs were used as a baseline for planning.

Sitting down with the leadership team in an overall retrospective we analyzed the situation to understand the impact of such a structure using causal loop diagramming.

The leadership team explained to the Inbox Teams the impact of the current backlog structure. The unit cleaned up the different repositories, paid back a part of the technical debt, and moved the rest of the technical debt to a single product backlog. The team installed a zero bug policy. Any new bug generated during feature development is directly fixed without debates. Small issues (improvement ideas, to-dos) not treated in the next two iterations are systematically deleted.

Github backlogs are now used as a backlog for the next interval of work (sprint backlog) only. One single product backlog is used to store product and non-functional requirements. The number of tickets decreased to 100. This simplification of the structure allows better usage, adoption and efficiency. All technical tickets are linked to the corresponding product ticket which increases transparency both for the product and engineering side.

Shared meeting structure The causal loop diagram triggered another change. The Inbox Team had four planning sessions per cycle, with key people filling up their day with these meetings, carrying dependencies from one session to another: in short, being bottlenecks. Two of the three teams were not refining requirements at all before trying to pull them into a cycle, making planning sessions long and ineffective. Team members were participating in these planning sessions without engagement, NPS of the planning sessions was -70. Largely due to this ineffective setup, average delivery time was usually 50% longer than planned.

All Inbox Teams now run a common pre-planning (i.e. refinement) session and a common planning session where all teams refine and plan at the same place, at the same time, for the next cycle of work (two weeks). Each session is a 60 to 90 minutes time box, key resources navigate from one team to another. Teams align alone, consulting others when needed for technical support and dependency management. The team members are satisfied with the setup, NPS of the planning session is up to 30, and plans are accurate. To quote one product manager: “When it’s Friday, the sprint is over and the work is done.”

Conclusion - Handling complexity through simplification Movements like Cynefin, management 3.0 and LeSS draw the same conclusions. To grow healthy and tackle the complexity of product development at the scale of a big company, you need to un-scale and simplify your structures. From an un-growable complicated structure of 10 backlogs, 400 issues, multiple planning sessions, and component focused teams, the Customer Inbox area moved to a resilient and scalable structure with a single source of information, shared planning sessions, and customer centric feature teams. Some thoughts from the team:

Omar Elasfar (Producer) “Silos around specific components were torn down, unleashing our teams’ potential to be able to focus our customers and incrementally deliver on solutions that solve their problems.”

Sina Golesorkhi (Engineer) “We have now a team-centric mindset and people value the incremental development and collaboration more than before.”

Petra Graß (Product Lead) “Thanks to the workshop, we now think rather about the products and the impact they have than about the team structure and single features.”

These changes occurred in a period of six months driven by the area leadership team and supported by the agile coaches. It became real thanks to the people working in the Inbox Team.