By PromptLeadz · Reading time 17 minutes · 50 prompts across 5 categories · Calibrated for 2026 frontier models

What separates the PM from the PM-influencer

Product management is one of the most LinkedIn-saturated disciplines in tech. Threads about customer obsession, falling in love with the problem, the magic of the MVP, default to action, and first-principles thinking get tens of thousands of likes. The threads describe a vibe. The actual job is shipping decisions.

A PM's primary job is producing decision-grade artifacts: PRDs that engineering can build from, trade-off memos that survive exec review, roadmap narratives that align cross-functional commitments, kill criteria that prevent zombie projects, A/B test designs that produce decisions, scope-cut docs that name what got dropped, post-launch retros that produce structural change. None of these artifacts look exciting on a screenshot. All of them compound.

Six dimensions separate the PM voice from the PM-influencer voice. Substance: the PM names the specific user, edge case, and dependency; the influencer names the disposition (customer-obsessed, bias-to-action, first-principles). Trade-offs: the PM names what is being asked of engineering, design, and the customer; the influencer says "and" instead of "or". Numbers: the PM opens with the metric, the cohort, the impact; the influencer opens with the philosophy story. Ownership: the PM names the owner and the date; the influencer names the team. Tone: the PM writes flat memos engineering can build from; the influencer writes narrative arcs that go viral. Audience: the PM writes for the engineering review, the exec escalation, and the customer cohort; the influencer writes for the algorithm.

Both voices exist in the wild. Only one survives the engineering review, the exec escalation, and the post-launch retro. This pack is calibrated for the first; it explicitly rejects the second at the prompt level by banning the genre's signature phrases inline. Output reads like a memo from a PM who has just defended a roadmap in front of finance, not a thread from a personal-brand PM who has not.

Five categories. The PM workflow end to end.

The five categories map to the five operating disciplines that determine whether a product team ships compounding value or shelfware. Discovery and Customer Research comes first because deciding what to build is upstream of every other decision. Strategy and Roadmap comes second because sequencing and trade-offs are where the leverage is. Specs and Execution comes third because PRDs and edge cases are where ideas become buildable. Stakeholder Comms comes fourth because cross-functional alignment is what determines whether the org understands what is shipping. Metrics and Iteration comes fifth because the discipline of measuring and killing is what separates compounding products from feature graveyards.

Most PMs who fail to compound do so by skipping the unglamorous categories: trade-off memo discipline, kill criterion memos, edge case enumeration, scope-cut docs, structural retros. The thread-genre PM skips these in favor of "customer obsession" content; the actual PM does these because they are the leverage.

1. User interview prep that earns honest answers

Product area: [paste]. Hypothesis to test: [paste]. Interviewee: [paste role, segment, tenure]. Draft a 400-word interview plan: the open questions sequenced from past behavior to current pain (no leading questions), the listen-for items per question, the disqualifying answers that would falsify the hypothesis, the close (no pitching the solution), the synthesis approach. Interview plans that pitch the solution produce confirmation bias not learning.

2. Jobs-to-be-done analysis from interview transcripts

Transcripts: [paste]. Domain: [paste]. Draft a 500-word JTBD analysis: the named functional jobs (with frequency and importance), the emotional jobs (status, anxiety, identity), the social jobs, the current solutions and their gaps, the trigger events that drive the job, the desired outcome named in the user's words. JTBD analyses that conflate job with solution produce features no one asked for.

3. Problem validation memo with falsifiable hypotheses

Problem hypothesis: [paste]. Evidence so far: [paste]. Open questions: [paste]. Draft a 500-word validation memo: the falsifiable hypothesis named ("users in segment X experience Y problem with frequency Z"), the validation method (interviews, instrumentation, survey, prototype), the kill criterion (the data that would tell us the problem is not real), the timeline, the named owner. Problem validation memos that cannot be falsified produce confirmation bias.

4. Persona memo with named decision criteria

Segment: [paste]. Available data: [paste]. Draft a 400-word persona memo: the role and seniority, the trigger event that creates the buying or adoption need, the alternatives they currently use, the decision criteria (named, ranked), the sources they trust, the channels they engage on, the rejection criteria (what would make them not adopt). Personas without rejection criteria produce marketing that targets everyone.

