deanpeters/product-manager-prompts: 119 Prompt Assets, a Licence Change, and a Python Repo That Is Mostly Markdown

The problem is not prompt quality, it is prompt inventory

Most product managers who use an AI assistant regularly end up with a folder of half-remembered prompts. The PRD prompt that worked in March sits in a chat history. The stakeholder map is a screenshot. Nobody versioned any of it, and when a colleague asks how the team frames a build-versus-buy decision, the answer is a link to a thread. This repository addresses that inventory problem rather than the model problem. Its README states the goal plainly: 119 practical prompt assets for AI-assisted product management, working by copy-paste into ChatGPT, Claude, Copilot, Gemini, or any AI assistant, with no installs, no accounts, and no framework. The audience is the working PM who has a deliverable due and a context dump already prepared. The README splits that audience in two. Readers who know the artefact they want go to /prompts/. Readers with a fuzzy situation go to /workshops/, where each file facilitates a session section by section with checkpoints. That split is the organising idea of the whole repository, and it is more useful than a flat list of prompt files sorted by topic.

Two directories, two different interaction models

The prompts directory is one-shot. The README pairs each entry with a trigger condition, for example: write a PRD from your discovery notes goes to prd-prompt-template, and kill the launch on paper before reality does goes to premortem-prompt-template. The workshop directory is multi-turn. prd-workshop walks the PRD section by section with checkpoints, and product-sunset-workshop produces a full facilitated sunset plan in the same gated style. The distinction matters because the two formats fail differently. A one-shot prompt fails by producing generic output when the pasted context is thin. A workshop fails by stalling when the user cannot answer an intermediate question, and the checkpoints exist precisely so the stall is visible rather than buried in a 2,000-word answer. The repository also carries a market-intelligence directory, described in the README as the place where the AI does the fieldwork with citations and labeled inference. That directory includes market-landscape-scan, competitive-research-snapshot, competitive-intel-watch, voice-of-customer-miner, and tam-sam-som-analysis. The README's framing of competitive-intel-watch is the most specific claim in that section: it is meant to run on a schedule and report only material shifts. That is a workflow claim, and whether it holds depends on the prompt text, which the supplied material does not include in full.

The EOL suite is the part with real design in it

End-of-life work is where this repository stops being a prompt list and starts being a method. The README states the premise directly: PMs sweat pricing, P&Ls, business cases, and build/buy/partner decisions, and EOL rarely makes that list, which is exactly why it goes badly. Six assets cover the lifecycle: eol-readiness-assessment for the go/no-go question, eol-checklist as a phase-gated tactical checklist across up to 15 functional areas, eol-stakeholder-sequence for who to talk to and in what order, eol-internal-enablement for the support FAQ and sales scripts and escalation playbook, eol-for-a-product-message for the customer-facing announcement, and product-sunset-workshop for the full facilitated plan. The mechanism that holds the suite together is what the README calls the Goldilocks rule. Every prompt asks how complex the sunset is before generating output. Tier 1, a feature deprecation, gets light-touch artefacts. Tier 2, a commercial product, gets the standard cross-functional process. Tier 3, revenue-critical or hardware or regulated, gets everything. The stated goal is coverage proportional to risk rather than maximum ceremony. That is a genuine constraint encoded in the prompt text rather than a description of one, and it is the strongest evidence in the supplied material that the author has run this process rather than assembled it.

Getting it running: there is nothing to install

The README is explicit that every asset works by copy-paste into ChatGPT, Claude, Gemini, Copilot, or any AI assistant, with no installs, no accounts, and no framework. The workflow it describes is: pick the problem you are solving, grab the prompt, go. In practice that means opening a file such as prompts/prd-prompt-template.md or workshops/prd-workshop.md, copying its contents into a chat session, and supplying your own context alongside it. The naming convention is consistent enough to guess at paths: prompt files live under prompts/ and carry either -prompt-template.md or -prompt.md suffixes, workshop files live under workshops/ and carry -workshop.md, and market research files live under market-intelligence/ with -prompt.md. Two files sit outside those patterns in the README's own listing: prompts/session-saver-prompt.md, described as saving this session's context for the next one, and prompts/agent-strategy-canvas-prompt-template.md, for designing an agentic AI system. The repository's primary language is listed as Python, but nothing in the supplied README describes a Python entry point, a CLI, or a package to install. Treat the Python label as metadata about the repository rather than an instruction about how to use it.

