What to include in Jira Product Discovery?

[Jeanette Bonifaz]

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!

[Ivan Ferreira]

Hello @Jeanette Bonifaz. I think that there is nothing wrong with having "in progress" projects mapped to JPD. Having all the work visible is key to good management.

JPD is not a replacement, it just provides different ways to communicate, and it has it's audience. 

You could even share a view with stakeholders that are not part of your site.

We use a combination of Atlas, JPD, Plans (Advanced Roadmaps) and Dashboards. Choose the best tool for the communication plan.

[Nigel Budd _CV_]

I think this is a common problem, I tend to recommend to my customers to use JPD for ideas management, and then for those ideas to be able to track them through to development (assuming the idea makes the cut of course)

There does tend to be a lot of excitement, it can feel like a kid in a sweet-shop problem with your stakeholders asking for everything and expecting it, so expectations do need to be set in how to use it.

Ideas need to be categorised into Large, Medium and Small and often displayed on different on different Lists as the decision making behind a large, strategic idea that might take months or years and a small 1 day change are very different things, even if all kinds of ideas have value to the customer.

I tend to encourage ideas like improving tech-debt, and other internal improvement 'ideas' to be kept out of JPD and instead created inside the JSW project.  The JSW project really needs to be seen as the source of truth for the backlog of the project, and JPD being ideas that we might, or might not consider doing.

[Stephen_Lugton]

@Jeanette Bonifaz as @Ivan Ferreira says there is nothing wrong with mapping existing projects to JPD, we did that with so that we could take advantage of the timeline view in JPR that is a lot cleaner for stakeholders to look at, especially as we were able to group that by Atlas Goals and Projects.  Doing so also allows us to look at high level capacity planning and show why we can't start on some of the new project ideas yet.

As you say it's part of the growing pains for a new tool, but if you do it at a minimum viable level it can be a quick task.

[Tanguy Crusson]

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? 

[Jeanette Bonifaz]

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]

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