LMS features: must-have vs nice-to-have

Count the must-have features in the last LMS guide you read. If the number was somewhere around twenty, that guide told you almost nothing.

The problem isn't that those lists are wrong. Most of the features on them are useful to someone. The problem is that a list where everything is essential has quietly handed the hardest part of the decision back to you: working out which of those twenty things matter for what you're actually trying to do.

And if your own must-have list has grown every time you spoke to a vendor, that isn't a lack of discipline on your part. That's the process working exactly as designed.

So let's do the hard part instead. Below is a way to get from "here is everything an LMS can do" to a short, ranked list you can defend in a meeting, plus an honest look at the features that impress in a demo and then sit untouched for the rest of the contract.

Why most LMS feature lists don't help you decide

Feature lists are easy to write and easy to sell. A vendor with forty features has an obvious incentive to tell you that all forty are important, because that's the story where they win. A comparison site has the same incentive, for different reasons: the longer the checklist, the more there is to compare.

Neither format tells you what matters most, and that ranking is the whole job. Two organisations can buy the same learning platform, use completely different halves of it, and both be right.

There's also a cost to breadth that rarely makes it into the list. Every extra feature is something to configure, something to explain to administrators, something that adds a step to a screen someone uses every week. Feature-rich and easy to run are not the same thing, and most buyer regret comes from that gap.

Start with the outcome, not the feature

The fastest way to cut a list of twenty down to a list of six is to stop asking "what can this platform do" and start asking "what has to be true twelve months from now".

Most organisations we work with are trying to achieve one or two of these four things. Find yours, and the feature question mostly answers itself.

Onboarding new employees

You're trying to shorten the time between someone signing a contract and someone being useful and comfortable in their role. That makes timing and automation the core of your requirement: content that reaches people before day one, sequences that trigger on a start date rather than on an administrator remembering, and enough visibility for managers to see where their new colleague has got to.

What matters much less here: deep skills frameworks, complex catalogue browsing, anything that assumes the participant will go looking for learning on their own. New starters don't go looking for learning. They do what they're given.

Compliance training

Here the question is what you can prove, to an auditor, a regulator, a client or your own board. Evidence is the requirement: certificates with an expiry date, automatic re-enrolment when that date approaches, reminders that escalate, and reporting that answers "who is missing what, right now" without an export and a spreadsheet.

The trap in compliance is buying for completion rates when you actually need defensibility. Any platform can show you a healthy-looking completion figure. Fewer can show you, in one view, which named people in which locations are out of date on which requirement.

Customer and partner training

You're training people who don't work for you. That changes almost everything: participants live outside your HR system, they arrive through self-registration or an invitation rather than an employee record, and you often need several customer organisations to coexist on the same platform without seeing each other.

This use case has the sharpest hidden requirement of the four. If external participants are in scope, permission structures and multi-organisation separation stop being nice-to-have and become the thing that decides whether the platform works at all.

Competence development

You're building capability over a longer horizon, which is the one use case where the softer features earn their place. Learning paths, skills frameworks and self-directed discovery matter when the goal is development rather than completion.

It's also the use case where organisations most often overbuy. A skills taxonomy is a serious commitment to maintain. If nobody owns it after launch, it becomes an expensive empty structure.

The core: features every organisation needs

Whatever your outcome, a small set of capabilities is doing the actual work. If a platform is weak here, no amount of breadth elsewhere rescues it.

• Course creation and content import. You need to be able to build something reasonable without a production team, and to bring in what you already own. Ask specifically which formats can be imported and exported, and ask for a live demonstration, not just a yes. Ask about SCORM, xAPI and cmi5 by name.
• Enrolment and assignment. Individually, by group, and by rule. Rule-based assignment is the difference between a platform that runs itself and a platform that needs someone to remember things every Monday morning.
• Participants, roles and permissions. Who can see whom, who can administer what, and how far down that can be delegated. This looks boring in a demo and turns out to be the feature that decides how much administrative load lands on one person.
• Notifications and reminders. Unglamorous, and responsible for a large share of your eventual completion rate.
• Reporting you can act on. The specific answer to a specific question, and the ability to get it without asking support. A dashboard on its own doesn't count.
• Language support. If you operate across borders, language support is core, and it covers two separate things: the interface participants see, and the content itself. Check both.
• Accessibility. Increasingly a formal procurement requirement, so ask about it directly. The relevant standard to ask about is WCAG 2.1 AA. Ask what has been tested and how, not whether the vendor believes they're accessible.
• Mobile access. Mobile access doesn't automatically mean an app. Ask what the actual usage pattern will be first, because responsive web covers more real situations than vendors selling apps tend to admit.

Features that depend on what you're doing

These belong on your list only if your outcome puts them there.

• Certificates with expiry and automatic re-enrolment: essential for compliance training.
• Escalating reminders to managers: essential for compliance training.
• Start-date-triggered automation: essential for onboarding.
• Pre-start access for new hires: essential for onboarding.
• Self-registration and invitation flows: essential for customer and partner training.
• Multi-organisation separation: essential for customer and partner training.
• Branding per customer or audience: essential for customer and partner training.
• Payments and e-commerce: essential when you sell training externally.
• Skills frameworks and competence mapping: essential for competence development.
• Learning paths across multiple courses: essential for competence development.
• Single sign-on and automated user provisioning: essential beyond a few hundred internal users.
• HR system integration: essential when employee data changes often.

