Real Work
LMS EdTech Product & Delivery Tridhya Tech

Three LMS Platforms,
Three Different Failure Modes

Across three separate LMS implementations, I worked across product and delivery — from requirement shaping and stakeholder alignment to UX, frontend execution, and go-to-market. The common lesson was not that every platform had the same UI problem. It was that each one started with a different wrong assumption about what the user actually needed to do next.

Type Real Work
Company Tridhya Tech
Scope 3 LMS implementations
Role Product & Delivery · UX · Frontend · Stakeholder Mgmt
Outcome All 3 shipped / reached GTM
Why this matters

This is the real delivery side of product work

Across these three LMS implementations, the challenge was not simply to design better screens. It was to understand the actual user workflow, identify where assumptions were breaking the product, and align teams around a more useful version of the problem before building.

Each project involved different clients, different users, and different kinds of ambiguity. What was consistent was the process: clarify the real job the product needs to do, frame the right problem, then bring product, design, and engineering into alignment around that framing.

These platforms shipped. They reached production and GTM. Some continued into a next phase. None of them were straightforward — which is what makes them worth documenting.

The repeated PM lesson

Each LMS started from the wrong question

The common thread was not bad design. It was that each product began with a different wrong assumption about the user, the workflow, or the real job the product needed to do.

Core observation

One platform treated learning like static recorded content — when users needed motivation, progress visibility, and a reason to come back. Another assumed manual administration was acceptable — when the real pain was operational overload accumulating invisibly every day. A third assumed an enterprise LMS could be built like a simpler course platform — when the actual need was multi-branch scale, complex data hierarchy, and layered permissions that no off-the-shelf model could handle.

01
Cybersecurity LMS

The real problem was learner motivation, onboarding, and platform speed — not the quality of course content.

02
University Admin LMS

The real problem was operational workflow burden for admins — not student-facing features or UI aesthetics.

03
Anantha Enterprise LMS

The real problem was translating a vague enterprise ambition into a phased, deliverable product — not cloning a known model.

Three projects

At a glance

Project 01 ·
Cybersecurity LMS
Learner-facing Israel Gamification

A dark-mode, gamified LMS with in-platform exams and milestone-based course unlocks. The product looked strong — but retention, onboarding, and platform speed were quietly killing adoption.

54 of ~60 enrolled students certified
Project 02 ·
University Admin LMS
Admin-heavy Australia Operations

A training management system for an Australian university context, primarily used by admin staff and trainers. The student portal was out of scope — the real pain was entirely internal.

Admin productivity & response time improved
Project 03 ·
Anantha Enterprise LMS
0-to-1 Multi-branch Enterprise

A concept-to-product enterprise LMS built to support 10–15 branches and their full downstream user hierarchy. Phase 1 was 16 months. Phase 2 was approved on the back of GTM success.

Phase 1 shipped · Phase 2 approved
Project 01 of 03
Cybersecurity LMS · Israel

A platform that looked ready — but wasn't being used

Dark Mode Gamification In-platform Exams Milestone Unlocks Admin / Teacher / Student

A dark-mode, gamified LMS with in-platform exams, milestone-based section unlocks, and three user roles. The product had the right features on paper — but learner retention, onboarding friction, and platform speed were undermining adoption.

What was failing

Students were uncomfortable with the built-in MCQ format and frustrated by limited file-size uploads. Teachers struggled with document upload flows. Admin approval processes were long and error-prone — teams were uploading incorrect databases. The platform felt closer to a recorded-course experience than a live learning environment, which was hurting both retention and new-user onboarding.

My role

Standalone APM. Led the development team, ran continuous stakeholder communication, gathered requirements, created story points, and managed the end-to-end delivery process from problem diagnosis through release.

Wrong assumption

A more expensive, feature-rich recorded-learning experience would remain compelling enough to retain users — without addressing authentication, speed, onboarding, or platform engagement at the foundation.

Corrected product question

What does a learner need at each stage to stay motivated and complete their certification path? The answer pointed to gamification depth, faster load times, simpler flows for teachers and admins, and role-appropriate dashboards — not more recorded content.

