Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,299,406
Community Members
 
Community Events
165
Community Groups

Using Jira Product Discovery at a Company with LOTS of Ideas

Edited

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!

 

2 comments

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!

Thanks @Cam ... preaching to the choir on the change the whole org mentality.  We are working on it for sure.  It is getting everyone else in a historically client/sales driven org to make the change that is the struggle.

I appreciate the response and validating what seemed the most sensical to me.  

So having gone through this same progression this is what we are settling on. We don't have a huge team but do have dedicated people in charge of delivery and discovery but to make things easy for our CS/BD staff we are still operating their INITIAL interactions with the delivery board (i.e. JIRA Software).

However, we have created a new issue type 'Suggestion' (and limited the others they can create). So effectively they only raise bugs & suggestions. Our weekly triage process will convert a Suggestion to a discovery idea if it's needed OR for the really small things, we hand to the PO to convert it to a User Story that outlines the small change as per SCRUM/Agile.

We will see how this goes, it's not perfect but a start. 

Like Cam likes this

@Colin Goudie Thank you!  Yes, this seems like the best for now.  I like the triage meeting concept as well. 

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you