Intermediate

AI Product Management


For PMs and founders who own the what and the why. Specs, scoping, and running a roadmap when implementation stops being the constraint.

  • [PLACEHOLDER: platform: self-hosted, Udemy, or Coursera]
  • [PLACEHOLDER: course price]
  • [PLACEHOLDER: AI Product Management: course length, lesson count, format, and how enrolment works]

Afterwards

What changes in how you run the roadmap.

This is a job-change course, not a tool course. The tool is the smallest part of it.

Product management was built around a scarce resource. Engineering time was the constraint, so the craft became prioritisation: deciding what not to build, defending the sequence, and writing documents whose real job was to survive an argument about capacity. Most of the discipline you were taught is an adaptation to that scarcity.

When execution gets cheap, that adaptation stops fitting. The bottleneck moves upstream to the quality of the specification and the quality of the decision, which is where your job always claimed to be. This course is about actually moving it there: what the PRD becomes, how work gets split, what discovery is for when you can build the answer in an afternoon, and how you review work you did not write without pretending to a competence you do not have.

  • Rewrite your PRD format for a world where execution is cheap
  • Scope work in agent-sized units instead of sprint-sized ones
  • Run discovery when you can prototype the answer in an afternoon

Fit

Who this is for, and who should not bother.

It assumes you already own something. If you do not, the free course is the better spend.

  • Take it if

    You own a roadmap and other people execute it

    PMs · heads of product · founders with a team

    You write the specifications, you defend the sequence, and you have watched a two-week estimate become six because the thing in your head and the thing in the engineer’s head were never the same thing. You want the documents to start doing real work rather than surviving a meeting.

  • Skip it if

    You do not have a product or a team yet

    Pre-idea · solo · pre-team

    Half of this is about working with engineers, review gates, and what leadership sees, which is a set of problems you do not have. Take the free course, ship something on your own, and come back when there are other people in the loop. It will be worth more to you then and it costs nothing now.

Syllabus

Six modules on the parts of the job that actually moved.

Every module ends with an artefact you can use on the roadmap item in front of you.

  1. 01

    What actually changed, and what did not

    Execution got cheap; judgement did not. We separate the parts of the job that were adaptations to scarce engineering time from the parts that were always the work, because the first set is now overhead and the second set is where your remaining leverage is.

  2. 02

    The PRD, rewritten

    From prose an engineer interprets to acceptance criteria something can fail. Constraints, edge cases, explicit non-goals, and a definition of done that is checkable rather than agreeable. The old format and the new one side by side, on the same feature, so the difference is visible rather than asserted.

  3. 03

    Agent-sized scoping

    The unit of work stops being a two-week ticket and becomes a brief with a boundary. How to cut a roadmap item so each piece can be executed and verified independently, why the seams matter more than the estimates, and what to do with the work that genuinely will not split.

  4. 04

    Discovery when the prototype is cheaper than the interview

    Building the answer in an afternoon changes what you should ask and what you should just try. It also does not replace talking to people: a prototype tells you whether they can use it, never whether they want it. Where each one is the right instrument, drawn from 50+ customer interviews that a prototype could not have substituted for.

  5. 05

    Reviewing work you did not write

    The uncomfortable module. What a non-technical owner can legitimately verify, what they cannot, and how to build a review gate you can defend to an engineer rather than one that launders a green tick into an approval. Includes the point at which the right move is to stop and ask someone technical.

  6. 06

    Bringing engineers and leadership with you

    Resistance from engineers is usually earned: they have watched a manager use AI output as an argument for a deadline that was never realistic. A shared specification standard rather than a mandate, and the small set of adoption measures that show leadership what the spend bought without turning into a surveillance dashboard.

The syllabus is finished. The price, the platform and the dates are not.

What comes with it

  • The PRD rewritten as an executable specification, with the older format alongside it so you can see exactly what changed and why
  • A scoping worksheet for cutting a roadmap item into agent-sized briefs with defensible seams
  • The review checklist for accepting work you did not write, including where it tells you to stop
  • Worked examples drawn from the products on the work page, with the specifications that produced them
  • The failure modes at team scale, which are not the same as the ones you hit working alone

Everything is plain Markdown. Nothing here depends on your company using a particular tracker.

The limit

Cheap execution does not make a wrong roadmap right.

It makes it wrong faster. If you are building the wrong thing, the only change this brings is that you will find out sooner and at higher volume, and that is genuinely worth something, but it is not the thing most people buy a course expecting. No specification system substitutes for knowing what your customers actually need.

This is also not an engineering course. You will not finish it able to review architecture, judge a data model, or assess whether a dependency is a liability. Module five is about being precise about that boundary rather than pretending it is not there, because the failure mode for a confident non-technical PM is approving work nobody competent looked at.

Not open yet. The price and the platform are genuinely undecided, and I would rather publish the syllabus than a launch date I made up.

[PLACEHOLDER: course price]

[PLACEHOLDER: AI Product Management: course length, lesson count, format, and how enrolment works]

The refund position

[PLACEHOLDER: refund policy for the paid courses: how many days, and whether it is unconditional]

Before the waitlist

The three objections I get from product people.

We already write PRDs. Why would the format need to change?
Because your current format is written for a reader who fills gaps. An engineer reads around an ambiguity, makes a sensible call, and only tells you at the demo, which is where the two-week estimate quietly became six. Something literal does not do that. It executes the gap, and you see it immediately. The rewrite is mostly making implicit things explicit: non-goals, edge cases, what done means, and what must not be touched. If your PRDs already do all four, you have most of this already and should take the free course instead.
I am a PM, not an engineer. Can I honestly review this work?
Partly, and being precise about which part is the whole of module five. You can verify behaviour against acceptance criteria you wrote, check that the non-goals were respected, and read a diff well enough to notice scope you did not ask for. You cannot assess architecture, security or performance, and you should not pretend otherwise. The course gives you a review gate that is honest about its own edges and tells you when to escalate to someone technical.
Our engineers will not accept specifications from a PM using AI.
Some will resist, and usually for a good reason: they have seen AI output used as leverage in a deadline argument. The adoption part of this is mostly about not doing that. In practice the engineers who push back hardest at the start become the strongest users, because the system rewards exactly what they have been asking for since they arrived: an actual specification instead of a Slack message and a shrug. If the relationship is already adversarial, a course will not fix it and I will say so on a call rather than sell you one.

Not open yet

There is nothing to buy here today.

The syllabus above is what the course is. When it has a price and a home, the newsletter is where I will say so: no countdown, no early-bird pricing that is really the normal price.

P.S. If your roadmap is on fire this quarter, a course is the wrong instrument regardless of when it opens. Book the free call and I will tell you whether a sprint is the answer, including when it is not.