5. Customer feedback synthesis with severity ranking

Feedback corpus: [paste source and volume]. Period: [paste]. Draft a 500-word synthesis: the top three themes ranked by frequency and severity, the named accounts or users behind each theme (with revenue impact where relevant), the disagreement signals (where users want opposite things), the implication for product (in-plan, deferred, declined, exploration), the cadence of the next synthesis. Customer feedback synthesis without severity ranking produces flat lists that drive no decisions.

6. Opportunity sizing memo with named assumptions

Opportunity: [paste]. Available data: [paste]. Draft a 500-word sizing memo: the addressable users with the named criteria, the pricing assumption, the conversion or adoption assumption, the resulting opportunity size, the named assumptions ranked by uncertainty, the validation approach for the most uncertain assumptions, the kill criterion. Opportunity sizing without named assumptions produces numbers leadership cannot debate.

7. Win-loss analysis from CRM and notes

Recent deals: [paste with stage, outcome, segment]. Sales notes: [paste]. Draft a 500-word win-loss analysis: the win patterns (segment, use case, competitive setup), the loss patterns (with the named cause: capability, price, timing, vendor consolidation), the gaps in our position, the gaps in our messaging, the actions for product and for marketing, the cadence of the next review. Win-loss analyses that lump losses as "competitive" miss the actual cause.

8. Competitive feature comparison with honest gaps

Competitor: [paste]. Our product: [paste]. Recent customer signals: [paste]. Draft a 500-word comparison: the dimensions that matter to the customer (not the dimensions we are good at), the honest assessment per dimension (lead, parity, gap, no fit), the strategic implication of each gap, the response (close, ignore with rationale, structural reposition), the named owner. Competitive comparisons written to make us look good produce blind spots.

9. User research findings to product implication memo

Research output: [paste]. Stakeholders: [paste]. Draft a 500-word implication memo: the top three findings with the evidence, the named product implication per finding (specific feature or change, not generic), the priority assessment, the dependencies, the timeline, the open questions. Research findings handed off without product implications produce shelved insights.

10. Discovery sprint plan with kill criteria

Hypothesis: [paste]. Time available: [paste]. Resources: [paste]. Draft a 500-word sprint plan: the falsifiable hypothesis, the methods sequenced (desk research, interviews, prototype, instrumentation), the day-by-day plan, the kill criterion at each gate, the deliverable at the end (decision memo, not just a research summary), the named decision-maker who acts on the output. Discovery sprints without kill criteria produce extended research that never resolves into a decision.

11. Product vision memo tied to measurable outcome

Product: [paste, current state, market position]. Time horizon: [paste]. Draft a 500-word vision memo: the named outcome (the customer change in 3 years stated specifically), the measurable indicators that prove progress, the bets that ladder to the outcome (named, sequenced), the bets we are not making (with rationale), the assumptions that would invalidate the vision, the cadence of vision review. Vision memos without measurable indicators produce inspiration that no team can ship to.

12. OKRs that survive board review

Quarter or year: [paste]. Strategic priorities: [paste]. Draft a 500-word OKR draft: three to five objectives stated as outcomes (not activities), three to four key results per objective with the metric and target, the rationale per target (the basis for the number, not aspiration), the dependency map, the explicit trade-offs (what is being deprioritized to enable these), the cadence of OKR review. OKRs that read like activity lists produce status meetings not decisions.

13. Roadmap narrative with named dependencies

Time horizon: [paste, e.g. next 2 quarters]. Bets in scope: [paste]. Draft a 600-word roadmap narrative: the headline thesis (what the user will be able to do at the end), the named bets sequenced with rationale, the dependencies between bets, the cross-functional dependencies (eng capacity, design, data, ops), the kill criteria per bet, the explicit cuts from this period (what was deferred and why), the asks of leadership. Roadmap narratives that read as a feature list produce roadmaps no one rallies around.

14. Prioritization memo with explicit trade-offs