The licence changed, and the metadata did not keep up

Release v2.3.0 is titled, in the release notes, the licensing release, and describes a move from MIT to CC BY-NC-SA 4.0. The README banner for Community Build v2.5 repeats CC BY-NC-SA 4.0. The repository metadata still reports NOASSERTION, which means the licence could not be identified automatically from the repository contents. That discrepancy is worth resolving before anyone builds on this. The practical shape of CC BY-NC-SA 4.0, as the name indicates, is attribution, non-commercial use, and share-alike on derivatives. A prompt file is text, and text is exactly what that licence family was written for, so the choice is coherent. The consequence is that a commercial product team embedding these prompts into an internal tool, or into a paid offering, has a question to answer that the README does not answer. This is not legal advice and the supplied material does not include the LICENSE file itself, so the only safe next step is to read that file directly and route it to whoever handles licensing at your organisation. The move away from MIT is a real reduction in permission, and it happened in a minor version bump.

Where copy-paste prompting stops working

The limitation is structural, not a defect. A prompt file is a document. It has no tests, no version pinning against a model, and no way to detect when a model update changes its output. If a workshop prompt produces worse results after a provider ships a new model, nothing in this repository will tell you. You will notice because a deliverable reads badly. The README's own answer to the agent question is instructive: it points readers who want to equip an AI agent rather than a chat session to a companion repository, Product Manager Skills. That is an honest boundary. This repository is not an agent framework, does not orchestrate tool calls, and does not persist state between sessions. The session-saver prompt exists because context does not survive on its own. The second limitation is context dependency. The README's trigger conditions assume you arrive with material: discovery notes for the PRD prompt, win/loss debriefs for win-loss-analysis, an inbound ask for incoming-request-breakdown. Arrive without that and the prompt has nothing to work on. The third is that tiering logic only helps if the tier question is answered honestly. A team that rates every sunset Tier 3 gets the ceremony the Goldilocks rule was written to avoid.

What it is not: a comparison with agent skill repositories

The clearest alternative is the companion repository the README itself names, Product Manager Skills. The difference is in the unit of work. Here, the unit is a document a human pastes into a chat window, and the human remains the orchestrator: you decide which file to open, you supply the context, you judge the output. In a skills repository, the unit is something an agent loads and invokes, which shifts the orchestration to the agent and changes what you have to specify up front. Neither is strictly better. The prompt-file approach has a lower floor: anyone who can copy text can use it today, and the output lands in a chat you can read and correct. The skills approach has a higher ceiling but requires a runtime and a working agent loop. For a PM preparing a single PRD, the copy-paste route is faster. For a team that wants EOL checks to run as part of a release process without a person remembering to open a file, the prompt collection is the wrong shape and the README says so. A second alternative is simply writing your own prompts, which is what most people do until the inventory problem described in the first section catches up with them.

Maintenance cost and who this is actually for

The last push recorded for this repository is 2026-08-10, and the README banner identifies the current build as Community Build v2.5 dated August 9, 2026, with v2.3.0 and v2.2.0 both released on 2026-07-17. That is an active maintenance cadence over the supplied window, and the v2.2.0 title, the intelligence release, suggests feature work rather than typo fixes. The upgrade cost for a user is close to zero in the technical sense: there is no dependency to bump, no migration script, and no API surface. The real cost is re-reading the files you have adapted, because a prompt you have already customised for your organisation will silently diverge from the upstream version. The sensible practice is to keep your edited copies under your own version control and diff them against upstream at each release, which is a documentation problem rather than an engineering one. As for fit: an individual PM or a small product team that wants structured artefacts without building a library from scratch is the intended user, and the EOL suite is the strongest reason to start there. A platform team looking for an agent runtime should go to the companion skills repository instead. A commercial team should resolve the licence question before adopting anything.

Editorial conclusion

Adopt this if you are an individual product manager or a small team that wants structured artefacts (PRDs, EOL plans, battle cards) without building a prompt library from scratch, and if non-commercial use matches how you work. Do not adopt it as an agent runtime: the README points to a separate Product Manager Skills repo for that, and this repository is a prompt collection, not an execution framework. Before relying on it, verify two things yourself: the actual contents of the LICENSE file, since the metadata reports NOASSERTION while the README banner and the v2.3.0 release title both state CC BY-NC-SA 4.0, and whether your organisation can accept a non-commercial share-alike licence on internal tooling, which is a question for your legal team rather than for this article.

Official sources

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