Building Customer Driven Backlog Across Several Component Teams

Maria Petrova

Principal Product Manager at Zalando SE



In some parts of software development, it’s really hard to enforce a product team to operate in a full-stack way. When you have one team of developers dedicated to end to end user cases and workflow, they can just ship features and develop products in a way that drives certain product goals.

However, as you move to work in bigger companies, the engineering teams might be organized based on components or microservices they develop. In that case each team is focused on the development of some back or front end components, which might be used by various products. For example, once I have been working with the development team responsible for recommendation and personalization engine which enabled content delivery for the e-commerce platform It consisted of the multiple components and was used in a variety of different applications and interfaces run by that platform. So it did not provide the best opportunity to build the smooth feedback flow between the development team and the user because customers did not interact with this product directly in one specific way.

The question then becomes, ‘How can we manage the backlog of the team using a customer-driven, problem-solving approach in the situation when user feedback is indirect?’

Actions taken

The first thing we did was try to hire product managers and make them work with the team responsible for the single component. After working in this setup for a quarter, we decided to restructure the whole thing a bit and make PMs responsible for value streams across different areas such as content targeting, budget allocation, personalized pages composition, etc…

Tech leads were now responsible for components, including things like their reliability and operational excellence. We essentially had two backlogs.

  1. Technical backlog → to make the component reliable and stable
  2. Product backlog → formed according to certain use cases and value adds

A product manager then worked across different teams and their tech leads made sure that all the changes to the necessary components were made so that the whole user experience could be delivered. Similarly, tech leads work with their backlogs to get requirements from different PMs into one singular backlog.

Lessons learned

  • Having five project managers working together to solve one use case is not the most efficient way to do it. This didn’t work well for us because when trying to support so many use cases and product features, it is really hard for a product manager to figure out a strategy to develop the whole thing. A reason for this is that they don’t own any user case end to end.
  • Our idea was to restructure things without completely blowing the whole engineering setup. It was really hard to enforce these product teams in a way where you have a complete team of leads, developers, and PMs. Deciding to divide workstreams was the best option. When it's crucial and important that components perform in a very productive way, you can use these product teams. The solution can be that product managers are responsible for certain product workstreams and then you have components with tech leads responsible for their performance.
  • We originally had a bit of kickback from both teams, but after a few iterations we figured out that this would be the best setup. At the end of the day, all the tasks that the development team received were dedicated to certain goals around the business and user behavior. Before that, since it was just a single component that didn’t deliver end to end on the use case, the problem was that developers weren’t sure if they should be changing anything or were just shipping code for some unclear reason.
  • The only issue with this kind of setup is that it requires a lot of buy-in from teams in terms of communication and alignment. What you get as a benefit, on the other hand, is that everyone understands what the user needs and values and how the product they build will change his or her life.

Be notified about next articles from Maria Petrova

Maria Petrova

Principal Product Manager at Zalando SE

Leadership & StrategyEngineering LeadershipLeadership DevelopmentCommunicationOrganizational StrategyDecision MakingCulture DevelopmentEngineering ManagementTeam & Project Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up