Welcome back! We just talked about getting people enrolled in your beta. Now let’s look at what you’ll need to deliver your program once they’re enrolled.
And I’m calling this lesson: Setting Up Your Beta Platform.
Your platform is the technical infrastructure that supports you and your students while your beta is running.
And don’t worry, if the thought of tackling the technical side of things doesn’t exactly “spark joy”, I’m going to do my best to make this as painless as possible.
The Two Beta Platform “Paths” You Can Take
You really have two paths you can follow with your beta platform.
You can use an existing course platform, like Teachable, Thinkific or Podia to do most of the work for you. Or you can pull together a kind of “DIY” platform using tools you’re already familiar with.
The first option has a learning curve as you get to grips with the software, but is easier to manage when things are up and running.
The second option has less of a learning curve at the start, but more work behind the scenes once your beta is in full flow.
Whichever path you take, you’ll need to understand what your platform actually does for you.
The 5 Jobs Your Beta Platform Needs to Handle
And I’ve broken it down into five separate “jobs”.
The first three jobs relate to those three pillars that underpin a typical online course: content, coaching and community:
- Job 1 is Hosting Your Content. That means making sure students can conveniently access your lessons, assignments, resources, and so on.
- Job 2 is Supporting Your Coaching. That means enabling students to get help and feedback from you when they need it; that could happen on a group Zoom call or over email or some other way.
- Job 3 is Facilitating Your Community. That means giving students a way to meet and interact with each other; that could be a weekly huddle or a private community or both.
Why Not Every Course Needs Three Pillars
Going back to those pillars, not every course will need all three – a self-study course may just have the content piece – but here’s the thing…
As weird as it sounds, you may need more of these pillars for your beta course than for your full course.
For example, your beta students may need more coaching than later students because you won’t have worked out all the kinks in the content yet.
Or you might provide a community to help beta students support and encourage each other – even if you don’t plan to have one in your full course.
How much of each of these pillars you provide in your beta is for you to decide and it’s all part of firming up your offer.
The point is that your beta platform must support the needs of your beta course, even if those needs are a little different to your full course.
Make sense? Good. Let’s talk about those other two jobs.
- Job 4 is Sending Updates. That means providing a reliable way to “broadcast” important information, like weekly bulletins or schedule changes, to all of your students at once.
- Job 5 is Getting Feedback. That means requesting and capturing feedback about your content and other aspects of your course for improving the next version.
So those are the five jobs your platform will handle for you.
Quick side note: I haven’t included taking payments, because it’s not an ongoing need and for a beta you’ll probably handle it manually.
How to Pick the Right Beta Platform
So how do you pick the right beta platform for you?
To help with this I’ve put together a resource with a handful of what I call platform recipes. They’re combinations of tools you could use to create your beta platform.
But to put the idea of recipes into context I’ll share the tools I used to deliver the first beta cohort of this course.
Example Recipe
For my content, I kept it super simple and just used Google Drive. My lessons, assignments and resources were just Google Docs that I shared with students.
For my coaching, I’d already decided to run a weekly Zoom call, so some of the coaching happened there. I also used the free version of Slack, which is a messaging app, to give the group somewhere to meet between Zoom calls. Students could post homework and I’d give them feedback within a day or two.
For my community, I already had the weekly Zoom calls and the Slack group, so the community element was already covered off.
For sending updates, I used good old-fashioned email. I’d send a “Welcome to Week X” email every Monday morning and any other emails as required.
And for getting feedback, I created some simple Google Forms and prompted students to complete them for each piece of content in the course.
It worked, and I think it was an okay student experience, but there was a lot of work behind the scenes, and I’m certainly glad I’d hired someone to help me!
Just for comparison, I also ran a beta of a smaller course using a free Facebook Group. I could create modules, post content, give people feedback, even run live video sessions, almost all within Facebook.
I know some people don’t get on with Facebook, which I understand, and it has some other limitations, but it just goes to show there are lots of options.
If you push me for a one-size-fits-all recommendation, I would say to go with a simple course platform, like Podia. Yes, there’s a learning curve but you can use it for your full launch too so that effort isn’t wasted.
Ready to Move On?
Okay, that’s everything about setting up your beta platform. Even if you’re not keen on tech, there’s usually a path through this that’s not too painful.
Once you’ve given your brain a rest, I’ll see you in the next lesson.