The 5 big takeaways from launching my first course

Most project managers would kill to know what’s about to happen.

They’d kill to have notes from someone who has done a similar project before, and learn from their mistakes and successes.

That would be the ultimate cheat code, right?

Yet those same project managers don’t log the lessons learned at the end of their project.

Crazy, I know. I’ve fallen for it too. Thinking that “no one will ever do something like this anyway” or being dragged into a new project before the previous one has been properly closed.

Don’t fall for it.

You owe it to your company, your team, and your own development and future success.

Lots of readers have asked how I do this, and an equal amount of readers are curious about what I learned from launching my course last week. So today, I’m combining the two.

What you should learn from previous projects

Lessons learned are not a collection of fun facts or a story you’ll tell your future grandkids. No, lessons learned are a collection of learnings from your project, that you write as a note to your future self.

I always try to answer the following questions:

• What do I know now, that I wish I knew at the start of the project?

• What worked well and should I double down on next time?

• What did not work well, and what should I do instead?

• What did we not do, that I now wish I did?

It usually starts with a brainstorm to identify what stood out most. You can also use the main deliverables or work packages from your work breakdown structure for this to get started.

For each of those things, your starting point is what you were trying to achieve. From there, you look at what actually happened instead. And then, the magic question: why?

Why did that happen?

You see, the first two are just observations. But you can only learn from them and improve next time if you deeply understand where the gap between plan and reality came from.

“Client communication sucked” is not a lesson. It’s an opinion from someone who has not had their morning coffee. You can’t learn from that.

“We discovered halfway through the project that the client had different expectations of deliverable X” - now that is something you can work with. Why was that? Did you skip something in the definition phase?

Great. What would you do differently next time to prevent that? That answer right there, that’s what you’re looking for.

So that when you or a colleague does something similar in the future, they read your lessons learned, smack their forehead and go “Ohh crap that’s a great idea!”.

The main learnings from launching Project Management Unraveled

The hardest thing by far was choosing what not to do. Deciding what’s out of scope.

The thing is, I can talk about project management for hours. Heck, make that days.

(In case you had not noticed…)

But no one cares about a 400-hour course that explains everything you’ve ever learned. Nope, people want their problems solved. Sprinkle in the minimum effective dose of context, and take them from A to B.

Once I had a clear view of where a student is today (point A) and where I wanted to take them (point B) everything got easier.

Next time I’d start with getting 100% clear on the journey first, then define the most effective way from A to B, and build a curriculum from that perspective.

The second thing is that I underestimated how hard it is to deliver that journey from A to B at scale.

You see, 80/20 applies to almost everything. The success of this course gets judged for 80% on the delivery and 20% on the content. Whether I like it or not.

I’m a consultant. A problem solver. I’m used to reducing complexity and explaining things. But I normally do that in a live setting, where I can get feedback from the crowd to see if something lands or not.

So that’s why I decided to run a course as a cohort first. With 10 live participants, small scale, to test things out.

The 10 folks got the rough cut of the slides delivered live, with room to ask questions, clarify, and take a mountain of notes. Without that, I think the final product would not have been anywhere near where it is today.

I’m definitely doing that again next time, even though it cost a lot of time.

The third big a-ha was when I finally caved and got a teleprompter.

I’ve given my share of presentations over the years, and have never, ever, written out my text. But this was simply too much material, and because of the lack of feedback while recording the videos, I found myself unsure in my explanations.

So I surrendered and started writing out the script. Word for word. It took forever, but it was the best decision I made. After that, recording a lesson took 3-4 takes maximum, while it took a day trying to wing it.

The fourth major takeaway is that the fact that this course is done is 100% due to fixing the deadline.

I’ve spoken about how I prefer to fix time as the leading constraint and leave budget, scope, and quality flexible in previous newsletters.

I announced my launch in public a month in advance, and that was mainly a forcing function. Without a deadline, I could easily have geeked out about the font size of the announcement email for a week.

But having a deadline forced me to make serious tradeoffs near the end of the project. Do I re-record that lesson where I stammered once 5 minutes in, or use that time to write another email?

Don’t get me wrong. A deadline is not an excuse to ship a bad product. But it did make sure that this thing got shipped, including a few imperfections that only I will ever notice.

The deadline made sure that I didn’t get perfect in the way of done. I already had a soft spot for this approach, but this makes me think of how many other projects could benefit from this kind of approach.

I’ll definitely keep applying it wherever possible.

The fifth and final takeaway is that I asked for help on a few topics too late.

This project was 90% a solo effort, and I spent too much time trying to figure certain things out. I had a few great friends and peers I could call on, but next time I’d make sure that I have an advisor on speed dial for any piece of the project that’s new and includes uncertainty and/or risk.

Note to self: put your pride aside and ask for help earlier.

Wrapping up

The five most important things I learned from building and launching a course:

1. Avatar & journey set curriculum, not “everything you know”

2. Never build a course without testing the material live

3. Teleprompters are not just for news anchors

4. Fixing the deadline saved my a**

5. I need to ask for help earlier

I hope this shows you what lessons learned are and why they matter, and gives you a quick look behind the curtains too. On top of that, it has taught me something I already knew: most of these lessons are universal.

The power is in the reflection and learning from the experience. They apply to every future project, not just building a course.

I won’t be building a new course any time soon. Instead, I’m doubling down on consulting work this winter.

And because of that, I’m testing a new offer.

If you or your company has a project that’s spiraling out of control, hit reply, and let’s talk. I’ll do a full project review with a detailed roadmap to get you back on track for 50% off.

Looking forward to hearing from you.

Talk soon,
Jasper