Workflow best practices
Asked by Michael Mackuliak:

I, like probably many here, have watched the many (fantastic) demo and ways of working videos [@Tanguy Crusson](/t5/user/viewprofilepage/user-id/502312) has produced. One thing I've noticed in the videos that the JPD team wasn't using workflows, instead a field for "Wonder, Explore, Build, Scale". But maybe there was a workflow that just didn't get shown ?   

I'm starting our setup and trying to come up with a workflow for ideas. Specifically I'm trying to decide if I should have two buckets for ideas, a sort of inbox where ideas just get a sanity check and if interesting enough go to a idea backlog where they can collect insights and be further evaluated for something like an impact score. Just not sure if there are other flows I should be consider - such as from an inbox straight into the garbage or onto the roadmap for later.


Answers:
author: Tanguy Crusson
body: By the way [@Michael Mackuliak](/t5/user/viewprofilepage/user-id/3627946) we've started working on a handbook to explain how you can adopt JPD for things like this.

You can find it here: [Jira Product Discovery handbook](https://pm-dev.atlassian.net/wiki/external/MDkxNmFkNWQ4Yzk1NDA5OGIxOWU0MmVkMmFmYjEwM2Q).

comments: author: Michael Mackuliak
body: [@Tanguy Crusson](/t5/user/viewprofilepage/user-id/502312) fantastic and thank you!! I think many customers (to be customers) will find this useful.


author: Hermance NDounga
body: Hey Michael,

I'm one of the Product Mangers for Jira Product Discovery. You didn't miss anything, we indeed don't use workflows or status field, and simply use a custom field for "Parking Lot, Wonder, Explore Make and Impact"

We are not using the Status field, because as Duncan mentionned, these are not linear phases, and we don't need to enforce fields, create gates or other frictions that would make us use less the product :)   
The workflow is super useful for a delivery team, but as product managers we have the leeway to be a bit more flexible. However, we recon not all companies can work in that manner, and that's why workflows are present in Jira Product Discovery.

Regarding the two buckets - we don't really have this problem because we (the product team) are the only ones creating ideas in this project, so we don't get ideas that need to be triaged afterwards. The feedback stays where it is - slack, Jira Service Management, community, and each one of us read these channels every week, and add each piece of feedback as an insight an existing idea or create ideas to attach the insight on the fly. Tanguys explains [this in this webinar.](https://www.youtube.com/watch?v=Yp0q7YVYM4c)

So sometimes we need to do some merging when we realize that we've been calling the same thing in different ways, the list of ideas is quite clean. Each week we review the ideas that recently got feedback, and once per quarter we evaluate which new ideas we want to start exploring (and that's when an idea enter the wonder/explore phase).

I hope this helps,

Cheers,

Hermance

comments: author: Michael Mackuliak
body: Thank you [@Hermance NDounga](/t5/user/viewprofilepage/user-id/430755) for the detailed reply and the extra insights, definitely helpful!

Reminding me that only the product team is entering ideas is key, otherwise it is easy to imagine how noisy it would get (and quickly).

Quick follow up on this part: "*The feedback stays where it is - slack, Jira Service Management, community, and each one of us read these channels every week, and add each piece of feedback as an insight an existing idea or create ideas to attach the insight on the fly."*

Does the team have some criteria they use to decide if a new insight that doesn't have an idea yet should be created in your JPD? (e.g. I read an insight for an idea that hasn't been yet entered, what criteria/rubric does your team use to decide if it should be created as an idea and that insight attached.


author: duncan_crowell
body: I have setup a similar thing for my place where we have a "Triage" step before it moves into the actually discovery approach.

I might get this wrong (I am not from Atlassian) but my understanding of why they use a custom field and not a workflow is because "The Atlassian Way" (Wonder, Explore, Build, Scale) is not a linear process but rather stages an idea pass through in a non-linear fashion. Workflows are great for enforcing a path an idea needs to take which is important for some but not everyone.

Back to the 2 buckets though. I setup (using a workflow as it happens) that any idea when first raised lands in a status called "Triage" this is where we do a lightweight assessment on the idea to see if it has the gusto to explore further or is maybe something we have tried before and had reasonable reasons as to why we did not progress. This enables us to ensure that the Ideas with promise do not get lost in the noise of all ideas ready for further exploration by teams.

Like most things I have setup so far, its not perfect but its a starting point that we are testing out and adapting as we go. SO far its serving the purpose of, as the name suggests, triaging out the noise to enable teams to focus.

comments: author: Michael Mackuliak
body: Thanks [@duncan_crowell](/t5/user/viewprofilepage/user-id/5409190) !! (sorry was on vacation)

That was my thinking with a Triage type of bucket as well. What are your current pathways out of triage ?