Lead imageassets/img/articles/teaching-130000-students.jpgOptional. 1600x900 JPG. Delete this block if the piece needs no image.
When I started teaching n8n I thought the job was knowing more than the student. It isn't. Anyone can know more. The job is deciding what to leave out, and being willing to be wrong about it in public, at scale, with a review score attached.
Here's what 130,000 students taught me — mostly by not finishing my early lessons.
People don't quit when it's hard. They quit when it's vague.
My worst drop-off was never in the difficult modules. It was in a five-minute video where I said "and then you configure the credentials" without showing which screen I was on. Difficulty is motivating. Ambiguity is humiliating, and people leave rather than feel stupid.
Now the rule is: never cut away from the screen at the moment something is confusing. That's the exact moment you slow down.
Show the error before the fix
Early on I recorded flawless runs. Clean canvas, green checkmarks, done. Students loved the videos and then couldn't build anything, because the first time real life returned a 400 they had no idea that this was normal.
A tutorial where nothing breaks teaches people that they are the thing that's broken.
So I leave the failures in. The malformed JSON, the rate limit, the node that needed a different data type. Watching someone recover from an error teaches more than watching them avoid one — and it's the difference between a student who can follow along and a student who can build.
One idea per lesson, and say it out loud
If I can't say what a lesson is about in one sentence, it's two lessons. Every time I've broken a long video in half, both halves performed better than the original. Nobody has ever complained that a lesson was too focused.
Reviews are a bug tracker
18,000+ reviews is a lot of feedback, and almost none of it is about me. The one-star reviews are nearly always a specific broken thing: an outdated screen, a renamed setting, a step that assumed knowledge from a course they hadn't taken.
I read them like a bug tracker. If three people are confused at 4:12, the problem is at 4:12. Re-record it. The rating recovers, and more importantly the person who was stuck gets unstuck.
Teach the tool, but sell the process
n8n changes. Nodes get renamed, models get replaced, the UI moves. If the course is only a tour of the interface, it expires. What doesn't expire is how you decide what to automate, how you handle failure, and how you know a workflow is working.
So I spend the first module on things that would still be true if every tool in the course got deprecated tomorrow — and students consistently name it as the part they use most.
Scale is just repetition with the mistakes removed
There is no clever growth trick in any of this. I published every week, I read the complaints, and I re-recorded the parts that didn't work. Do that for long enough and the course gets good, and then the numbers follow. In that order — never the other way round.
The one thing I'd tell anyone starting: your first version will be too long, too clever, and too proud of itself. Cut it in half. Then show the part where it breaks.