How to: manage cross-team dependencies in Jira Product Discovery (incl. Premium features)

Tanguy Crusson

This page articles explains how to manage cross-team dependencies in Jira Product Discovery (JPD) using connection fields on the Premium plan. It covers a model that we use at Atlassian to replace the chaotic "spaghetti" of ad-hoc dependency asks between teams and bring better visibility internally.

 

The problem: spaghetti dependencies

When multiple source teams need things from a shared target team (e.g. many product teams needing help from the same platform team), managing point-to-point requests breaks down quickly:

• Teams make informal asks directly to the target team, often buried in comments or side channels

• No one has clear visibility into everything the target team is being asked

• The target team gets swamped with requests and has no way to surface, prioritise, or arbitrate them

• Source teams cannot see what other teams are asking for from the same target

• There is no structured process to go from a request to a commitment. It can quickly turn into a big mess.

 

The solution: a shared "requests" idea type

This solution uses a separate JPD space to host requests to bring structure and visibility to the dependency workflow:

 

Space	Who uses it	Purpose
Source team space	Product team (making asks)	Roadmap with ideas linked to dependency requests. Shows which ideas are at risk due to unresolved asks.
Target team space	Platform team (receiving asks)	Roadmap showing committed delivery items, each linked back to the request and source solution they fulfil.
Team requests space	All teams	Central hub where all inter-team requests live. Anyone with access can make or respond to requests here.

How it works end-to-end

Request stages

Requests through a defined workflow:

1. Requested — source team submits the ask via a form in the requests space

2. Negotiating — both teams discuss scope, rationale, and priority (via comments)

3. Committed — target team accepts and links the request to a delivery item in their own space

4. In progress — target team is actively working on it

5. Done or Rejected — request is resolved

 

Connection fields

Connection fields (available on the Premium plan) help link work to requests:

• A request object in the requests space is connected to the source idea (e.g. "New Rewards App" in the product team space)

• The same request is also connected to the target idea (e.g. "New Notifications API" in the platform team space). The target idea is linked to delivery items.

• This creates a traceable chain: source idea → request → delivery item

 

Key benefits

• Full visibility: all requests are centralised in one space

• Easy arbitration: team leads can negotiate priorities in a single location rather than across multiple channels

• Traceability: each request links back to the source idea and forward to the delivery item, giving both teams a shared view of progress

• Scalable: works the same whether there are 4 requests or 60 from 60 different teams

 

Prerequisites

• JPD Premium plan (connection fields are a Premium feature). 

• Knowledge of the hierarchy/connections field feature

 

How to configure this

Here's how to reproduce this configuration:

 

Bill Sheboy

Hi @Tanguy Crusson 

Thanks for your article, and for including both the "why" and "how" for using this approach!

This appears to be a solution to a process problem...which Jira, and particularly JPD, are good at helping manage.  In my opinion, one key predecessor for this approach is alignment: all of the requesting teams and service teams need shared definitions of Classes of Service, including specifics of Impact, Severity, Priority, Cost, Value, and Capacity.  Those will align decision-making in selections, and support any pre-emption of work ordering for higher classes of request items.

Kind regards,
Bill