How-to guide: set up JPD for many teams with the Premium plan

[#1]

We're posting this article in preparation for the launch of the Jira Product Discovery Premium plan, coming soon. 

---

In this first version of the Premium plan we’ve tried to cater 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 Projects 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 Projects, 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 Projects.

• How to get visibility of product work in these multiple projects 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 Project with Opportunities at the company/department level.

• Product teams work in different Discovery Projects 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 Project, 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:

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 Projects - hosting one or multiple product backlogs - and connected to one or multiple Delivery Projects.

• If your product team is small and everyone works on a common mission, it’s usually best to use a single Discovery Project for the product backlog, even if you have multiple Jira Projects for delivery. We’ve seen teams with up to 200 people collaborating in a single Discovery Project. 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 projects. 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 Projects (one for each product team), and multiple Delivery Projects (one for each squad - PM, design, engineering).

We’ll now focus on Discovery Projects (the part on the left of the diagram above).

Understand the basics

Discovery Projects

A Discovery Project is a self-contained space for working with Ideas. An Idea belongs to a single Discovery Project: you cannot have a single Idea belonging to multiple projects. In a Discovery Project you create Views to visualise Ideas based on fields and their values.

Jira Product Discovery Projects are built on top of Jira Team-Managed Projects (TMP). This architecture ensures that each Discovery Project is self-contained, allowing you to configure Types, Workflows, Fields, Views, Automation rules, Access rules, and more within each project.

Currently, JPD does not support Company-Managed Projects (CMP), but you can still standardise specific aspects of the configuration across projects using the Global Fields and Copy Project features which we’ll cover later in this guide.

Types

In Discovery Projects 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 Project has the “Idea” Type. You can create new Types to represent things like opportunities, solutions, experiments, iterations or customer problems.

Fields

In each project you can use a combination of System, Project and Global Fields.

• System fields come by default in every project and are not editable. For example delivery progress, insights or reporter.

• Project Fields are fields that are created and managed within a project, and can only be used with Ideas created in the same project.

• Global Fields are fields that are created and managed at site level by a Jira admin, and can be used across multiple projects.

More info and demos for Global Fields here. And the documentation.

Roadmaps

Roadmaps let you create views with Ideas from multiple projects (aka “cross-project views”). If you have multiple teams working in multiple Discovery Projects 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 Project Fields.

More info and demos for Roadmaps here. Example:

Hierarchies - via Connection fields [Beta]

⚠️This feature is currently in beta.

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 projects.

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 projects

Since Jira Product Discovery is built on top of Jira Team-Managed Projects (TMP) each Discovery Project is self-contained, with its own configuration for Types, Workflows, Fields, Views, Automation rules, Access rules, etc.

However you can standardize fields across projects using Global Fields, and roll out many Discovery Projects faster using the “Copy Project” feature.

“Copy Project” feature [Coming soon]

The “Copy Project” feature allows you to utilize an existing project as a template for creating a new one. This functionality replicates the configuration of the selected project, simplifying the setup process for the new project. This feature is relatively new and currently only supports copying of fields (including connections), views, types, and workflows - with more options to follow.

Here is a demo of how the “Copy Project” feature works, and the documentation.

We are currently in the final rounds of testing for this feature and it’s launching very soon.

⚠️ This feature performs a point-in-time copy of the project configuration. After creation, each project still needs to be managed independently. For instance, updating a workflow status will need to be done in each project. 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 projects:

• One for the leadership team

• One for the platform team

• And one we’ll use as the template for product teams projects

We’ll then use the Copy Project feature to create individual product team projects based on that template:

🎦 Here’s a demo for the base project 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 project: opportunities, solutions, experiments, etc.

There’s no concept of Global Type yet: you’ll need to configure each Typs individually in each project, including its workflow. You’ll be able to use the “Copy Project” feature to replicate this configuration in more projects.

Applying to this scenario

For our scenario we’ll first configure the following Types:

1. “Opportunity” in the leadership team’s project

2. “Solution” and “Experiment” in the product team’s template project

3. “Capability” in the platform team’s project

Set up fields: Project 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 Projects. Most organisations adopt a hybrid approach, utilising both Global and Project Fields.

If you use Project Fields	If you use Global Fields
✅ Each team has the autonomy to configure fields in their project to best reflect how they work.	✅ You can standardize this aspect across multiple projects. These fields can be used in cross-project 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 projects with identical Project 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 projects are Project Fields)

• And it’s also a good Idea to have Global Fields for how you rate things like impact and effort

Transition from a Project Field to a Global Field

If you are already using Project Fields in Discovery Projects 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 project from a Project Field to a Global Field.

More info and demo for Copy Values here. And the documentation.

How to make sure projects only use of Global Fields

Some companies only want to use Global Fields and centralise all configuration. To do that you can:

• Configure projects that will serve as templates (you can create multiple templates).

• Make sure you only use Global Fields in these template projects.

• Use the “Copy Project” feature to create new projects based on these templates.

⚠️ It will still be possible for Project admins to create a Project Field in each project 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 projects.

Applying to this scenario

For our scenario we’ll create the following fields - a mix of Global Fields (for common aspects) and Project Fields (for aspects specific to each project):

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 project - there’s no concept of Global Views yet. You’ll be able to use the “Copy Project” feature to replicate this configuration in more projects.

Set up Roadmaps

At this point you can use Roadmaps to create views with Ideas from multiple projects (“cross-project views”). A few things you should be aware of:

• Roadmaps only work with Global Fields - you can’t use Project Fields there.

• Permissions: you'll need to make sure everyone with access to the Roadmap also has access to the projects containing the Ideas in that Roadmap. They’ll just be able to see the Ideas from the projects 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 Project Fields, depending on your overall set up.

Even though Types are not Global, you can configure a Connection field to connect Ideas from different projects, for example connecting opportunities from project A to solutions from projects B and C. This will work as long as the Types (in this case: "Solution") have the exact same name in all projects:

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:

1. “Opportunity”, configured to point to Ideas of Type “Opportunity” in the leadership team’s project.

2. “Solutions” and “Experiments”

3. “Capabilities”

And we’ll add these Global Fields to all projects.

We’ll then configure views in each project to reflect a hierarchy.

🎦 Here’s a demo for how to set up the hierarchy in our scenario.

Copying projects with hierarchies

⚠️ In the current version of the “Copy Project” feature you’ll need to fix a couple of things manually after copying projects, if the template project 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-project views in Roadmaps, the same way you would in a view created in a project.

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.

[Mirko Grahnert]

Hey @Tanguy Crusson, thanks for putting this together, super helpful 🙌

Just a heads-up: one of the looms (Here’s a demo for how to set up the hierarchy in our scenario)seems to be restricted to workspace members only.