Product Manager Prompts: 119 copy-paste prompt assets for ChatGPT, Claude and Copilot

The problem: PM artefacts are written from scratch every time

Product managers produce a narrow set of recurring documents: PRDs, user stories, stakeholder maps, win/loss analyses, premortems, sunset plans. Each one is written under time pressure, in a different template depending on who asks, and the quality depends on how much context the author happens to remember that week. deanpeters/product-manager-prompts addresses that by shipping the scaffolding as text you paste into an assistant.

The README frames the audience directly: the assets are for "both the strategic thinking and the daily execution of product management", and the banner counts 119 prompt assets targeting ChatGPT, Claude, Copilot, Gemini "and others". The repository is not a product with a UI. It is a directory tree of markdown files, plus Python-adjacent tooling in prompt-generators/, scripts/ and skeletons/, with Python listed as the primary language. If you are looking for something to install and run as a service, this is the wrong shape of project, and that is worth knowing before you clone it.

The second audience signal is the EOL section. The README argues that PMs "sweat pricing, P&Ls, business cases, and build/buy/partner decisions" while end-of-life work rarely makes the list, "which is exactly why it goes badly". That is a pointed claim about where the library spends its effort, and it explains why the repository carries a full six-prompt EOL suite rather than one generic sunset template.

Two interaction modes: one-shot prompts and facilitated workshops

The repository splits its assets by how much thinking the user has already done. The README describes the first mode as "I need this artifact, and I have my context ready", pointing at /prompts/. Here you arrive with discovery notes, a win/loss debrief or an inbound request, paste the prompt, and expect execution-quality output in one pass. Examples named in the README include prd-prompt-template, jobs-to-be-done, win-loss-analysis-prompt, stakeholder-map-prompt-template, incoming-request-breakdown, premortem-prompt-template and user-story-prompt-template.

The second mode is /workshops/, described as "I need to think it through, facilitate me". These are guided sessions that end in a finished deliverable rather than a single generated block: battle-card-workshop, prd-workshop, opportunity-solution-tree-workshop, feature-investment-workshop, problem-framing-canvas-workshop, painstorming-workshop and product-sunset-workshop. The distinction matters operationally. A one-shot prompt assumes you can supply context in one message. A workshop assumes you cannot, and walks you through checkpoints instead.

There is a third area, /market-intelligence/, for research tasks the README says should be done "with citations, labeled inference, and no invented facts". That framing is the repository's own quality bar: the prompts are written to demand sourcing from the model rather than accept confident prose. Whether a given assistant honours that is a property of the assistant, not of the markdown file.

The Goldilocks rule and how the EOL suite sizes its output

The most concrete design decision in the README is what it calls "The Goldilocks rule": every prompt asks how complex the sunset is before generating output. Tier 1 covers feature deprecation and gets light-touch artifacts. Tier 2 is a commercial product and gets the standard cross-functional process. Tier 3 covers revenue-critical, hardware or regulated products and gets everything. The stated goal is "coverage proportional to risk, not maximum ceremony".

That is a real constraint on the prompt text, not marketing. A prompt that branches on complexity has to ask the question first and then hold back output, which is harder to write than a prompt that dumps a full template regardless. It also means the same file produces very different artefacts depending on how you answer the tier question, so the first response is a classification step rather than a deliverable.

The EOL suite itself is staged in a specific order: eol-readiness-assessment for the go/no-go call, eol-checklist for the phase-gated operational plan across up to 15 functional areas, eol-stakeholder-sequence for who to talk to and in what order, eol-internal-enablement for support FAQs and sales scripts before the announcement, eol-for-a-product-message for the customer-facing announcement, and product-sunset-workshop for the full facilitated plan. The README's trigger for the first one is the sentence "we should probably kill this", which is a usefully honest description of how these decisions actually start.

Installing it and running a first prompt

There is nothing to install. The README states every asset works by copy-paste into ChatGPT, Claude, Gemini, Copilot or any AI assistant, with "no installs, no accounts, no framework". The practical setup is cloning the repository so you can open the markdown files locally and keep them under version control alongside your own product docs.

git clone https://github.com/deanpeters/product-manager-prompts.git
cd product-manager-prompts
ls prompts workshops market-intelligence

The listing should show three directories of markdown files. If you want the prompt text on screen without opening an editor, the files are plain markdown, so a pager works.

cat prompts/prd-prompt-template.md

Copy the prompt body into your assistant, then supply your own context in the same message. The README's own example of that pairing is "Write a PRD from your discovery notes", which tells you the expected input is notes you already have, not a blank page.

For a task where you do not have context ready, use the workshop variant instead and expect a multi-turn session rather than one response.

