What is a dependency?

Dependencies have a direct impact on the progress of product development, and arise frequently in cross-functional product teams. That’s why it’s so important that dependencies are clearly mapped out and planned for, to avoid any disruptions to overall product development.

Get our Mastering Prioritization eBook

Learn how to prioritize by making it a simple process, to build products that stand out. Learn more about how to source insight, choose the right prioritization framework and much more.

Get the eBook

Examples of dependencies

To configure a dependency the type of reliance between a pair can be further defined by one of following relationship models:

Finish-to-start 

The finish-to-start dependency is the most common relationship between two tasks. The predecessor task must be finished before another task, the successor, can start.

Start-to-start 

The predecessor must have started before the dependent task can start. The finish of either task is unaffiliated.

Finish-to-finish

The successor can only finish after the predecessor has finished. The successor’s start is doesn’t rely on the predecessor and can begin before, after or at the same time.

Start-to-finish

The start-to-finish is the least common relationship between two tasks. The successor has already started and cannot finish until the predecessor has started as well. 

Dependencies can occur between teams, initiatives, or deliverables.  

One very common example of an internal dependency would be requiring another team to do something they own within their function, before developers are able to deploy a new feature. This could be needing your design team to finish creating Sketch files in order for your engineering team to implement them.

Challenges

Common challenges appear when dependencies are connected to external contributors. These so-called risky dependencies may occur e.g. when software from a third-party represents a key component to your product or a task dependency has a constraint and its completion process cannot be forecasted. Another difficulty may be to identify dependencies in the first place. It is important to stay on top of them when a project gains traction and becomes more complex. 

Advantages of mapping dependencies

Visualizing dependencies asserts the task management and timeline of any project schedule. Especially when managing a cross-functional team it is crucial to substantiate the level of awareness by including dependencies and status reports into e.g. the product’s roadmap. However, there are multiple approaches in doing so. Whether depicting dependencies in a Gantt Chart, diagram, table or with other means, it will enable the team to reevaluate commitment and to object to impractical measures if necessary.

How to manage a dependency

Dependencies aren’t inherently problematic, but they do require a focused approach to product planning to reduce the risk of any issues. 

As products grow in features and functions, they naturally grow in complexity. This increased complexity means that knowing where dependencies exist well ahead of time is critical to successful product development — regardless of whether a development team works in a startup environment or inside an established organization.

Effective roadmapping is one of the most effective ways to reduce any potential risks of dependencies. 

For example: say your design team has an unexpected delay and they need a few more days to complete some mockups. Development, QA, marketing, and sales will need to know about it well ahead of time to minimize disruption. This can be effectively handled with a dedicated product management tool — this will enable you to communicate the progress of all dependencies across key stakeholder, in real-time.

Product Dependency Mapping

What is product dependency mapping?

While dependencies in project management usually refer to project tasks, product dependencies and product dependency mapping relates to anything that a product or any part of a product relies on.

Product dependency mapping typically includes identifying product dependencies and documenting critical information such as who controls the dependency, the likelihood of disruption to the dependency, the impact of any disruption, and alternatives should the dependency become unavailable.

Mapping these dependencies helps product managers identify and mitigate risks by defining priority dependencies, putting backup solutions in place, and opening lines of communication with owners of dependencies.

Various aspects of product dependency mapping can be automated to identify third-party components, plug-ins, and hardware that are dependencies. These are often called application dependencies, and existing application dependency mapping tools are available. Other types of dependency, such as critical team members or data, need a more manual approach.

What are products dependent on?

Products can depend on various things, some of which are in your control and others that are not. Common among these are:

• Shared software libraries or components that are integrated into your product

• Special hardware needed to run your product

• Staff with specialist knowledge that you can’t do without

• Third-party data feeds or databases that your product uses

• Third-party software such as add-ins or plug-ins that your product incorporates

Depending on your product and organization, there may be others. When performing product dependency mapping, it is important to review all the possible dependency types.

An example of product dependency mapping

If a module of your product requires access to a third-party data feed to function, it is dependent on that third party continuing to provide the feed through the same channel and in the same format. Having identified this dependency during their product dependency mapping process, a product manager would realize that this poses a risk.

The project manager has multiple options to mitigate this risk. They could reach out to the third party and get assurance that the feed will continue, or if there will be changes, agree that they will notify the project manager well in advance.

Alternatively, they could seek a way for the product to function without the need for the third-party data feed, perhaps by developing an in-house solution.

At the very least, they could identify potential backup solutions so that if there is a disruption to the third-party data feed, they have another data source to fall back on.

Top tips for product dependency mapping

1.       When performing product dependency mapping, consider distinct types of dependency independently to ensure you don’t miss any. Feel free to start with our list, and add any other types that apply to your product:

• Hardware

•  Common software libraries

• Third-party software (i.e., plug-ins, apps, etc.)

• Staff

• Data sources

 2.       Include everyone in the product dependency mapping process. Software dependencies are often well hidden and hard to identify without a deep knowledge of how the product works. Engaging the whole team means you are more likely to find these deep dependencies.

 3.       Don’t stop at mapping the dependencies. The value of product dependency mapping is helping teams avoid problems before they arise and identifying the cause of unexpected issues more quickly. Take the time to understand and record who controls dependencies, how your product interacts with dependencies, whether the dependency is necessary, and what impact a disruption to a dependency will have.

Get our How To Succeed as a Modern Product Manager eBook

A comprehensive look into all the core topics of the product manager role: what they do, what their characteristics are, how their day looks like, how to prepare for an interview in product management and so, so much more.

Get the eBook