Prompting as a PM Tool: 6 PM-Specific Prompt Patterns That Compound

Most prompting content is "I asked ChatGPT to write my OKRs and it was amazing." Useless. The PMs who get the most out of LLMs treat prompting as a craft with patterns, not a single chat box they hope into.

This post is the six prompt patterns we teach in ShipSet Lesson 4 ("Prompting as a PM tool") and Lesson 38 ("Prompt iteration loop"). Each pattern solves a real PM problem with a template you can paste tonight. None require a paid tool. None are "be more specific" advice. By the end you have six reusable prompts that compound across every feature you ship.

Why generic prompting advice fails PMs

The Twitter thread version of prompting is "give context, be specific, ask for the format you want." Not wrong, but not useful. Three reasons PMs need PM-specific patterns:

1. PM artifacts have structure. A PRD is not a free-text blob. It has six sections (problem, hypothesis, solution, metrics, edge cases, rollout). A prompt that ignores the structure produces a prose blob you cannot use. A prompt that knows the structure produces sections you can paste into a doc.

2. PMs are reviewing AI outputs, not just generating them. The hardest PM prompt skill is not "write me a thing," it is "critique this thing I wrote." Critique prompts require different scaffolding than generation prompts.

3. PMs care about edge cases more than first drafts. A first draft of a PRD is easy. The hard work is finding the edge case that breaks the feature. PM prompts that systematically enumerate edge cases save the most time and produce the most differentiated work.

The six patterns below solve those problems specifically.

Pattern 1: The structured critique

Use when: you have a PRD, eval set, cost model, or roadmap and need someone to find what is missing.

The mistake everyone makes: "Critique this PRD." The model returns three vague paragraphs about how it could be more specific.

The pattern:

You are a senior PM reviewing a junior PM's draft. Your job is to find weaknesses, not to be encouraging.

Review the PRD below against these criteria, in this order:

1. Problem clarity: Is the user problem stated as a specific person doing a specific thing? Or is it abstract?
2. Success metric: Is the metric measurable in the first week post-launch? Or is it a vanity metric?
3. Edge cases: Are at least 5 edge cases listed? Which one is missing?
4. Rollback plan: If the feature is broken at launch, what is the literal undo button?
5. The one thing: What is the single weakest section that would get this PRD rejected at a senior PM review?

Return one short paragraph per criterion. End with "The one thing to fix first: ..."

Draft PRD: [paste PRD here]

Why this works: the model now has five specific things to check, in a defined order, with a forced ranking at the end. The output is actionable: you know what to fix first, why, and have a structured list of what is good and what is not.

You can adapt this pattern for any artifact. Replace the five criteria with the criteria that matter for that artifact (eval suite, cost model, business case).

Pattern 2: The adversarial edge-case generator

Use when: you have a feature draft and need to find the 5-10 edge cases you will forget to handle until production traffic hits them.

The mistake: "What are the edge cases for this feature?" The model returns the obvious ones (empty input, malformed input) and you knew those.

The pattern:

You are a quality engineer trying to break the feature below. Your goal is to find inputs that produce wrong, embarrassing, or harmful outputs that the PM did not think of.

Generate 10 adversarial edge cases. For each:

• The input (specific text, file, or interaction)
• Why this input is dangerous (1 sentence)
• The expected wrong behavior (what would the feature do wrong if not handled)
• The cost of getting it wrong (legal / reputational / monetary)

Skip obvious cases (empty input, too long). Focus on the 10 that would actually slip past a normal PM's review.

Feature spec: [paste feature description]

Why this works: you forced the model into adversary mode and disqualified the obvious cases. You get back actual adversarial inputs you can add to your eval suite. The "cost of getting it wrong" column is what turns "I should fix this" into "I must fix this before launch."

I have used this prompt to find 3-5 cases per feature that I would have missed. The compound value over a quarter is large.

Pattern 3: The eval rubric scaffolder

Use when: you need to score a generation feature (the model writes prose, summary, code, etc.) and need a rubric to score it consistently.

The mistake: "Score this output 1-10." Inconsistent, noisy, and your scores drift over time.

The pattern:

Build me a 5-criterion scoring rubric for evaluating outputs from this feature: [1-sentence feature description].

For each criterion:

• Name (2-4 words)
• 1-sentence definition
• Anchor examples for score 1, 3, and 5

The criteria should cover: correctness, usefulness, safety, format adherence, and one criterion specific to this feature.

Return as a markdown table with columns: Criterion, Definition, Score 1, Score 3, Score 5.

Why this works: the model now produces a calibrated rubric with concrete anchors at each score level. You can ship this rubric to a teammate and they will score consistently with you because the anchors define what "3" means. This is the difference between gradient eval that works and gradient eval that produces noise.

Save the rubric next to your eval spreadsheet. Reuse it. Iterate the anchors as you discover edge cases.

Pattern 4: The launch communications drafter (4 voices)

Use when: you are launching a feature and need internal Slack copy + customer email + changelog entry + LinkedIn post. Each has a different voice.

The mistake: "Write launch copy for this feature." You get back generic marketing prose that does not fit any channel.

The pattern:

The feature below is launching tomorrow. Draft four pieces of copy, each tuned to its channel:

