FAQ: does Jira Product Discovery support Company-Managed Spaces? (CMS, aka CMP)

[#1]

If you’re asking this question, you’re probably trying to figure out whether you can roll out JPD across your organization with the right controls in place. Can you standardize fields, enforce consistent workflows, and manage governance at scale?

The answer is yes. The path just looks different from what you might be used to in Jira (ex-Jira Software).

JPD is built on team-managed spaces (formerly “team-managed projects”). This is intentional, and there are no plans to change it. Instead, we’ve built (and are continuing to build) a set of capabilities that give you centralized governance without sacrificing team autonomy. This page explains how.

Both autonomy and governance

Rolling out a product management tool at scale requires solving for two things at once:

• Team autonomy: Product teams need to move fast. They need to set up their own spaces, create views, experiment with how they organize and prioritize ideas, and adapt their process without waiting on an admin for every change. Inside the same organisation product teams might have different ways to prioritise and ship features: new product vs established product, mobile team vs AI experiences, etc. 
• Centralized governance: Product leadership, ProductOps and Admins need to ensure consistency for the product process: how teams present their roadmap so it's possible to compare bets apples-to apples, standardizing how to measure impact to the company's bottom-line, etc. Some parts of the company might adopt one way of working, while the other part uses another. This is done via fields, workflows, permissions, and the ability to manage configuration across many teams.

These aren’t in conflict. Our goal is to deliver both: give teams the speed and flexibility to do product work, while giving leadership and operations the controls they need to manage their product process at scale.

Team-managed spaces are how we deliver the first part. The features below are how we deliver the second.

What you can do today

Here's an implementation guide for the Premium plan that shows you how to put this all together.

Use permissions to limit who can do what

Within spaces, JPD has distinct roles that control what users can do:

• Space Admin: Full control. Can create fields, views, and configure the space
• Creator: Can create and edit ideas, views, and insights, but cannot create custom fields or invite other users
• Contributor: Can comment, react, and vote, but cannot create ideas or views

For governance, assign most product managers the Creator role. They can do their day-to-day work (creating ideas, building views, writing insights) without being able to create new custom fields. Only Space Admins and Site Admins can create fields, keeping your field population under control.

Use global fields for standardization 

Global fields are shared across all JPD spaces on your site. Only site admins can create them, which gives you central control over what fields exist and how they’re defined.

How to use them:

• Create your fields (e.g., business impact, effort, strategic theme) as global fields
• When creating new spaces, add these fields
• Teams can add space-level fields for their own needs, but the core set stays consistent

This covers most of what enterprises need from centralized field governance: a standard set of fields that every team uses, without blocking teams from adding their own.

Practical tips:

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

If you are already using a space Field in a space and you would like to use a 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.

Use space templates with Copy Space 

You can create a “template space” configured with your standard global fields, views, and preferred layout, then use the Copy Space feature to create new spaces from that template.

How to use it:

1. Set up a space the way you want all new spaces to look, with your global fields, views, and settings
2. When creating a new space, select that space as the source
3. The new space inherits the configuration

This lets you standardize the setup experience without requiring every team to configure from scratch. You can also restrict space creation to site admins or trusted users to enforce that all new spaces follow the template.

Practical tips:

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

Note: as of today, what this does is to provide a starting point for the space. If you then want to make changes to space-scoped entities (e.g. views) you still have to do that manually in each space. That's what we're now investing in 👇

Where we’re investing 

We’re actively working on capabilities that bring more centralized control to JPD. Here are the key areas:

• Global views (coming soon): Create views centrally and apply them across multiple spaces, so every team gets the same roadmap format, the same board layout, or the same prioritization matrix, defined once. 
• Global statuses and workflows: We're working with the Jira platform team to bring shared status definitions and workflow standardization to team-managed spaces. This will let admins define a standard set of statuses (e.g., Idea → Under Review → Committed → Done) that apply across spaces.
• Controlled autonomy for team-managed spaces: The Jira platform team is investing in giving admins more governance controls within the team-managed model, including restricting what teams can change and managing permissions more centrally (for example restricting which spaces can have space fields vs global fields). This will work across Jira including JPD
• Space governance and administration: Making it easier for admins to manage many JPD spaces at once, including applying configuration changes across spaces.

You can follow the latest on our public roadmap ↗.

[Josh]

@Tanguy Crusson it was nice getting to meet you at TEAM this year. We're very much looking forward to these enhancements:

1. Controlled autonomy for team-managed spaces
   1. If you're looking for any feedback from enterprises on this topic, I'd be happy to chat
2. Space governance and administration
3. Global statuses and workflows

[Gary Spross]

I appreciate the additional controls being introduced in JPD — assuming they aren't gated behind Premium — but I'm struggling to understand the rationale for this approach. Rather than building a parallel permission model, why not leverage the existing company-managed/team-managed architecture that already exists across Jira and JSM? This pattern isn't new — JPD's "Global fields" concept is a prime example: instead of reusing the custom fields administrators already manage in Jira and JSM, JPD introduced its own parallel construct, which means additional admin screens to learn, navigate, and maintain.

The intent seemed to be a unified "it's all Jira now" platform, but additions like the Edit Workflows and Manage Issue Layouts permissions make it feel like Jira, JSM, and JPD are architecturally diverging rather than converging. That raises a broader question: is Atlassian actively planning to align the company-managed and team-managed space configurations across products?

My concern is consistency. As administrators, each product-specific deviation adds operational overhead and makes it harder to apply standardized governance across the suite. I'd appreciate seeing a roadmap commitment to bringing these products into architectural alignment rather than continuing to layer on product-specific constructs.

[Bill Sheboy]

Hi @Tanguy Crusson 

Thanks for the guidance information in the article, including providing the context of mapping customer needs to JPD features.  Yes, and...

Please consider including in the "Where we’re investing" section any information on providing calculated JPD field values to automation rules, JQL, plans, dashboards, REST API endpoints, etc. 

While those are currently space-specific fields rather than shared / company-managed fields (correct?), multiple-teams contributing to enterprise governance would value consolidating values with built-in features.  I recall the current workaround is to "guess" how a calculated field is implemented behind the scenes, and then re-implement that calculation using additional custom fields and expensive automation rule usage.

Kind regards,
Bill