← All projects
Live

Atlassian Learning

How I led a team of 10 to ship a customer learning platform, 0-to-1, in six months, by building instead of buying.

Visit the platform
Role
Product owner & platform lead
The problem

Why build at all

Atlassian needed a new customer-facing learning platform: a place to scale product education to millions of users and partners. The company had already cycled through three LMSs, and the market itself was shifting underneath us, away from instructor-led training as the core offering and toward free, self-paced microlearning. Salesforce Trailhead had proven the model: tons of learning, deep engagement, badges and certifications all the way down.

The economics were the real forcing function. LMS pricing balloons at scale. Even at $3 per user per year, reaching millions means millions in platform fees alone, before the overhead of running the content model, forcing in features like badging and points, and stitching together integrations that were never designed to live in one ecosystem. We had just merged with Community, and the ambition was a single system of points and badges with a unified UX. Trailhead was the model to learn from. We took off.

Build vs buy

The build-vs-buy call

We evaluated several vendors, including the headless CMS leaders of the time, then made the call to build, because roughly 80% of the infrastructure already existed inside Atlassian. We leaned on our internal Content Platform: a front-end monorepo wired into the same front end as Jira, Confluence, and our marketing sites, built on Contentful, with native localization, load balancing, and a stack that made the infrastructure layer almost free. Going custom also let us integrate directly with Community's existing Kudos gamification system, powered by Bunchball.

The sharpest decision was splitting the problem. We would build the free, self-paced platform ourselves, but buy the instructor-led, commerce-driven LMS, because that side exchanged money and carried real complexity. We extended the LMS one more year and shrank its license count to only paying customers, so free learners no longer burned a paid seat whether or not they ever returned. That single move opened the funnel for free content at the top while keeping the paid business intact.

Build in-house vs. headless LMS
Evaluated layer by layer
Course UI & brand
Custom front end on our design system
Themeable course player
Authoring & content
Headless CMS we already ran
A new authoring stack to adopt
Gamification & badges
Reused the community's points engine
Limited native support
Learner transcript
One record across every touchpoint
Siloed per course
Commerce & instructor-led
Heavy custom build
Native carts, seats, scheduling
The split that fell out of it: build the free, self-paced platform where we already owned the pieces; buy the commerce-driven, instructor-led side where the capability was commodity. One front end over both.
The solution

Building the MVP

I led a team of ten engineers, distributed across Ukraine and Poland, to architect and ship the app. Without hallway conversations, the specs and architecture decisions had to be unambiguous up front, which made me a sharper product owner. We designed the architecture together: diagramming the system, walking through the operational and monetary cost of each design, and pressure-testing the tradeoffs. I didn't write the microservice internals, but I drove the simplification, poking holes in the details so we weren't over- or under-engineering the pieces that mattered.

The durability came from the content layer. Moving onto a headless CMS let us build the metadata, governance, and content foundations so the catalog could scale and stay a single source of truth as the product evolved. Just as important, it changed what learning could be: we broke multi-hour courses into 20-to-30-minute microlearning and made it interactive and natively responsive with React components. Where Trailhead read like technical documentation, ours activated users inside the product, and the same content could be embedded directly into Jira and Confluence.

That investment is also what made AI a real story rather than a bolt-on. Because we left heavy SCORM packages behind, content changes could ship immediately, or wait only on human approval, instead of a full rebuild in another platform. That opens the door to agentic operations: recommending content updates as features change, keeping the catalog aligned with the product automatically.

The result

Outcomes

We shipped a customer-facing product from the ground up in about six months: startup pace inside an enterprise the size of Atlassian. Because it ran on the same native infrastructure as the products, the economies of scale were dramatic. For the same headcount and platform investment that an LMS would spend serving roughly 750,000 users a year, we could reach effectively unlimited learners, without the UX, integration, and transformation tradeoffs. We owned the code, the system, and the content end to end. It launched as a global learning platform and catalog now used by millions.

The platform

How it’s built

The platform was deliberately composed from systems Atlassian already ran, which is what made a six-month 0-to-1 possible. Roughly 80% of the infrastructure existed before we started: it rode the same headless Contentful content platform and React monorepo that sit behind Jira, Confluence, and the marketing sites, so localization, load balancing, and the design system all came for free.

The one thing we refused to inherit was the LMS content model. Courses are native, responsive React components broken into 20 to 30 minute units rather than SCORM packages, so lessons ship instantly and embed directly inside the products. And gamification reused the community's existing Kudos points and badges (powered by Bunchball) instead of bolting on an LMS equivalent, giving learners a single identity across learning and community.

The stack
Contentful
Headless CMS at the core of Atlassian's Content Platform; the catalog's source of truth
React monorepo
Shared front end with Jira/Confluence; design system, localization, load balancing
Kudos (Bunchball)
Reused Community's points, badges, and credentialing, powered by Bunchball
How the platform composes
ContentApp & logicGamificationCommunity
contentinteractions→ missionbadgesprogresslearner recordHeadless CMSLessonsCoursesQuizzesBadge artFront-end appone learner UICourse-logic backendrules · progressLearner transcriptevery touchpointGamification enginepoints · badge logicCommunityprofile · rep
Badge art lives in the CMS; badge logicand points run in the gamification engine — the two stay in sync. One front end, one backend, reusing the community’s existing reputation system.