The last two deserve a note. Single sign-on and user provisioning feel like technical detail during selection and become the difference between a platform that stays current and one that quietly fills with people who left eighteen months ago. If your requirements sit at the larger end of this list, the picture changes again.

Nice-to-have: useful, rarely decisive

Gamification, discussion features, advanced analytics, elaborate learning path logic, and the more advanced end of security configuration all fall here for most buyers. Not because they're bad, but because they rarely decide whether the project succeeds.

Two of them cause most of the overbuying.

Advanced analytics impresses in the demo dashboard and then goes unopened, because nobody has the time to interpret it. Basic reporting that someone reads beats sophisticated reporting that nobody opens.

Gamification works in voluntary, repeated learning. It does close to nothing for a mandatory annual compliance course, where the motivation is already external.

If you're weighing an LMS against a learning experience platform or another category entirely, that's a different question from this one.

Demo theatre: features that impress and then go quiet

Every demo is a performance, ours included. Some features look far better in a demo than in daily use. A few that consistently look better in the room than they do in month six:

• The dashboard with beautiful data. It's beautiful because it's populated with a fictional organisation that has been generously active. Ask to see the same view with fifty participants, three of whom have done nothing.
• AI content generation with a perfect prompt. The prompt was chosen because it works. Ask to generate something from your actual material, live.
• "Everything is configurable." Usually true, and usually the answer to a question you didn't ask. Configurable by whom, in how long, and does it survive an upgrade?
• The participant view. Almost always the polished part. Ask for the administrator view, because that's where your colleagues will spend their working hours.

The general fix is one question, asked repeatedly: can you show me that with our material and our participants? A vendor who can is worth more than a vendor with a longer feature list.

Why organisations pay for features they never use

Three things push buyers towards breadth, and none of them is anyone's fault.

A procurement process that treats every requirement as equal will select the platform with the most boxes ticked, which is not the same as the platform that fits. Meanwhile, the person choosing the system is frequently not the person who will administer it, so the daily cost of complexity is invisible at the moment of decision. And features tend to arrive in tiers, so you pay for a bundle to get the one thing you needed.

We've sat in on a lot of these processes, and one pattern keeps repeating: the organisations that end up happiest are almost never the ones that bought the most capability. They're the ones that were specific about three or four things and honest about not needing the rest.

All three are avoidable once you know they're there, and the priority list further down is the cure.

AI features in 2026: what adds value and what is noise

AI earns its place on your list the same way every other feature does: by what it does with your material. It's a feature category, not a philosophy.

Where it helps today: producing a workable first draft of content instead of a blank page, translating and adapting material across languages, generating questions from existing material, and making a large content library findable. All of these save real time on tasks that were previously tedious.

Where it mostly doesn't: anything presented as a headline without describing what it does with your material. Just because there's AI in the product doesn't mean the result is any good. The content and the intent behind it still have to be there.

Four questions separate the two quickly. What exactly does it do with our content? Can we edit and approve the output before a participant sees it? Where does our material go when it's processed, and which jurisdiction does it sit in? And is this available now, or is it on a roadmap?

On that third question: if the answer is vague, treat the vagueness as the answer.

How to build your own priority list

This takes about twenty minutes and beats any generic checklist, because the ranking comes from your outcome rather than someone else's catalogue.

1. Write down the one outcome that has to be true in twelve months. Just one.
2. Take the four to six features that outcome directly depends on. Those are your must-haves.
3. Everything else goes on a second list, kept but ranked below.
4. For each must-have, write the question you'll ask in a demo and the answer that would count as a pass.
5. Give the second list a budget: how much extra you're willing to pay for all of it combined.

That last step is the one people skip, and it's the one that prevents the slow slide from "we need assignment rules" to "we need everything, apparently".

When your list is stable, it belongs in a requirements document rather than an email thread.

Common mistakes when choosing features

• Copying someone else's list. It encodes their outcome, not yours. It's also the fastest route to a twenty-item must-have list.
• Treating every item as equally important. If your list has no order, the broadest platform wins by default. How you rank and weight it belongs in the requirements document, and it's worth doing there properly.
• Ignoring administrative effort. Ask how long a routine task takes, in clicks, for the person who'll do it forty times a year.
• Letting the tool define the process. If a platform can only run onboarding one way, you haven't chosen a feature, you've chosen a process.
• Forgetting the people who will run it. The most reliable predictor of whether a rollout works is whether the person administering the platform has somewhere to turn when something doesn't behave. That's worth evaluating as carefully as any feature, and it's much harder to see in a comparison table.

Where to go from here

Write down your one outcome before you look at another feature comparison. Then build the short list from it, take the ranked version into your requirements document, and spend your demo time asking vendors to show you their platform doing your work rather than theirs.

A shorter list, defended properly, will serve you better than a longer one that nobody prioritised.