Is There Any Point In Courses Now?

Good morning.

If you've bought or sold courses the past few years, thought about doing so, or wondered if there's any point now that AI is here…

This issue will show you what's working now and how you can get the most out of any training you might sign up for.

Inside: the audit that splits any course into the part that ships as files and the part that stays teaching, what to do with each half, and how to price them once they come apart.

— Sam

IN TODAY’S ISSUE 🤖

What a course buyer is paying for
The audit prompt: paste a curriculum, get the split
Three marks that say an outcome ships as a file
The prompt that pulls a procedure out of your head
Turning one bad output into a permanent constraint
The index your buyer reads before anything else
Why judgment is the half you keep
Pricing two halves that used to be one
Running the audit on a course before you buy it
Making any course fit your business

What A Course Buyer Is Paying For

If you're a creator, expert, coach or consultant, you probably sell something close to a course already, whether it's a program, a workshop, or the method you walk every new client through. And almost everyone reading this has bought one.

The split in this issue works from both sides of that sale, so I'll start with the person selling, where it's easiest to see, and come back to the buyer once the prompts are on the table.

If you've built one, you likely created the outline first. Eight modules, or twelve, each one a piece of what you do when somebody hands you the problem. Then you recorded it, because video was the only way to show the judgment. Written down, the same process came out as a checklist.

The buyer wanted the result. They bought the hours because the hours were the route to it, and everybody involved understood the trade: watch me do this enough times and you'll be able to do it.

That trade has two filters in it, and you already know both numbers from your own dashboard:

The finish filter. A fraction of the people who buy reach the last module.
The transfer filter. A fraction of the people who finish can produce the outcome on their own afterwards.

Stack those two and you get the result you already live with: good reviews, and very few people doing the work.

A Skill removes the first one. It's a set of written instructions for a single job, in a file, and the buyer installs it into whatever AI platform they already pay for. They run it and the job comes out done. There's nothing to watch, so there's nothing to finish.

So change the question: Instead of asking what a student should learn, ask what a student should be able to run on the day they buy, then ask which of those jobs needs a person to understand it at all.

The Outcome Audit

Open your curriculum, or the outline of your program or workshop, and ignore the module titles, which describe teaching rather than results.

Write out every outcome the course claims to produce, phrased as a job somebody does:

Writes a cold email sequence for one offer
Audits a landing page and ranks the fixes
Turns a call transcript into a proposal
Builds a quarterly content calendar from a positioning doc
Prices a retainer from a scope

Most courses produce between eight and twenty of these once you write them as jobs, and the list usually comes out shorter than the module count because three modules often feed one outcome. That gap is the first thing the audit shows you.

Now mark each outcome against three tests:

The procedure test. Could you write this job down as a sequence of steps, such that somebody following them carefully gets a usable result?
The inputs test. Does the job run on material the buyer already has or can get in a few minutes, such as their own copy, their own numbers, a competitor's page, a transcript?
The judgment test. Does the job need somebody to weigh two defensible options where the right answer depends on things a file can't see?

Pass the first two and fail the third, and the outcome ships as a file. Anything else stays with you.

Rather than scoring twenty outcomes by hand, paste your curriculum into this and let it do the first pass:

Read the material below, which is the curriculum, sales page, or module list for a course, program, or workshop I sell. Ignore the module titles and the marketing language. Extract every distinct outcome the product promises, phrased as a job a person does, in the form verb plus object plus context (for example: "writes a cold email sequence for one offer", "audits a landing page and ranks the fixes"). Merge duplicates where two modules feed the same outcome, and tell me which ones you merged.

Then score every outcome against three tests and return a table with one row per outcome and these columns: the outcome as a job, Procedure, Inputs, Judgment, Verdict.

Procedure: can this job be written down as a sequence of steps such that somebody following them carefully gets a usable result? Answer Yes or No.

Inputs: does the job run on material a buyer already has or can get in a few minutes, such as their own copy, their own numbers, a competitor's page, or a call transcript? Answer Yes or No, and name the inputs it needs.

Judgment: does the job require weighing two defensible options where the right answer depends on context a written procedure cannot see? Answer Yes or No, and where the answer is Yes, name the specific judgment call in one line.