Candidate items: [paste with rough effort and impact]. Constraints: [paste]. Draft a 600-word prioritization memo: the framework used (RICE, ICE, weighted scoring, with the inputs honest), the ranking with the rationale per item, the named cuts from the list (with the rationale), the dependency map, the resourcing implication, the named decision-maker who signs off. Prioritization memos that hide the trade-off produce roadmaps that crumble at first slip.

15. Build, buy, or partner decision memo

Capability needed: [paste]. Strategic context: [paste]. Available options: [paste]. Draft a 600-word decision memo: the strategic thesis (why this capability matters), the build option with cost, time, and team implications, the buy option with vendor candidates, cost, integration cost, the partner option with structure and dependency risk, the recommended option with rationale, the kill criterion, the named decision-maker and date. Build-buy-partner memos that omit the kill criterion produce stalled decisions.

16. Market positioning memo for new product or wave

Product or feature: [paste]. Target segment: [paste]. Competitive context: [paste]. Draft a 500-word positioning memo: the named target user, the alternative they currently use, the unique value (the specific outcome we deliver they cannot get elsewhere), the messaging anchor, the proof points required, the rejected positioning options with rationale. Positioning memos without rejected options miss the most important strategic clarity.

17. Competitive landscape memo with strategic posture

Market: [paste]. Time horizon: [paste]. Draft a 600-word landscape memo: the named competitors classified (leader, challenger, niche, adjacent), the moves each competitor is making, the implications for our roadmap, the strategic posture per competitor (compete head-on, differentiate, ignore, partner), the named decision-makers per posture, the cadence of landscape review. Competitive landscapes without explicit posture per competitor produce reactive product decisions.

18. Sequencing rationale for multi-bet roadmap

Bets in scope: [paste with effort and dependency]. Constraints: [paste]. Draft a 500-word sequencing memo: the dependency graph, the rationale for the order (why this before that), the parallel work where possible, the critical path with named risks, the buffer assumption, the named decision-maker for re-sequencing if the path shifts. Sequencing without explicit rationale produces roadmaps that get re-shuffled every standup.

19. Cross-team dependency map for roadmap commitments

Roadmap commitments: [paste]. Dependent teams: [paste]. Draft a 500-word dependency map: the named dependency per commitment (team, output, timing), the risk per dependency (capacity, prioritization, technical), the named owner on the dependent team, the escalation path if the dependency slips, the cadence of dependency review. Dependency maps without named owners produce surprise misses.

20. Kill criterion memo for projects in flight

Project: [paste, current state, original thesis]. Recent signals: [paste]. Draft a 500-word kill criterion memo: the original thesis stated, the current evidence (supporting and contradicting), the kill criterion stated as a falsifiable signal ("if metric X is below Y by date Z, kill"), the path forward if the kill criterion is hit (graceful exit, not abandonment), the named decision-maker, the cadence of review. Projects without kill criteria produce zombie features that drain capacity.

Most product management advice circulating on LinkedIn is content marketing. The work that actually compounds is the work that does not screenshot well.PromptLeadz Product Manager Pack

21. PRD outline with edge cases enumerated

Feature or capability: [paste]. User segment: [paste]. Acceptance bar: [paste]. Draft a 700-word PRD outline: the user problem stated specifically, the proposed solution, the user stories with named acceptance criteria, the named edge cases (typically the ones engineers will ask about: empty states, error states, latency, race conditions, permissions, rollback), the explicit non-goals, the dependencies, the success metrics, the open questions. PRDs that skip edge cases produce specs engineering re-writes.

22. User story acceptance criteria that hold up

User story: [paste]. Context: [paste]. Draft 5 to 8 acceptance criteria: each stated as a testable Given/When/Then or equivalent, each covering one behavior, the negative cases included, the data conditions named, the user permission states named, the device or browser caveats where relevant. Acceptance criteria written as wishes (not testable) produce stories engineering will not estimate.

23. Scope reduction memo with kept and cut named

