Product Manager / Owner

Start here

Widely used and core to this role

• ChatGPT(opens in new tab)

  · AI chat assistant

  General AI assistant for drafting PRDs, presentations and research summaries, and for simple prototypes in chat.

Also worth a look

Depends on your team and stack

Written from the changes above. Read and adapt one before you use it.

• Customer feedback synthesisTurns tickets, surveys, reviews and call notes into themes traced back to the sourcecustomer-feedback-synthesisView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named customer-feedback-synthesis. When to use it: Synthesises high-volume customer feedback from support tickets, survey comments, app or product reviews and sales call notes into themes, with every theme traced back to the original items and a spot-check of the summary against the source. Use when a product manager asks to summarise a large set of customer feedback, find recurring themes or pain points, prepare insight for roadmap or prioritisation discussions, or turn a pile of tickets and comments into evidence for a product decision. For moderated interviews or usability sessions, use the UX research synthesis instead.

  ---
  name: customer-feedback-synthesis
  description: "Synthesises high-volume customer feedback from support tickets, survey comments, app or product reviews and sales call notes into themes, with every theme traced back to the original items and a spot-check of the summary against the source. Use when a product manager asks to summarise a large set of customer feedback, find recurring themes or pain points, prepare insight for roadmap or prioritisation discussions, or turn a pile of tickets and comments into evidence for a product decision. For moderated interviews or usability sessions, use the UX research synthesis instead."
  metadata:
    title: "Customer feedback synthesis"
    summary: "Turns tickets, surveys, reviews and call notes into themes traced back to the source"
  ---
  
  # Customer Feedback Synthesis
  
  Turn scattered customer feedback into traceable themes a product manager can verify before acting on them.
  
  This skill is for feedback at volume, used for prioritisation. A handful of moderated interviews or usability sessions needs a qualitative research synthesis instead, where who said what matters more than counts.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The feedback itself: support tickets, survey comments, reviews or sales call notes, with an identifier for each item.
  - The question the synthesis should answer (for example "why do trial users churn?"), not just "summarise this".
  - Who the feedback comes from: segment, plan, region or product area, and the time period it covers.
  - Whether the data is allowed to be processed here. Confirm the user has checked their company's AI policy for customer data, and ask them to remove personal details they do not need.
  - Any themes the team already believes in, so you can test them rather than repeat them.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Restate the question and the scope (sources, segment, period) in one short paragraph, and confirm it with the user if anything is unclear.
  2. Read every item. Give each an ID if it has none, and note its source type and segment.
  3. Note the need or problem behind each item, not the feature the customer asked for. Keep the customer's own words next to your note.
  4. Group notes into themes. A theme needs at least two independent items; keep single items in an "Unclustered" list instead of forcing them into a theme.
  5. For each theme, list every supporting item ID, pick one or two short verbatim quotes, and describe who raised it (segments, source types).
  6. Look for disagreement: items that contradict a theme, or segments that want opposite things. Record them under the theme.
  7. Compare your themes with the beliefs the team already holds. Mark each belief as supported, contradicted or not covered by this data.
  8. Spot-check your own work: pick at least three themes (or all themes if there are fewer), reopen their source items, and confirm each quote is verbatim and each item really supports the theme. Fix or drop anything that does not hold.
  9. Describe how often something came up only in plain words tied to this dataset ("mentioned in 7 of the 40 tickets reviewed"). Counts are fine for large ticket or survey sets; for a small qualitative sample, describe who raised it instead. Never extrapolate to all customers.
  10. List the open questions that this data cannot answer and suggest how the product manager could find out (for example a follow-up interview).
  
  ## Output format
  
  ```markdown
  # Feedback synthesis: <question>
  
  **Scope:** <sources, segment, period, number of items reviewed>
  **Prepared by:** AI draft for review
  
  ## Themes
  
  ### 1. <Theme name, phrased as a customer problem>
  
  - **What customers are trying to do:** <one or two sentences>
  - **Evidence:** <item IDs>
  - **Who raised it:** <segments, source types>
  - **In their words:** "<verbatim quote>" (<item ID>)
  - **Counter-evidence:** <item IDs and a short note, or "none found">
  
  ## Existing beliefs checked
  
  | Belief | Supported / Contradicted / Not covered | Item IDs |
  | ------ | -------------------------------------- | -------- |
  
  ## Unclustered items
  
  - <item ID>: <one-line note>
  
  ## Spot-check log
  
  | Theme | Items reopened | Result |
  | ----- | -------------- | ------ |
  
  ## Open questions for further research
  
  - <question> — <suggested way to find out>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - A fluent summary is not the same as a correct one. Every claim must point to item IDs a human can open.
  - Loud or repeated feedback from one account can look like a trend. Count distinct customers, not messages, when you can tell them apart.
  - Feature requests are not needs. Keep "they asked for X" separate from "they are struggling with Y".
  - The synthesis informs prioritisation; it does not decide it. Do not rank the roadmap or recommend what to build.
  - Do not invent segments, revenue impact or customer names that are not in the data.
  - Never reproduce secrets, credentials or personal data (names, emails, account details) in the output unless the user needs them; anonymise quotes by default.
  
  ## Before you finish
  
  - [ ] Every theme lists item IDs and at least one verbatim quote.
  - [ ] The spot-check log shows at least three themes (or all, if fewer) rechecked against the source.
  - [ ] Counter-evidence and unclustered items are included, not hidden.
  - [ ] No numbers extend beyond the dataset reviewed.
  - [ ] No recommendation on what to build is presented as decided.
  - [ ] Clearly flag your assumptions and anything a human must review or decide before this is shared or acted on.
  

• AI feature eval criteriaReviews real AI feature use to name failure modes and draft pass/fail quality criteriaai-feature-eval-criteriaView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named ai-feature-eval-criteria. When to use it: Helps a product manager define what good output looks like for an AI feature by reviewing real user interactions, naming failure modes and drafting binary pass/fail criteria to agree with engineering and QA. Use when defining what good output means for an AI feature from real user interactions (error analysis), before building an eval suite.

  ---
  name: ai-feature-eval-criteria
  description: "Helps a product manager define what good output looks like for an AI feature by reviewing real user interactions, naming failure modes and drafting binary pass/fail criteria to agree with engineering and QA. Use when defining what good output means for an AI feature from real user interactions (error analysis), before building an eval suite."
  metadata:
    title: "AI feature eval criteria"
    summary: "Reviews real AI feature use to name failure modes and draft pass/fail quality criteria"
  ---
  
  # AI Feature Eval Criteria
  
  Draft pass/fail criteria for an AI feature, grounded in how it actually fails on real interactions.
  
  This skill stops at the criteria. Building the eval dataset, grading and regression runs is covered by QA's eval plan (`llm-feature-eval-plan`).
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - What the feature is for: the user, the task it helps with, and what a successful outcome means for that user.
  - A sample of real interactions (inputs and outputs), ideally from production or a realistic test group. If none exist, say that criteria written without them are provisional.
  - Confirmation that the sample may be used here under the company's AI and data policy, with personal details removed.
  - Any existing acceptance criteria, product rules, tone guidelines or policies the output must respect.
  - Who the principal domain expert is (often the product manager) and who in engineering or QA will build the evals.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Summarise the feature's purpose and the user's goal in two or three sentences. Confirm it with the user.
  2. Read each interaction in the sample. For each, write a pass or fail judgement and a one-sentence critique saying why. Do not skip the ones that look fine.
  3. Mark every judgement you are unsure about as "needs expert review" rather than guessing.
  4. Group the failure critiques into named failure modes (for example "invents a policy", "ignores the user's constraint", "wrong tone for an upset customer"). Keep the wording specific to this product.
  5. For each failure mode, list the interaction IDs that show it and describe the context in which it happens.
  6. Turn each failure mode into a binary criterion that a reviewer could apply consistently: "Pass if…, Fail if…". Avoid rating scales unless the user asks for them.
  7. For each criterion, suggest how it could be checked: human review, a code-based check (for format, length, required fields) or an AI judge that a human calibrates first. Say which checks need a human.
  8. Suggest which interactions QA could keep as starter test cases, including passes, failures and edge cases. Leave the dataset, grading and regression runs to QA's eval plan.
  9. List what the sample did not cover (user types, languages, rare but risky situations) so the team can collect more.
  10. Draft questions to agree with engineering, such as where the evals run and what result would block a release. Leave the thresholds for humans to set.
  
  ## Output format
  
  ```markdown
  # Eval criteria draft: <feature name>
  
  **Feature goal:** <who it helps and with what>
  **Sample reviewed:** <number of interactions, source, date range>
  **Status:** Draft for domain expert and engineering review
  
  ## Interaction review
  
  | ID  | Pass/Fail/Needs expert review | Critique |
  | --- | ----------------------------- | -------- |
  
  ## Failure modes
  
  ### <Failure mode name>
  
  - **Seen in:** <interaction IDs>
  - **When it happens:** <context>
  - **Why it matters to the user:** <one sentence>
  
  ## Criteria
  
  | #   | Criterion (Pass if… / Fail if…) | Failure mode | Suggested check | Human needed? |
  | --- | ------------------------------- | ------------ | --------------- | ------------- |
  
  ## Starter eval set
  
  - <interaction ID>: <why it is included>
  
  ## Gaps in the sample
  
  - <situation not covered>
  
  ## Questions to agree with engineering
  
  - <question>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Trying a few prompts by hand does not show how a feature fails. Base criteria on the real sample, and say plainly when the sample is thin.
  - Generic criteria like "helpful" or "accurate" cannot be applied consistently. Rewrite them until two reviewers would agree.
  - AI output can differ for the same input. A single pass on a test case is not proof it will always pass.
  - An AI judge needs to be checked against human judgements before anyone trusts it.
  - Do not decide release thresholds, and do not present your pass/fail calls as final. The domain expert makes those calls.
  - Never reproduce secrets, credentials or personal data (names, emails, account details) in the output unless the user needs them; anonymise quotes by default.
  
  ## Before you finish
  
  - [ ] Every interaction in the sample has a judgement and a critique.
  - [ ] Every criterion links to a failure mode seen in real interactions.
  - [ ] Uncertain judgements are marked for expert review.
  - [ ] Gaps in the sample are listed.
  - [ ] No release threshold or ship decision is presented as settled.
  - [ ] Clearly flag your assumptions and anything a human must review or decide before these criteria are used.
  

