메뉴
Write structured, opinionated PRDs that engineers actually read. Use when asked to write a PRD, product spec, feature requirements, or product requirements document. Creates concise, evidence-backed specs with clear scope boundaries and measurable success criteria.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Evaluate product bets and shape pitches using Shape Up's appetite model and Bezos's Type 1/Type 2 decision framework. Use when asked to assess a product bet, evaluate initiative risk, decide resource allocation, or shape a pitch for a new feature or project.
Analyze competitive landscape with feature matrices, positioning maps, and strategic gap analysis. Use when asked to analyze competitors, map the competitive landscape, find differentiation, or evaluate alternatives to a product.
Design hypothesis-driven experiments and A/B tests with proper methodology. Use when asked to design an A/B test, validate a hypothesis, plan an experiment, or set up a test for a product change. Covers hypothesis writing, sample size, and common mistakes.
Prioritize features and backlog items using RICE scoring and Linear's enablers vs blockers lens. Use when asked to rank features, prioritize a backlog, decide what to build next, or evaluate feature requests against each other.
Analyze customer motivations using Jobs-to-be-Done and Forces of Progress. Use when asked about jobs-to-be-done, why customers switch products, what job a product is hired for, or when analyzing the forces that drive or resist product adoption.
Plan product launches with the right tier and coordinated checklists. Use when asked to plan a launch, coordinate a release, prepare for go-to-market, or figure out how to announce a new feature or product. Covers silent, soft, and big-bang launch tiers.
SOC 직업 분류 기준
| name | prd-writing |
| description | Write structured, opinionated PRDs that engineers actually read. Use when asked to write a PRD, product spec, feature requirements, or product requirements document. Creates concise, evidence-backed specs with clear scope boundaries and measurable success criteria. |
Write PRDs that are evidence-first, concise, and scannable. A PRD is a thinking tool — if it's longer than 1200 words, the author hasn't thought hard enough. Brief specs are more likely to be read, more likely to be followed, and more likely to ship on time.
Follow this structure. Every section is mandatory unless marked optional.
Lead with customer evidence. Quotes, data, support tickets, observed behavior. If you have no evidence, say so explicitly — that's an opinion-driven PRD and should be flagged.
Example:
"3 of 5 interviewed customers abandon onboarding at the team invite step. Average time spent: 47 seconds before closing the tab."
NOT: "Users find onboarding confusing."
Measurable outcomes, not outputs. Each goal has a number attached.
Who specifically benefits. Be narrow. "Series A startup founders doing PM work before their first PM hire" — not "product managers."
Use P0/P1/P2 with clear definitions:
Each requirement is one sentence. If a requirement needs a paragraph to explain, it's too big — break it down.
Numbers. Always numbers. "Reduce X from Y to Z within W weeks."
ALWAYS pair each metric with a counter-metric to prevent gaming:
What you are deliberately NOT building and why. This section prevents scope creep and signals that you've thought about boundaries.
Unresolved decisions that need input. Each question names who should answer it and by when.
Bad P0 requirement:
"The system should handle authentication in a secure and user-friendly manner, supporting multiple providers and edge cases."
Good P0 requirement:
"P0: User can sign up and log in with email + password. Google OAuth is P1."
One sentence. Clear scope. Priority forces a decision.
Built on Linear's "short specs > exhaustive docs" philosophy. Skills from productskills.
