Article

Article

Article

Why Atlassian’s Public Issue Tracker Must Evolve

And how to make it useful again

Atlassian has run a public Jira instance (JAC) for more than two decades. It’s where anyone can log feature requests and bugs and follow along publicly. Early on, JAC was a great way to talk to customers and get feedback. I joined Atlassian in 2004 and spent 15 years working across Jira, Bitbucket, and more, and I watched JAC grow from a helpful conversation space into something teams couldn’t realistically keep up with: 10,000+ requests, slow or no updates, and frustrated customers when their issue sat for months without news.

If I was still at Atlassian today, I’d shut down the public issue tracker. Here’s why.

The intention was good—be open, invite feedback, show progress. The constraint is capacity. A system that promises updates on everything, forever, breaks as soon as you outgrow it.

What it looked like day to day

For a while, we set a goal to update the top 50 requests every quarter. It sounded sensible, but most of those updates were just “no change,” and the routine didn’t scale—too much time spent confirming nothing had moved. At one point, we even had product managers dedicating half their week to updating JAC, often just to say there wasn’t anything new to share. That’s time better spent engaging on the work that’s actually in play.

“Why hasn’t there been an update?”

When customers ask “why hasn’t there been an update?”, this is the honest answer: the math doesn’t work. If you only update the top 10% of 10,000 requests (1,000 items) once a quarter, and each update takes 15 minutes, that’s 15,000 minutes—250 hours. At 8‑hour days, that’s about 31 person‑days every quarter. 

How to openly communicate at scale

A public idea backlog works when you can stay on top of it; at scale, it breaks. That doesn't mean growth makes customer communication impossible. it just calls for a tighter, more focused surface.

Here is the model I would use if I was leading product at Atlassian:

  1. Time‑boxed visibility
    Publish only the requests and ideas the product teams intend to consider or build in the next 6–12 months. Capture everything else, but don’t list it publicly. This creates a clear public surface that reflects the real planning horizon.

  2. Engagement where it matters
    For published items, invite feedback, share trade‑offs, and provide progress updates. Keep those threads alive with context: what problem we’re solving, what constraints we’re navigating, and where we’re heading next.

  3. Team‑originated ideas
    Don’t just mirror inbound requests. Share the team’s own exploration and concepts early—before code. Ask for feedback on problem framing and approach, not just on a feature wishlist.

  4. Replace voting with Wishlists
    Instead of public voting, use a “Wishlist” to remove the groupthink. Limit number of wishes to force customers to prioritize.

  5. Capture feedback
    Feedback is a gift. Capture as much of it as you can. Ensure the product team responds to every single one. Even if it's just a quick "Thank you!".

  6. Track demand internally
    For any ideas that are not publicly listed, connect the feedback to the ideas and keep track of demand internally.

What this changes for customers and teams

  • Customers see a shorter list, but get better context and more frequent updates on items that are actually being considered or built.

  • Teams spend less time maintaining a giant queue and more time engaging deeply where it matters.

  • Product managers learn faster from targeted conversations, not from a mountain of “+1”s.

  • The public surface aligns with the roadmap and release cadence, so expectations don’t drift.

This approach engages customers where it counts, avoids setting the wrong expectations, and gives product teams better insights.

Open company

“Open company” doesn’t have to mean “publish everything.” It means being clear about what’s planned, why it’s planned, and inviting feedback on those plans. That way, conversation stays focused on the work that’s actually happening.

Fewer public ideas. More customer engagement. Better outcomes.

Build what matters

If you’re rethinking how you share plans, gather feedback, and publish updates, that’s exactly what we built Released for. Roadmaps, portals, and changelogs that engage customers without creating a public backlog you can’t maintain.

Build what matters

With customer feedback in Jira

Build what matters

With customer feedback in Jira

Build what matters

With customer feedback in Jira