How to deal with dependencies

“We cannot reach our sprint goal because Team Blue didn’t solve the dependency. We’re blocked.”

How Product Managers Can Effectively Deal With Dependencies

When I heard that from our most experienced software engineer, I got annoyed because it put me in a powerless situation. It’s like we accept the case but decide not to act. That’s not me, so I decided to talk to Team Blue.

The product manager from Team Blue explained that they couldn’t deal with the dependency because Team Yellow had another dependency that blocked them. And there I was again, in the same situation with a different team.

Guess what happened when I talked to Team Yellow? They also had a blocking dependency, but at this time, with Team Green, and I was the product manager at this time. Curiously, I was unaware of such dependency.

How did we end up in such a nonsense situation?

I will walk you through it during this post, hoping you’ll understand and learn how to deal with dependencies effectively.

What’s a dependency?

Maybe you clearly understand dependencies, but I know that I stumbled upon some misunderstandings. That’s why I will briefly describe my understanding and ensure we’re talking about the same thing.

Suppose you work for a marketplace and are responsible for the search experience. You realized that you could optimize the search results by taking related product information. Yet, such information isn’t available. Another team takes care of product information management. That means to get your idea done, you’re dependent on the other team.

The above example is a product dependency, which happens when one team cannot finish something because of another team. You can face other types of dependencies, such as business and external.

Dependencies can be treated as blockers, but not all are the same. Sometimes you can identify alternatives and escape from the dependency.

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

How to manage dependencies

If you fail to deal with dependencies effectively, you end up in horrible situations.

Coming back to my initial example about teams Blue, Yellow, and Green. What happened?

We worked with Jira, and whenever we had a dependency, we’d create a product backlog item on the response team’s product backlog. Then, we’d put our item as “blocked” due to the dependency. Of course, someone would drop a comment hoping it was enough.

In summary, we managed dependencies electronically and barely had conversations to solve them as a team.

Learning: Talk to teams instead of just creating tickets and expecting them to tackle them promptly.

The team’s setup plays a critical role in product dependencies. Let me clarify that:

Component teams: when the responsibilities lie on the component level, teams will inevitably have to deal with several dependencies. This is a suboptimal way of working
Cross-functional: teams with all the required skills to get the job done reduce dependencies. For example, some teams don’t have a dedicated designer because a separate team takes care of that. This approach forces dependencies and will create hassles. The more independent teams are, the more functional they become

Understanding your scenario and striving to reduce dependencies to a bare minimum is essential. Doing that quickly pays off because dependencies slow progress down.

Use technology in your favor

No matter the scenario, don’t let your team fall victim to the circumstances. You can always act and reduce dependencies. Here’s how:

Events: benefit from an event-driven architecture. Ensure that events are published so interested teams can consume information whenever needed
Mocked APIs: in some situations, you’ll need to interact with others’ domains, and you won’t have an API for that. Instead of creating a ticket and blocking progress, sit down with the team, agree on the API format, mock it, and conclude the application. It will still not be production ready, but you don’t get blocked
Data exposure: it’s fundamental to have a strategy for how teams make their data available to others. Each team has a domain responsibility and eventually interacts with each other. Searching for a solution when you have a dependency is counter-productive. Having a strategy and knowing how to exchange data between teams is best. For example, the domain team that is responsible for offering APIs could be a strategy

Map dependencies early

Whether you like it or not, dependencies will exist, and you cannot ignore them. You can say you’re a product manager, not a project manager. I’d say you’re right, but choosing to ignore dependencies is the same as choosing to fail.

You don’t need to create a gigantic flow with all dependencies, timelines, etc. This will be a waste. We know we suck at estimates.

You can map dependencies, define the responsibility for solving them, — name the person, not the team — and define the type. Not all dependencies are the same. Some will block you, and for some, you have alternatives. Deal first with blockers and then with the others.

I could recommend you use Jira Project Plan or other tools to map dependencies. They would visually show a gigantic map full of connections, but I won’t. The reason is simple — a massive flow of dependencies will frighten people. My recommendation is to keep it simple and focus on collaboration.

My approach is the following:

Name dependencies
Define business criticality and how it blocks progress
Use a 2×2 matrix to visualize your dependencies
Prioritize the ones that block progress and are business-critical for now
Drop the ones that are business irrelevant, and you’d have an alternative
Define responsible and actions
Rinse and repeat

Map Dependencies Early Graph

Dependency map

You can ignore my tip and use a dependency map if that suits you best. Jira offers dependency maps out of the box. I don’t like them because people prioritize processes and tools over collaboration when they see a map like the following:

Key takeaways for dealing with dependencies

Dependencies are part of any product. You must understand them and define actions. Ignoring them is a wrong choice for everyone.

The key takeaways of dealing with dependencies are:

Define a strategy to deal with technical dependencies — ensure your team knows how to reduce the impacts of dependency and continuously improve this strategy
Never fall victim — instead of saying we cannot progress because of a dependency, ask what we can do now. Search for alternatives
Not all dependencies are the same — some dependencies have alternatives, and you could benefit from them. Others, you must deal with. Don’t panic about dependencies. Mindfully deal with them
Collaboration beats tools — overcoming dependencies is a teamwork exercise. Tools can help you visualize them and understand your current status but remember that the goal is to solve dependencies. Collaboration is your best tool for that
Design to reduce dependencies — set teams as independent as possible. Also, strive to have a set of strategies in place that enable teams to know how to act when facing dependencies quickly

Additional point. Eventually, you will stumble upon a business-critical external dependency that will block progress if not solved. This is a dangerous type of dependency because it doesn’t depend on you. Ensure such dependencies are solved before investing significant time in a product or project. Otherwise, you’re betting on luck.

“It’s okay to admit what you don’t know. It’s okay to ask for help. And it’s more than okay to listen to the people you lead — in fact, it’s essential.” — Mary Barra, CEO of General Motors

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.