Dependency Management (Product Dev)

Dependencies fall into four categories. Technical dependencies — Code or API work must complete before dependent features can be built (e.g., the data model migration must complete before the new reporting feature can be developed). Cross-team dependencies — Team A requires Team B to build or expose an API, service, or component. External dependencies — Third-party integrations, vendor API changes, or infrastructure provider actions. Sequential dependencies — Features that must ship in a specific order because Feature B improves on Feature A that customers have not yet seen. Product Ops maintains a Dependency Registry — a table tracking all active cross-team and cross-sprint dependencies, with owners, target completion dates, and escalation status — updated weekly and reviewed in sprint planning.

Dependency visualization makes the hidden visible. Dependency maps (Gantt-style or network graphs) show which features are blocked by which other features, enabling planning teams to see the critical path clearly. Most project management tools (Jira Advanced Roadmaps, Linear, Monday.com) have built-in dependency linking that shows blocked/blocking status visually. For cross-team dependencies in larger organizations, team topology tools (such as Productboard's dependency tracking or custom Miro boards) visualize the inter-team dependency graph at the portfolio level. Product Ops maintains the canonical dependency view and surfaces it in PI Planning (quarterly cross-team sync) and in the weekly leadership report.

Persistent, high-volume cross-team dependencies are a product of team topology design, not individual planning choices. The solution is team design: squads should be organized to maximize autonomy (each team can deliver its primary responsibilities without waiting for any other team). This is the core principle behind Spotify's Squad model and Conway's Law (system design mirrors team structure). Where dependencies cannot be eliminated, they should be managed through: APIs and platform contracts (Team A publishes a stable API contract that Team B can build against without real-time coordination), event-driven architectures (teams produce and consume events asynchronously, reducing synchronous coupling), and platform teams (dedicated teams own shared services so product squads don't block each other on infrastructure work).