What changed

Deeper gamification mechanics. Technical shift from Java to Angular with AWS to resolve speed and optimization issues. Simplified UI across user roles. Dedicated dashboards for student, teacher, and admin. Streamlined enrollment, course creation, and content approval flows.

Platform context

The LMS was used by students, teachers, and admins — each with distinct workflows and friction points. The system also conducted exams natively and managed milestone-based section unlocks, which required careful pacing logic and fail-safe approval paths.

~60 students enrolled post-release
54 completed with certification
Previously: ~10–15 enrolled, 0 certified
Project 02 of 03
University Admin LMS · Australia

When admin workflows are the product — not the student portal

RTO / University Context Admin-heavy Super Admin Trainer Scheduling Operational Visibility

An administration-first LMS for an Australian university context. The primary users were super admins, trainers, and administrative staff. The student portal existed but was not in scope. The real pain was entirely invisible from the outside — and entirely operational.

What was failing

Admins had no visibility into trainer schedules. Assignment and course submission tracking was fragmented. A long information hierarchy created cognitive load. Enrollment, progress, and trainer tracking all required manual effort — with no notifications to signal what needed attention. The absence of search functionality made everything slower than it needed to be.

My role

APM. Identified the problem through stakeholder sessions, created the FRD, iterated the approach with key stakeholders, built a prototype, handled project estimation, formed the technical team, ran development, and shipped the final product.

Wrong assumption

The manual tracking workflow was acceptable because the team was used to it. Familiarity was being mistaken for fitness. In practice, the accumulated friction was quietly degrading productivity, response quality, and staff time every week.

Corrected product question

What does an admin need to see and act on — without hunting for it? The answer was a restructured information architecture, proactive notifications, consolidated dashboards, and search — all designed around reducing the time between "something happened" and "someone knows about it."

What changed

Restructured information hierarchy for admin and super admin roles. Notifications for student logins, course pushes, mark updates, and submission events. Simplified inner system navigation. Search functionality across students, trainers, and content. Consolidated dashboards for operational visibility.

Scope note

The student portal was deliberately kept out of scope. This was a product decision — not an oversight. The operational admin layer was the primary source of friction and the place where changes would deliver the most measurable impact for the client.

Faster admin visibility on updates
Reduced query resolution time
Improved staff productivity & response speed
Project 03 of 03
Anantha Enterprise LMS · Concept to Product

Turning a broad ambition into a phased enterprise product

0-to-1 Build Multi-branch 10–15 Institutes Phase 1 → Phase 2 BA + Technical PM

A concept-to-product enterprise LMS designed to support 10–15 branches and their full downstream user hierarchy from a single platform. The client had ambition but limited product clarity. The work was translating that ambition into something deliverable — without underestimating the complexity.

What was unclear at the start

The client had a broad idea — a single LMS that could support multiple branches and their respective institutes, trainers, and students. But they didn't have clarity on the data hierarchy, permission model, workflow dependencies, or what "phase 1" should actually contain. The ambiguity was the first product problem to solve.

My role

Started in a BA and Technical PM capacity. Owned requirement discovery, requirement documentation, technical architecture decisions, story points, QA test case review, sprint planning, budgeting, and stakeholder reporting throughout a 16-month Phase 1.

Wrong assumption

An enterprise LMS with multi-branch scope could be created like a simpler course platform — following familiar models like Udemy or standard SaaS LMS products. The actual need was far more complex in data structure, user hierarchy, and workflow design.

Corrected product question

What does a single admin need to control across 10–15 branches — without needing a separate system for each? The answer required building a permission-layered, branch-aware data model first — and then designing a user experience that kept that complexity invisible to end users while keeping it fully accessible to administrators.

How it was built

Phased build. Phase 1 covered the foundational data architecture, branch management, user hierarchy, core LMS workflows, and the admin interface. Phase 1 took approximately 16 months and went to GTM. The internal stakeholder response was strong — Phase 2 was approved and scoped for deeper logic and more complex functionality, while keeping execution simple for end users.

