How-to guide: set up JPD for many teams with the Premium plan
In the Premium plan we’re catering for the needs of larger companies looking for a prioritisation and roadmapping solution that works across many teams.
The goal of this guide is to help you understand how to approach the implementation of Jira Product Discovery to set it up successfully across multiple teams.
We’re not going to delve into the practices side of things (how to do product management or organise product teams in a large product organisation) but discuss key considerations to set up the tool correctly from the get go.
This guide assumes you already have a good understanding of the basics of Jira Product Discovery features from the Standard plan - how to configure Discovery Spaces with custom fields, create Ideas, create and publish views, etc. If not, start with this guide first.
What to expect from this guide
After covering the basics we’ll explain:
-
How to configure multiple Discovery Spaces, and balance standardization across teams and autonomy for each team.
-
How to to create hierarchies that ladder up product work from multiple product teams working in different Discovery Spaces.
-
How to get visibility of product work in these multiple spaces in shared roadmaps.
A scenario 🎦
To show you how to use all this together we’ll use this hypothetical scenario where:
-
The leadership team works in a single Discovery Space with Opportunities at the company/department level.
-
Product teams work in different Discovery Spaces on Solutions that ladder up to company / department-level Opportunities, and make use of platform Capabilities. Solutions are broken down in Experiments.
-
The platform team works in a single Discovery Space, on Capabilities used by Solutions from product teams.
By the end of reading this, you should be able to configure something like this relatively easily:
And here's a demo for what that could look like:
A bit of context
Let’s start with a refresher on JPD: Jira Product Discovery is where you manage your product backlog, Jira is where you manage your delivery backlog. The two are connected.
See the Atlassian Discovery Handbook for more details.
You can use one or multiple Discovery Spaces - hosting one or multiple product backlogs - and connected to one or multiple Delivery Spaces.
-
If your product team is small and everyone works on a common mission, it’s usually best to use a single Discovery Space for the product backlog, even if you have multiple Jira Spaces for delivery. We’ve seen teams with up to 200 people collaborating in a single Discovery Space. This is the simplest set up.
-
For large product organisations, or one where product teams work in different products that have little functional overlap, you can set up multiple Discovery Spaces. Each one can host a separate product backlog for each product team. Setting this up needs more work upfront but is usually what larger companies choose: multiple Discovery Spaces (one for each product team), and multiple Delivery Spaces (one for each squad - PM, design, engineering).
We’ll now focus on Discovery Spaces (the part on the left of the diagram above).
Understand the basics
Discovery Spaces
A Discovery Space is a self-contained space for working with Ideas. An Idea belongs to a single Discovery Space: you cannot have a single Idea belonging to multiple Spaces. In a Discovery Space you create Views to visualise Ideas based on fields and their values.
Jira Product Discovery Spaces are built on top of Jira Team-Managed Spaces (TMP). This architecture ensures that each Discovery Space is self-contained, allowing you to configure Types, Workflows, Fields, Views, Automation rules, Access rules, and more within each Space.
Currently, JPD does not support Company-Managed Spaces (CMP), but you can still standardise specific aspects of the configuration across Spaces using the Global Fields and Copy Space features which we’ll cover later in this guide.
Types
In Discovery Spaces you can configure Types for Ideas the same way you’d do it for work items in Jira. Each Type can have its own workflow.
By default each Discovery Space has the “Idea” Type. You can create new Types to represent things like opportunities, solutions, experiments, iterations or customer problems.
Fields
In each Space you can use a combination of System, Space and Global Fields.
-
System fields come by default in every Space and are not editable. For example delivery progress, insights or reporter.
-
Space Fields are fields that are created and managed within a Space, and can only be used with Ideas created in the same Space.
-
Global Fields are fields that are created and managed at site level by a Jira admin, and can be used across multiple Spaces.
More info and demos for Global Fields here. And the documentation.
Roadmaps
Roadmaps let you create views with Ideas from multiple Spaces (aka “cross-Space views”). If you have multiple teams working in multiple Discovery Spaces and you’d like to visualize their combined Ideas in a single place, that’s what Roadmaps are for.
In Roadmaps you can only use Global Fields: they do not work with Space Fields.
More info and demos for Roadmaps here. Example:
Hierarchies - via Connection fields
You use Connection fields to create a custom product hierarchy, for example:
How it works: you use Connection fields to connect Ideas of different Types, for example connecting "Solutions" to "Opportunities".
The easiest way to think about this is: Ideas can be field values for other Ideas. For example an Opportunity called “An opportunity” can have the field value “A solution” for its field “Solutions”.
Under the hood connections between Ideas are stored as Jira issue links. It’s a flat model, where all Ideas are at the same level in a graph. Then you use Connection fields in views to visualize Ideas in a hierarchy. You can also connect Ideas from different Spaces.
More info and demos for Hierarchies here. And here's how the end result can look like:
How to use all this together
We'll now cover how you can use these different features to configure the scenario defined earlier.
Set up Spaces
Since Jira Product Discovery is built on top of Jira Team-Managed Spaces (TMP) each Discovery Space is self-contained, with its own configuration for Types, Workflows, Fields, Views, Automation rules, Access rules, etc.
However you can standardize fields across Spaces using Global Fields, and roll out many Discovery Spaces faster using the “Copy Space” feature.
“Copy Space” feature
The “Copy Space” feature allows you to utilize an existing Space as a template for creating a new one. This functionality replicates the configuration of the selected Space, simplifying the setup process for the new Space. This feature will copy fields (including connections), views, types, workflows, permissions and custom roles - with more options to follow.
Here is a demo of how the “Copy Space” feature works, and the documentation.
⚠️ This feature performs a point-in-time copy of the Space configuration. After creation, each Space still needs to be managed independently. For instance, updating a workflow status will need to be done in each Space. Using Global Fields in the template will reduce the maintenance as they are centrally managed (and need to be updated only once).
Applying to this scenario
For our scenario we’ll initially configure 3 Spaces:
-
One for the leadership team
-
One for the platform team
-
And one we’ll use as the template for product teams Spaces
We’ll then use the Copy Space feature to create individual product team Spaces based on that template:
🎦 Here’s a demo for the base Space set up (types, fields) for our scenario.
Set up Types
You can set up Types to represent the types of Ideas you want in the Space: opportunities, solutions, experiments, etc.
There’s no concept of Global Type yet: you’ll need to configure each Typs individually in each Space, including its workflow. You’ll be able to use the “Copy Space” feature to replicate this configuration in more Spaces.
Applying to this scenario
For our scenario we’ll first configure the following Types:
-
“Opportunity” in the leadership team’s Space
-
“Solution” and “Experiment” in the product team’s template Space
-
“Capability” in the platform team’s Space
Set up fields: Space Fields vs Global Fields
How you set up fields depends on how much autonomy you want to give each team, how much you want to standardise across teams, and how you want to visualise data across Discovery Spaces. Most organisations adopt a hybrid approach, utilising both Global and Space Fields.
|
If you use Space Fields |
If you use Global Fields |
|---|---|
|
✅ Each team has the autonomy to configure fields in their Space to best reflect how they work. |
✅ You can standardize this aspect across multiple Spaces. These fields can be used in cross-Space views in Roadmaps. There is only one instance of the field throughout the site. |
|
❌ These fields cannot be utilized in Roadmaps, and each field must be managed individually |
❌ This approach sacrifices some autonomy for individual teams. |
|
⚠️ Creating X Spaces with identical Space Fields will result in X separate instances of that field on your Jira site, which can lead to issues, e.g. performance, in larger Jira environments. |
⚠️ Only Jira admins can configure Global Fields |
As a starting point we recommend creating a few Global fields to set up a common vocabulary between all teams:
-
Fields for how you put Ideas in a roadmap (Now/Next/Later or Q1/Q2/Q3)
-
Fields to use in timeline views, e.g. “Project start” and “Project target” (⚠️ the ones that come by default in new Spaces are Space Fields)
-
And it’s also a good Idea to have Global Fields for how you rate things like impact and effort
Transition from a Space Field to a Global Field
If you are already using Space Fields in Discovery Spaces and you would like to use Global Fields instead: you can use the “Copy Values” feature which helps you copy field values for all Ideas in a Space from a Space Field to a Global Field.
More info and demo for Copy Values here. And the documentation.
How to make sure Spaces only use of Global Fields
Some companies only want to use Global Fields and centralise all configuration. To do that you can:
-
Configure Spaces that will serve as templates (you can create multiple templates).
-
Make sure you only use Global Fields in these template Spaces.
-
Use the “Copy Space” feature to create new Spaces based on these templates.
⚠️ It will still be possible for Space admins to create a Space Field in each Space subsequently though, you can't stop that currently. One way to achieve this is to have a central Product Operations/Admin team managing the set up of all Spaces.
Applying to this scenario
For our scenario we’ll create the following fields - a mix of Global Fields (for common aspects) and Space Fields (for aspects specific to each Space):
We’ll also need to create fields to set up a custom product hierarchy, but we’ll cover that later in this guide.
Set up Views
You’ll need to configure Views individually in each Space - there’s no concept of Global Views yet. You’ll be able to use the “Copy Space” feature to replicate this configuration in more Spaces.
Set up Roadmaps
At this point you can use Roadmaps to create views with Ideas from multiple Spaces (“cross-Space views”). A few things you should be aware of:
-
Roadmaps only work with Global Fields - you can’t use Space Fields there.
-
Permissions: you'll need to make sure everyone with access to the Roadmap also has access to the Spaces containing the Ideas in that Roadmap. They’ll just be able to see the Ideas from the Spaces they have access to.
🎦 Here’s a quick demo of the Roadmap base set-up for our scenario.
Set up product hierarchies [Beta]
You use Connection fields to configure custom product hierarchies, based on connections between Ideas of different Types.
To set this up you'll need to create one Connection field for each Type. For example if you have a Type called “Opportunity” you need to create a Connection field with the same name, configured with that Type as a source.
Here’s a demo for how to do create a Connection field, step by step.
Here are a few things you should be aware of:
-
Make sure you create one Connection field for each Type - otherwise if you connect 2 Ideas the connection will only show on one of them, not both.
-
There’s no point creating more than one Connection field for each Type - because it stores connections as Jira issue links, if you connect Ideas via one Connection field, it will also show in any other field pointing to the same Type
-
You can create connection fields as Global or Space Fields, depending on your overall set up.
Even though Types are not Global, you can configure a Connection field to connect Ideas from different Spaces, for example connecting opportunities from Space A to solutions from Spaces B and C. This will work as long as the Types (in this case: "Solution") have the exact same name in all Spaces:
Configure views
You can then set up views to show up to 3 levels of Ideas in a hierarchy, e.g. Opportunity / Solution / Experiment:
Applying to this scenario
For our scenario we’ll create a corresponding Global Field for each Type:
-
“Opportunity”, configured to point to Ideas of Type “Opportunity” in the leadership team’s Space.
-
“Solutions” and “Experiments”
-
“Capabilities”
And we’ll add these Global Fields to all Spaces.
We’ll then configure views in each Space to reflect a hierarchy.
🎦 Here’s a demo for how to set up the hierarchy in our scenario.
Copying Spaces with hierarchies
⚠️ In the current version of the “Copy Space” feature you’ll need to fix a couple of things manually after copying Spaces, if the template Space contains Connection fields:
🎦 Here’s a quick demo for how to do that in our scenario.
Set up Roadmaps with Hierarchies
Finally, you can configure hierarchies in the cross-Space views in Roadmaps, the same way you would in a view created in a Space.
Applying to this scenario
For how scenario we’ll create views focusing on Opportunities, Solutions and Experiments:
🎦 Here's a demo for how to add hierarchies in Roadmap views in our scenario.
And that's it! This should cover the basics. If you have any comments or questions, just do so in the comment section below.
Was this helpful?
Thanks!
Tanguy Crusson
About this author
Product @ Atlassian
Atlassian
Nice, France
382 accepted answers
13 comments