Or rather, should Atlassian shut down JAC (as we know it)?
Hear me out...
For more than two decades, Atlassian’s public Jira instance (JAC) has been the place to log requests, report bugs, and follow along publicly.
Early on, it worked: an open channel to talk to customers, gather feedback, and show progress. Over time, JAC grew 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.
The intention was right. The constraint is capacity.
“Be open” is easy to say. “Put everything out in the open” doesn’t scale. A system that implicitly promises updates on every request breaks as soon as you outgrow it
If I were at Atlassian today, I’d shut down the public issue tracker. Here’s why... and what I’d do instead.
What it looked like day to day
I worked across various product teams at Atlassian for 15 years. In the early days of Confluence, JAC worked great. Same on Stash. But as the number of suggestions grew, we struggled to keep pace.
At some point we had a goal to update the top 50 requests every quarter. Sounds reasonable in theory. But it was still very time consuming.
At one point, we had a dedicated PM spent half their week in JAC, often just to say there wasn’t anything new. Customers didn't love it, and that’s time better spent on the actual work in play.
“Why hasn’t there been an update?” – lots of customers
The honest answer: the math doesn’t work. Even if you only update the top 10% of 10,000 requests (1,000) once a quarter, and each update takes 15 minutes, that’s 15,000 minutes—250 hours. At 8-hour days, that’s ~31 person-days every quarter. For status updates.
How to openly communicate at scale
Open communication at scale needs a tighter public surface.
A public idea board works when you can stay on top of it. At scale, it breaks. You can still be open. Just be open about the work you intend to consider or build.
- Time‑boxed visibility
Publish only the requests and ideas you intend to consider or build in the next 6–12 months. Capture everything else, but don’t list it publicly. The public surface should reflect the real planning horizon, not an infinite queue.
- Engagement where it matters
For published items, invite feedback, share trade‑offs, and provide progress updates. Keep threads alive with context: the problem you’re solving, constraints you’re navigating, and where you’re heading next.
- Team‑originated ideas
Don’t just mirror inbound requests. Share the team’s exploration and concepts early—before code. Ask for feedback on problem framing and approach, not just a running feature wishlist.
- Replace voting with Wishlists
Instead of public voting, use a “Wishlist” that limits the number of wishes per customer. Prioritization beats groupthink. You’ll get a sharper signal without turning feedback into a popularity contest.
- Capture feedback (all of it)
Feedback is a gift. Capture as much as you can. Ensure the product team responds to every single note—even if it’s just “Thank you!” Acknowledge the input; don’t promise action where none exists.
- Track demand internally
For ideas not publicly listed, connect inbound feedback to internal ideas and track demand. Keep the accounting inside; keep the conversation outside focused on what’s actually in play.
What this changes for customers and teams
- Customers see fewer public items, but get better context and more frequent updates on work that’s truly 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 a mountain of +1s.
Open company
“Open company” doesn’t mean “publish everything”
It means being clear about what’s planned, why it’s planned, and inviting feedback on those plans. Keep the conversation focused on the work that’s actually happening.
Fewer public ideas. More customer engagement. Better outcomes.
What do you think, does JAC need a revamp? Let me know in the comments 👇
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.
Take a look at our public roadmap or try Released on the Atlassian marketplace.
