What to include in Jira Product Discovery?

Question

Hi everyone.

I am looking for advice from those who have been using JPD.

We recently started using JPD for both our Product team and our Data Science team.

One problem that is surfacing now is that because there is so much excitement around JPD, people want to add everything to JPD. I am having a hard time distilling what should go there and what shouldn't. For example, should JPD be where all stakeholders can see ALL projects that these teams are working on? The way I see it is that only actual ideas should go there, and while those might eventually become "projects," we still need to track the work in Jira Software or Jira Work Management and link it to JPD. But if we have projects that are already in progress, having those "transferred" to JPD seems odd to me. JPD should not be a "replacement" for Jira Software or Jira Dashboards, where we can see all projects in progress, but a place were discovery and ideation take place. Of course, those ideas do become projects eventually, but the actual work should still be tracked in Jira Software or Work Management, in my opinion.

Anyway, I hope this makes sense. Is anyone struggling with something similar? It might be part of the pains of introducing a new tool. I feel like we need something like a "criteria for inclusion" in JPD (what goes there and what does not, and what should we use it for and what should not use it for). I know there isn't one answer to this, but I am super curious to hear your thoughts!

Thanks in advance!

Tanguy Crusson · Answer

Gotcha, thank you for the context.

I get it - you need to show everything on the roadmap that is relevant to the stakeholders you're sharing with. That's the reason we've created a field called "Type" in our project, to differentiate between the different types of objects in the project (product ideas, large investment areas, user feedback, even things like competitors or customer stories). We then make sure the right "types" show in each view.

The fact that you can define a filter for each view makes things like this possible (it's only when you have no filter at all that it becomes a mixed bag of stuff).

We're going to implement support for different issue types in JPD later to make that easier to deal with (so you can have ideas with a workflow, and "initiative" with a different workflow for example).

Jeanette Bonifaz · Answer

Hi Tanguy!

Thank you so much for your detailed response. That is exactly what is happening to us as well. At first I was hesitant and trying to dissuade the leadership and stakeholders from using it that way, but as you pointed out it seems like it is something other companies are doing.

One particular concern I have:

- There are certain "projects" or "initiatives" that are in the realm of Data Governance, for example, or something that is not directly Product related, where the work does not involve "building" something. Having a bird's eye view requires that we also have those there, but having those initiatives included in JPD seems a bit confusing since they don't really follow the traditional workflow we have set up in JPD for actual product discovery.

You may or may not have advice on this, as I realize it is more of a business question rather than a tool question. I just want to make the most of JPD, which is truly a great tool, and I don't want it to become cluttered with a "to do" list of all kinds of stuff. Does that make sense? If you have seen anything similar or if you come up with a similar situation in the future, I'd love to hear more.

Thank you!

Tanguy Crusson · Answer

Great question, and here's how we've seen it play out in different companies:

* Initially JPD is used to put in all the "some day, maybe" ideas - all the stuff that's not prioritized yet* It's used for prioritization discussions
* Out of that eventually comes a product roadmap in JPD. This roadmap tells the story for what which team will focus on and why, and when

* Then the work is broken down in Jira Software. That work is linked to the idea, and the idea can show a high level progress.
* Because everyone is now in JPD, and all future ideas and initiatives in-flight are now in JPD alongside their progress, many companies start to adopt JPD to get a "helicopter view" or "bird's eye view" or "executive dashboard" of initiatives/projects (both in flight and coming next)

Usually that translates into:

* The product managers, customer facing teams, business stakeholders and leadership in JPD to get the top level view of things and discuss progress, risks, issues, tradeoffs
* The product managers and IT/Engineering leadership in JSW to drive the execution

We didn't initially design JPD for that purpose (it was mostly about prioritization and roadmapping) but we've seen this happen time and time again with many customers we talked to. It does make sense, and the tool does a pretty good job at that for them as far as we could see.

Does that make sense?