How do I install the Product Manager skill?

Run npx skillmds@latest add barastrong/product-manager in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Product Manager safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Product Manager?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Product Manager free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Product Manager?

barastrong (@barastrong) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Product Manager by barastrong — Agent Skill

Name: Product Manager
Rating: 4.666666666666667 (3 reviews)
Author: barastrong

Product Manager

Use when defining product requirements, managing backlogs, prioritizing features, writing PRDs, or driving product strategy. Trigger phrases: "product manager", "PRD", "product requirements", "backlog", "roadmap", "feature prioritization", "user story", "product strategy", "OKR", "product discovery", "go-to-market", "product metrics", "sprint planning", "product backlog", "MVP", "product vision", "stakeholder alignment".

barastrong Updated Sep 22, 2026

File contents

Product Manager (Tech/IT)

Role Summary

A Technical Product Manager defines what the product should do and why, aligning business strategy, user needs, and technical constraints. The role drives product discovery, manages the backlog, and ensures the engineering team builds the right things.

Core Responsibilities

Define product vision, strategy, and roadmap
Write Product Requirements Documents (PRDs) and user stories
Manage and prioritize product backlog
Conduct product discovery (user interviews, market research, competitive analysis)
Define success metrics (OKRs, KPIs, North Star metrics)
Facilitate sprint planning, backlog refinement, and stakeholder reviews
Coordinate go-to-market for new features
Analyze product usage data and iterate
Manage stakeholder expectations and communicate product decisions

Standard Workflow

Discovery — user interviews, analytics review, competitive analysis, market research.
Problem Definition — problem statement, user persona, job-to-be-done.
Solution Design — collaborate with design and engineering on solutions.
Requirements — PRD: context, user stories, acceptance criteria, edge cases, metrics.
Prioritization — RICE, MoSCoW, or value vs. effort matrix.
Development — answer questions, unblock engineering, protect scope.
Launch — go-to-market coordination, feature flags, comms.
Post-Launch — measure against defined success metrics, iterate.

Technology Stack

Layer	Tools
Roadmap	Productboard, Aha!, Linear, Notion, Jira
Analytics	Mixpanel, Amplitude, PostHog, GA4, Heap
Research	Dovetail, Maze, UserTesting, Notion
Collaboration	Figma, Confluence, Notion, Miro, Coda
Communication	Slack, Loom, Notion

Prioritization Frameworks

Framework	When to Use
RICE (Reach, Impact, Confidence, Effort)	Feature prioritization with data
MoSCoW	Release scope definition
Kano Model	Understanding user satisfaction
Value vs. Effort	Quick team alignment
Jobs-to-be-Done	Deep user problem framing

Best Practices

Outcome over output: "increase activation rate by 15%" > "build onboarding flow".
Start with the problem, not the solution.
PRDs describe what and why, not how (that's engineering's domain).
Ruthless prioritization — say no more than yes.
Data-informed decisions: instrument before you iterate.
Small, frequent releases over large infrequent ones.
Always communicate "why" to engineering — context enables better decisions.
Regular stakeholder communication to prevent surprise escalations.

Anti-Patterns to Avoid

HiPPO-driven product (Highest Paid Person's Opinion over user research).
Feature factory: shipping features without measuring outcomes.
Roadmap as a commitment rather than a hypothesis.
Requirements that specify implementation instead of outcome.
Ignoring technical debt in prioritization.
No success metrics defined before launch.

References

references/prd-template.md — Product Requirements Document template
references/discovery-research-guide.md — user research methods
references/metrics-framework.md — product metrics and OKR framework

Expected Output Format

PRD (context, problem, user stories, acceptance criteria, metrics)
Prioritized backlog (with rationale for ordering)
Roadmap (quarterly, with confidence levels)
Post-launch metrics report (vs. targets defined pre-launch)

---name: product-managerdescription: > Use when defining product requirements, managing backlogs, prioritizing features, writing PRDs, or driving product strategy. Trigger phrases: "product manager", "PRD", "product requirements", "backlog", "roadmap", "feature prioritization", "user story", "product strategy", "OKR", "product discovery", "go-to-market", "product metrics", "sprint planning", "product backlog", "MVP", "product vision", "stakeholder alignment".---# Product Manager (Tech/IT)## Role SummaryA Technical Product Manager defines what the product should do and why,aligning business strategy, user needs, and technical constraints. The roledrives product discovery, manages the backlog, and ensures the engineeringteam builds the right things.## Core Responsibilities- Define product vision, strategy, and roadmap- Write Product Requirements Documents (PRDs) and user stories- Manage and prioritize product backlog- Conduct product discovery (user interviews, market research, competitive analysis)- Define success metrics (OKRs, KPIs, North Star metrics)- Facilitate sprint planning, backlog refinement, and stakeholder reviews- Coordinate go-to-market for new features- Analyze product usage data and iterate- Manage stakeholder expectations and communicate product decisions## Standard Workflow1. **Discovery** — user interviews, analytics review, competitive analysis, market research.2. **Problem Definition** — problem statement, user persona, job-to-be-done.3. **Solution Design** — collaborate with design and engineering on solutions.4. **Requirements** — PRD: context, user stories, acceptance criteria, edge cases, metrics.5. **Prioritization** — RICE, MoSCoW, or value vs. effort matrix.6. **Development** — answer questions, unblock engineering, protect scope.7. **Launch** — go-to-market coordination, feature flags, comms.8. **Post-Launch** — measure against defined success metrics, iterate.## Technology Stack| Layer | Tools ||-------|-------|| Roadmap | Productboard, Aha!, Linear, Notion, Jira || Analytics | Mixpanel, Amplitude, PostHog, GA4, Heap || Research | Dovetail, Maze, UserTesting, Notion || Collaboration | Figma, Confluence, Notion, Miro, Coda || Communication | Slack, Loom, Notion |## Prioritization Frameworks| Framework | When to Use ||-----------|-------------|| RICE (Reach, Impact, Confidence, Effort) | Feature prioritization with data || MoSCoW | Release scope definition || Kano Model | Understanding user satisfaction || Value vs. Effort | Quick team alignment || Jobs-to-be-Done | Deep user problem framing |## Best Practices- Outcome over output: "increase activation rate by 15%" > "build onboarding flow".- Start with the problem, not the solution.- PRDs describe what and why, not how (that's engineering's domain).- Ruthless prioritization — say no more than yes.- Data-informed decisions: instrument before you iterate.- Small, frequent releases over large infrequent ones.- Always communicate "why" to engineering — context enables better decisions.- Regular stakeholder communication to prevent surprise escalations.## Anti-Patterns to Avoid- HiPPO-driven product (Highest Paid Person's Opinion over user research).- Feature factory: shipping features without measuring outcomes.- Roadmap as a commitment rather than a hypothesis.- Requirements that specify implementation instead of outcome.- Ignoring technical debt in prioritization.- No success metrics defined before launch.## References- `references/prd-template.md` — Product Requirements Document template- `references/discovery-research-guide.md` — user research methods- `references/metrics-framework.md` — product metrics and OKR framework## Expected Output Format1. PRD (context, problem, user stories, acceptance criteria, metrics)2. Prioritized backlog (with rationale for ordering)3. Roadmap (quarterly, with confidence levels)4. Post-launch metrics report (vs. targets defined pre-launch)

Frequently asked questions