Recently we were working on an initiative that required some cross-POD collaboration and we got to a point where my POD was blocked by a ticket in another POD’s backlog. In our next product leadership meeting, we discussed how to unblock both teams. It would turn out that we weren’t able to unblock the work, and so the focus shifted to how we could maintain the momentum while the work was blocked.

What are the priorities?

In this case, the other POD’s current priorities were more urgent and important to the overall company’s strategy, so we couldn’t ask them to drop their current task to unblock ours.

Because we can’t change their priorities, we have to focus on what we can control; our own priorities. When these conflicts in priorities and tasks come up, there’s a few questions we can ask

What is known that we can focus on right now?

Aside from our blocked work, we can consider what our next highest priority on our backlog is. In this case, we had other work that was deprioritized to make room for the blocked task. One option would be to return to the original work we had planned.

Alternatively, we could consider what else surrounding the blocked work could still be done. In this case, we had a few small tasks surrounding the blocked work that could progress without the other POD’s involvement. To figure out how to allocate resources to the tasks surrounding the blocked work, we needed to ask ourselves one more question.

What are our assumptions and how can we validate them?

In order to set ourselves up with the highest probability of success when the other POD was available to unblock us, we needed to determine which tasks surrounding the blocked work needed to be done, and in what order.

What will give us the best chance of success? As we went through the list of tasks, we knew that none of them were strictly necessary in order for the other POD to unblock us, but some were “nice to haves.” In this case, we prioritized those tasks higher than the ones that were neither necssary nor nice to have for the other POD. From the list of “nice to haves,” we were able to identify which ones would have the highest impact on the other POD’s ability to understand the implications of their work, or understand edge cases better. From there, we had a well prioritized list of tasks to do over the next 2 week sprint. We informed the other POD of what we were planning to do and explained how it would provide helpful context for their work in the next sprint.

What are the most important unknowns? For example, will a user want to do X or Y action? When we asked ourselves this question, we also uncovered a few more assumptions we could validate over the upcoming sprint.

Wrapping Up

By asking these questions, we now had 3 lists of tasks. The original work, the work surrounding the blocked tasks, and a set of new customer validation questions. We decided to prioritize the work surrounding the blocked tasks, our product manager was able to identify a few users to interview to validate our assumptions, and we decided that the original work would fill any gaps in the sprint if the work went faster than expected. This way we were able to maintain momentum, even though our work was blocked. It even set us up for stronger collaboration 2 weeks later.