Building Customer Driven Backlog Across Several Component Teams
16 May, 2020
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?’
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.
- 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.
Kowsheek Mahmood, Principal and CTO at ArchetypeTech, explains how he adapted an ineffective team by determining and implementing team-evaluation processes to better align the team on product delivery.
Principal & CTO at ArchetypeTech
Viacheslav Bessonov, Chief Technology Officer at Algalon Capital, outlines how he improved communication internally - with his fully distributed team, while also improving communication with the customer - located across various time zones.
Chief Technology Officer at Algalon Capital
Alessandro Pintaudi, Product Management Director at Payfit, talks about how teams need to focus more time on building the right things and how to keep doing it with scale.
Product Management Director at PayFit
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.
Principal Product Manager at Zalando
Maria Petrova, Principal Product Manager at Zalando recounts a problem that she has encountered with several different teams regarding request management and stakeholder management.
Principal Product Manager at Zalando
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.