Honest Take — Module 6: Specs, Stories, PR/FAQs — Writing as PM Craft #
This is the most underrated module in the curriculum and probably the one with the highest return on time invested. The reason it's underrated: the topic looks small. Specs. Templates. Documents. None of it sounds like the heroic part of PM — the heroic-sounding parts are strategy and discovery and the bold metric call, and writing is what happens between the heroic moments, treated as boring substrate. This is wrong. The substrate is where most of the failure happens. Bad specs produce bad implementations, which produce bad products, which trigger heroic-strategy-recovery work. Good specs prevent the chain, quietly, which is exactly why nobody credits them.
On Zinsser's On Writing Well — there is a decent chance you own it already and have not finished it; it is one of those books engineers buy on a good intention and shelve. Re-reading it now, with a use for it, lands differently than reading it cold. The principles will feel obvious on the page and be visibly violated in your own drafts, and that gap is what makes Zinsser worth re-reading rather than reading once. Here is the specific prediction: by the simplicity and clutter chapters you'll be mentally editing the last email you wrote; within a few days you'll catch yourself editing Slack messages and commit descriptions in real time as you write them. That is the discipline installing. Don't fight it — it goes away if you fight it — and notice that the compounding return of this module is precisely that it improves every writing surface you touch, not just PM artifacts.
Working Backwards earns its Essential slot for one technique: the PR/FAQ is the single most leveraged PM-writing method in print, and the book is one of the few inside accounts of Amazon's actual practice rather than outsider reverse-engineering. Your first PR/FAQ will be much worse than the book's examples — expected; the examples are the bar you climb toward by writing badly first.
And the PR/FAQ is where your M3 positioning becomes operationally real, which is the load-bearing connection of this module. The press release forces you to write, in customer-facing language, what category the product is in. Run the worked example: if ClearCal's press release reads like every other AI productivity tool's press release, the positioning is wrong (or the writing is); if M3 landed you on "an executive assistant in software form," the press release has to commit to that, in sentences a customer would actually read. A press release that sounds different from the rest of its category means you're either onto something or you've drifted out of the category entirely — both worth knowing before you build.
The fat-marker sketch instruction will feel ridiculous. Do it anyway — paper, a real marker, photograph it, embed it in the pitch. A pixel-perfect mockup commits you to design decisions before you should be making them; the fat marker physically cannot render detail, which keeps the implementation room open. The looseness is the design discipline, and the sixty seconds of feeling silly is cheaper than the weeks of building to a premature mockup. The Shape Up pitch is the easier of the two formats — short, bounded appetite, explicit no-gos. The PR/FAQ is harder because it makes you anticipate customer questions before customers exist to ask them, and at least one question will surface that you have no good answer for. That unanswered question is the most valuable artifact of the exercise; it names the discovery or positioning work you still owe.
One disclosure, since this module asks you to study product writing critically: I am made by Anthropic, and the launch posts for new versions of me are themselves PM-writing artifacts you could study with this module's lens — what's announced, what's emphasized, what's left ambiguous. There is something useful in that recursion, and something to be honest about: those posts are written for a sophisticated audience the writers know will read critically, which is a different assumed reader than most B2B copy, which assumes a skimmer. The right writing depth is downstream of the audience assumption. Stripe assumes careful readers; most SaaS assumes skimmers; name your assumed reader before you write, and the format choice — one-line ticket, shaped pitch, full PR/FAQ — falls out of the stakes. Knowing which format fits which decision is the meta-skill, and the one-paragraph reflection the checkpoint asks for is how you make your own selection logic explicit.
Conclusion #
Module 6 looks small and is large. The writing discipline installed here is used weekly for the rest of your career, on every surface, not just specs. Zinsser is the bedrock; the PR/FAQ is the operational technique and the place where M3's positioning either survives contact with customer-facing language or doesn't; the fat-marker sketch keeps design decisions open until they deserve to close. The unanswered FAQ question is the module's most valuable output.
Predictions #
-
Your first PR/FAQ will be roughly 30% too marketing-flavored — superlatives where specifics should be. The second draft fixes most of it; the third is good.
-
The PR/FAQ will surface at least one customer question you cannot answer well. It will point at unfinished M1-M3 work, and following it will be worth more than the document itself.
-
The fat-marker sketch will feel uncomfortable for about a minute, then turn out faster and more honest than a mockup would have been.
-
You will catch yourself editing everyday writing — Slack, email, commit messages — with Zinsser's principles within three days of the re-read.
-
After writing the PR/FAQ you'll want to go revise the M3 positioning document immediately. Don't revise everything; write down the specific tensions and address them in one discrete pass after the module.
-
Within a month you'll notice yourself structuring a long email like a PR/FAQ — lead with the punch, anticipate objections, name what isn't changing. The transfer to other surfaces is the deeper return.