Launching a learning management system can be a stressful process.
A failed launch can cost you both time and money and issues can sever the trust you have with your users, causing them to turn their back on your business.
What's more, a failed or bumpy launch can stress out your internal team, consultants and external vendors (like Plume), so it's important to approach your product's launch with a solid plan.
Having launched over 180+ projects, we’ve learned how to successfully launch an LMS and mitigate the common risks.
Preparation is key to a successful launch, and it's important not to rush it. First, some general rules about preparing for launch:
So, what will we help you to do in the weeks leading to launch?
At Plume, when we develop an LMS, we test as we go. We also dedicate an entire week for testing just prior to handover and will often ask you to review our work. Regardless, for peace of mind and so that you can understand how your content works alongside the technology, we recommend you run your own tests at least 4 weeks prior to launch.
If you’re a Plume client, we’ll be here to resolve critical issues that might arise. There are three types of issues:
A bug is an error or fault in the LMS that causes it to produce an incorrect or unexpected result.
Some bugs are relatively minor, such as those that impact a very small number of user or that doesn't stop users from completing a task. These low-priority bugs can be logged in the system, but should often be addressed at a later date.
Medium and high priority bugs should be resolved in priority order with the time allotted to bug-fixing.
Reporting many high-priority bugs very close to launch may mean that they don't all get addressed, so it's important to report them and request they are actioned at least 2-3 weeks prior to launch.
These are improvements to functionality that does work, but could be improved.
While iteration is key to a successful long-term product, getting to perfect is rarely the goal for a phase one launch; instead, it’s better to launch with the minimum viable product (MVP). Make a note of any non-critical improvements that you’d like to implement later down the line and set these aside for post-launch consideration.
New ideas will inevitably crop up in the weeks leading up to launch, but they're often isn’t enough time to research, design, develop and test new functionality ahead of this if your launch is looming.
Make a note of these for later consideration.
Before we launch a beta to real users, it's important to set0up a feedback mechanism to allow users to report issues and provide feedback.
At Plume, we use Marker.io, which will allow both your internal team and end-users to report issues visually. These are automatically pushed to your Teamwork Project for review by both our team and yours.
We will install a session monitoring tool, allowing us to record the screens of users as they use your system - just as if we were looking over their shoulder.
Being able to watch your user's sessions back provides incredibly insightful data that can be used to improve the design, functionality and even conversion rate of your LMS product. We can:
Popular session monitoring tools include Hotjar (includes a limited free plan) and Fullstory.
Remember to mention the use of such tools in your privacy policy
If you have users, subscriptions and learner data that you need to migrate to your new system, we'll need to create a migration plan. This allows us to determine what data should be imported and when, and whether we'll need to develop custom tools to facilitate the migration.
Migrating users should not happen close to your big launch to new users, since our resources will be focussed on ensuring a successful launch. Instead, we recommend migrating your existing users earlier - potentially in batches - during your Beta period - and then "launch" to new users later on. This helps to spread the workload over a more manageable period of time.
Migration should be planned at least 2 weeks before it begins to take place. This window of time allows us to carry out a dry-run, which helps us to identify issues earlier and then circumvent them on the day of migration.
Before you open up your courses to the masses, start small with a beta launch. There are three key benefits to a smaller beta launch:
Before the beta, let your users know that they are among the first to try this new system and that they may run into a bug or two - they’ll be excited to be trying something new and will be more forgiving of bugs if they are forewarned.
We'll help you to analyse and understand the feedback collected via Marker.io and we'll discuss potential improvements to be made to the product, including bug fixes, UX improvements and new functionality or extensions to existing functionality.
We'll begin iterating right away, bringing in our consultants, designers and developers to make any adjustments necessary prior to launch.
At this point, you should have had a successful soft-launch/beta and fixed any critical bugs. You’ve collected some great feedback, prepared your team and are confident in your system and courses.
Now is the time to go public with your launch. There are a few things to consider:
Poor planning leads to poor launches, and poor launches can damage your customer’s trust in your company.
We’ve launched over 170+ successful projects, so get in touch if you'd like us to develop a fully considered launch strategy for your LMS.
