Plato Elevate Winter Summit has been announced (Dec 7th-8th)


Back to resources

Building Customer Driven Backlog Across Several Component Teams


16 May, 2020

Maria Petrova

Maria Petrova

Principal Product Manager at Zalando SE

Maria Petrova, Principal Product Manager at Zalando describes how she built an organizational design from product and stack in a way that tech and product effectively function in a collaborative environment.


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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

How to Pivot a Product Idea at the Right Time

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.

Innovation / Experiment
Product Team
Embracing Failures
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

Overcoming imposter syndrome through focusing on your strengths

19 November

James Engelbert, Head of Product at BT, recalls when he had to battle imposter syndrome when managing a new team.

Product Team
Health / Stress / Burn-Out
James Engelbert

James Engelbert

Head of Product at BT

The Right Way to Ship Features in a Startup

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.

Dev Processes
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

How Data-Driven Products Help Customers and Increase Sales

11 November

Richard Maraschi, VP of Data Products & Insights at WarnerMedia, shares his insight on incorporating data science, AI, and product management to overcome slowing growth of the company.

Conflict Solving
Data Team
Richard Maraschi

Richard Maraschi

VP Data Product Management at WarnerMedia

How to Scale Product Teams for Empowerment & Impact?

5 November

Prasad Gupte, Director of Product at Babbel, shares his insights into the challenges behind successfully growing a team.

Scaling Team
Prasad Gupte

Prasad Gupte

Director of Product at Babbel

You're a great engineer.
Become a great engineering leader.

Plato ( is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.