Jakob LechnerDE/EN

Case study · Falkenberg Akademie GmbH

The Production Line

Four years running production on digital learning and marketing. Twenty-plus e-learning courses from conception to publication, over three hundred hours of material, more than eighteen hundred participants — and the place where I first started writing software to solve production problems, because doing them by hand had stopped scaling.

E-learning courses
20+
conception → publication
Course material
300h
produced
Participants
1,800+
in 2024
Films & ads
30+
social, image, YouTube

What the job was

Project manager on digital learning, media and marketing. In practice that meant owning the line that turned an idea for a course into a published course people paid for and completed — conception, production planning, filming, post, publication — and doing a good deal of the production myself rather than only coordinating it.

Alongside the courses ran the marketing output: more than thirty social ads, image films and YouTube videos over the four years, on the same production line and often with the same crew.

Three hundred hours is a systems problem

A TYPICAL WEEK — NINE PIECES IN FLIGHT, FIVE STAGESCONCEPTPRODUCTIONEDITAPPROVALPUBLISHE-LearningSocial AdE-LearningImagefilmYouTubeE-LearningSocial AdImagefilmE-Learningautomated underneath — briefs · asset handoff · version tracking · sales20+ courses · 30+ films and ads · 300+ hours · four years

The stages never emptied. At any given week there were pieces at every one of them, in four different output formats, which is the part that makes it a pipeline rather than a sequence of productions.

One course is a production. Twenty courses is a pipeline — and nothing about a pipeline is solved by working harder. The constraint stops being how fast you can edit and becomes how reliably work moves between people: briefs, assets, versions, approvals, publication.

That's where I started introducing automated workflows, including automation connected to sales — not because anyone asked for it, but because the manual version had visibly run out of room.

The automation work at NaschNatur wasn't a sudden pivot. It started here, with worse tools and a harder problem.

The migration nobody could do by hand

TWO ROUTES · SIXTEEN COURSES · ONE NEW PLATFORMOld platformproprietary builderPython scriptwalks the old platform's APISCORM packagesauthored in Articulate 360Self-hosted + iframedno native SCORM supportLearningSuitecourses live, learners unaffectedthe courses that could not be moved were the ones that had to be rebuilt

Written rather than coordinated. Sixteen courses was past the point where rebuilding by hand made sense, so the rebuild became a script.

The old platform was purpose-built, and then left behind. The problem was that courses had been authored inside its own course builder — so the content wasn't sitting in files anyone could pick up and move. It existed in a structure only that system understood.

There were sixteen of them, which is past the point where rebuilding by hand makes sense. So I wrote a Python script that walked the old platform's API, pulled out the course material, formatting, videos and downloads, and rebuilt each course inside LearningSuite's builder.

Then a second problem. Several courses were SCORM packages authored in Articulate 360, and LearningSuite had no native SCORM support. Rather than rebuild those from scratch, I self-hosted the packages and embedded them in iframes — so they ran inside the new platform unchanged.