Atlassian

Learn for Jira: In-App Training for Atlassian

Built an in-app Jira training product at Adaptavist that replaced $6.5M in classroom costs, scaling from 20,000 to 140,000 users.

Screenshot of the Learn for Jira documentation home.

I was leading a pilot project for a consulting client at Adaptavist – 20,000 Jira and Confluence users to start, scaling to 140,000. The only training Atlassian offered was seated classroom, limited to 12 people per session even when delivered virtually. The quote to train just the pilot group of 20,000 was $6.5 million. I proposed building e-learning instead – something Atlassian didn't offer – and delivering it in-app through Jira using a plug-in. That became Learn for Jira, a product that scaled to any number of users at a fraction of the cost. Then, six years later, I recommended killing it. This is the full story.

The $6.5 Million Problem That Sparked a Product

In 2016, I was working at Adaptavist and leading a pilot project for a consulting client. The plan was to start with 20,000 Jira and Confluence users and scale up to 140,000 across the organization. Not just "here's where the login button is" – real, task-level training so people could create issues, manage boards, run reports, and do their jobs without flooding the help desk with basic questions.

At the time, Atlassian's only training option was seated classroom – and even when delivered virtually, sessions were limited to 12 people. That simply didn't scale. The quote from Atlassian to train just the pilot group of 20,000 was $6.5 million. This was a multi-billion dollar company – budget wasn't really the issue. The sticking point was that the Atlassian licenses were only $3 million, so it seemed insane that Atlassian would charge more than twice the license cost just for training. Very few organizations would accept that math.

I proposed an alternative: build e-learning, something Atlassian didn't offer at all, and deliver it in-app through Jira itself using a plug-in. Instead of pulling people out of their work and into a classroom, the training would meet them where they already were. That proposal became Learn for Jira.

This wasn't a one-off problem either. Every enterprise Jira deployment faces the same training gap. The tool is powerful but not intuitive for new users. And the cost of untrained users isn't just help desk tickets – it's bad data, misused workflows, abandoned boards, and teams reverting to spreadsheets because they never learned the system they were supposed to adopt.

How In-App Training Inside Jira Actually Worked

The core insight was simple: train people where they work. Don't pull them out of Jira and into a classroom or an LMS. Put the training inside Jira itself.

Learn for Jira was an Atlassian Marketplace app that embedded interactive training content directly into the Jira interface. When a user needed to learn how to create a project, they didn't watch a video about it or read documentation about it. They followed guided steps inside their actual Jira instance, with contextual tips appearing right where the relevant buttons and menus lived.

This approach solved several problems at once. There was no scheduling – users trained on their own time. There was no context switching – the training happened in the actual tool. And the training stayed current because it was tied to the live interface, not screenshots that went stale with every product update.

The content covered the core tasks that new Jira users struggle with: navigating the interface, creating and managing issues, working with boards, understanding workflows, running searches and filters, and generating reports. Each module was designed around the real tasks that job task analysis had shown to be most critical for typical Jira users – a direct application of the methodology I'd used building the certification program.

Wearing Every Hat: Product Management to Release Management

In the early days of Learn for Jira, I was the product. Not just product manager – I handled product management, content creation, QA, release management, and customer support. I had to learn how to read code a little because I was doing QA and watching builds kick off, running tests, and making sure things were working. I was using SonarQube for code quality. I was the one who actually ran the release and put new versions of the plugin on the Atlassian Marketplace. I was also handling sales calls, marketing, copywriting, and speaking at conferences about it.

By working so closely with the engineers and doing so much of the operational work, it made me really conversant in cloud architecture and building these types of products. That benefited me a lot later in my career.

This wasn't a glamorous setup, but it had a real advantage: zero distance between customer feedback and product decisions. I didn't need to schedule a meeting to relay what customers were saying. I was hearing it directly, every day, and could act on it immediately.

Over time, the product justified dedicated resources. But that early period of doing everything taught me things about the product that I wouldn't have learned any other way. I understood not just what the product did but how customers actually used it, where they got stuck, what they wished it could do, and what they didn't care about at all despite our assumptions.

Growing a Loyal Customer Base on the Atlassian Marketplace

Learn for Jira found its audience. Enterprise customers who faced the same training-at-scale challenge that sparked the product in the first place became loyal users. The Atlassian Marketplace reviews were strong. Customers renewed because the product solved a real problem that didn't have many alternatives.

The growth pattern was organic and steady rather than explosive. Each new Jira deployment at a large organization created potential new customers, and word of mouth within the Atlassian partner ecosystem drove awareness. We didn't need aggressive marketing because the problem the product solved was universal and the existing solutions – classroom training or "figure it out yourself" – were obviously inadequate.

Customer retention was high because training is an ongoing need, not a one-time purchase. New employees join. Jira gets updated. Teams adopt new features. The training content needed to evolve with the product, which created a natural renewal cycle.

When Atlassian Invested $1 Million in Competing

When I first started working on Learn for Jira, I identified eight different risks to the business. In 2021, all eight of them happened.