1. Internal Slack post (140 chars): matter-of-fact, what shipped + link to PR/doc. No emojis.
2. Customer email opening paragraph (50-80 words): empathetic, what problem this solves, no hype.
3. Changelog entry (1 line): technical, what changed.
4. LinkedIn post by the PM who shipped it (3 short paragraphs): humble, what we learned, who helped.

Each piece should reference the feature specifically. Skip "thrilled to announce" and "delighted to share" — those are dead phrases.

Feature: [1-paragraph description] Why we built it: [1-paragraph motivation]

Why this works: each output has a constraint (word count, voice, no-go phrases). The model produces four pieces of copy you can edit in 5 minutes rather than write from scratch in 45.

The "skip dead phrases" line is the highest-leverage instruction in any PM prompt. Once you bank a list of phrases your team has agreed are dead ("delighted to share," "leverage AI," "next-generation," "revolutionary"), feeding that list into every comm prompt saves real editing time.

Pattern 5: The user-research synthesizer

Use when: you have 30 interview notes and need to find the patterns without spending 6 hours re-reading.

The mistake: "Summarize these interviews." You get a paragraph that is too high-level to act on.

The pattern:

You are analyzing customer-research notes. Identify patterns, not summaries.

Below are notes from 30 user interviews about [topic]. For each, find:

1. 5 problem patterns mentioned by 3+ users. For each, quote the most concrete user quote and count how many users said something similar.
2. 3 surprising signals (mentioned by 1-2 users but feel important). Explain why each might matter.
3. 2 user segments that emerged. Define them by what they have in common.
4. The one question I should ask in my next interview. Choose the question that would discriminate between the segments.

Notes: [paste notes here]

Why this works: the prompt forces the model to count occurrences and quote users, not generalize. The "surprising signals" section catches the weak signal that a summary would smooth over. The "next question" output gives you a concrete action coming out of the synthesis.

Pair this with verbatim notes (not summaries) and your synthesis quality jumps. Notes you sanitised before pasting will produce sanitised analysis.

Pattern 6: The roadmap stress-test

Use when: you have a quarterly roadmap and want to find the 3 things that will go wrong before your manager finds them.

The mistake: "Review this roadmap." Model is too polite to push back.

The pattern:

You are an experienced VP of Product reviewing a Q3 roadmap that a PM will present tomorrow. The PM is asking for honest feedback before the meeting.

Identify the 3 weakest things on this roadmap. For each:

1. The item
2. Why it is weak (specific reason, not "needs more detail")
3. The hard question the VP will ask in the meeting
4. A specific concrete suggestion to strengthen it before tomorrow

Skip praise. The PM has 90 minutes before the meeting and needs to fix the worst items, not feel validated.

Roadmap: [paste roadmap]

Why this works: the role (VP) and the framing (hard questions before tomorrow's meeting) push the model out of polite mode. The output is the three things that need fixing tonight. You walk into the meeting having already pre-empted them.

I use this prompt before every quarterly review. It has caught at least one "weak item I had not noticed" every single time.

Why these patterns compound

A pattern is reusable across features. A one-shot prompt is not.

When you have used Pattern 1 (structured critique) on five PRDs, you have an internal sense of which criteria matter most for your domain. You can tune the criteria list for your team. When you have used Pattern 2 (adversarial edge cases) on five features, you start spotting the cases without the prompt. Patterns are scaffolding that produce skill in the long run.

The PMs who treat prompting as patterns ship better artifacts faster every quarter. The PMs who one-shot it from a chat box have the same output quality two years in.

Where these patterns live

Three places:

1. A Notion / Obsidian page called "PM Prompts." Each pattern is a top-level section with the template, an example output, and a one-line "when to use this."

2. Snippets in Claude / Cursor / Raycast. Bind each pattern to a keyboard shortcut. The pattern is one keystroke away when you are mid-thought.

3. Your team's playbook. When a peer PM has a draft PRD and asks "any tips on how to critique it?", you send them Pattern 1. The team's prompting baseline rises.

The one habit that matters more than any pattern

After every prompt, save the version that worked. Tag it with the date and the context (what feature, what artifact). Three months from now you will re-encounter the same problem and the saved prompt is the starting point, not the chat history.

Most PMs treat prompts as throwaway. The 5% who save them have a compounding library of tuned tools by the time they are senior. The other 95% are typing the same prompt from scratch every time.

TL;DR

• Generic prompting advice fails PMs. Patterns tuned to PM artifacts compound.
• Six patterns: structured critique, adversarial edge cases, eval rubric scaffolder, launch comms (4 voices), user-research synthesizer, roadmap stress-test.
• Each pattern has a defined output format that turns vague model responses into actionable artifacts.
• The "skip dead phrases" instruction is the highest-leverage line in any PM prompt.
• Save the prompts that worked. Tag them. Three months later they are starting points, not chat archaeology.

In ShipSet Lessons 4 and 38 you learn to write and iterate prompts as a PM-specific craft. By Day 90 your portfolio includes 5+ tuned prompts as artifacts hiring managers can read. The prompt library is the second-most-cited portfolio piece after the working AI feature.

If you have not started one: open a Notion page right now. Paste Pattern 1. Use it on the next PRD you write. The library starts with one prompt.