Original scope: [paste]. Constraint: [paste, e.g. ship in 4 weeks not 12]. Draft a 500-word scope reduction memo: the kept slice with the named user value, the cut items named with rationale ("this is deferred because"), the user impact of the cuts honestly, the staged plan for the cut items, the named decision-maker who signs off. Scope reductions that hide what got cut produce surprise gaps at launch.

24. Design brief with constraints called out

Feature: [paste]. User segment: [paste]. Engineering and platform constraints: [paste]. Draft a 500-word design brief: the user problem, the named constraints (technical, brand, accessibility, performance), the named non-goals, the inspiration or precedent, the success measure for the design (specific user outcome, not aesthetic preference), the timeline, the named design owner. Design briefs without constraints produce reviews that surface constraints late.

25. Engineering trade-off doc for technical decision

Decision: [paste, e.g. monolith vs microservice, build vs library]. Context: [paste]. Draft a 600-word trade-off doc: the named options, the trade-off matrix (performance, cost, time, maintenance, team familiarity), the recommended option with rationale, the rejected options with rationale, the named risks of the recommended option, the kill criterion that would force a re-evaluation, the named decision-maker. Trade-off docs that hide the rejection rationale produce decisions that get re-debated.

26. Beta criteria memo with kill threshold

Beta scope: [paste]. Cohort: [paste]. Draft a 500-word beta criteria memo: the named admission criteria for the cohort, the success criteria (specific metric thresholds), the kill threshold (the metric values that would stop the beta), the cadence of review, the named decision-maker for graduation, the comms plan for the cohort, the rollback plan. Betas without kill thresholds produce extended exposure to a broken feature.

27. Launch readiness checklist with named owners

Launch: [paste, scope, date]. Cross-functional teams: [paste]. Draft a 500-word readiness checklist: the named items per function (eng, design, data, support, sales, marketing, legal, finance), the named owner per item, the status criteria (red/yellow/green with the threshold), the go/no-go criteria, the decision-maker, the rollback plan with named owner. Launch readiness checklists without named owners produce launches with surprise gaps.

28. Release notes that survive customer reading

Release: [paste, scope]. Audience: [paste segment]. Draft 200-word release notes: the headline (the user benefit, not the feature name), the specific change, the named limitations or known issues, the actions the user can or should take, the link to the full doc, the contact for questions. Release notes that read as feature lists produce confused customers.

29. Engineering runbook for new feature

Feature: [paste]. Operational complexity: [paste]. Draft a 500-word runbook: the named monitoring signals (with thresholds), the named alert routes, the playbook for common failure modes, the rollback procedure with named owner, the post-incident review trigger. Runbooks written as afterthought produce on-call confusion.

30. Decision log entry for product trade-off

Decision: [paste]. Context and constraints: [paste]. Draft a 300-word decision log entry: the date, the decision stated specifically, the alternatives considered with rationale for rejection, the named decision-maker, the assumptions that would invalidate the decision, the next review date. Decisions made verbally without a log produce future re-debates.

31. Exec update with the trade-off named

Period: [paste]. Audience: [paste]. Draft a 400-word exec update: the headline outcome in one sentence (with the metric or shipped scope), the wins with the named owner on team, the open issues with the named path forward, the trade-off the team is making (specific, not generic), the ask of the executive (specific decision or unblocking), the next checkpoint. Exec updates that read as activity lists produce executives who skim.

32. Engineering team weekly note

Team: [paste]. Week: [paste]. Draft a 400-word weekly note: the headline (what shipped, what is shipping next), the open blockers with named owner and ask, the open risks with the threshold to escalate, the team capacity reality (slack, overload, named gaps), the explicit asks of the team, the asks of the PM. Weekly notes that omit blockers produce silent slips.

33. Sales enablement brief for new feature

Feature: [paste]. Target segment: [paste]. Competitive context: [paste]. Draft a 500-word enablement brief: the user problem stated in customer language, the value framed in their KPI, the qualification criteria (who this is for, who this is not for), the discovery questions, the objection handling with the honest answer, the demo flow, the supporting collateral. Enablement briefs that hand sales a feature list produce discovery calls that miss qualification.

34. Support handoff doc to prevent escalations

