You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 0: The PM Frame — and Why Your PM Education Didn't Operationalize #

If you hold a PM certificate that never changed your behavior — a university-branded course, a Coursera track, an employer-paid program you finished and filed — you will be defensive about the audit this module asks for, and I want to name the defensiveness before you start, because it is the first thing that has to move out of the way. The defense will be some version of "the cert was fine, I just didn't apply it" — half true and entirely insufficient. The cert was fine in the sense that the frameworks it taught are real frameworks used by real product people at real companies. It was insufficient in the sense that those companies are 50-person product orgs inside VC-funded teams, and you are one engineer trying to ship things that make money. Most of the frameworks assume coordination layers — a PM, a designer, an engineering lead, a data analyst — that you do not have and will not have for years. Running Cagan's empowered-team model on a one-person operation is like running Kubernetes on a single laptop: technically possible, operationally insane.

My prediction for the audit: 70-80% of the cert's content will classify as "understood, and explicitly inappropriate for your operating context." That is the corporate-PM tax baked into the genre. The remaining 20-30% — lightweight discovery, JTBD synthesis, basic metrics literacy — is what you genuinely could have used in the last twelve months and didn't. That sliver is the gap this curriculum closes; the rest you can stop feeling guilty about, because it was never going to operationalize at your scale.

I should be honest that the two earlier drafts of this module disagreed about what M0 is for. One was built around the cert audit — classify every framework you were taught, find the gap, let the gap become the scope. The other was built around reading Cagan for taste, and it warned against exactly the move the first draft encourages: you will read Inspired, recognize that Cagan is describing a 100-person product team with a researcher and weekly stakeholder meetings, and mentally file the book as "not for me." That categorization is the trap. Cagan's substance — outcomes over output, discovery as continuous rather than pre-flight, real decisions pushed to the people closest to the work — is what you take; the org-chart trappings are what you discard. Dismissing Inspired because of the trappings is the same error as dismissing Designing Data-Intensive Applications because you don't run a multi-region database. Both drafts are right, and the merged module asks for both motions: audit what you were taught against your actual context, and re-read the canon for the principles that port.

Here is the asymmetry I most want to confront, because I have watched it in the writing of many engineer-founders, including very sharp ones: they read Kleppmann four times and Cagan once. The asymmetry is downstream of a quiet belief that PM is "soft" and engineering is "hard," and the belief is exactly backwards. The math in a systems textbook is a closed system — you can verify your understanding by writing tests. The frames in PM literature are open systems — you can only verify your understanding by shipping products and watching what strangers do with their money. The latter is much harder to develop competence in, which is why most engineers are bad at it, and why "I can just build it" so reliably produces engineers who build five things and sell none of them. Take Cagan as seriously as you take Kleppmann. The dual refusal this curriculum runs on starts here: the corporate-PM register is wrong for you, and so is "just build and see." Build, and sell, and make money — which requires the frame.

One consolation the audit will also surface: some of the cert operationalized implicitly anyway, and you should take the partial credit. If you maintain an open-source package, its release cadence is probably shape-up-shaped without your having read Singer. If one of your products has a waitlist, the waitlist is discovery-shaped without your having drawn a Torres tree. The audit shows you what you have been doing right by instinct and what you have been doing wrong by misapplication; both findings are useful, and neither requires shame about the certificate. Certificates that don't operationalize are curriculum-design failures, not personal ones — they sell frameworks abstracted from the org context where the frameworks live, and the pattern is industry-wide.

The deliverable you are most likely to skip is the position document — what product management is, in your own words, after the module's reading — and I want to defend it in advance. It is the single most important artifact in this curriculum, because it is the only one that gets edited fourteen more times. The Module 0 version will be embarrassing in six months; the Module 14 version will be embarrassing in two years; the diffs are the curriculum. If you skip the writing because you "already know what PM is," you lose the only mechanism this curriculum has for showing you, in your own words, what changed. I cannot run the audit or write the document for you. I can hold the rubric and predict where you'll flinch. Two to three honest hours produce the rest of the curriculum's scope.

Conclusion #

The cert wasn't wrong; it was wrong-for-you, and most of what didn't operationalize was never going to operationalize at one-person scale. M0 names that gap, and then refuses the opposite error — discarding the PM canon entirely because its trappings don't fit your room. Audit the education, re-read Cagan for the portable substance, write the position document, and treat both motions as the precondition for everything that follows.

Predictions #

  • You'll resist labeling 70-80% of your cert's content as "inappropriate for context" because it feels like dismissing the time and money you spent. Label it anyway; the labeling is the recovery.
  • The frameworks you couldn't operationalize will turn out, mostly, to be the multi-stakeholder ones — OKR cascades, roadmap-as-comms-artifact, product-trio rituals. The ones you could have used but didn't will be lightweight discovery, JTBD, and metrics — exactly what M1, M2, and M7 retrain.
  • At least one framework you remember as "I get this" will turn out, when you try to write it down, to be hazier than you thought. The haze is data, not embarrassment.
  • The audit will take 4-6 hours, not the 2-3 you'll budget, because your first pass will be too kind to the cert and the honest second pass is where the gap analysis lives.
  • You will write the position document in 30 minutes, then realize within three days that you wrote what you think you should think, not what you think. The rewrite is the real document.
  • You will feel a pang of "I wasted money on that cert." The pang is wrong: you bought a vocabulary you didn't yet have an operating context for. The vocabulary still works; the context is what this curriculum supplies.