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:
- Set up a space the way you want all new spaces to look, with your global fields, views, and settings
- When creating a new space, select that space as the source
- 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 ↗.
