Shft LMS
Led a team & built a university LMS as a first-time founder to solve inefficiencies in the LMS product market.
Overview
Shft LMS is a company I co-founded to rethink how university LMS (Learning Management System) actually serves lecturers & students.
The idea started when my co-founder and I kept hearing our network complaining about how bad their LMS is and how they don't really utilize the platform given by their institute to facilitate the lecturing process. These platforms were supposed to make teaching & learning accessible, but they're super bloated and designed to ridiculously shift your attention towards administrative work.
We saw a clear gap in the market: a user first LMS built to simplify academic life, not complicate it. That became our focus. What followed was a fast moving, problem-led product journey from insight to launch.
Here’s how we built it, broken into five key phases:
Overview
Shft LMS is a company I co-founded to rethink how university LMS (Learning Management System) actually serves lecturers & students.
The idea started when my co-founder and I kept hearing our network complaining about how bad their LMS is and how they don't really utilize the platform given by their institute to facilitate the lecturing process. These platforms were supposed to make teaching & learning accessible, but they're super bloated and designed to ridiculously shift your attention towards administrative work.
We saw a clear gap in the market: a user first LMS built to simplify academic life, not complicate it. That became our focus. What followed was a fast moving, problem-led product journey from insight to launch.
Here’s how we built it, broken into five key phases:
Phase 1
we interviewed users, audited platforms, and validated the real-world pain points.
Phase 2
we went deep into user behavior to guide what we actually built.
Phase 3
we shipped early versions to learn fast and adjust based on real feedback.
Phase 4
I focused on aligning design, development, and research into one shared direction.
Phase 5
we launched through pilot programs, and a national education event.
Phase 1
we interviewed users, audited platforms, and validated the real-world pain points.
Phase 2
we went deep into user behavior to guide what we actually built.
Phase 3
we shipped early versions to learn fast and adjust based on real feedback.
Phase 4
I focused on aligning design, development, and research into one shared direction.
Phase 5
we launched through pilot programs, and a national education event.
Phase 1 Spotting the gap
We started with conversations.. HUNDREDS of them. Students told us they felt like LMS platforms were just homework dumps. Lecturers said they avoided using theirs unless they were forced to. Some even ran parallel workflows on WhatsApp or Google Drive because it was just easier.
We also looked under the hood of some big-name LMS products, and what we found wasn’t surprising: feature bloat, poor UX, and zero flexibility to match different teaching styles. What was surprising was how normalized this had become. Most users just assumed that LMS has always been clunky.
The opportunity wasn’t to build another LMS with nicer buttons. It was to rebuild the core experience around actual academic needs, especially from a user-first mindset.
We started with conversations.. HUNDREDS of them. Students told us they felt like LMS platforms were just homework dumps. Lecturers said they avoided using theirs unless they were forced to. Some even ran parallel workflows on WhatsApp or Google Drive because it was just easier.
We also looked under the hood of some big-name LMS products, and what we found wasn’t surprising: feature bloat, poor UX, and zero flexibility to match different teaching styles. What was surprising was how normalized this had become. Most users just assumed that LMS has always been clunky.
The opportunity wasn’t to build another LMS with nicer buttons. It was to rebuild the core experience around actual academic needs, especially from a user-first mindset.
Phase 2 Solving real problems, not ticking feature boxes
A common trap in EdTech is building for decision-makers (like admin or IT teams), not end-users. We actively avoided that. We kept going back to one question: What do lecturers and students actually need on a day-to-day basis?
We mapped out a week in the life of both groups on three pillar: what they’re trying to get done, what annoys them, where things break.
..and we realized most pain points stemmed from friction of too many steps to complete a single journey or having to jump between platforms. So instead of trying to be everything, we focused on being useful. Every feature had to solve a job and not just fill a roadmap.
A common trap in EdTech is building for decision-makers (like admin or IT teams), not end-users. We actively avoided that. We kept going back to one question: What do lecturers and students actually need on a day-to-day basis?
We mapped out a week in the life of both groups on three pillar: what they’re trying to get done, what annoys them, where things break.
..and we realized most pain points stemmed from friction of too many steps to complete a single journey or having to jump between platforms. So instead of trying to be everything, we focused on being useful. Every feature had to solve a job and not just fill a roadmap.
A common trap in EdTech is building for decision-makers (like admin or IT teams), not end-users. We actively avoided that. We kept going back to one question: What do lecturers and students actually need on a day-to-day basis?
We mapped out a week in the life of both groups on three pillar: what they’re trying to get done, what annoys them, where things break.
..and we realized most pain points stemmed from friction of too many steps to complete a single journey or having to jump between platforms. So instead of trying to be everything, we focused on being useful. Every feature had to solve a job and not just fill a roadmap.
Phase 3 Prototype fast, test early, repeat
Once we had a lean problem set, we moved fast. I led the initial wireframing in Figma, and within 2 weeks we had a working prototype. Funnily, as someone who loves designing, lowering the perfectionist side of my creative brain was a super pet peeve because the prototype had to be done in a short timeframe and you had no time for polishing.
Once we had a lean problem set, we moved fast. I led the initial wireframing in Figma, and within 2 weeks we had a working prototype. Funnily, as someone who loves designing, lowering the perfectionist side of my creative brain was a super pet peeve because the prototype had to be done in a short timeframe and you had no time for polishing.
We ran usability tests with real lecturers from our pilot university partner. We gave them simple tasks e.g. upload your week 3 lecture notes, mark 3 students as absent and just watched where they struggled.
Early feedback led to some big pivots like rethinking how course pages were structured or making attendance fully mobile-friendly because half the lecturers were doing it right before class.
That loop of prototype > test > refine became our rhythm. And instead of pitching it as “LMS 2.0”, we just framed it as: Would this make your teaching week easier? I couldn't emphasized enough how the practice of language shift helped us stay grounded & got higher quality feedback from participants.
We ran usability tests with real lecturers from our pilot university partner. We gave them simple tasks e.g. upload your week 3 lecture notes, mark 3 students as absent and just watched where they struggled.
Early feedback led to some big pivots like rethinking how course pages were structured or making attendance fully mobile-friendly because half the lecturers were doing it right before class.
That loop of prototype > test > refine became our rhythm. And instead of pitching it as “LMS 2.0”, we just framed it as: Would this make your teaching week easier? I couldn't emphasized enough how the practice of language shift helped us stay grounded & got higher quality feedback from participants.
Phase 4 Leading the product as a PM
Before anything, I understood the success of the whatever product we build would depend on the team - not only their abilities but also their common dedication to a single, uniting goal. The value of leadership is impossible to overestimate in a startup environment, where resources are few, uncertainty is constant, and stakes are high.
I spearheaded to put together our group from the job posting to learning how to contribute their EPF as an employer. Every hire was deliberate, motivated by cultural fit and a conviction in our purpose rather than only technical ability.
Before anything, I understood the success of the whatever product we build would depend on the team - not only their abilities but also their common dedication to a single, uniting goal. The value of leadership is impossible to overestimate in a startup environment, where resources are few, uncertainty is constant, and stakes are high.
I spearheaded to put together our group from the job posting to learning how to contribute their EPF as an employer. Every hire was deliberate, motivated by cultural fit and a conviction in our purpose rather than only technical ability.
A startup team works best when everyone’s on the same page, and as the product manager, my role was to keep things clear and coordinated. Without that, even the most talented team can end up pulling in different directions.
The first thing I focused on was alignment. During onboarding, I didn’t just hand over documents filled with technical specs or feature lists. Instead, I shared real struggles that were documented in prior user interviews to helped ground our work in the problems we were actually trying to solve.
Next came prioritization. In a startup, ideas are endless, and it’s easy to get caught up chasing every exciting suggestion. To avoid this, we held weekly planning sessions. We’d review our goals, sort out what mattered most, and set aside anything that wasn’t solving a core issue.
Lastly, I acted as a connector. Developers think in terms of functionality, designers in visuals, and researchers in insights. My job was to make sure those perspectives worked together. For example, when our UX researcher pointed out a pain point in the onboarding flow, I worked with our designer to simplify the layout and made sure our developers understood how to build it without missing the details that mattered.
A startup team works best when everyone’s on the same page, and as the product manager, my role was to keep things clear and coordinated. Without that, even the most talented team can end up pulling in different directions.
The first thing I focused on was alignment. During onboarding, I didn’t just hand over documents filled with technical specs or feature lists. Instead, I shared real struggles that were documented in prior user interviews to helped ground our work in the problems we were actually trying to solve.
Next came prioritization. In a startup, ideas are endless, and it’s easy to get caught up chasing every exciting suggestion. To avoid this, we full throttled on Scrum ceremonies to review our goals, sort out what mattered most, and set aside anything that wasn’t solving a core issue.
Lastly, I acted as a connector. Developers think in terms of functionality, designers in visuals, and researchers in insights. My job was to make sure those perspectives worked together. For example, when our UX researcher pointed out a pain point in the onboarding flow, I worked with our designer to simplify the layout and made sure our developers understood how to build it without missing the details that mattered.
At the end of the day, my role wasn’t about overseeing every task - it was about making sure everyone was focused, aligned, and building something meaningful together … remotely.
Phase 5 GTM with community & credibility
Shipping a product is equal parts thrilling and terrifying. After months of deep research, design, and development, it’s easy to think the toughest work is behind you. But in reality, building the product is just one part of the journey. Getting it adopted, especially within a university ecosystem, is a whole different challenge.
From mentor advice, we knew we couldn’t treat launch as a one-off event. So instead of going wide immediately, we rolled out slowly but surely.
Our first step was running full-semester pilot programs with two mid-sized universities. These weren’t controlled demos or simulations. They were real deployments where lecturers taught actual classes using our LMS, and students submitted their coursework through it. We got direct insight into how our platform held up under real academic pressure. More importantly, we got feedback that wasn’t sugarcoated.
To make sure the pilots had a fighting chance, we identified early adopters within each university. These were lecturers already frustrated with their current tools, and who were open to trying something better. We brought them in early, listened to what mattered to them, and let their experience shape our positioning. Once they saw value, their support helped us open doors to other departments. Their endorsement made our presence feel less like a vendor and more like a solution that came from within.
We also learned the trap of treating every university the same. One campus wanted us to prioritize training and onboarding for academic staff. Another was more concerned with integrating their existing systems. So we took a flexible approach. We built out custom walkthroughs, integrated legacy data, and adjusted our onboarding playbook based on each institution’s workflow and maturity level.
Shipping a product is equal parts thrilling and terrifying. After months of deep research, design, and development, it’s easy to think the toughest work is behind you. But in reality, building the product is just one part of the journey. Getting it adopted, especially within a university ecosystem, is a whole different challenge.
From mentor advice, we knew we couldn’t treat launch as a one-off event. So instead of going wide immediately, we rolled out slowly but surely.
Our first step was running full-semester pilot programs with two mid-sized universities. These weren’t controlled demos or simulations. They were real deployments where lecturers taught actual classes using our LMS, and students submitted their coursework through it. We got direct insight into how our platform held up under real academic pressure. More importantly, we got feedback that wasn’t sugarcoated.
To make sure the pilots had a fighting chance, we identified early adopters within each university. These were lecturers already frustrated with their current tools, and who were open to trying something better. We brought them in early, listened to what mattered to them, and let their experience shape our positioning. Once they saw value, their support helped us open doors to other departments. Their endorsement made our presence feel less like a vendor and more like a solution that came from within.
We also learned the trap of treating every university the same. One campus wanted us to prioritize training and onboarding for academic staff. Another was more concerned with integrating their existing systems. So we took a flexible approach. We built out custom walkthroughs, integrated legacy data, and adjusted our onboarding playbook based on each institution’s workflow and maturity level.
Beyond the pilots, we knew we had to build credibility at the national level. That’s why we created SEM2023: Shifting Education in Malaysia, a conference that brought together educators, consultants, and policy voices to talk openly about what Malaysia's higher education actually needed.
Over 200 people attended, including stakeholders from government, public institutions, and private universities. The conversations were meaningful and helped reframe our LMS as part of a broader movement to improve learning experiences in Malaysia. Several sales discussions began from that one event, simply because we showed up in a way that felt mission-led instead of product-led.
Beyond the pilots, we knew we had to build credibility at the national level. That’s why we created SEM2023: Shifting Education in Malaysia, a conference that brought together educators, consultants, and policy voices to talk openly about what Malaysia's higher education actually needed.
Over 200 people attended, including stakeholders from government, public institutions, and private universities. The conversations were meaningful and helped reframe our LMS as part of a broader movement to improve learning experiences in Malaysia. Several sales discussions began from that one event, simply because we showed up in a way that felt mission-led instead of product-led.
Conclusion
Looking back, it’s amazing to see how a simple observation turned into something so impactful. What started as a frustration with how education tools were being used has now grown into a product that’s genuinely trying to improve the day-to-day experience for educators, students, and administrators.
There was no smooth part of the path we took. It's not always easy to build a product from scratch, especially if you want to fix experience-seated problems. There were times when we felt like we had to start over, failures that made us question our decisions, and days when making progress felt, pointless..
That said, will I run another startup? Ask me on a day when everything works perfectly, and I might say yes. Ask me when the server crashes at 3AM or the anxiety of the looking at the company's cash burn, and I’ll pretend I didn’t hear the question. But despite the chaos, I wouldn’t trade this journey for anything.
Looking back, it’s amazing to see how a simple observation turned into something so impactful. What started as a frustration with how education tools were being used has now grown into a product that’s genuinely trying to improve the day-to-day experience for educators, students, and administrators.
There was no smooth part of the path we took. It's not always easy to build a product from scratch, especially if you want to fix experience-seated problems. There were times when we felt like we had to start over, failures that made us question our decisions, and days when making progress felt, pointless..
That said, will I run another startup? Ask me on a day when everything works perfectly, and I might say yes. Ask me when the server crashes at 3AM or the anxiety of the looking at the company's cash burn, and I’ll pretend I didn’t hear the question. But despite the chaos, I wouldn’t trade this journey for anything.
wafiuddin.fy@gmail.com
wafiuddin.fy@gmail.com