Verdict: "Ships" when Procedure is Yes, Inputs is Yes and Judgment is No. "Teaching" in every other case.

After the table, give me the count and percentage in each verdict, then list any outcome that was close to the line with one sentence on why you scored it the way you did.

MATERIAL:
[paste your curriculum, module list, or sales page here]

The Judgment column is the one to read closely, which is why the prompt asks it to name the judgment call rather than answer yes or no. A named call like choosing between a retainer and a project fee when the client's volume is unpredictable is real judgment. A vague one usually turns out to be a preference, so write it into the file and move the outcome across.

Scored across a typical consulting curriculum it comes back looking something like this:

Outcome, written as a job	Procedure	Inputs	Judgment	Verdict
Writes a cold email sequence for one offer	Yes	Yes	No	Ships
Audits a landing page and ranks the fixes	Yes	Yes	No	Ships
Turns a call transcript into a proposal	Yes	Yes	No	Ships
Produces ten headline variants for a sales page	Yes	Yes	No	Ships
Builds a quarterly calendar from a positioning doc	Yes	Yes	No	Ships
Prices a retainer from a scope	Yes	Yes	Yes	Teaching
Decides which of three offers to build next	No	Yes	Yes	Teaching
Tells a client their strategy is wrong	No	No	Yes	Teaching

Expect the split to run near two thirds to one third, weighted toward delivery, and expect that ratio to feel wrong the first time you see it. Most of what any expert teaches is procedure that has been with them for a while.

Three Marks That Say An Outcome Ships

The tests will leave you with a pile you're unsure about. Three marks settle most of that pile in about a minute each:

You have said the same sentence to every client. Explain the same sequence out loud more than about five times and it's a procedure, and you already know every step of it. The repetition is the tell, which is why the outcomes you're most tired of teaching are the ones that ship first.
The output has a recognizable form. A sequence, a table, an audit with findings, a scored list. When you can describe a good output before you see it, a file can produce one and you can check it against your description. If you only know it's good once it's in front of you, the job stays with you.
Somebody could be wrong about it and you'd know why. If there's a failure mode you can name in advance, you can write it into the instructions as a constraint. If the failure mode is it just isn't very good, you haven't finished thinking about the job and it isn't ready to ship as anything.

Look twice at the outcomes failing all three, because that group holds the two or three things buyers pay you for, and the teaching half gets built around them.

Pulling The Procedure Out Of Your Head

Take the outcome at the top of your Ships list and write the procedure behind it. You've done this job hundreds of times, so writing it out means skipping every step that feels obvious to you. Those skipped steps are the expertise, which is why a straight attempt at write out how you do this comes back thin.

Talk it through instead, and have the gaps marked rather than filled:

I am going to describe how I do one job for a client. Turn my description into a procedure precise enough that somebody else following it produces the result I would.

Work in three passes and show me each one.

Pass 1: write the procedure as numbered steps, using only what I said. Where I skipped a step because it is obvious to me, mark it [GAP] and move on. Do not fill it in with your own best practice.

Pass 2: list every [GAP], plus every point where I said something like "it depends" or "usually" or "in most cases". For each one, ask me the question that closes it. Order the questions so the ones unblocking the most of the procedure come first.

Pass 3: once I answer, rewrite the procedure with my answers built in, and add a final section headed "Checks" that lists what a wrong output looks like for this job and what to do about each one.

Write in plain instructional language addressed to whoever runs the procedure. No preamble, no summary, no explanation of what you did.

THE JOB: [name the outcome]

HOW I DO IT: [talk it through the way you would explain it to somebody starting on Monday, in as much detail as you can stand. Rambling is fine. The gaps are the point.]

The [GAP] instruction is the whole prompt. It stops the model filling your gaps with generic best practice, which would leave you shipping a file full of somebody else's opinions under your name, and it turns Pass 2 into questions only you can answer. Your answers to them are what make the file yours.

What comes out of Pass 3 is a procedure in a markdown file. That file already works: paste it into a project, a chat, or any platform with a memory of its own, and it runs. Packaging it so a model reaches for it on its own is one more step, and a small one.

Turning One Bad Output Into A Constraint

