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.
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.
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.
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.
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.
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.
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?
I am a PM, not an engineer. Can I honestly review this work?
Our engineers will not accept specifications from a PM using AI.
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.