📢 Survey Results Are In: Here’s What We Heard — loud and clear

Yousef Abusamak

🌍 Overview

In May 2025, the Jira Extensibility team ran a global survey to better understand the challenges, needs, and priorities of partners and developers working with Jira Cloud. We collected 105 responses so far from Marketplace partners, app developers, and enterprise teams.

This report summarizes the key findings across four questions, along with visual charts and actionable insights to inform platform investments.

Please feel free to leave comments—we'd love to hear your thoughts, questions, or even your own experiences related to this topic. Your feedback not only helps us improve, but it also keeps the conversation going and helps others who might be exploring the same challenges or ideas. Let’s learn together!

---

🔍 Section 1: Top Challenges Faced by Partners

Question: What are the biggest challenges you face today when extending Jira?

Participants were asked to select all applicable challenges they encounter when working with Jira extensibility. The results reflect where the platform is currently falling short in developer experience, performance, and support.

🌐 Chart: Top 10 Challenges Reported

📈 Results (by number of mentions):

🧠 Insights:

• UI extensibility is the top blocker for building native-feeling apps.

• Widespread frustration with limited APIs, documentation, and support.

• Performance bottlenecks (rate limits, latency) are viewed as business-critical.

---

🚀 Section 2: Areas of Investment Requested

Question: What are the top 5 areas where Atlassian should invest to improve extensibility?

Participants ranked feature categories from most to least important. These reveal priority themes for platform evolution.

🌐 Chart: Requested Areas of Investment

Results (by number of mentions):

🧠 Insights:

• Investment needs cluster around UI, APIs, automation, and performance.

• A common ask is to treat extensibility as part of the feature launch lifecycle.

---

🎭 Section 3: Importance of Native Look & Feel

Question: How important is it that your app looks and feels like a native part of Jira?

This assesses how critical seamless UX integration is for Marketplace partners.

🌐 Chart: Importance of Native Look & Feel

📈 Results:

Response Option	Count	%
Critical – We want deeper integration so it feels native	45	48%
Important – We'd like more capabilities to blend into Jira’s experience	35	38%
Nice to have – but not blocking	10	11%
Not important	3	3%

🧠 Insights:

• 86% of respondents say native look and feel is either critical or important.

• Several call out the inability to render apps in new Jira UI areas as a key limitation.

---

🧰 Section 4: What Would Help Most?

Question: What specific improvements (APIs, UI, docs, etc.) would help?

Respondents shared specific pain points and suggestions.

🧠 Insights:

• Clear demand for API versioning, typings, and auto-generated docs

• Developers want to see Forge UI bridge improved and load times reduced

• Strong sentiment around lack of Forge parity with Connect and Data Center

• Many ask for notification and automation extensibility to be unlocked

---

🔍 Additional Insights from Free Text

• “Stop shipping features without extensibility. It makes us look bad to customers.”

• “Jira Cloud performance feels like a 56k modem at times.”

• “We need consistency and long-term stability across all APIs.”

• “Docs are vague and trial-and-error costs us weeks of effort.”

---

✅ Next Action Items Being Considered by the Jira Extensibility Team

1. Treat extensibility as a feature, not an afterthought.

2. Publicly commit to API-first development with governance.

3. Invest in performance, documentation, and real-time debug tooling.

4. Bridge the gap between Forge and Connect/DC parity.

5. Engage the ecosystem earlier via RFCs, betas, and co-design.

Nick Wade -Opus Guard-

Somehow I missed the opportunity to engage in this survey, so just adding on here. Let me start with this highlighted comment from free text: 

• “We need consistency and long-term stability across all APIs.”

I don't know if this is a true need (Atlassian has been very successful with limited consistency so far) but the Conway's Law is very real at Atlassian and it shows in many places across the Cloud products. It shows in inconsistent permissions models and choices, inconsistent UI and UX designs, (despite Jurgen's years of championing consistent design language and systems), strange differences in API patterns and versioning b/w products, performance challenges in totally different areas across products, Atlassian product and developer change communications, you-name-it there's probably a separate team with it's own goals building it and here we go with the unique approach again. And as a result it can be somewhat frustrating to deal with a feature design for more than one Cloud product, or a bug / oversight that actually affects multiple products but requires multiple entry points for discussion, enhancement planning, fixing, etc. If I were back at Atlassian working on the ecosystem again and I could wave a magic wand, it would be to introduce a program designed to effect some consistent goals for extensibility and the ecosystem, and use those to drive change at product levels in order to get there. This is none too small an ambition, would require senior leadership to sponsor it, and likely is not a priority, I'm aware; but there's my key comment.