How to Map Dependencies in a Roadmap
7 min read ยท 2026-10-08
To map dependencies in a roadmap, list every roadmap item, ask for each one what must be true before it can start or finish, classify each answer by type and owner, then draw it as an arrow between items on a swimlane view. Highlight the longest chain of dependent items, the critical path, and plan buffers and early starts around it.
This guide covers the types of dependencies product teams face, a step-by-step mapping process, a worked example for a quarterly product plan, and how to keep the map current once work starts, so blockers show up during planning rather than in the week before launch.
The roadmap at a glance
Goal: Produce a quarterly roadmap with all critical dependencies identified, owned and visualized. Duration: 1 to 2 weeks of mapping, maintained through a 3-month quarter
Inventory Roadmap Items (Days 1-2)
Get a clean list of every item the quarter's roadmap includes.
- Export all roadmap items at epic or milestone level into a single list.
- Write a one-line definition of done for each item.
- Tag each item with its owning team and target month.
- Remove duplicates and merge items that are really one deliverable.
Milestone: A deduplicated item list with owners, target months and definitions of done.
Discover Dependencies (Days 3-5)
Surface every internal and external dependency for each item.
- Ask each owner what they need from others before they can start or finish.
- Ask each team what others are expecting from them this quarter.
- Check for shared resources such as one designer, a platform team or a test environment.
- Capture external dependencies including vendors, legal reviews, app store approvals and partners.
- Record each dependency in a register with provider, receiver, need-by date and type.
Milestone: A dependency register where every dependency has a provider and a receiver.
Classify and Prioritize (Days 6-7)
Separate hard blockers from soft dependencies and rank by risk.
- Label each dependency as finish-to-start, start-to-start or finish-to-finish.
- Mark each as hard or soft depending on whether a workaround exists.
- Rate risk using provider reliability, novelty of the work and schedule slack.
- Flag dependencies on teams outside your planning cycle as high risk by default.
Milestone: Each dependency classified by type, hardness and risk level.
Visualize the Map (Days 8-10)
Make dependencies visible on the roadmap itself.
- Lay out the roadmap as a swimlane timeline with one lane per team.
- Draw an arrow from each provider item to each receiver item.
- Highlight the critical path in a distinct color across all lanes.
- Add buffer blocks before high-risk dependencies on the critical path.
- Resequence items where arrows point backward in time.
Milestone: A swimlane roadmap with dependency arrows, a highlighted critical path and buffers.
Confirm and Monitor (Months 1-3)
Lock commitments between teams and track dependency health all quarter.
- Get explicit agreement from each provider team on need-by dates.
- Review the dependency register in a short cross-team sync every two weeks.
- Escalate any dependency at risk at least two weeks before its need-by date.
- Update arrows and the critical path whenever scope or dates change.
Milestone: All hard dependencies confirmed by provider teams and reviewed biweekly.
Types of Roadmap Dependencies
Dependencies come in a few shapes. The most common is finish-to-start: the API must be done before the mobile screen can be built. Start-to-start means two things must begin together, such as marketing copy and design starting in parallel for a launch. Finish-to-finish means two items must complete together, such as documentation and the feature it documents.
Beyond timing, classify by source. Technical dependencies come from architecture. Resource dependencies come from shared people or environments, such as a single security reviewer. External dependencies come from vendors, regulators, partners or app store review. Knowledge dependencies come from research or decisions that must happen first. Resource and external ones are the most often missed, because they do not appear in any codebase.
- Technical: code, APIs, data models, infrastructure.
- Resource: shared people, environments, budgets.
- External: vendors, partners, legal, app stores.
- Knowledge: research results or decisions needed first.
- Hard vs soft: whether a workaround or mock can unblock work.
A Worked Example: Launching Single Sign-On
A B2B product plans to ship SSO for enterprise customers this quarter. The roadmap items are: identity provider integration (platform team), admin settings UI (web team), account linking migration (data team), security review (security team), help center docs and launch email (marketing).
Mapping reveals that the admin UI depends finish-to-start on the integration API contract, but can begin against a mock, making it soft. The migration depends hard on the integration. The security review is a shared resource with a backlog, so it is high risk. Docs and launch email are finish-to-finish with the feature. The critical path runs integration, migration, security review, launch. The team schedules the security review request in week one, adds a two-week buffer before launch, and has the web team build against a mocked contract to start early.
Running the Dependency Discovery Session
Dependencies hide in assumptions, so the discovery session should be built around direct questions. Bring one representative from each team, put the roadmap on a shared board, and go item by item. For each, ask: what do you need from anyone else, by when, and what happens if it is late? Then flip it: who is expecting something from you this quarter?
Capture every answer in a register before debating it. A simple spreadsheet works: item, provider team, receiver team, what is needed, need-by date, type, hard or soft, risk, status. The register is the source of truth; the visual map is generated from it. This keeps the drawing honest and makes biweekly reviews quick.
Tools for Visualizing Dependencies
Small teams can map dependencies on a digital whiteboard like Miro or FigJam with swimlanes and connector arrows. Larger organizations often use Jira Advanced Roadmaps, Linear project relations, Aha!, or Productboard, which can link items and show dependency lines on a timeline. Scaled agile teams sometimes run a physical program board during PI planning with red yarn between sticky notes.
Whatever the tool, keep the map readable. Show dependencies at epic or milestone level, not task level. Use one color for hard blockers and another for soft dependencies. If the picture becomes a tangle of lines, that itself is a signal: the work is too coupled and might need restructuring or team realignment.
Reducing Dependencies Instead of Just Managing Them
The best dependency is one you remove. Look at clusters of arrows and ask whether scope can be cut so a team ships without waiting, whether an API contract can be agreed early so both sides build in parallel, or whether one team can temporarily own a slice end to end.
Over several quarters, recurring dependencies point to structural problems. If every roadmap depends on the same platform team, that team needs more capacity or a self-service model. Track how many cross-team dependencies each quarter has and how many caused slips; a falling number means your team boundaries and architecture are improving.
Common mistakes to avoid
- Only mapping technical dependencies misses the riskiest blockers, so explicitly ask about shared people, vendors and approvals.
- Mapping at task level creates an unreadable web, so keep dependency arrows at epic or milestone level.
- Assuming another team agreed because they attended the meeting causes slips, so get explicit confirmation of need-by dates.
- Planning critical-path items late in the quarter leaves no recovery room, so start them first and add buffers.
- Drawing the map once and never updating it makes it misleading, so review the register every two weeks.
- Treating every dependency as hard blocks parallel work, so use mocks and early API contracts to soften them.
Frequently asked questions
What is a dependency in a product roadmap?
A dependency is a relationship where one roadmap item cannot start or finish until something else happens, such as another team delivering an API, a vendor providing access, or a legal review concluding. Dependencies define the order in which work must happen and are often the main reason roadmaps slip, especially when they cross team boundaries.
How do you show dependencies on a roadmap?
Use a swimlane timeline with one lane per team and draw arrows from each provider item to each item that depends on it. Use distinct colors for hard and soft dependencies, highlight the critical path, and place buffer blocks before risky handoffs. Keep the arrows at epic or milestone level so the view stays readable for stakeholders.
What is the critical path in a roadmap?
The critical path is the longest chain of dependent items that determines the earliest possible finish date. Any delay on the critical path delays the whole outcome, while delays elsewhere may be absorbed by slack. Identifying it tells you which items to start first, protect with buffers, and watch most closely during the quarter.
How do you manage dependencies between agile teams?
Run a joint planning session each quarter where teams state what they need from each other, record each dependency with a need-by date and owner, and confirm commitments explicitly. Review dependency status in a short cross-team sync every two weeks. Reduce dependencies over time by agreeing API contracts early, using mocks, and restructuring teams around end-to-end ownership.
What tools can track roadmap dependencies?
Jira Advanced Roadmaps, Linear, Aha!, Productboard, Asana and Monday all support linking items and displaying dependencies on timelines. Digital whiteboards like Miro and FigJam work well for initial mapping workshops. Many teams combine a spreadsheet register as the source of truth with a visual timeline for communication.