Why Public Voting (and JAC) Are Broken

[#1]

If you’ve ever spent time on jira.atlassian.com, you’ve seen how massive public feedback systems can get.

A short history of JAC

When I joined Atlassian in 2004, JAC was one of the most valuable tools we had as a product team. It gave us a direct connection to customers and an incredibly fast feedback loop. You could release something one day and see real reactions the next. It was open, transparent, and exactly in line with Atlassian’s values.

Here is a great example of how we used feedback really well in the Stash team during the early days: https://jira.atlassian.com/browse/BSERV-2462

But as the company grew, that openness started to create new challenges. Keeping up with new requests was already hard at scale, but what became even tougher was maintaining updates on the thousands of items that accumulated over time.

On our team, we had a rotating PM role dedicated to triage and replying to tickets. We tried to focus on the top 50 requests and the “hot” issues that generated lots of discussion. But even with structure and good intent, it took a lot of effort.

Over time PMs (and any Atlassian employees) became more reluctant to comment. A single update could spark a firestorm and hundreds of replies. People got worried that saying the wrong thing might impact their careers.

We had multiple discussions about what to do. Whether to shut down JAC entirely or move it to another system. But neither option felt right. Shutting it down didn’t align with our “open company” value, and moving it somewhere else would have just shifted the problem without solving it.

Where Public Voting Falls Short

From the outside, public voting seems like a fair way to capture customer needs. The features with the most votes must be the ones that matter most, right?

But inside a product team, it doesn’t quite work that way.

Popularity doesn’t always equal value. Sometimes an idea blows up in a user group or gets a few passionate voices behind it, while genuinely important requests get lost down the list. And the nuance gets stripped away. Take JRACLOUD-96247 — the title suggests one thing, but if you read the comments, most people were actually asking for something completely different.

And that’s before you even factor in business goals, technical dependencies, and limited resourcing. All the things that influence what actually gets built.

Over time, the feedback starts to lose meaning. Customers feel like their input disappears into a void, and product teams struggle to keep the community happy and stay focused on their strategy at the same time.

All of a sudden, that feedback board that once felt so valuable turns into an endless backlog that’s impossible to keep up with.

Why It’s Not All Bad

To be fair, voting does a few things really well.

It’s simple, transparent, and great for engagement. It can reveal broad trends and give you a sense of where interest lies.

But votes alone don’t make feedback actionable. They don’t tell you why something matters, or how it connects to your strategy. And they come with all the drawbacks we already discussed.

A Better Alternative: Wishlists

That’s why we took a different approach when designing feedback in Released, our app for sharing Jira roadmaps and collecting feedback.

Instead of public votes, we use Wishlists.

Each customer can create a private list of features or improvements that matter most to them — without being influenced by what others ask for.

Every wish links directly to a Jira issue, so product managers can see not just what users want, but who wants it, and can easily follow up.

Here is why Wishlists work better

• Reduces bias: Each user creates their own personal list, so feedback reflects what they actually need — not what’s trending.

• Forces prioritization: With a limited number of wishes, people think carefully about what really matters.

• Manages expectations: Public vote counts can set unrealistic expectations without offering much value.

• Stays connected to the work: Every wish links directly to Jira, keeping feedback part of the actual workflow.

Managing expectations

But Wishlists alone aren’t a silver bullet. What matters just as much is what you choose to share. Don’t publish every feature request you’ve ever received. Focus on the ideas your team is actively considering over the next 12 months. Everything else just adds noise.

Users can still submit feedback on anything, and you can link it to existing ideas internally. This approach gives your team control over expectations and ensures customers see a curated, realistic view of what’s being worked on.

Build what matters 

If you want to better engage your customers and actually build features that matter, try out Released on the Atlassian Marketplace. 

And if you want to learn more, schedule a demo.