How one team in Atlassian uses Jira Product Discovery

[#1]

Hi all, 

Recently one of the product managers in Atlassian shared a Loom video showing how he and his team (BitBucket) have been using Jira Product Discovery.  

Every team has a different way of working. However, many have been curious to see how other teams use Jira Product Discovery so I thought it might be useful to share this externally. 

Part 1: Ideation & Triage

Watch the video here: https://www.youtube.com/watch?v=o8R0cc3jzBU

This is the first in a series of practical videos (prioritisation next) and it focuses on the initial ideation and triage stages of the overall product management process including:

• How product and feature ideas get proposed by Bitbucket

• How ideas are triaged every fortnight

• How Edmund and his team use automation to make sure good ideas are never lost and everyone feels heard

• And ultimately what his team does when they are ready to work on something right away.

The goal, as ever, is to ensure Edmund’s team is building the right features that customers will actually use and hopefully love. This video is the first in a series that will take you through how product discovery is done in real life, the benefits gained, and some tips on how you could get started too.

Also in the video, you will see Edmund showing a visual of the workflow they use. I have included a screenshot below as it helps orientate. 

Part 2: Prioritisation 

Watch video #2 here: https://www.youtube.com/watch?v=yW3B0VU8sxE

In this video, Edmund walks through how the BitBucket team prioritise all of the potential ideas and features to build and how JPD:

• Provides a single source of truth for each project, at all stages of the product development cycle.
• Helps to find the perfect balance between accuracy and efficiency when scoring potential work in terms of things like effort, value, reach, etc.
• Enables you to combine multiple simple, easy-to-understand, easy-to-score metrics together to create powerful and sophisticated measurements of relative value between different potential projects that your team has to prioritize.
• How doing all of this in JPD allows you to instantly compare these numbers for all of your potential projects in a true "apples to apples" way, allowing you to make well-informed prioritization trade-offs.

Edmund gets deep into the weeds here showing in great detail how his team prioritises what to build next for customers. It’s a great video for those who are already familiar with Jira Product Discovery and looking to improve their tool usage and practices.

Part 3: Automation

Watch video #3 here: https://www.youtube.com/watch?v=wDQAWfv5_j8

In this video, Edmund answers your most asked question on how his team uses automation to manage ideas throughout the discovery process. More specifically how you can use automation for idea deferment, when you want to work on an idea at a later point in time but don’t want it to crowd your roadmap until your ready to tackle it. He’ll walk through:

1. The process his team takes when they want to defer an idea to 3, 6, or 12 months later
2. A no-code way to build your automation rules using automation scripts in Jira.

Edmund dives deep into the entire process, step by step, on how to setup your automation using custom fields and JQL. You can view the written automation rules below. This video is best suited for those who are already familiar with automation rules, JQL queries, and Jira Product Discovery and are looking to level-up their product management rituals.

Pre-steps:

1. Create a set of statuses to track how long you want your resurfacing to take.

2. Record the Status names for each.

   1. For this example, the statuses will be "Reviewing Next Quarter", "Reviewing Next Year", "Reviewing Six Months"

3. Create a “Short Text” field to hold the date for when you want to resurface each item back into view.

4. JPD Fields are created as custom fields, so you’ll need to go and get the Custom Field ID for the field you just created.

   1. Follow the “Using the Advanced JQL view” guide on this page to get the Custom Field ID: How to find any custom field's IDs | Jira | Atlassian Documentation

   2. For this example, the custom field is 13088

Automation 1 - Set resurface date.

1. When an issue is set to one of your deferment statuses, populate the field you created with {{now.plusDays(<days>).jiraDate}}

   1. now gets today's date

   2. .plusDays(90) adds 90 days to today's date (for a 1 quarter deferment).

   3. .jiraDate converts that new date into a simple date format of yyyy-mm-dd which is easy to compare as a string.

   4. So if today is the 28th of August, 2023; {{now.plusDays(2).jiraDate}} would inject “2023-08-30” into the field.

      1. This would be the day we want the issue to be resurfaced for review.

Step 2 - Daily check for Bubble up.

1. On Daily, run JQL that searches for project = <your project key> AND status in (<your first status>, <your second status>, <etc>)

   1. So for our example, we have a Project key of “BBCPM“ and the statuses mentioned before. Our JQL is t project = BBCPM AND status in ("Reviewing Next Quarter", "Reviewing Next Year", "Reviewing Six Months")

   2. This JQL query fetches all the issues in your JPD project with the statuses set to one of those deferment statuses.

2. Add a condition action to check that the custom field you put the date into matches the current date as a jira date.

   1. To lookup the resurface date field on the JPD Issue use {{issue.fields.customfield_<custom field id>}}

      1. Which would be {{issue.fields.customfield_13088}}

   2. Then compare it to {{now.jiraDate}}

3. If it does, update the status back to whatever your status is for triaging issues.

If you find these videos useful, please throw a like or a comment on this post to ensure you get notified when we add more videos to this page. 

All comments and feedback are appreciated as always. 

Cheers,

John

[Ted]

Great video, thanks for sharing! Love getting some insights on how your teams use the tool internally. 

Would it be possible for Edmund to share the automation rule they wrote for the "bubble-up" rule (3/6/12 months)? 

[Chris Timms]

That was interesting to watch, thanks for posting!

[Dana Weinbaum]

Thanks for this great video. Very informative. I love the 'bubble up' idea, this is something that we are doing manually today... Can't wait for the next videos. I'm particularly interested in seeing exactly how you created the different automations (step by step) and how the ideas are linked (if at all) to the actual creation of the feature (the steps after an idea went into the backlog). Thanks again.

[John McKiernan]

Delighted you liked the video. I have updated the page with a second video focusing on prioritisation. For those looking to go deep, you'll enjoy this! https://www.youtube.com/watch?v=yW3B0VU8sxE

I'll also dig in and get more information from you on the automation rules he uses :) 

[Omer Meshar]

I am in the middle of viewing this and I just saw Edmund talk about the "triage escalation" flag that supposedly can be flagged by the contributor (engineer). But wouldn't a contributor, after submitting their idea, not be able to flag this? They should be able to just comment, vote or add insights, right?

Easily, one can add the flag to the initial form (I think), but if anything changes and you would like to flag it after submission, you would need some creator to do it... am I missing something?

Update: continued to watch the video, and the idea of asking the contributor to add more information is also contradicting the fact that the contributor cannot edit the idea. They would need to email/comment or recreate the idea instead...

[Chris Hall]

Hey @Omer Meshar, thanks for your question. You are right, the contributor can only comment, vote or add insights on an idea once the idea is created. A contributor would need to select the "triage escalation" box while creating the idea (a creator can add this as a field to the submission form) and the additional information discussed would need to be added in the form of a comment.

Apologies for any confusion!

[Rebekah Nguyen]

Thanks for sharing these videos! I'm a design program manager and would love to see how the "Design" section in Edmund's project is being used.

[Dana Weinbaum]

Hi,

I'm trying to implement the "bubble up" automation and hit a wall. 

Are there plans to have a video on that? or perhaps you can share a step-by-step post?

Thanks!

[Edmund Munday]

Hi @Omer Meshar - in response to your question, for our internal processes we setup the JPD permissions fairly openly, so members of the internal team who create idea (engineers etc) also have permissions to edit the fields on those ideas too. This way they can easily make the changes they need in terms of escalations etc.

One of the great things with JPD is that there is quite a lot of flexibility in the permissions without making it super complex. We've been able to find a really good balance in our workflow between keeping things under control, whilst still giving people the level of access required to make the process work.

For anyone curious about the "Bubble Up" automation (CC @Dana Weinbaum, @Ted, I finished recording the deep-dive on that last week. It should be published soon! Really excited to share the details of that one, this is one of the more powerful automations I've built using Automation for Jira, but I was pleasantly surprised by how achievable it was.

[Omer Meshar]

Thanks @Edmund Munday - I agree with you about flexibility. Unfortunately, the issue is not flexibility but cost. You probably have the privilege to not pay for Atlassian products... Those of us that do need to pay, need to pay for every "creator", so having all internal team members as creators is a very high cost for the ability to edit their ideas.

[Ritika Kapoor]

These are great videos, however as mentioned by @Omer Meshar contributors cannot edit the idea once created. We have been finding this challenging and are also seeing contributors wean away from idea generation on using JPD. They are resorting to the the old ways like email, chat etc and are asking the admins/PMs to create the ideas and have them set as Reporters. While I understand that part of it is process, it still would help if Creators/Reporters both are given the rights to edit the idea. Ours is a small company so cost of adding additional creators is not feasible.

[Jan-Hendrik Spieth]

I want to confirm @Ritika Kapoor observations from my experience with my previous employer: not being able to edit your own ideas once submitted doesn't work out and didn''t feel right to reporters, in quite some scenarios.

I think one factor was/is that oftentimes, you just submit too early, and forgot a detail. Or you have a typo in the description. Bummer - you can't fix it. It really doesn't feel good, and even can be embarassing to then have to ask one of the creators to fix things for you (worst case, by deleting the submitted idea, and the reporter then starting from scratch) ...

[Dana Weinbaum]

Thanks @Edmund Munday for this great video. Very informative. I was able to easily perform the automation! 

[Omer Meshar]

Thanks @Edmund Munday for the third video!

Sadly, the new packaging model for jira cloud automation will let us have only 500 successful automation runs per month (for Standard license). If we take into account 1 idea per day that is deferred to a later date, and 1 idea per day bubbled back up, it means we will need to spend 60 runs out of the 500 we have (more than 10% for a single idea for this functionality only). If we have 5 ideas deferred per day, we lose more than 30% of our automation.

This doesn't make sense.

Automation enables many functionalities that are otherwise missing, and limiting the number of successful runs is a real hit to our ability to create a useful system to our users.

[NC]

Hi @Edmund Munday  

Great series!!! We do something like your bubble up process but within JSM currently. 

I have two questions:

1. What are your thoughts on using JSM to receive new JPD requests and then using automation to clone into JPD and keep the two issues coordinated? We currently have this logic implemented for Incidents and linked Bugs within Jira software but if there was some sort of JPD portal in the pipeline then i might hold off.
2. I notice that you have several Atlas fields in JPD (26.25) when JPD was in Beta there were Atlas options in the project setting but I am no longer able to locate these... Linking ideas to current goals would be a fantastic way to add value

[Summer.Hogan]

Thanks @John McKiernan for these great videos! It really helps to see how JPD is used in real life! 

[Leon Meier]

Really cool feature! Actually went ahead and implemented the workflows shown in the video and tried to include the bubble-up automation, but i got stuck here for hours:

Tried editing a date field: won't let me do it
Tried editing a short text field: ignores the field entirely
tried with JSON and field finder: both failed

[acorvino]

@Edmund Munday - I'm having a similar issue as described by Leon Meier.  I don't see the custom field for selection in Jira Automation.  When I attempt to add the custom field to the automation step, I'm unable to see it.  I added it with reference to the custom field instead, and it always creates an error.  I get the same kind of error even if I select a JPD field like "Roadmap" and attempt to update it. 

My current rule is just set up to change the Roadmap field to another available value and the "Bubble Up" date to a hard coded date.

[Edmund Munday]

Hi @Leon Meier - sorry I missed the earlier notification for this. Are you able to share a screenshot of the full "update field" JSON you're inputting?

@acorvino - It looks like the issue you might be having is just down to the syntax of the JSON you're using for the update.

Rather than specifying "update", you should just be able to pass in the value you want to set the field to, and it will overwrite whatever is there currently.

For example:

{
  "fields": {
    "customfield_11574": "02/15/2025"
  }
}

However, I would recommend using a dynamic date that you set your "bubble up" to, rather than a static one, otherwise you're going to have to come in here and change it all the time.

So, rather than "02/15/2025", you could use "{{now.plusDays(90).jiraDate}}" which will spit out the date 90 days from now, in the Jira Date format.

So for the full update (assuming you're doing a 90 day bubble up time) it would be something like:

{
  "fields": {
    "customfield_11574": "{{now.plusDays(90).jiraDate}}"
  }
}

You want this in double quotes, because later on you will be doing a comparison that is matching on a string value for that same date.

Final point I would suggest, even if you're writing dates by hand rather than using the smart values, always use the "jira date" format (yyyy-mm-dd).

You will make your life SO much easier later on when you need to start feeding these dates back into other automations, or doing any kind of "date comparison" logic with them, if they are already in the format that Jira "speaks" natively.

[Edmund Munday]

@NC - only 6 months late... sorry!

What are your thoughts on using JSM to receive new JPD requests and then using automation to clone into JPD and keep the two issues coordinated? We currently have this logic implemented for Incidents and linked Bugs within Jira software but if there was some sort of JPD portal in the pipeline then i might hold off.

I can't speak to any kind of future features for JPD (I'm actually from the Bitbucket Cloud team (shameless plug for my teams latest release: https://bitbucket.org/blog/forge-for-bitbucket-cloud).

@John McKiernan is actually much closer to the day-to-day plans for JPD than I am.

One thing I will say, as a general rule I've learned that trying to keep two totally seperate Jira issues "synced" via automation is 100% doable, but the complexity grows quite rapidly depending on the number of fields you need to sync, especially if any of them are dates.

I notice that you have several Atlas fields in JPD (26.25) when JPD was in Beta there were Atlas options in the project setting but I am no longer able to locate these... Linking ideas to current goals would be a fantastic way to add value

As far as I'm aware, all of those fields should still be available! We use Atlas a LOT, so we had to create additional fields beyond the "canonical" Atlas link field.

[acorvino]

Thanks @Edmund Munday

The version I posted was just my most recent draft - I keep adjusting things to hope something will work and was finally hardcoding the date to eliminate things that could be a factor.  I adjusted to match your suggestion, and it still doesn't work.  

I also notice that I'm getting an error for the step that should just be updating the Roadmap field, which I was able to select.

[secutechconsultingservices]

Hello,

We currently use Jira Work Management to handle our product engineering workflows with statuses (open, in progress, and done). We are planning to switch to Jira Product Discovery. Could you advise if there's a way to transfer our existing stories from Jira Work Management to Product Discovery?

[John McKiernan]

Hey @secutechconsultingservices 

This page will give you the best direction if you want to move your work over to JPD :) 

https://support.atlassian.com/jira-product-discovery/docs/import-existing-jira-issues-into-jira-product-discovery/