cat workshops/prd-workshop.md

The README describes that file as "PRD, section by section with checkpoints", so the assistant should stop and wait at each section rather than emit the whole document at once. If it does not stop, the checkpoint instruction has been lost somewhere in the paste, and that is the first thing to check.

Where the copy-paste model breaks down

The main limitation is the delivery mechanism itself. Because the assets are text you paste, nothing in the repository enforces that the model actually follows the prompt. There is no test harness, no output schema and no validation step described in the README. A prompt that asks for labeled inference in the market-intelligence area depends entirely on the assistant's willingness to comply.

Version drift is the second problem. Prompts tuned for one model behave differently on another, and the README lists ChatGPT, Claude, Copilot and Gemini as targets without claiming identical behaviour across them. The repository does ship prompting-style-guide.md, generative-guidance-pattern.md, interaction-modes.md, jinja2-prompt-structures.md and a prompting-style-guide, which suggests the maintainers think about prompt structure formally, but that is authoring guidance for contributors rather than a compatibility guarantee for users.

The third issue is licensing, and it is the one most likely to catch people out. Release v2.3.0 is titled "The licensing release: MIT → CC BY-NC-SA 4.0". The repository's LICENSE file is reported as NOASSERTION by the hosting platform, which is why LICENSING.md exists at the top level. CC BY-NC-SA 4.0 carries a non-commercial restriction and a share-alike condition. If you were planning to embed these prompts in a paid product, or in internal tooling at a commercial company, that is a question for your own legal review, not something this article can settle. Anyone who adopted an earlier version under MIT should read LICENSING.md before assuming the old terms still apply to the current tree.

How this differs from an agent skills repository

The README points to a companion repository, Product Manager Skills, for people who want "to equip an AI agent rather than a chat session". That is the closest thing to an alternative named in the README, and the difference is architectural rather than cosmetic. A chat-session prompt assumes a human in the loop who pastes context, reads the output and decides what to do next. An agent skill assumes the model is invoked by a runtime that supplies context and consumes the result.

Choosing between the two comes down to where the work happens. If your PRD review is a person pasting notes into a paid chat window, the prompt library fits and an agent skill adds machinery you will not use. If you are building a pipeline that generates artefacts on a schedule, copy-paste is the wrong primitive no matter how good the prompt text is, because there is no interface to call.

The repository also sits apart from generic prompt collections in one respect: it is organised by PM problem rather than by prompt technique. The README's navigation is a list of situations ("I need evidence about the market, not another meeting") with file links underneath. That structure is the actual product. A folder of 119 prompts sorted by category would be harder to use than this one, because you would have to translate your problem into the library's taxonomy first.

Maintenance, contribution and what the release history shows

The last push to the default branch was on 2026-08-10, and the repository is not archived. Two releases are listed: v2.2.0, "The intelligence release", and v2.3.0, "The licensing release: MIT → CC BY-NC-SA 4.0", both dated 2026-07-17. The README banner identifies the content as "Community Build v2.5 • August 9, 2026", which is a version label inside the README rather than a tagged release, so the banner and the release list do not line up exactly.

Upgrade cost is close to zero in the technical sense. There is no package to bump and no migration script. The cost is editorial: if you have adapted prompts into your own templates, a new release does not merge into your copies. You re-read the changed markdown and port the differences by hand. The presence of CHANGELOG.md, COUPLING-REMEDIATION-PLAN.md and several SESSION-SUMMARY files at the top level suggests the maintainers track changes carefully, but the README does not document a rollback path or a deprecation policy for individual prompt files.

Contribution is governed by SUBMISSIONS-GUIDE.md and the prompting-style-guide, with AGENTS.md and CLAUDE.md present for AI-assisted editing of the repository itself. If you plan to fork and maintain your own variant, the share-alike condition in CC BY-NC-SA 4.0 applies to what you redistribute, which is a licensing question rather than a workflow one.

Editorial conclusion

Adopt this if you are a product manager who already pays for a chat assistant and wants structured artefacts such as a PRD, a premortem or an end-of-life plan without writing the scaffolding yourself. Do not adopt it if you need a programmatic pipeline, an agent runtime, or a commercial product built on top of the prompt text: the v2.3.0 licensing release moved the repository from MIT to CC BY-NC-SA 4.0, and the README states every asset works by copy-paste, with no installs, accounts or framework. Before committing, open prompts/prd-prompt-template.md and workshops/prd-workshop.md side by side and check that the output format matches the artefacts your team already reviews, then read LICENSING.md rather than assuming the old MIT terms still apply.

Frequently asked questions

Official sources

1. deanpeters/product-manager-prompts on GitHub
2. Issues
3. README
4. Releases