Pros/cons of using one vs multiple JPD products

[David Nadri]

Regarding the FAQ below: Could you please provide more details about the various 'factors' involved in deciding between using one JPD project shared across all products or having multiple JPD projects (one project per product)?

We're assessing the pros & cons of each approach and would appreciate more info, such as a comparison table to help teams like us decide which approach to take.

While we've already seen the demo of using a single project for multiple products and teams, we'd greatly appreciate more info or a demo video using multiple projects (one per product), especially when ideas/features span across different projects (products), such as when a feature idea for one product has dependencies on another.

For example, while Product A & Product B are two totally separate products with their own deliverables, sometimes a feature idea for Product A has dependencies on Product B, and there's a need for visibility of that relationship from within both the JPD project for Product A & the JPD project for Product B.

We have multiple products and teams. Should we use one project or multiple? 

This depends on many factors. Jira Product Discovery was designed to work best when used by individual teams using the Spotify squad model. But it's possible to use a single project to share between teams/products, especially when there's a high level of collaboration required between these teams. 

[Stephen_Lugton]

The way that we cope with cross product dependencies is by using Plans / Advanced Roadmap alongside JPD showing the delivery epics (colour coded by Product) since on Advanced Roadmaps we can show the dependency links.

[David Nadri]

@Stephen_Lugton - thanks. At this time, we're on the Jira Standard plan and unable to migrate to Jira Premium (which has the Plans feature) at this time. 

However, in this case, my question is specifically about how to view the dependency of an idea (still in discovery) that spans across multiple JPD projects.

For example, when a feature idea for one product has a dependency on another product, how can we view this dependency within JPD if the ideas span multiple JPD products?

If you have any ideas, would love to hear it! 

[Paul Northup]

I've been using multiple JPD projects and though it has proven useful in some ways, the data coming back is an absolute mess.

JPD doesn't seem to re-use fields yet, so if you're doing any reporting on the outcomes or collecting any of the data, you will have messy or duplicated data fields for any fields you "share" (and by share I mean duplicate) in other JPD projects.

I'm realizing now that my implementation path may well have been wrong, and I may need to refactor to a single JPD instance to deal with the fallout.

[Gary Spross]

@Paul Northup, a feature called "Global Fields" is currently being beta tested. Although I still believe Atlassian needs to make it so JPD projects can be of the Company-managed style (along with the ability to utilize the normal custom fields interface), I do think this is a good compromise for now. It's good to at least have an option to start to standardize fields/values among several projects.

[David Nadri]

Hi @Hermance NDounga @Amina Bouabdallah @Rohan Swami @John McKiernan - any guidance or best practices for how to best handle the scenario where you have separate JPD projects but an idea from one project has a dependency on the other project? For details, see the example in my post.

Looking for something more practical then having the other team create a corresponding idea in their project to have visibility of dependency work in their roadmap/planning:

• Idea in JPD Project A: Feature A
• Idea in JPD Project B: Dependency work for Feature A in JPD Project A.

[Stephen_Lugton]

Link ideas in Project A to the dependency idea in Project B, add a 'linked issues' column to your views then those linked issues will be visible, you still have to look at them but at least you can see where there is a linked issue.  Then when the dependency is cleared unlink it.