Turning your knowledge into curriculum is not rocket science, and I'll say that plainly. The method is straightforward. What trips people up is starting in the wrong place, at the beginning of what they know, instead of the end of what their student needs to become.
Start With the End: Backwards Design
Backwards design means you think first about what you want your student to know or be able to do by the time they finish, whatever you're building, teaching, or providing. Then you work backward from that end point. This single shift changes everything about how curriculum design for online courses actually works. You're not organizing your knowledge, you're organizing your student's path to a specific outcome, and those are two very different exercises.
Once you have that end goal named clearly, you identify the checkpoints: the specific things your student needs to be able to do along the way to reach that final outcome. Those checkpoints create a ladder, a sequence they move through step by step, and that sequence is what actually makes someone successful at the thing you're trying to help them do.
Where Do You Even Start When You Know a Lot but Have Never Taught It Before?
You start by writing down the transformation in one sentence: what can this person do at the end that they couldn't do at the beginning. Not what will they know, what will they be able to do. Knowledge without application is trivia. A curriculum built around what your student can do at the end will naturally pull in the right knowledge to support it, instead of trying to cram in everything you happen to know about the topic.
How Do You Break Broad Knowledge Into Modules That Actually Make Sense?
Once you have your end transformation, list the checkpoints between where your student starts and where they'll finish. Each checkpoint is a specific capability or milestone, and each one becomes a natural module boundary. This is different from organizing by topic. Topic based organization asks what are all the things I know about this subject. Checkpoint based organization asks what does my student need to be able to do next, and what's the smallest unit that gets them there.
- Name the final transformation in one clear sentence.
- List every checkpoint a student has to pass through to get there.
- Order the checkpoints by dependency: what has to come before what.
- Turn each checkpoint into a module built around that specific capability.
Not Sure How to Structure What You Know?
If you've got the expertise but the outline keeps falling apart, that's a design problem, not a knowledge problem, and it's exactly the kind of thing I help clients work through. Book a discovery call and we'll map the transformation and the checkpoints together.
What Order Should the Material Be Taught In?
Order follows dependency, not preference. If a student needs to understand concept A before concept B makes sense, A comes first, regardless of which one you find more interesting to teach or which one you developed first in your own career. This is where a lot of practitioner built curriculum goes wrong: it follows the order the founder learned things in, or the order they find exciting to talk about, rather than the order a brand new student actually needs to encounter them.
A useful test: for every checkpoint, ask what a student would need to already know or be able to do to succeed at it. If the answer points to a checkpoint you haven't placed earlier in the sequence, move it.
How Do You Know If Your Outline Covers Too Much, or Not Enough?
Too much shows up as checkpoints that don't connect directly to the final transformation. If a module exists because it's interesting or because you know a lot about it, but a student could reach the end outcome without it, that's a sign to cut it or move it to a resource rather than a core module. Not enough shows up as gaps in the ladder, places where a student would need a capability you never actually built a checkpoint around. The transformation itself is the test in both directions. Everything in the curriculum should be there because the end goal requires it, nothing more and nothing less.
This is a load bearing idea across almost everything I teach: backwards design is the bridge between expertise and teachability, and between an offering and the outcome it's supposed to deliver. When you build this way, on purpose, from the end backward, you're not just organizing information. You're building the ladder someone else is going to climb, and the care you put into each rung is something they'll feel, whether or not they ever know to name it.
