Last week, my team hit a roadblock that threw our carefully planned Sprint into chaos. We were working on a critical feature, and everything was on track until we realised we needed a deliverable from an external provider — a crucial API integration to connect our platform to a third-party service.
The problem? The external provider informed us — at the last minute — that their update was delayed by two weeks due to internal issues. Without their work, we couldn’t proceed. We had to leave our task halfway, reshuffle priorities, and scramble to find alternative (less important) work.
Such situations are not uncommon in Product Development.
But why do these situations arise so often, and why are they so disruptive? To understand the root of the problem, we first need to unpack what dependencies are and why they’re such a critical factor in product development.
What Are Dependencies?
Generally, dependencies are relationships between Product Backlog items (or work items), teams, or systems in which one entity relies on another to complete its work or achieve a goal.
Dependencies are a double-edged sword in product development. On the one hand, they are an inevitable part of building complex products that require collaboration across teams, systems, and sometimes, external partners. On the other hand, when not managed effectively, dependencies can quietly snowball into major bottlenecks, derailing timelines, inflating costs, and frustrating teams and leaders.
Think about it: a single missed handoff or a delayed external deliverable can create a domino effect, pushing deadlines further and forcing teams to constantly reshuffle priorities. Dependencies are often the hidden culprit behind delayed launches and unmet customer expectations, yet they rarely get the attention they deserve until it’s too late.
Understanding dependencies isn’t just about avoiding risks — it’s about improving predictability, enabling collaboration, and ultimately delivering value to customers on time. The better you identify, map, manage, or kill these connections, the stronger your product delivery becomes.
But what causes these dependencies in the first place? Let’s break down the most common root causes to understand better how they emerge.
Root Causes of Dependencies
To illustrate how these root causes play out in practice, let’s start with one of the most common challenges in product development: dependencies tied to people and skills.
Lack of Skills or Right People
People or skills-based dependencies arise when the progress of a task relies on the availability or expertise of specific individuals or teams. These dependencies can become bottlenecks if the required people are unavailable or too busy.
Let me share a recent example:
Last year, my product team worked on a new mobile app feature that involves integrating machine learning (ML) to personalise user recommendations. While the team was capable of building the front-end interface and connecting APIs, we lacked expertise in training and fine-tuning machine-learning models.
The dependency? The team relies on the company’s lone data scientist to create the ML model. However, the data scientist was already stretched thin, supporting multiple projects across the organisation.
As a result:
- The ML integration got delayed because the data scientist didn’t have enough bandwidth to prioritise the work.
The team could not fully test or deploy the feature as planned, and it delayed the public release of the product. This left the project partially completed and blocking the downstream tasks like user testing
While people and skills dependencies are common, they’re not the only ones teams face. Decision or authority-based dependencies can be just as disruptive, especially when they delay critical approvals.
Decisions Are Taken By Other People
Decision or authority-based dependencies occur when a team’s progress hinges on approvals, sign-offs, or strategic decisions from stakeholders, leadership, or regulatory bodies. These dependencies can lead to delays if decision-makers are unavailable, lack clarity, or take too long to respond.
A few years ago, I worked in a financial services company where my team was tasked with improving the website’s user experience and interface. We redesigned it to be more intuitive, visually appealing, and in line with modern design standards.
However, there was one catch: our work could only go live after it was signed off by the Release Management department. This department was responsible for reviewing and approving all changes before they went into the production environment to ensure compliance with security, regulatory, and operational standards.
The dependency lay with the Release Management department, which was overwhelmed with a backlog of requests and operated through a resource-constrained and overly bureaucratic approval process. Despite our ability to deliver enhancements to improve the customer experience on a weekly basis, those changes languished in the queue for weeks, awaiting their sign-off before seeing the light of day.
As a result:
- Slowed feedback loop, which increased rework and waste
- The delays caused misalignments with the planned marketing campaigns
Tightly Coupled Architecture
Architectural dependencies arise when the design or structure of a product or system creates constraints that limit flexibility, scalability, or the ability to make changes independently. These dependencies often occur because different components of a system are tightly coupled, meaning changes in one area directly impact others.
A few years ago, a team I worked with was tasked with improving the performance and scalability of a legacy application. The goal was to migrate the system from a monolithic architecture to a microservices-based one.
However, the monolithic nature of the existing system created significant architectural dependencies:
- Tightly Coupled Components: Any change to one module required updates to multiple other parts of the system, increasing the complexity of even minor modifications.
- Single Point of Deployment: All features had to be deployed together, meaning a delay in one area could hold back the release of unrelated functionality.
- Shared Databases: Multiple modules relied on the same database schema, making it difficult to isolate and migrate individual services without causing system-wide disruptions.
As a result:
- The migration was slower than expected, as teams had to carefully untangle dependencies between components to avoid breaking the system.
- The development of new features was delayed because resources were tied up managing these dependencies.
External Suppliers/3rd Parties
External dependencies occur when a team’s progress relies on third parties, such as vendors, service providers or open-source projects. These dependencies can introduce risks due to factors outside the team’s control, such as delays, miscommunication, or differing priorities.
In one of my previous projects, we were tasked with developing a new feature for a payment platform that allowed users to link their bank accounts directly. This required integrating with a third-party API provided by a banking services provider.
However, this external dependency introduced several challenges:
- Delayed API Updates: The provider was in the middle of updating their API, and the new version we needed was delayed by several weeks.
- Limited Support: The provider’s technical support team had limited availability, slowing down troubleshooting and integration.
- Unaligned Priorities: The provider’s roadmap didn’t prioritise our feature’s requirements, leaving us at the mercy of their timelines.
External dependencies may be the most challenging, but they’re just one piece of the puzzle. Managing all types of dependencies effectively requires a structured approach, tailored strategies, and proactive planning — topics we’ll dive into in the next part of this series.
Conclusion
Dependencies are an inevitable part of product development, but their impact doesn’t have to derail your efforts. By understanding the different types of dependencies — whether internal or external, immediate or long-term — we can begin to address their challenges systematically. Through real-world examples, we’ve seen how dependencies cause delays, increase complexity, increase waste, and disrupt even the best-laid plans. The key to managing them lies in identifying, categorising, and planning for them early. In the next part of this series, we’ll delve deeper into how to categorise dependencies effectively and why this step is critical for improving your product delivery.
Stay tuned for actionable insights to help you tackle dependencies head-on and streamline your workflows!
Learn more about managing dependencies in a Scaled environment in our Scaled Professional Scrum with Nexus (SPS) class.