Feature: [paste]. Common issues anticipated: [paste]. Draft a 500-word handoff doc: the user-facing changes, the FAQ with answers (the questions support will get on day one), the troubleshooting tree, the escalation criteria with the named owner on PM and engineering, the metrics support should watch, the cadence of feedback to product. Handoffs to support without an FAQ produce escalations PM did not anticipate.

35. Internal launch announcement with actual scope

Launch: [paste, scope]. Audience: [paste internal]. Draft a 400-word announcement: the user benefit in one sentence, the actual shipped scope (with what got cut from the original plan named), the people who built it (named credit), the cross-functional asks for launch week, the metrics we will watch, the next iteration plan. Internal launches that overstate scope produce credibility damage when others find the gaps.

36. Exec escalation when launch is at risk

Launch: [paste]. Risk: [paste, e.g. capacity, technical blocker, dependency slip]. Draft a 400-word escalation: the issue in the first sentence with the dollar or strategic impact named, the action the team is taking, the request of the executive (specific decision: re-prioritize, add capacity, accept slip, accept reduced scope), the consequence of inaction in named timeframe, the next checkpoint. Exec escalations that bury the impact in narrative produce executives who deprioritize.

37. Board readout for product progress

Period: [paste]. Audience: [paste board profile]. Draft a 500-word readout: the strategic frame in one paragraph, the quantified progress on the named bets, the open risks (with management response), the strategic decisions made this period, the asks of the board (input, capital, executive time), the next quarter focus. Board readouts that read as activity lists miss the strategic conversation the board wanted.

38. Cross-team alignment doc for shared initiative

Initiative: [paste]. Teams involved: [paste]. Draft a 500-word alignment doc: the shared outcome (what will be true at the end), the named commitments per team with owner and date, the dependency map, the decision rights (who decides what), the escalation path, the cadence of review. Cross-team initiatives without explicit decision rights produce coordination thrash.

39. Exec prep memo for a tough product conversation

Conversation: [paste topic, audience]. Context: [paste]. Draft a 400-word prep memo: the audience's stated priorities, the audience's likely concerns, the open questions to ask, the position to defend, the trade-offs to acknowledge, the asks to make, the worst-case scenarios and the response. Prep memos written as our talking points miss the audience's actual concerns.

40. Customer-facing change announcement

Change: [paste]. Customer segment: [paste]. Draft a 300-word announcement: the change stated in user terms in the first sentence, the user benefit, the named limitations or known issues, the action the user must or should take, the support resource, the timeline. Customer announcements that lead with our reasoning miss the user perspective.

41. North-star metric definition tied to retention

Product: [paste current metrics]. Strategic priority: [paste]. Draft a 500-word definition memo: the candidate metric stated specifically (not "engagement"), the linkage to retention and revenue, the formula, the segments where it is meaningful, the gaming risks named, the cadence of review, the named owner. North-star metrics defined as vanity engagement produce teams optimizing the wrong thing.

42. Funnel analysis with named drop-off causes

Funnel: [paste stages and current numbers]. Period: [paste]. Draft a 500-word analysis: the conversion at each stage with the historical comparison, the segment cuts (where conversion differs by segment), the hypothesized causes per major drop-off (with evidence), the proposed experiments, the resourcing ask. Funnel analyses that report the rates without hypothesized causes produce no decisions.

43. A/B test design with explicit kill criteria

Hypothesis: [paste]. Variants: [paste]. Population: [paste]. Draft a 500-word test design: the falsifiable hypothesis, the primary metric, the secondary metrics (guardrails), the sample size with statistical power, the duration, the kill criteria (what would stop the test), the decision criteria (what would ship the variant), the named owner. A/B tests run without kill criteria produce zombie tests with no decision.

44. Retention diagnosis with named cohort cause

Retention curves: [paste]. Recent product changes: [paste]. Draft a 500-word diagnosis: the cohort comparison (where retention is improving or declining), the hypothesized cause per cohort (onboarding, feature gap, value gap, competitive, lifecycle), the evidence per hypothesis, the recommended actions ranked, the kill criterion for the actions, the cadence of review. Retention diagnoses without named cohort causes produce broad initiatives that miss the actual issue.

