We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Building Customer Driven Backlog Across Several Component Teams

Product
Users Feedback
Reorganization

16 May, 2020

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.

Problem

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.

Related stories

Launching a Product in a Large Organization
14 September

Shikhar Bajaj, Senior Product Manager at VMware, highlights the key differences between a product launch in a large organization and a small one.

Product
Cross-functional collaboration
Shikhar Bajaj

Shikhar Bajaj

Sr. Product Manager at VMware

Successful Launching of a Brand New Product
14 September

Shikhar Bajaj, Senior Product Manager at VMware, describes how he successfully launched a new product using the competitive advantages his company had over its competition.

Product
Shikhar Bajaj

Shikhar Bajaj

Sr. Product Manager at VMware

Developing a Product Mentality in Engineering-Centric Organizations
14 September

Shikhar Bajaj, Senior Product Manager at VMware, discusses how he developed a product mentality in his engineering-centric organization by introducing a formal stage-gate process that included the business review.

Team processes
Product
Shikhar Bajaj

Shikhar Bajaj

Sr. Product Manager at VMware

Merging a Web and Mobile Team: A Tale of Two Cultures
14 September

David La France, VP of Engineering at Kenna Security, explains how to merge two teams with different cultures, technology and operating modes.

Cross-functional collaboration
Company Culture
Internal Communication
Collaboration
Reorganization
David La France

David La France

VP Engineering at Synack

Being the Right Fit in Face of the Reorganization
28 August

Brad Henrickson, CTO at Scoop, discusses how to assess if someone is still the right fit for the organization, especially during the organizational restructuring.

Career Path
Reorganization
Brad Henrickson

Brad Henrickson

CTO at Scoop

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

Plato (platohq.com) 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.