The first three or four runs produce something you wouldn't send, and the instinct is to fix the output. Fix the procedure instead, because a change to the procedure applies to every run after it.

Below is a procedure I wrote, an output it produced that I would not send, and my note on what is wrong with it.

Do not rewrite the output. Work out which step of the procedure allowed it, and write the constraint that would have prevented it. Give me three things:

1. The step number that let it through, and one sentence on why that step is permissive enough to allow this.
2. The exact line to add, written so I can paste it in as-is, and the step number to put it under.
3. Whether this is a one-off or a class of failure. Where it is a class, name two other outputs the same gap would let through.

Where the real cause is that the procedure asks for something the model has no way of knowing, say so plainly and tell me which input to add instead of which constraint to write.

PROCEDURE:
[paste the numbered procedure from Pass 3]

OUTPUT:
[paste the run you would not send, in full]

WHAT IS WRONG WITH IT:
[one or two sentences in your own words, the way you would say it out loud]

Point three is what makes this worth running. One bad output is usually a whole class of them, and having it name two more saves you finding them one at a time over the next month. Keep every constraint it gives you, because that growing list is the part of your file nobody can copy off your sales page.

Why Judgment Is The Half You Keep

Handing over the delivery half makes the teaching half worth more, and that takes a while to believe. A buyer holding a set of Skills and no teaching hits the same three walls inside two weeks:

Selection. They don't know which Skill fits the situation in front of them.
Reading. They can't tell a good output from a plausible one, because plausible is what these systems are best at.
Correction. When something comes back wrong, they have no idea whether to rerun it, change an input, or do the job themselves.

Every one of those is a teaching problem, and none of them was ever the bulk of your curriculum. You spent the modules explaining the procedure, which was the part you could explain, while selection and reading and correction stayed as things students picked up by watching you. Those three are now the whole job.

So the teaching half gets shorter and harder, and it's worth more per hour than anything you've recorded, because the buyer needs it on day two rather than in week six.

Something else stays with you, and it's why nobody can commoditize this. The instructions inside your Skills are your opinions: what a good cold email does, how you price, what you refuse to do.

Anyone can copy the format of a Skill in an afternoon, so what buyers come back to you for is the answer to why this step and not the other one, which is the teaching half.

What The Buyer Sees On Day One

The delivery half arrives as a small set of files and one page that tells the buyer what each of them does. That page matters more than it sounds, because a buyer handed nine files with no map runs the wrong one, gets a mediocre result, and concludes the product is thin.

Write the map as one line per file, in the order somebody meets the jobs in real life:

1. Proposal Writer. Paste a call transcript, get the proposal draft.
2. Page Auditor. Paste a landing page, get the ten changes ranked.
3. Sequence Builder. Describe one offer, get the five-email sequence.
4. Headline Set. Paste your page, get ten variants with the angle named.
5. Calendar Builder. Paste your positioning doc, get the quarter.

The buyer reads five lines, recognizes their own situation in one of them, and starts there. Once the procedures exist, the index writes itself:

Below are the procedures I ship to buyers, separated by a line of three dashes. Write the index page a buyer reads before opening any of them.

Give each procedure one line in this form: a short name in title case, a full stop, then what the buyer pastes in and what they get back, in plain language, under twenty words.

Order the lines by the sequence somebody meets these jobs in real work rather than the order I pasted them, and tell me in one sentence what order you used.

Then add a short section headed "What comes back" that sorts every procedure under exactly one of three labels: "Runs close to finished", "Strong draft, your opening", or "Check the numbers first". List the names under each label with no commentary.

Write nothing else. No introduction, no closing paragraph, no encouragement to get started.

PROCEDURES:
[paste each one, separated by ---]

Keep the closing instruction. A model asked for an index will otherwise open with a welcome paragraph, and that paragraph is the first thing your buyer reads.

Then give them one complete run, start to finish, with the real inputs and the real output printed. A buyer who has seen one job go end to end will attempt the other eight, because they already know what a finished run looks like and roughly how long one takes.

Say what comes back wrong, in writing, on day one. Three labels cover it:

Runs close to finished. Read it, send it. The audit and the headline set usually sit here.
Strong draft, your opening. The structure holds and the first paragraph needs your voice. Most writing jobs sit here.
Check the numbers first. The reasoning is sound and a figure may be wrong. Anything touching price or forecast sits here.

