The PM's Cognitive Load Problem
It is Tuesday morning. You have 20 unread Slack messages, a 10am sync with engineering, and a 2pm with the CEO who wants to understand the Q3 roadmap. Between those meetings, you need to finish the feature spec that was promised for sprint planning tomorrow, respond to a customer success manager who says a top account is threatening to churn over a missing integration, and review the NPS data that came in over the weekend.
By 6pm, you have handled all of it — urgency managed, meetings attended, fires extinguished. You have also written approximately 800 words of the 3,000-word spec that engineering needs. The rest will happen tonight, or tomorrow morning before standup, or during the sprint planning session itself when the engineer asks "wait, what does this acceptance criterion actually mean?"
This is not a bad week. This is a normal week. And this is the PM's cognitive load problem.
The Five Simultaneous Roles
Product management is unique among professional roles because it requires five distinct types of cognitive work — simultaneously, not sequentially.
| Role | What it requires | Documents produced |
|---|---|---|
| Researcher | Synthesise user interviews, support data, NPS verbatim, and behavioral analytics into a coherent picture of what users actually need | Discovery notes, research synthesis, problem briefs |
| Writer | Produce feature specs tight enough that engineers can build without ambiguity; PRDs comprehensive enough that no edge case is missed | Feature specs, PRDs, acceptance criteria, user stories |
| Strategist | Maintain a roadmap that reflects business priorities, technical constraints, user needs, and market reality simultaneously | Roadmap documents, initiative briefs, prioritisation frameworks |
| Communicator | Translate the same product decisions for engineers (technical precision), executives (business outcomes), customers (value language), and market (positioning) | Stakeholder updates, changelog entries, customer FAQs, launch briefs |
| Decision-maker | Prioritise a backlog that is always longer than the capacity to execute, with incomplete information and competing stakeholder pressures | Prioritisation docs, sprint briefs, retrospectives |
None of these roles can be turned off when you are operating in another. The strategist cannot go dormant while the writer is drafting a spec — because a good spec requires understanding the strategic context. The communicator cannot disengage during research — because understanding what executives need to see shapes which insights matter. The five roles run in parallel, all the time.
The Document Gap
The volume of writing required to PM well is staggering. A single feature from ideation to launch might require:
- A discovery brief (framing the problem before committing to a solution)
- An interview guide (for the user research that informs the spec)
- A research synthesis (turning interview notes into product direction)
- A competitive brief (understanding what the market already offers)
- A feature spec (what to build and why)
- A PRD (the multi-team alignment document)
- User stories (decomposed requirements for engineering)
- A sprint brief (scoped work for the next two weeks)
- A stakeholder update (progress and decisions for leadership)
- A launch communication (what it is and why it matters, for customers)
- A retrospective (what we learned, what we will do differently)
Most PMs either write some of these poorly — because there is not time to write them well — or skip them entirely. The result is the most common failure modes in product development:
- Engineers who built the wrong thing because the spec was ambiguous
- Executives who lost confidence because the roadmap narrative was unclear
- Users who could not figure out how to use a feature because the documentation was an afterthought
- Teams who repeated the same mistakes because the retrospective was never written
The document gap is not laziness. It is a structural constraint: the volume of writing required to PM well exceeds the time available to PM well. An experienced PM who can write a brilliant feature spec in two hours typically does not have two uninterrupted hours to spare — they have 45 minutes between meetings and three Slack interruptions.
The PM's job is judgment: deciding what to build, for whom, and why. AI agents remove the bottleneck between that judgment and the documentation that expresses it. The agent writes the first draft. You review, direct, and refine. The document reflects your judgment at the quality it deserves — in a fraction of the time it would have taken you to write it alone.
What PM Craft Actually Looks Like
Craft is not about polish — it is about precision. A well-crafted PM artifact has specific, observable properties that distinguish it from a rushed one. Here is what to look for:
In a Feature Spec
| Signal | High Quality | Mediocre | Poor |
|---|---|---|---|
| Problem statement | Describes observable user pain with evidence | Describes what to build without explaining why | Missing, or just repeats the feature request |
| Acceptance criteria | Each criterion is independently testable; no "and" | Some criteria are testable; some are vague | "The feature should work correctly" |
| Out of scope | Explicit list with reasoning | Partial list or implied | Not addressed |
| Edge cases | Enumerated with specified behaviour | A few mentioned informally | Ignored |
| Open questions | Named, with owners and due dates | Some questions noted, no owners | Unacknowledged |
In a Stakeholder Update
| Signal | High Quality | Mediocre | Poor |
|---|---|---|---|
| Audience calibration | Written for this specific audience's concerns | Generic status update | One version sent to everyone |
| Progress vs commitment | Honest delta against the plan | Progress described, no reference to plan | "Things are going well" |
| Risk visibility | Risks named with impact and mitigation | Risks hinted at | No risks mentioned |
| Decision requests | Specific decisions with options and recommendation | "Seeking input" without structure | No decisions surfaced |
In a Research Synthesis
| Signal | High Quality | Mediocre | Poor |
|---|---|---|---|
| Behavior vs opinion | Distinguishes what users do from what they say | Mixes behavioral observations with stated preferences | Only reports what users said |
| Evidence grounding | Each insight has source count and quote | Insights named without evidence | "Users want X" without attribution |
| What NOT to build | Explicit section | Implied or absent | Not addressed |
| Product implications | Directly connected to roadmap decisions | General implications | Research findings without implications |
The Two-Plugin Architecture
This chapter uses two plugins that together cover the full PM workflow. You will install both in Lesson 2.
Layer 1 — Official plugin (product-management): Maintained by Anthropic, this plugin provides the foundational PM commands: writing feature specs, updating roadmaps, synthesising research, communicating with stakeholders, running competitive analysis, and reviewing metrics. These are the high-frequency PM artifacts that any team needs regardless of product type.
Layer 2 — Custom plugin (product-strategy): This plugin fills the workflow gaps the official plugin does not cover: discovery briefs, interview guides, PRDs, user stories, prioritisation frameworks, and retrospectives. It also includes three agents for automating recurring PM intelligence work.
The two plugins complement each other. The custom plugin helps you frame a problem and gather evidence. The official plugin helps you turn that evidence into documented product decisions. Together, they cover the end-to-end PM workflow cycle.
The official plugin is a general-purpose foundation. The custom plugin encodes PM-specific craft principles — like "never propose a solution in a problem brief" or "acceptance criteria cannot contain 'and'" — that the general plugin does not enforce. When the two plugins work together, you get both speed and craft quality.
Quality Diagnostic Exercise
Time: 10 minutes Format: Reflective — no tools required
Step 1 — List your PM artifacts
Write down every PM artifact you have produced in the last month (or, if you are new to PM, write down every PM artifact you have observed or worked from). Group them loosely into the five role categories:
- Researcher role (discovery notes, research syntheses, problem briefs)
- Writer role (feature specs, PRDs, acceptance criteria)
- Strategist role (roadmap documents, initiative briefs)
- Communicator role (stakeholder updates, launch comms, changelogs)
- Decision-maker role (prioritisation frameworks, sprint briefs, retros)
Step 2 — Evaluate three artifacts
Pick one artifact from your Writer role category and evaluate it against the quality signal table above. Then pick one from your Communicator role. Then pick one that you consider your best recent work.
For each, answer:
- Which signals does this artifact satisfy?
- Which signals does it fail or omit?
- If an engineer received this as their only source of truth, what would they have to decide for themselves?
Step 3 — Identify the gap
Based on your evaluation: where does the document gap show up most visibly in your own practice? Which role's artifacts are consistently underpowered relative to what the work requires?
This is the gap that the next 14 lessons address.
Try With AI
Use these prompts in Cowork or your preferred AI assistant.
Prompt 1 — Reproduce (apply what you just learned):
I am a product manager working on a B2B SaaS analytics platform.
My team is 12 engineers, and we run 2-week sprints.
List the PM artifacts I should be producing for a single feature
from problem identification to post-launch retrospective. For each
artifact, tell me which of the five PM roles (researcher, writer,
strategist, communicator, decision-maker) produces it, and what the
most common quality failure looks like when that artifact is rushed.
What you're learning: Mapping the full document lifecycle of a feature reveals how many PM artifacts most teams skip, and which failure modes each skipped artifact creates downstream.
Prompt 2 — Adapt (change the context):
A startup PM at a Series A company has 1 engineer and 3 weeks
until their first paying customer pilot. They have time to write
exactly 2 PM artifacts before the pilot.
Which 2 artifacts would have the highest leverage? Why those two?
What are the risks of skipping the others?
What you're learning: Prioritising PM artifacts under constraints reveals which documents are load-bearing and which are refinements. The lesson applies even when you cannot do everything.
Prompt 3 — Apply (connect to your domain):
Think about the last feature your team shipped or is currently
building. Walk me through the PM artifacts that were actually
produced for that feature — not what should have been produced,
but what was.
For each artifact that was skipped or produced at low quality:
- What decision did the team have to make without it?
- Who made that decision?
- Was that the right person to make it?
What would you do differently with AI assistance?
What you're learning: Connecting the cognitive load framework to real work you have done (or observed) reveals the actual cost of the document gap — not as a theoretical problem but as decisions made by the wrong people, or not made at all.
Flashcards Study Aid
Continue to Lesson 2: Plugin Architecture & Your Product Context →