45. Post-launch retro with structural lesson

Launch: [paste, planned vs actual]. Cross-functional team: [paste]. Draft a 600-word retro: the planned outcome vs actual, the wins with structural source (process, team, capability), the misses with structural cause (not blame), the structural changes for next time (specific, not generic), the named owner per change, the cadence of follow-up. Retros that produce no structural changes produce the same misses next launch.

46. Churn signal review across the cohort

Cohort: [paste segment, period]. Churn data: [paste]. Draft a 500-word review: the churn rate with the historical comparison, the named causes (with frequency and revenue weight), the segment patterns, the leading indicators identified, the actions for product (retention features, lifecycle), the actions for CS (intervention), the named owners. Churn reviews without named cause analysis produce broad retention initiatives that miss the actual churn driver.

47. Feature kill memo with data named

Feature: [paste, scope, launch date]. Performance: [paste]. Draft a 500-word kill memo: the original thesis stated, the actual data (adoption, retention, revenue, support load), the gap explanation, the cost of keeping vs killing, the user impact of killing with the migration plan, the named decision-maker, the cadence of comms. Feature kills handled without explicit data and migration plan produce user revolt and team morale damage.

48. Scope creep diagnosis mid-sprint

Sprint: [paste, original scope, current state]. Reasons for creep: [paste]. Draft a 400-word diagnosis: the named additions with the source (user feedback, exec request, technical surprise), the assessment per addition (in scope, defer, decline), the recommended action, the named decision-maker, the structural change to prevent recurrence. Scope creep handled silently produces missed sprints and burnout.

49. Roadmap re-prioritization memo mid-quarter

Quarter: [paste]. Triggering event: [paste]. Original roadmap: [paste]. Draft a 600-word re-prioritization memo: the trigger named (market signal, capacity loss, dependency miss, exec direction change), the assessment of impact, the proposed re-sequence with rationale, the cuts from the original plan with named user impact, the comms plan for the team and stakeholders, the named decision-maker. Mid-quarter re-prioritization handled by rumor produces team morale damage.

50. OKR scoring memo for end-of-quarter review

Quarter: [paste]. OKRs: [paste with target and actual]. Draft a 500-word scoring memo: the score per key result with rationale, the structural lessons (what the team learned about its capacity, sequencing, market), the named misses with cause, the named overshoots with cause, the implications for the next quarter's OKRs, the named owner. OKR scorings that report numbers without structural lessons produce repeated patterns next quarter.

How the prompts fit a real PM week and quarter

Daily: backlog grooming with engineering, customer signal triage, blocker resolution. The daily discipline is where small drift gets caught before it becomes a sprint miss.

Weekly: exec update, engineering team note, sprint review, sales and support sync, customer feedback synthesis. The weekly cadence is where alignment gets re-established.

Monthly: roadmap re-baseline, dependency review, OKR check-in, competitive pulse, customer cohort review. The monthly cadence catches drift before it becomes a quarterly miss.

Quarterly: OKR scoring, roadmap commit for next quarter, post-launch retros for shipped work, kill review for in-flight projects, cross-team alignment for next-quarter dependencies. The quarterly cadence is where the PM job actually shows.

Annually: product vision refresh, segmentation review, build-buy-partner decisions for the next year, executive sponsor review, structural team and capacity review. The annual cadence is where the strategy gets calibrated.

A good PRD names the edge cases. A good roadmap names the cuts. A good kill memo names the threshold. The job is decision work with named owners. The threads about the job are not.PromptLeadz Product Manager Pack, Section 6

Five mistakes that wreck PM prompts

1. Filling in the prompt with vibes instead of dependencies, dates, and named owners. The prompts ask for the cohort, the metric, the named eng owner, the named exec sponsor, the date. Filling with "important", "high-priority", "strategic" produces output of the same low calibration that engineering will reject. The discipline is putting the actual dependencies and dates into the inputs.

2. Treating the output as the final PRD. The prompts produce drafts. The actual PRD is the draft after you have edited it for accuracy, removed the LLM-cliche phrasing, verified that every dependency exists, and checked the edge cases against the actual codebase. Shipping the LLM draft directly to engineering is reckless.

