Using Jira Product Discovery at a Company with LOTS of Ideas

Erin Mihalik

Hey everyone!  Just looking for some thoughts around how to use JPD with my current organization.

Short story: We aren't 100% embracing Product Driven org so we end up with hundreds or "ideas" or "requests" submitted to our Product Division.  While we are working on changing this mentality, it will not be an easy change.  Requests submitted could be from enterprise clients and they could be large initiatives but ideas submitted can also just be changing or adding a button here or there.

From a previous thread on this site, the recommendation is to use a Jira Service Management desk to allow those to still be submitted. I agree with this.

I am trying to figure out the best way to use JSM/JPD/Software to be as transparent as we need to.

Here are my thoughts and places where I have some questions, please feel free to chime or offer other suggestions:

• Small idea submitted to JSM
  1. Gets approved
  2. Linked development (software ticket) created
• Larger idea submitted to JSM
  1. Item needs more discovery and will require epics, design, etc. so item created in JPD
     1. OPINION QUESTION:  Should we link the JSM item to the JPD item? or should we wait until the dev tickets are created and then link to the dev tickets?
  2. Dev tickets created and added to the Implements on JPD

Any other idea or thoughts, please feel free to offer any and all opinions!  Thanks!

 

Cam_etz775

In my opinion, this is a critical place to implement some practices that will help drive your org to be more product-driven. It seems like you need to separate out delivery team vs product team and then set the appropriate paths for each.  In this, you can change the process for your product team side to stop receiving requests (mostly) and give a pathway for ideas and feedback to be sent but without the expectation that it will be acted on. Then if you have a clear vision and OKR (or equivalent) you can easily filter out all the stuff that doesn't apply currently and avoid having a backlog with hundreds of things. Having a backlog like this often times will keep you from being user-focused and outcome-based and will keep your team in a perpetual state of drowning under the waterfall. 

More practically, I think your plan makes sense. We do something similar. It's always going to be in your favor to have the fewest amount of inputs possible, if you can get to just one (JSM), that will be in your favor big time. 
For your opinion question, I would link them all together. If you spin up something in JPD, I would link to the original JSM request. If something gets to development, I would link either the JSM request or JPD task to it. Essentially just make it easy for whoever is working on the current thing to go backwards and see the original context, work done, etc. 

Good luck!