Saying so costs you nothing and saves you the week-two refunds.

The Protocol

Step 1. Write the outcomes as jobs. Go through the curriculum and list every result the product promises, phrased as something a person does. Ignore module titles. Stop when the list stops growing, usually between eight and twenty items.

Step 2. Score each one against the three tests. Run the audit prompt over your curriculum, then correct its table by hand, because it will miss the judgment hiding in two or three of your outcomes. Where you're unsure, apply the three marks and move on rather than deliberating.

Step 3. Pull the procedure for the outcome you've taught most often. The one you're sick of explaining, because you know every step and every way it goes wrong, and the three-pass prompt will get you through it in an afternoon. Answer the Pass 2 questions properly; they're the job.

Step 4. Run it against your own work, then somebody else's. Every output you wouldn't send goes through the constraint prompt, and the line it returns goes into the procedure. Then give it to one existing student with no explanation beyond the one-liner and watch where they hesitate.

Step 5. Build the rest against that pattern. Once one works the others are copies with different procedures inside them. Keep each file to one job, because a file doing three jobs makes the buyer choose which part they wanted, and that choice is the thing you were removing.

Step 6. Rebuild the teaching half around selection, reading and correction. Cut everything the files now do. What's left is thin, and that's correct. Use the real bad outputs from Step 3 as your examples.

Pricing Two Halves That Used To Be One

The two halves have different economics, and one price hides that from you.

	The delivery half	The teaching half
What the buyer gets	Files that do a named job	Selection, reading, correction
When value arrives	Inside the first hour	Over weeks, as they hit real work
What sets the price	What the outcome is worth	Your time and your judgment
Volume ceiling	None, it copies	Low, it needs you in the room
Delivered by	The files, on their own	Cohort, office hours, output review
Refund pressure	Falls, because it worked on day one	Rises if the cohort is thin

At one price the teaching subsidizes the delivery, and you never find out which half the buyer wanted. Price them apart and you learn it inside a month.

Some buyers take the files and go, which is fine, because they were never going to finish the course either and now they get the outcome instead of a refund request. Some take both. The ones who take only the teaching are telling you something about the delivery half, and it's worth asking them what.

Ship the files first and add the teaching second, because a buyer who has already run the jobs arrives at the teaching knowing what to ask.

Getting The Most From Training You Buy

Everything above works in reverse when you're the one paying. A course, a coaching program or a paid workshop still has two halves, and knowing which half you're buying tells you what to ask for before you sign up and where your time should go after.

Paste the sales page of anything you're thinking about into this:

Read the sales page below for a course, program, or workshop I'm thinking of buying. List every outcome it promises, written as a job a person does (verb plus object plus context), and merge any that overlap.

Sort each outcome into one of two groups. PROCEDURE: a job that could be written down as steps and run on material I already have, so I could get it as a file, template, or Skill and run it myself. JUDGMENT: a job that needs someone to weigh options against my situation, which is where live teaching, feedback, or review is worth paying for.

Then give me three things. First, the share of promised outcomes in each group. Second, for the PROCEDURE group, the questions to ask the seller before I buy, including whether templates, prompts, or files are included and whether I keep them. Third, for the JUDGMENT group, exactly what access to the person the page promises (calls, reviews, feedback on my own work) and how often, quoting the page.

Where the page is vague about what's delivered, say so plainly instead of assuming.

SALES PAGE:
[paste the page]

What comes back points one of three ways:

Mostly procedure, with no files mentioned. Ask whether the templates, prompts or Skills come with it before you pay. If they don't, you're paying for hours of watching a job you could be running on day one.
Mostly judgment. Check the access the prompt quoted back. Calls, reviews and feedback on your own work are what the price is for, so a vague line about "community support" is worth a question before you buy.
A real mix. Buy it, then run the procedure half yourself in the first week with the three-pass prompt above, and save your time with the teacher for the judgment half.

Making Any Course Fit Your Business

Once you've bought a course, most of its value depends on what you do in the first two weeks, and a few habits turn a course written for everybody into one written for your business.

