The Logic of JPD - Voting
Asked by Ryan Gordon:

I was quite excited to see Jira Product Discovery- it lined up with an initiative to get our internal idea management off of a different platform and into Jira.

I've ported everything over, but some of the decisions in JPD make me question the logic of it as a product and the envisioned use-case.

***Our use case*** is to capture all the internal ideas our staff would like to submit for review and possible implementation. Voting seemed like one really nice feature we would gain, but the *logic* of voting in JPD makes no sense to me.

You can't replenish votes, you can't limit how many votes someone can have per issue, and you can't set a time period for how long users can use a specific voting field.

According to [@Rohan Swami](/t5/user/viewprofilepage/user-id/2842658) [here:](https://community.atlassian.com/t5/Jira-Product-Discovery/How-are-you-restarting-votes/td-p/2279149)
>
> #### ... most customers are using the voting feature as part of a collaboration session ... It's a point-in-time activity. {#toc-hId-236071834}
>
This is baffling to me, given the way the JPD works currently. *Every time*you want to have a session of voting, you are expected to make a new field? Is everyone just polluting their projects with dozens of voting fields? The workaround in that thread says to make a new field every quarter.

So you just have a whole bunch of voting fields on every idea? If an idea crosses over from one quarter to another, and you want to know the total amount of votes, are you supposed to just add up all the votes from all the fields and ask your users nicely not to use fields from previous quarters?

The most *sensible* form of voting, to me, would be the way it works in other Jira projects- 1 vote per issue, unlimited votes per user. However, I could come up with viable ways to use this, if I had any of the following:

* Archive voting fields while retaining their votes
* Replenish votes, with a maximum number per idea and total per user
* Control which fields were visible on ideas

Since we have none of this, I really can't see how this could be useful to most people, beyond having a bunch of ephemeral JPD projects that don't last long.

Am I completely off-base here? Have I missed something obvious?

To be clear, I see the value of a field that implements dot-voting (though less-so if you can't archive it). It just seems counterintuitive to me that the regular voting system, which seems much more broadly relevant, be removed entirely when its replacement seems *less broadly relevant*.

Dot voting feels niche, something I'd want to do under a specific circumstance.

*** ** * ** ***

There are some other oddities to JPD too, like the fact that I can't control what fields appear during idea creation or which ones are required, though at least this can be worked around by ingesting ideas into Jira over the API via something like Slack or a Google Form.


Answers:
author: Tanguy Crusson
body: Hi [@Ryan Gordon](/t5/user/viewprofilepage/user-id/5234558)

This feature is meant to be used for understanding the relative importance of ideas/opportunities by stakeholders, at a point in time. For example, at the start of a planning cycle, you create views with a pre-selection of ideas, one for each stakeholder group, and a corresponding voting field for each, e.g.:

* "Votes from sales - Q1"
* "Votes from execs - Q1"

Only having $10 to allocate changes what people vote for, it puts them more in your shoes, they have to think about what's more important, and trade-offs. It's meant to be a conversation starter. You review all this with them to understand what's important to each group, and factor that in your prioritization decisions.  

If what you're looking for is a way for people to vote for all ideas continuously and have the most popular ones "bubble up to the top" then I suggest you create a "Reactions" field as [@Rohan Swami](/t5/user/viewprofilepage/user-id/2842658) suggested (?,?,?). It's more lightweight, there are no limits in how many reactions people can use, but also it doesn't create the expectation that the team will commit to doing the thing with the most reactions . We've seen that "votes" tend to create more expectations, and we all know that prioritization is more complicated than that!

That being said, you could also give everyone an infinite number of votes (e.g. 100,000) if you believe that crowd-sourcing your roadmap, via the Votes field, is something that would help you.

comments: author: Ryan Gordon
body: To be clear, I am fully familiar with the idea of "dot voting", which is what this notion of having $10 to spend is. I just don't understand how it's expected to be used.

It's meant to be a capture of a voting session that happens in a moment in time, but you need to use a field to do that. A field is a global entity (for the project), it will in the Field dropdown menu, and on *all ideas regardless of view* , for **forever**.

If you did 10 sessions of voting, you'd have 10 now completely defunct fields sitting in your field selection dropdown and in your "Other fields" section on ideas.

It's not like you can archive them such that they only appear on ideas that had votes for that field and disappear elsewhere. You need to continuously pollute your board with them.

God forbid someone falls involve with dot voting and does sessions every week- after two years you'd have \>100 defunct fields polluting your board that you can't get rid of if you want to keep the data for historical reference.

Unless I'm wrong, and there's a way to get rid of the field everywhere but the ideas it was used? I like team-managed projects, but without the flexibility of controlling screens at a granular level, I don't know how to implement something that requires a new field each time neatly.

Also, on a side note, like I said I like dot voting, I just think the decision to replace normal voting for it instead of adding it on as an extra feature was questionable.


author: Rohan Swami
body: Hi Ryan.

We've also now released a Reactions field type which can function more like a permanent field for voting, it has the additional flexibility of allowing your team to express themselves in different ways (eg. pick a heart emoji if you think this will delight customers, a cash emoji if it will improve revenue).

Bear with us! Our process is to release a simple version of features and iterate on them over time and we'll factor in your feedback as we make these improvements.

![Screenshot 2023-06-05 at 9.21.54 am.png](https://community.atlassian.com/t5/image/serverpage/image-id/261262i8DE9872D175EBD95/image-size/large?v=v2&px=999 "Screenshot 2023-06-05 at 9.21.54 am.png")![Screenshot 2023-06-05 at 9.24.55 am.png](https://community.atlassian.com/t5/image/serverpage/image-id/261264iDB31008C0B0D1167/image-size/large?v=v2&px=999 "Screenshot 2023-06-05 at 9.24.55 am.png")

comments: author: Kyren Cabellon
body: This might work for us. Do you have other "name" suggestions for the "Reaction" field?


author: Rohan Swami
body: [@Kyren Cabellon](/t5/user/viewprofilepage/user-id/3746290) it really depends on how you want the field to be used! We've built this in an abstract way so that it can be extended to a wide variety of use cases for example: feedback (heart, fire),voting (thumbs up/down), metric themes (cash for revenue, heart for customer love).


author: Kyren Cabellon
body: [@Rohan Swami](/t5/user/viewprofilepage/user-id/2842658) Thank you for this explanation! We'll explore more what works best for us.


author: Ryan Gordon
body: Reactions would be nice if I could limit the emoji selection (thus making it basically identical to a vote field). Still, this will work for now.


author: Julia Titeux
body: Thanks for your reply.

I had tested the reaction field on September 1st and I remember that you could pick any emoji to react. Now when I check I can only see 6 emojis (thumbs up, applause, fire, heart, surprised, thoughtful). Can we go back to picking any emoji for reaction?

This is particularly important for me because I had planned on using the reaction field for Managers to prioritize ideas from 1 to 10 using the number emojis 1?? , 2?? , ...

I had presented this way of doing things to all the top management of my company, only to realize that it was not possible anymore the day of the big launch. This is the kick-off of Jira Product Discovery for my company, and we are not sending a good signal with this ...


author: Tom Haapanen
body: Based on the comments below, we should be able to select an arbitrary total number of votes per person, but the number of votes per idea is limited to 10. We can live with this, and we have created a distinct contributor role for people who cannot vote (as contributors can always vote) as we have 100+ contributors and we need to manage who can vote and who cannot.

However ... it's not working. When I create the field, I can specify the number of votes per person. But when I actually try to vote for multiple issues, the total is still fixed at 10: if I apply four votes to the first idea, the next one has only six remaining, even though I set the total at 50.

This looks very much like it's a bug, whether new or whether this is the way it always has been. Can this be addressed ASAP?

comments: author: Tanguy Crusson
body: Hi [@Tom Haapanen](/t5/user/viewprofilepage/user-id/5281403) , you can select an arbitrary total number of votes per person - just open the votes field setting. The only thing that's fixed is the max number of votes for a single idea for one person (you can give a maximum of 10 votes for a single idea as a person)


author: Abby Kiesling
body: I'm confused on how this is supposed to work... I manually add votes when customers request specific integrations, and I've set my voting field to be able to vote 10 million times or something. But I can't allocate more than 10 votes per idea... This is VERY limiting.

I don't want to create multiple voting fields and I don't want to use a reaction field when Voting is already there. That's just confusing, and I've already trained my entire company on tracking votes with the vote field.

comments: author: Omer Meshar
body: I think that it would be better to track when customers request specific integrations (or anything relevant for that matter) in the insights and not as votes. An insight can hold which customer requested, when, and additional information that you don't have on a vote.

And of course, it is not limited...


author: Abby Kiesling
body: [@Omer Meshar](/t5/user/viewprofilepage/user-id/4828263) That doesn't really work either, because if another insight is added, let's say an article about market adoption of said idea or some other information to be considered, it would look like an additional customer was interested. So then all customers interested PLUS all other insights would artificially inflate the number of interested parties.

Why wouldn't voting just work for voting... Why do we need to create a work around... JPD should simply expand the ability to add votes to whatever number. Change it from a drop down to a text entry field...


author: Tanguy Crusson
body: Hi, actually [@Omer Meshar](/t5/user/viewprofilepage/user-id/4828263) 's suggestion would work if you create a formula field that only counts insights with a specific label:

<https://www.loom.com/share/6bb613af23d94974ac7ef22e107bf16a?sid=30bb7be6-5e8c-4754-bad2-3fb295977951>

It sounds like what you need is another kind of field that lets you do "+1" on an idea (with commentary or not), with the ability for the same person to keep adding "+1" anytime they come across a new customer that wants this - that's a great idea, not quite what we designed the "voting" field for though.


author: Abby Kiesling
body: [@Tanguy Crusson](/t5/user/viewprofilepage/user-id/502312) Then what's the purpose of being able to set the number of votes someone gets? It's meaningless, since it still caps the number I can apply to a single idea.


author: Tanguy Crusson
body: [@Abby Kiesling](/t5/user/viewprofilepage/user-id/5096665) the concept behind this field is the "$10 game" - "if you had $10 what would you invest in and why?". We understand a few teams then took this field to do other things, and that's fine, but it's just not what we designed it for, so there will be some weirdness involved ? We'll review this at some point, but we can't do this in the short term.

In the meantime, I'd suggest you watch the video I shared in my previous comment, in there I suggest a solution that may work for you.


author: Tanguy Crusson
body: Hi [@Julia Titeux](/t5/user/viewprofilepage/user-id/5317387) that's a bug, we're looking into it!

comments: author: Tanguy Crusson
body: [@Julia Titeux](/t5/user/viewprofilepage/user-id/5317387) we've found the root cause - should be fixed in the next day or 2


author: Julia Titeux
body: Merci Tanguy ! Really nice to see such responsiveness from the Jira team ;)


author: Omer Meshar
body: I think this was already asked for on another thread, but this bug could be a good feature [@Tanguy Crusson](/t5/user/viewprofilepage/user-id/502312) if you would allow the admins to decide which icons can be used for a reactions field.   
Having all icons allowed may not help in trying to understand whether an idea is popular or not (how do you understand what each one meant?)  
Having a limited set of icons (e.g. thumbs up, thumbs down. or 1,2,...,10 like Julia needs) can help get the feedback we want.  
So if you allow the admin to decide which icons can be used, this field type would be much more useful, in my eyes, as a way to get feedback.


author: Tanguy Crusson
body: [@Julia Titeux](/t5/user/viewprofilepage/user-id/5317387) it took a bit longer than we were expecting, but it's now fixed! Can you please confirm it's working fine for you now?


author: Julia Titeux
body: Yes I just saw end of last week, thanks a lot ! working as expected


Tags: vote