Product Management: Building Products With a Model Inside Them

Learn the product function as a mechanism rather than a vocabulary, then learn what changes once the product contains something slow, expensive, probabilistic and occasionally wrong: how to specify behaviour you cannot pin down, how to know it works, what to charge for it, what it costs to run, and how all of that bends by sector.

Most product writing teaches artifacts. You learn what a PRD is, what RICE stands for, what a roadmap should look like, and you are left holding templates with no theory of when each one is the wrong tool. Most AI product writing is worse: it teaches vocabulary for a field that changes every quarter. This course inverts both. Every lesson starts with the mechanism, shows the arithmetic where arithmetic decides the answer, and only then names the artifact or the tool.

Metrics live here too. Every number this course refers to is defined inside it, in its own topics, with the formula, the denominator people get wrong and a program that computes it. There is no separate metrics course to cross reference, because in practice the measurement and the decision are the same conversation.

It assumes you have worked near software and can read a table of numbers. It does not assume you have shipped anything, run a research study, owned a price, written a prompt, or managed a person.

The course is long on purpose. Product management touches strategy, engineering, design, data, pricing, abuse, economics and the organisation itself, and a short course on it can only be a glossary.

What the job looks like now#

flowchart LR
  M[":i-users: <b>Market</b><br/><small>problems, alternatives, triggers</small>"] --> D[":i-search: <b>Discovery</b><br/><small>what is true</small>"]
  D --> S{":i-compass: <b>Decide</b><br/><small>and refuse</small>"}
  S --> SP[":i-file-text: <b>Behaviour contract</b><br/><small>must, must never, should</small>"]
  SP --> B[":i-wrench: <b>Build</b><br/><small>prompt, context, tools</small>"]
  B --> E{":i-list-checks: <b>Evaluate</b><br/><small>against a bar set beforehand</small>"}
  E -->|"passes"| L[":i-rocket: <b>Ship</b><br/><small>canary, then all</small>"]
  E -->|"fails"| B
  L --> ME[":i-gauge: <b>Measure</b><br/><small>quality, cost, trust</small>"]
  ME --> V[(":i-coins: <b>Value captured</b><br/><small>retention, revenue, margin</small>")]
  ME -->|"every failure becomes a case"| E
  ME -->|"what we got wrong"| D
  B -.->|"no eval set"| X[":i-triangle-alert: <b>Shipping on vibes</b>"]
  class M neutral
  class D,B compute
  class S,SP,E,L queue
  class ME io
  class V memory
  class X warn

Two loops, not one. The outer loop is the product loop that has always existed. The inner loop, build to evaluate and back, is the one a model adds, and the dotted branch is what happens when a team never builds the eval set: it still ships, it just stops being able to tell whether it is getting better.

How this course works#

Every lesson follows the same shape.

1. The idea in one minute. The argument, in a few sentences.
2. A picture. The mechanism. Press Expand on any diagram to open it full size.
3. How it really works. The precise version, with names and numbers.
4. Run the numbers. Where arithmetic decides, a small Go program using only the standard library, so you can put your own inputs in.
5. The AI layer. What a model changes about this specific piece of work, what it costs, and how it fails.
6. Sector lens. The same mechanism in enterprise software, fintech, ecommerce, marketplaces, devtools, healthtech and vertical software.
7. Remember this, Try it, Check yourself.

Two rules hold throughout. A metric is defined in exactly one lesson and linked everywhere else. Market shape is defined once, in Product by Sector, and every other sector mention states only the delta.

Where to start#

Four pages sit alongside the lessons, under Reference in the sidebar.

If you read nothing else first, read the Roadmap. It lists only lessons that exist, so you can follow it top to bottom without hitting a topic that has not been written yet.

The topics#

flowchart LR
  A["The job,<br/>and what a model changes"] --> B["Discovery, specs<br/>and primitives"]
  B --> C["Context, agents<br/>and the interface"]
  C --> D["Evaluation,<br/>pricing and cost"]
  D --> E["Sector, lifecycle,<br/>org, worked calls"]
  class A neutral
  class B compute
  class C io
  class D queue
  class E memory

How the six levels are meant to be read#

Foundations is the entire product function with no model in it: the job, how to get into it, users, discovery, delivery, roadmapping, strategy, pricing, design and systems literacy, the functions around you, and how to read a number. Twelve topics, all of which would be true if generative models had never shipped, which is why they go first and why they stay true longest.

Basic is what a model is and what it changes: the five facts, the product shapes, the primitives, and how discovery works when the component is probabilistic.

Intermediate is building with one: specifying behaviour you cannot pin down, context and retrieval, agents and autonomy, and the interface that makes an imperfect answer usable.

Advanced is shipping it safely and keeping it working: evaluation, guardrails, pricing a feature whose cost scales with use, and surviving the next model release.

Expert is measurement, money and construction. Every number the job is judged on is defined here, next to the business vocabulary a review assumes you have and the topics that build real things end to end, because a number you cannot compute is a number you do not have.

Sectors comes last on purpose. The same job bent by the market it runs in only makes sense once the job itself is familiar.

What you need#

Go 1.22 or newer if you want to run the programs, and a terminal. Every program runs offline with no account, no key and no network.

A promise about names and numbers#

Tool names, benchmark figures and regulatory dates in this course were checked on 12 October 2026, and each lesson lists where its dated facts live. Benchmarks rot within a year and model capabilities rot faster. Mechanisms do not, and every lesson separates the two so you know which half to recheck.