3. Skipping the prompts that ask uncomfortable questions. The kill criterion memo, the rejected positioning options, the structural retro, the honest competitive gap assessment. The avoided prompts are usually the ones with the most leverage. Notice the avoidance.

4. Sharing the LLM draft externally without redaction. The prompts produce internal artifacts naming roadmap dependencies, competitive positioning, and revenue at stake. The outputs should not leave the product organization without explicit review and the customer-facing redaction step.

5. Running the PM-influencer prompts instead of these. Prompts that produce "customer obsession" content reinforce the genre this pack rejects. Calibration to the LinkedIn-thread voice produces threads, not PRDs.

Sources and further reading

The pack draws on a body of public work from senior product leaders. Recommended reading for PMs who want depth beyond the threads.

Marty Cagan, Inspired, remains the clearest book on what product discovery and product strategy actually look like inside a working product organization, with the operating model that most modern product orgs ladder back to.

Teresa Torres, Continuous Discovery Habits, is the most rigorous treatment of weekly customer touchpoints and opportunity mapping, especially the framework for moving from interviews to a structured opportunity tree.

Lenny Rachitsky's writing at lennysnewsletter.com is the most consistently useful contemporary writing on the operational details of PM work, especially the templates and case studies from working operators.

John Cutler's writing at cutlefish.substack.com covers the operating-model and team-design side of product management, including the structural patterns that produce stuck product orgs.

About PromptLeadz

PromptLeadz publishes free component-built prompt packs and the production-grade Drop-in utilities that wrap them. The franchise covers role-based packs (PM, EM, CSM, Sales Leader, Operator, Data Analyst, VC), format-based packs (.md agent files in breadth and depth), and the underlying frameworks (the 8-Component Skeleton, the Anti-Prompt-Engineering Manifesto).

Every pack rejects the LinkedIn-influencer voice at the prompt level by banning the genre's signature phrases inline. The result is output calibrated for memos that survive peer review, not threads that go viral. Free packs ship with no email gate at promptleadz.com.

Questions people ask

Who is this product manager prompt pack for?

Product managers, senior PMs, group PMs, and heads of product at B2B and consumer software companies. Most useful for PMs of 1 to 5 product surface areas working with engineering and design teams of 5 to 50.

Does it work for early-stage PMs and senior PMs?

Yes for both, with calibration. Early-stage PMs lean on the PRD outline, beta criteria, and launch readiness prompts. Senior PMs lean on the roadmap narrative, trade-off memo, and kill criterion prompts.

Why does the pack ban phrases like customer-obsessed and first principles?

Both are legitimate ideas reduced to LinkedIn cliches. The pack bans the cliche framing because it produces low-calibration output that performs vision rather than naming the trade-off, the dependency, or the kill criterion.

What output format do the prompts produce?

PRD register: flat, factual, named edge cases, specific dependencies, specific owners and dates. The opposite of LinkedIn-thread register.

How does this pair with other PromptLeadz packs?

Pairs with the 8-Component Skeleton framework as the foundation, the Engineering Manager Pack for cross-functional execution, the Operator Pack for finance and ops dependencies, and the Customer Success Pack for the post-launch lifecycle.

Are these prompts safe to share with my team?

The prompts themselves are free to share. The outputs of the strategy, kill criterion, exec escalation, and competitive prompts are confidential and should stay inside the product organization.

Do these prompts work with Claude, ChatGPT, and Gemini?

Yes for all three. The prompts are built on the 8-component skeleton which works across frontier models.

What is the difference between a PM, a product owner, and a product marketing manager?

A product manager owns strategy and roadmap and works with engineering and design to ship. A product owner is typically a Scrum role focused on backlog grooming. A product marketing manager owns positioning, messaging, and launch.

The franchise: free packs, frameworks, and the manifesto

The thesis: The Anti-Prompt-Engineering Manifesto. The framework: The 8-Component Skeleton.

Free packs, no email gate · Calibrated for 2026 frontier models · promptleadz.com