Have you encountered this situation?
You have multiple product teams working on different parts of the same product, each with their own Product Backlog and their own Product Owner. Each has gained deep knowledge of that area – they know what their user needs for that part of the product, and they take great pride in owning the tech stack for that part of the product.
However, there’s a problem – when you look at the list of Epics or Features, the different teams are working on them not in value order, but in the order of the local knowledge they have gained. The priority 2 epic is waiting for Team A to become available whilst they complete the priority 1 epic. Meanwhile, Team B are working on epic 4, because that is their area of expertise. The real world impact is our customer is waiting for their problem to be solved.
Under pressure, Team A pulls in priority 2 and now multitasking, this slows down priority 1 and causes lots of context switching. To make matters worse, the engineers on the different teams have become demotivated and stopped learning. Great people leave, and knowledge is lost.
Why is this happening?
One key reason for this is because we have locally optimised the Product creation system. Teams are experts in their small slice of the product, and the Product “Owner” of each team has their own backlog. We have inadvertently created a push system at the Product level.
We are pushing work onto teams in this scenario, and there is no single Product Vision keeper. Instead, we have team-level proxies acting as SME’s. This ties into the biggest myth of Agile product development approaches – that each team has a Product Owner – they do not. Each Product has a Product Owner.
Ideally, this Product Owner responsibility is carried out by someone with a role in the organisation known as a Product Manager. This Product Manager is not an SME in the technical side, but an empowered Product leader and visionary, obsessed about customer & business value.
The Product Owner is the hat this person wears, and this hat comes with accountabilities, including maximising overall product value.
If we want to truly scale product development, we need to think about moving to a global optimisation at the Product level – and this leads to some hard choices and realisations.
Our users and customers don’t care who works on what
That is the big gotcha – they really don’t care if Team A are experts or not. More of them that you might imagine don’t even care that an output wasn’t delivered by the end of the sprint deadline! Quite simply, customers and users about their needs being met, and their problems being solved in ways they never even imagined. From an overall business point of view, we care about business impacts being realised.
What behaviours and outcomes are we optimising for?
We need to think about what behaviours we are optimising for. Are we optimising for local expertise and tribal Product knowledge? Or are we optimising for Product-level continuous learning?
Product-level continuous learning – enter the Matrix…
Imagine this scenario in a parallel universe…
Team A is working on the priority 1 Epic around the Shopping Cart experience. Team B has just completed working on the priority 2 Epic around the Checkout experience. The P3 epic is on the enhanced Shopping Cart experience. Rather than this waiting in the backlog for Team A to become free, Team B pulls this in. They have never worked on this area of the product before. The 2 Product Owners don’t talk to each other – why? Because there is just 1 Product Owner, Jane.
She invites Team B to interviews with users of the Shopping Cart, and the team learns about their needs. Jane talks with team B around how she sees the problem and how it fits into the Product Vision. Members of Team A join the Team B backlog refinement workshop to share examples and help answer questions.
Without further ado, Team B creates some paper prototypes, tests them with the users the next day, and based off validated learning, gets to work on building the winning solution. Team B has delivered this slower than Team A would have, but they have learned about the users, and learned about a different part of the tech stack. Leadership understands they have taken an efficiency hit to increase effectiveness, and reduce key team risk. The payoff comes further down the line when Team B works on a future Shopping Cart epic.
This is a pull system within a Product, and yes – it will challenge traditional views of roles, ownership and accountabilities. This means having a single Product Backlog, and most likely a single Product Owner. Or at massive scale, maybe even a Product Owner team, collaborating together.
This is all well and good, but how do we clarify how epics get pulled from the single Product Backlog. Enter the idea of a Product Pull Policy…
What is a Product Pull Policy?
A Product Pull Policy is an idea from the world of Kanban, where teams of teams create working agreements around pulling the next highest priority item they possibly can from a single Product Backlog. This provides shared understanding around delivering the highest possible value next, just when the customer needs it, and also helps enable self-management.
At a team level, this is usually something along the lines of “pull the next highest ordered item in the Ready queue.” At a team of teams level, the principle is the very same.
A Product Pull Policy also helps empowers teams to manage dependencies and speak directly to users themselves. It also helps shift the focus from outputs to outcomes.
Ok, so how might this look?
An example might be useful around now. Here’s how the Kanban board may look with a single product backlog, a visible Ready queue with a Product Pull Policy, and multiple teams pulling from it…
Product Pull Policy:
- Pull the next highest priority epic, which meets the Definition of Ready and has been ordered by the Product Owner
- If a team cannot work on the next highest value epic, ask Why? 5 times
- If 1 person is needed from a different team, negotiate
- If a team has not worked in this product area before, trigger a knowledge sharing session with a team which can help. Invite the user researcher, tempt them with cake 🙂
- The Product Owner is optional to join the Backlog Refinement workshop if the team is familiar with the area
- Refer to the list of users who have opted into Discovery sessions
- If dependencies exist, the team triggers a session with the dependent team. If dependencies can be removed, the team is empowered to experiment. If not, agreements are put in place for team of teams sessions moving forward.
- The team pulling owns the outcome. Ensure measures of success are defined before pulling.
As a Product person, how can I get started to try this out?
Don’t try to boil the ocean with moving to a more pull-based system. Instead, think about what is the smallest experiment you can try to move towards this ambitious direction? Maybe experiment with just 2 teams working in the same area, and if you have team-level product owners, perhaps consider moving between teams based on the epic. Try it out, see how it works, and iterate.
How about you? I’d love to hear how you’ve experimented with moving towards a more pull-based system.
Have you encountered this situation? You have multiple product teams working on different parts of the same product, each with their own Product Backlog and their own Product Owner. Each has gained deep knowledge of that area - they know what their user needs for that part of the product, and they take great pride in owning the tech stack for that part of the product. However, there's a problem - when you look at the list of Epics or Features, the