I spent a decade in learning and development, mostly in the LMS space. When I talk to people about moving into product management, they see it as a career pivot. A different industry, different skill set, starting from scratch. I see it as specialised training that nobody recognises.
Running an LMS — actually running one, configuring it for real users, supporting people while they’re trying to use it — teaches you things about product that you can’t get from a PM handbook. It’s not obvious until you step back, but the skills are deeply transferable.
The first thing an LMS teaches you is that your users have wildly different technical literacy, and you have to build for all of them simultaneously.
In a fitness app, you’re mostly building for people who wanted to open your app. They chose to download it. They’re motivated. They probably have at least baseline technical competence or they wouldn’t have gotten to signup.
In an LMS, you’re building for people whose manager told them to take a course, or whose compliance officer mandated it, or whose school assigned it. These people range from “I can use a computer fine” to “I’m not sure what a browser is, is that the same as Google?” You need the interface simple enough for the second group, powerful enough for the first group, and configurable enough that corporate admins can set it up correctly and break it in new and creative ways.
This teaches you empathy at scale. You stop designing for the person in your head and start designing for the actual distribution of users. You get really good at understanding that the person struggling with your product isn’t dumb; they’re using it in a context you didn’t predict. You learn to build in a way that gives people guardrails without being condescending.
I learned this while watching a training manager try to set up a single sign-on integration and accidentally lock herself out of the entire system. She wasn’t being careless; she was following what seemed like logical steps. I learned that when you build something that handles credentials and access, you have to think about all the ways a smart person can confidently do the wrong thing.
The second thing is requirements gathering at its finest. Or worst, depending on how you look at it.
When someone in corporate L&D says they need “better reporting,” what they actually need is fourteen different things. One person wants to see who hasn’t completed required training. Another wants to see completion rates by department. Another wants proof for auditors that training happened. Another wants to understand why someone abandoned a course so they can improve it.
You can’t build “better reporting.” You have to ask questions until you understand which kind of better. You have to sit with people and watch how they actually work. You have to realise that they’re solving a problem differently than you’d solve it, and you have to figure out whether they’re right.
I’ve seen someone spend fifteen minutes writing a report to Excel just so they could pivot it a different way. My response wasn’t “our reporting is terrible,” it was “let me understand why they need it that way, and what happens if we build something that skips the Excel step.” Usually the answer is “they need it pivot-able because they’re answering a question that changes based on the audience.”
This translated directly to fitness SaaS. When you’re talking to fitness coaches or studio owners, they’ll describe their workflow in ways that seem roundabout until you realise they’re actually solving multiple problems at once. A coach who wants “a report of who’s not showing up” isn’t just asking for attendance data. They’re asking for a list they can contact, understanding their own liability if someone gets hurt and they hadn’t noticed the person wasn’t there, thinking about how to have the conversation with someone who’s slipping away.
You don’t build features; you solve problems. And problems are usually more complex than the person asking understands until you talk to them properly.
The third thing is stakeholder management when nobody technically reports to each other.
An LMS sits in the middle of everyone. The training team wants certain capabilities. The IT department wants security and integration. The compliance people want audit trails. Senior management wants it to look impressive and prove ROI. HR is somewhere in the middle trying to keep everyone happy. And the people using it don’t really want to use it at all; they want the training to be done.
You can’t make everyone happy. So you learn to make the decision that serves the most important constraint and then explain it clearly enough that other people can understand the trade-off. You learn that sometimes the compliance requirement wins and the training team has to work around it. Sometimes user experience wins and IT has to accept a less elegant integration. You learn that transparency about the decision matters more than pretending everyone got what they wanted.
This is exactly the politics of any SaaS product. Sales wants unlimited flexibility. Engineering wants a clean data model. Finance wants predictability. Users want it to just work. You need to understand all of these constraints and make decisions that are defensible, even if nobody got exactly what they wanted.
The fourth thing is integration and ecosystem thinking. An LMS almost never lives alone. It connects to HR systems, email, authentication, sometimes classroom management systems, sometimes content repositories, sometimes certification platforms. You live with the consequence of integration decisions. If the sync is slow, people think the LMS is broken. If you break the API, clients’ entire workflows fall apart. If you don’t implement a feature because it would require an integration change, someone’s very real workflow becomes impossible.
You learn to think beyond your own product. You learn that the feature you’re building doesn’t exist in isolation; it exists in someone’s entire workday with seventeen other tools. You learn that sometimes the right decision is to build less, not more, because less means it integrates cleanly. You learn that your job isn’t to build a perfect LMS; it’s to be a good citizen in someone’s ecosystem.
Fitness tech is getting there too. People are integrating with Strava and Apple Health and nutrition apps and wearables. The product that understands it’s part of a larger context will win.
And finally, LMS work teaches you that users will tell you what they need if you actually listen, but they’ll tell you in their own language.
Someone will say “we need to hide this field” and what they mean is “we collect this information but we get it from another system, so asking users to enter it again is confusing.” Someone will say “the course completion date is wrong” and what they mean is “our compliance deadline doesn’t match your course completion date and we don’t have a way to mark someone as trained before the course is formally finished.”
You learn to translate. You learn that the problem isn’t what they said it was. You learn that the solution isn’t to build what they asked for, but to understand the underlying constraint and find a way to work with it.
Nobody lists “ten years in LMS configuration” on a PM job application and expects it to be taken seriously. It’s not a prestigious background. But honestly, it’s better training than most MBA programs I’ve seen. You’ve learned to empathise with real users in their actual context. You’ve learned requirements gathering from people who don’t know how to articulate what they need. You’ve learned stakeholder management without formal authority. You’ve learned that the solution is almost always more complex than the problem statement suggests, and that’s okay.
The transition to SaaS isn’t a career change. It’s a sideways move into a space where these skills actually matter more than they did in the last place. The L&D space is full of people solving hard problems for users in complex environments. If you’ve done that for ten years, you’re actually overqualified to move into product.