The most significant: Atlassian completely overhauled their in-house training team and systems, investing around $1 million into rebuilding, improving, and expanding them. They massively grew their instructional design team and sped up the rate of developing training. Atlassian went from updating their training courses every two to three years to about five weeks. They were only accelerating, and it was getting to the point where they were releasing new training on the day of a product release – something they were uniquely able to do because they knew what was coming out.

Part of what gave rise to Learn for Jira was that Atlassian had been underinvesting in training. There was a gap we could fill. We had pioneered a training development process that was really fast – we could fully update a training course in around eight to twelve weeks using a methodology called LAMA (Looks A Lot like Agile Management), often used for instructional design. We were also developing e-learning with interesting visuals and animations that led to a 60-70% completion rate, far above the industry standard of about 8%.

But when Atlassian committed that kind of investment, Adaptavist – as large as it was – simply couldn't compete with a billion-dollar company throwing resources at the training space. We got Sherlocked.

The Hard Decision to Sunset a Product I'd Built

We were close to completing the Cloud version of Learn for Jira. Months of work had gone into it. The product had loyal customers, revenue, and a market position. Every instinct says to keep going.

I recommended retiring the product.

This was one of the hardest professional decisions I've made, and I think it was the right one. Here's the reasoning.

First, competing with Atlassian on their own platform is a losing proposition over time. They control the APIs, the interface, the Marketplace rankings, and the customer relationship. A third-party training app will always be at a structural disadvantage against native functionality.

Second, the Cloud version was almost ready to release but not quite done. The issue wasn't the remaining development work – it was that even after launching, we'd be competing against a company that was updating training faster than we could keep up. Investing more resources into a product with a shrinking competitive window didn't make financial sense for Adaptavist.

Third – and this is the part that doesn't show up in spreadsheets – I cared about the customers. Recommending a product I knew would lose ground over the next few years felt dishonest. Better to give customers time to transition than to sell them something with a limited future.

Prioritizing company health over sunk costs is easy to say and genuinely painful to do. I'd spent years building this product. I knew every feature, every customer complaint, every workaround. Walking away from that work required separating my emotional investment from the strategic reality.

What Building and Sunsetting a Product Taught Me About Product Lifecycle

Learn for Jira's full arc – from a client problem to a Marketplace product to a deliberate sunset – taught me more about product management than any success story could.

Validation matters more than vision. The product worked because it started with a real, expensive, quantifiable problem. Not a theory about what users might want. A client staring at a $6.5 million quote. That foundation kept the product grounded throughout its life.

Platform dependency is a strategic risk, not just a technical one. Building on the Atlassian Marketplace gave us distribution and credibility. It also meant our product's future depended on decisions we didn't control. This tradeoff is inherent in any platform ecosystem, and there's no way to eliminate it. You can only manage it by staying aware and planning for multiple scenarios.

Knowing when to stop is a product management skill. The industry celebrates launches and growth. Nobody writes blog posts about the time they recommended killing their own product. But the ability to assess a product's trajectory honestly and make the hard call is as important as the ability to build and launch.

Sunk cost thinking is the enemy of good decisions. The Cloud version was nearly done. We'd invested significant time and money. None of that spending could be recovered by continuing. The only relevant question was whether future investment would generate returns, and the honest answer was that it probably wouldn't.

In-App Training as a Product Category: Where It's Headed

The fundamental insight behind Learn for Jira – that training belongs inside the tool, not in a separate system – has become mainstream. Digital adoption platforms like WalkMe and Pendo have built entire categories around it. Atlassian's own investment in native guidance validated the approach.

What I'd do differently today involves the content model. The original product had relatively static training content that needed manual updates. Modern in-app training can be more dynamic, adapting to user behavior and surfacing guidance based on what someone is actually struggling with rather than following a predetermined curriculum.

The market proved the concept. The product's eventual sunset wasn't a failure of the idea – it was the natural lifecycle of a Marketplace app that successfully identified a need the platform owner eventually chose to fill themselves.

FAQ

What was Learn for Jira and why was it built?

Learn for Jira was an Atlassian Marketplace app that delivered interactive training directly inside the Jira interface. It was built after a consulting client's pilot project – 20,000 Jira and Confluence users scaling to 140,000 – received a $6.5 million quote from Atlassian for seated classroom training (limited to 12 people per session, even virtually). I proposed building e-learning delivered in-app through a Jira plug-in as an alternative. The result was self-paced training that scaled to any number of users at a fraction of the cost.

Why was Learn for Jira sunset instead of continuing development?

In 2021, Atlassian invested in building native in-app guidance and training capabilities directly into Jira. Competing with the platform owner on their own platform is a structurally disadvantaged position. Rather than invest further in a product with a shrinking competitive window, I recommended retiring Learn for Jira to prioritize company health and give customers time to transition.

What's the difference between in-app training and traditional software training?

Traditional software training pulls users out of their work environment into classrooms, LMS platforms, or video courses. In-app training delivers instruction directly inside the application while the user is working. This eliminates context switching, scales without scheduling constraints, and stays current with the live interface rather than relying on screenshots that go stale.

Related Case Studies

Dealing with something similar?

Through Fieldway, I help product and engineering teams figure out what's broken – whether that's a delivery problem or a strategy problem – and build a concrete plan to fix it.

Learn more at fieldway.org