What made it hard

The combination of a vague brief, enterprise-scale data requirements, and multi-branch complexity meant that requirement clarity had to be built from scratch. Every assumption needed to be tested against the actual org structure before being committed to architecture or sprint planning.

Phase 1 shipped — GTM reached
Strong internal stakeholder response
Phase 2 approved & scoped
What I owned

Consistent responsibilities across all three projects

My role repeatedly sat at the intersection of requirements, UX, delivery, and coordination — translating ambiguity into something teams could execute against.

Problem clarification

Identifying the real product problem before jumping to solution mode. Stakeholder sessions, requirement gathering, and upstream framing.

FRD & documentation

Writing functional requirement documents and keeping them current through iteration and stakeholder review cycles.

UX & prototyping

Shaping user flows and building prototypes where needed to align teams on experience direction before development began.

Story points & planning

Breaking down requirements into development-ready work items, estimating effort, and managing sprint structure alongside engineering leads.

Team coordination

Forming technical teams where needed, coordinating across design, frontend, backend, and QA throughout delivery.

QA review

Reviewing QA test cases against functional requirements to ensure the right things were being tested before release.

Sprint planning

Running sprint planning sessions, managing sprint scope, and adjusting priorities based on delivery progress and stakeholder input.

Budgeting & reporting

Handling project budgets and producing progress reports for internal stakeholders — particularly relevant on the Anantha Enterprise build.

End-to-end delivery

Owning the full arc from requirement to release — ensuring nothing critical fell through the gap between functions.

How I worked

Cross-functional delivery, not isolated execution

The work was not isolated to one function. It required regular stakeholder communication, planning discipline, technical coordination, and keeping UX decisions tethered to delivery reality — especially when scope pressure or ambiguity created drift.

On the Cybersecurity LMS, I was the only person holding the product and delivery perspective — working directly with the engineering team and the client simultaneously. On the University Admin LMS, the challenge was keeping the scope tightly focused on the admin layer when external pressure pushed toward student-facing features. On the Anantha build, the challenge was phasing a genuinely complex enterprise product so that it could ship within a reasonable timeline without cutting the wrong things.

Stakeholder communication

Regular structured updates, expectation management, and requirement iteration with clients and internal leadership — across all three projects.

Technical coordination

Bridging product decisions with engineering realities — particularly on the Java-to-Angular migration and the Anantha multi-branch architecture.

Scope discipline

Holding the boundary between what needed to ship and what could wait — including deliberately keeping the student portal out of scope on the university admin project.

What I learned

Three things these projects sharpened

Product work usually goes wrong before visual design goes wrong. Across all three LMS implementations, the deeper issue was that the team — or the client — had not clearly defined the real user task, the real source of friction, or the real definition of success. That gap, left unaddressed, compounds quickly once development starts.

Familiarity is not the same as fitness. The admin team in the university project had lived with their manual workflow for long enough that it felt normal. It was still causing daily productivity loss. Helping a team see their own inefficiency — without making them feel criticised for it — is as much a product skill as any framework or tool.

Phasing is a product decision, not a compromise. On the Anantha enterprise build, choosing what went into Phase 1 — and defending that choice — was one of the most important things I did on the project. Shipping a well-scoped Phase 1 created the credibility and stakeholder confidence that made Phase 2 possible.

Related — but separate

Working across LMS delivery sharpened my understanding of where these platforms consistently struggle — and that later informed a separate concept exploration.

Concept Case Study · Separate work · Not part of these shipped projects
Enterprise LMS Policy & Support Assistant

A concept exploration of how AI could reduce repeated support burden in enterprise LMS environments — using permission-aware RAG retrieval, source citations, and safe escalation for Training Operations Managers. This is a structured product concept, not a feature of any of the three platforms documented here.

Explore Concept
Next step

Seen enough to want a conversation?

This page shows the real delivery side of my LMS experience. The related AI concept case study shows where I'm taking that domain knowledge next.

Explore LMS AI Concept ← All Case Studies Let's Talk