Get the transcripts of every module and every live call. Many course platforms and meeting tools will give you captions or a transcript, and when one won't, the recording goes through whatever transcription tool you already use.

Put them all in one project in Claude or ChatGPT, along with the workbook and any templates, so you can ask questions across the whole course, such as where does it cover pricing, and do any two modules disagree? Keep them for your own use, since they're still the teacher's work.

Write your business down once. The prompts below are only as accurate as what they know about you, and a model with no context fills the gaps with a generic business that isn't yours. Nine lines cover most of it:

MY BUSINESS:
What I sell: [each offer, its price, and roughly what share of revenue it brings in]
Who buys: [the two or three kinds of customer, one sentence each, the best-paying first]
Where customers come from: [your main channels, and which one brings in the most]
Current numbers: [revenue range, list or audience size, and any conversion rates you know, marking each one as measured or a guess]
Who does the work: [just me, me plus contractors, or a team, and the hours per week I can put into new things]
Tools I pay for: [email platform, CRM, course or community platform, AI tools]
What I've tried: [anything related to this course's topic, what happened, and why I think it worked or didn't]
Constraints: [budget, things I won't do, anything the business can't change right now]
90-day goal: [one outcome, as a number if possible]

Mark each number as measured or guessed, because a suggestion built on a guessed conversion rate reads exactly as confident as one built on a real one, and the prompt below is told to flag the difference.

Then attach two or three real pieces of the work the course is about to change, like your sales page, a recent proposal, or last month's emails, so the suggestions can point at specific lines of yours.

Decide what to watch. Before you open a module, ask the project to turn its transcript into a list of steps and say whether the module is mostly procedure or mostly judgment. Read the procedure modules as a list and save your viewing time for the judgment ones, since that's where the teacher explains why.

Run each lesson through your business. This is the prompt that does the customizing:

Below is the transcript of one lesson from a course I'm taking, followed by a description of my business. Adapt the lesson to my business.

Give me five things, in this order.

1. What applies as taught: the parts I can use unchanged, one line each.
2. What needs adapting: each part that assumes a different business from mine (a bigger team, a bigger audience, a different business model, a budget I don't have), what it assumes, and the version rewritten for my business using my offers, customers and numbers.
3. What doesn't apply: the parts that don't fit my business, with one sentence on why, so I can skip them without wondering.
4. The one action to take this week: the single change most likely to move my 90-day goal, the first step, and roughly how long it takes.
5. Questions for the teacher: anything the lesson leaves to judgment that depends on my situation, written as a question I can ask on a live call, with the context they'd need in one or two sentences.

Use only what's in the transcript and my description. Where the lesson makes a claim my numbers can't support, or where a suggestion depends on a number I marked as a guess, say so.

LESSON TRANSCRIPT:
[paste one module or one call]

MY BUSINESS:
[paste your nine lines and attach your examples]

Point two is where the course starts to fit. If you're a coach taking a course built around a paid-ads budget, it rewrites each step for the channels you already use, like referrals, a small list, or LinkedIn, and says what that costs you in speed.

Point four stops the course turning into notes you never open again, and point five gives you something specific to bring to the next live call.

Keep the course's procedures as files. When a lesson teaches a job you'll do again, run the three-pass prompt from earlier on it, pasting the transcript where the prompt asks how you do the job.

The teacher's method comes out as a numbered procedure in your project, and every [GAP] marks a step the teacher skipped because it was obvious to them. Take those gaps to the live calls, which is the judgment half you paid for.

Last Byte

Look at the outcome you're most tired of explaining. Write it down as a sequence of steps tonight, run it against a real piece of your own work tomorrow, and see whether the output is something you'd have sent a client.

Inside a day you'll know whether the half of your business you've spent years recording should have been a file.

If you're on the buying side, run the buyer prompt on the next sales page you're tempted by before you pay, and the adaptation prompt on the first lesson once you're in.

If the split leaves you with something good and no idea what to charge for it, that's the ground Cortex covered this month.

In Cortex, I share the formulas and strategies that help busy online business owners implement AI and Agents inside their businesses, in just minutes or hours instead of days or weeks.

Learn more about Cortex here

Talk soon,
Sam Woods
The Editor