• Prototype to product gapLists what a tested prototype still needs to become a shippable productprototype-to-product-gapView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named prototype-to-product-gap. When to use it: Reviews a validated prototype or demo and drafts a plain-language gap analysis of what is still needed to turn it into a shippable product, such as untested use cases, reliability, telemetry, performance, data security and compliance, plus open questions for engineering. Use when a product manager has an AI-built or throwaway prototype that tested well and needs to plan next steps, brief engineers, set expectations with stakeholders, or avoid treating a demo as nearly done.

  ---
  name: prototype-to-product-gap
  description: "Reviews a validated prototype or demo and drafts a plain-language gap analysis of what is still needed to turn it into a shippable product, such as untested use cases, reliability, telemetry, performance, data security and compliance, plus open questions for engineering. Use when a product manager has an AI-built or throwaway prototype that tested well and needs to plan next steps, brief engineers, set expectations with stakeholders, or avoid treating a demo as nearly done."
  metadata:
    title: "Prototype to product gap"
    summary: "Lists what a tested prototype still needs to become a shippable product"
  ---
  
  # Prototype to Product Gap
  
  Draft an honest list of what separates a learning prototype from a product customers can rely on, to discuss with engineering.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - What the prototype does: a description, screenshots, a walkthrough, or read access to its code if the user wants you to look.
  - What it was built to learn, and what customers or stakeholders actually said when they tried it.
  - The use cases the prototype covers, and the product area or existing system it would become part of.
  - Known constraints: target users and scale, data involved (especially personal or regulated data), platforms, and any company rules for AI-built code.
  - Who will read the result (engineering lead, stakeholders, leadership) and what decision it should support.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Summarise what the prototype proved and what it did not try to prove. Separate evidence from customer sessions from the product manager's own impressions.
  2. List the use cases the prototype covers. Then draft the use cases a real product would likely need (other user roles, empty and error states, edits, cancellations, permissions, migrations). Mark which are guesses for the team to confirm.
  3. Walk through each product concern below and note what the prototype does today, what is unknown, and a question for engineering:
     - reliability and error handling
     - telemetry and analytics
     - performance at expected scale
     - data security and privacy
     - compliance and legal requirements
     - accessibility
     - integration with existing systems and data
     - support, operations and maintenance
  4. If you were given code, note any shortcuts that are typical of prototypes (hardcoded data, missing authentication, no tests). Describe them as observations, not verdicts on quality.
  5. Decide, with the user, which parts of the prototype are worth keeping as reference (flows, copy, layout) and which should be treated as throwaway.
  6. Draft open questions for engineering and design. Do not produce effort estimates or dates; ask the team for them.
  7. Write a short stakeholder summary that explains the gap without technical jargon and without promising a launch date.
  
  ## Output format
  
  ```markdown
  # From prototype to product: <idea name>
  
  **Prototype built to learn:** <question>
  **What we learned:** <evidence, with source of each point>
  **Status:** Draft for engineering and design review
  
  ## Use cases
  
  | Use case | In prototype? | Needed for product? (confirm) |
  | -------- | ------------- | ----------------------------- |
  
  ## Product concerns
  
  | Concern | Prototype today | Unknowns | Question for engineering |
  | ------- | --------------- | -------- | ------------------------ |
  
  ## Keep as reference vs throwaway
  
  - **Keep:** <flows, copy, patterns>
  - **Throwaway:** <parts not intended for production>
  
  ## Stakeholder summary
  
  <three to five plain sentences>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - A polished prototype can hide how much work a real product takes. Never describe it as "almost done" or suggest the leap is easy.
  - Positive reactions in a demo are not proof of demand or willingness to pay. Keep the evidence and its limits visible.
  - Do not estimate effort, cost or timelines. Those belong to the engineering team.
  - Do not recommend shipping prototype code as-is, and do not deploy, merge or share it.
  - If the prototype used real customer data, flag that for a data policy check.
  - Never reproduce secrets, credentials or personal data (names, emails, account details) in the output unless the user needs them; anonymise quotes by default.
  - Prioritisation is the product manager's call. Present gaps, not a ranked plan.
  
  ## Before you finish
  
  - [ ] Every product concern in step 3 has an entry, even if it is "unknown".
  - [ ] Guessed use cases are marked for the team to confirm.
  - [ ] No effort, date or "nearly done" language appears.
  - [ ] The stakeholder summary matches the detailed sections.
  - [ ] Clearly flag your assumptions and anything a human must review or decide before this is shared.