AI Prompts for Delivery
54 prompts available for product managers.
PRD 작성기(PRD Generator)
이 프롬프트는 프로덕트 매니저(Product Manager)가 Head of Product 관점에서 명확하고 전략적인 PRD(Product Requirements Document, 제품 요구사항 문서)를 작성할 수
사용자 스토리(User Story)
Head of Product가 사용자 니즈와 비즈니스 목표를 크로스 펑셔널 팀(cross-functional team)의 실행 가능한 작업으로 효과적으로 옮기는 사용자 스토리(user story)를 작성하도록 안내하
Jira 이슈 작성(Write Jira Issues)
제품 기능을 위한 명확하고 간결한 Jira 티켓(ticket)을 만들어주는 프롬프트입니다. 기능의 목적과 동작을 설명하기만 하면, 팀이 곧바로 시작할 수 있는 실행 가능한(actionable) 티켓으로 포맷팅됩니다.
v0.dev PRD 작성기 — 프로 버전(v0.dev PRD Generator (Pro Ver.))
이 프롬프트는 제품 리더가 구조화된 PRD 전체를 v0.dev에 입력하고, 그 결과로 여러 파일로 나뉜 자동 모듈형 Next.js 19 스캐폴드(scaffold)를 받을 수 있게 해줍니다. v0.dev는 코드를 ap
최적의 PM 툴 찾기(Discover the Best PM Tools)
이 프롬프트는 다양한 PM 업무에 맞춘 소프트웨어 솔루션 목록을 종합적으로 생성해, 꼭 필요한 개발 및 제품 관리 툴을 식별하도록 돕습니다. 각 툴의 핵심 기능, 장점, 활용 사례(use case)에 대한 인사이트를
기술 개념 분해(Technical Concept Breakdown)
이 프롬프트는 초보자, 중급 학습자, 전문가 등 사용자가 원하는 이해 수준에 맞춰 기술 개념을 설명하도록 돕습니다. 명확한 헤더와 중첩된 불릿 구조를 사용해 과도한 단순화 없이도 명료성과 정확성을 유지합니다. Fey
아마존 스타일 1-Pager(Amazon-style 1-Pager)
이 프롬프트는 아마존(Amazon)의 침묵 독해(silent reading) 형식을 사용하여 전략적이고 실행 중심의 1-Pager 작성을 안내합니다. 명확성, 논리, 진실 추구를 중심으로 제품 제안을 구조화하며, 고
SRS(Software Requirements Specification) 작성기
이 프롬프트는 프로덕트 매니저가 명확하고 실행 가능하며 전략적인 SRS(Software Requirements Specification)를 작성하도록 돕습니다. 문제 정의, AI 활용, 비즈니스 목표, 기능 명세,
원페이저 생성기(One-Pager Generator)
이 프롬프트는 핵심 메시지를 효과적으로 전달하는 간결하고 매력적이며 임팩트 있는 원페이저(one-pager) 작성을 돕습니다. 비즈니스 제안, 마케팅 전략, 프로젝트 요약 등 어떤 용도든 명확성과 구조를 보장해 아이
핵심 제품 지표(Key Product Metrics)
이 프롬프트는 핵심 제품 지표(product metric)를 정의하고 비즈니스 목표와 정렬시키는 것을 돕습니다. 솔루션 임팩트, 사용자 인게이지먼트(engagement), 성장을 측정하는 데이터 기반 접근을 보장합니
v0.dev PRD 작성기 — 심플 버전(v0.dev PRD Generator (Simple Ver.))
이 프롬프트는 제품 리더가 구조화된 v0.dev 최적화 템플릿을 통해 공유 가능한 PRD(Product Requirements Document)를 만들도록 안내합니다. 목표, 사용자 스토리, 기능 명세, UX, 지표
그로스 해킹 플레이북 만들기(Develop a Growth Hacking Playbook)
이 프롬프트는 AARRR 프레임워크(Acquisition, Activation, Retention, Revenue, Referral)를 사용하여 그로스 해킹 전략을 정의함으로써 지속 가능한 제품 성장을 보장합니다.
바이럴 제품 성장 루프 설계(Design a Viral Product Growth Loop)
이 프롬프트는 바이럴 루프(viral loop)와 네트워크 효과를 구조화해, 추천(referral)과 참여 루프를 통해 유기적 사용자 획득을 견인하고 리텐션을 높이도록 돕습니다.
인시던트 포스트모템 템플릿(Incident Post-Mortem Template)
제품 인시던트(incident) 후 비난 없는(blameless) 포스트모템을 작성합니다. 타임라인, 근본 원인, 임팩트 평가, 그리고 재발을 방지하는 구체적 액션 아이템을 포착하도록 구조화됐습니다.
비즈니스 임팩트 점수가 있는 가치 중심 스프린트 회고(Value-Driven Sprint Retrospective)
팀 프로세스를 넘어 스프린트 결과를 비즈니스 가치와 명시적으로 연결하는 회고를 진행하는 프롬프트입니다 — 산출물(output) 중심에서 결과(outcome) 중심 딜리버리로 팀을 전환시킵니다.
GTM 시퀀싱이 있는 제품 런칭 체크리스트(Product Launch Checklist with GTM Sequencing)
메이저 기능 런칭 2주 전인데, 제품, 마케팅, 세일즈, 서포트 사이의 조율된 계획이 없다는 걸 깨달았다고 합시다. 이 프롬프트는 베타 테스트부터 런칭 후 모니터링까지 무엇도 빠지지 않도록 보장하는 순차적 런칭 체크
우리 팀에 맞는 딜리버리 방법론 설계하기(Design a fit-for-purpose delivery methodology for your team)
팀이 경직된 Scrum이나 Waterfall을 넘어, 자신들의 프로젝트 맥락에 맞는 맞춤형 딜리버리(delivery) 접근 방식을 설계해야 할 때 이 프롬프트를 사용하세요.
PM 팀 회의 감사하기(Conduct a PM team meetings audit)
PM 팀이 주당 18시간을 회의에 쓰는데 그 회의 때문에 무엇이 출시되고 있는지 누구도 말하지 못할 때. 이게 감사를 돌립니다 — 모든 회의의 목적, 참석 비용, 결정 산출물 — 그리고 PM당 주 6~10시간을 되돌
리텐션 중심의 온보딩 최적화 계획 수립하기(Build a retention-focused onboarding optimization plan)
회원가입 후 활성화까지의 전환율이 낮고 사용자가 제품의 핵심 가치를 경험하기 전에 이탈할 때 사용하는 프롬프트입니다. 온보딩 퍼널을 단계별로 해부해 정확한 이탈 지점을 찾고, 리텐션 개선에 직접 연결되는 우선순위 최
Product Hunt 출시 플레이북 실행하기(Run a Product Hunt launch playbook)
3-4주 안에 Product Hunt 출시를 앞두고 있는데 지난번에는 그냥 올리고 기대만 했다가 upvote 20개로 끝났을 때 쓰는 프롬프트입니다. hunter 선정, 사전 audience 워밍, 출시 당일 시프트
제품 출시 속도가 떨어지는 이유 진단하기(Diagnose why your product's shipping velocity is declining)
팀 규모는 5명에서 15명으로 늘었는데 분기당 출시 기능 수는 오히려 줄고 있을 때 쓰는 프롬프트입니다. 스탠드업은 형식적이고, PR은 며칠씩 리뷰에 묶이며, 스프린트 약속은 계속 어긋나는 상황에서 진짜 병목이 프로
제품 브리프 템플릿(Product Brief Template)
전체 PRD를 쓰기 전에 이해관계자를 먼저 정렬시키는 1-2페이지짜리 간결한 product brief를 만드는 프롬프트입니다. PRD보다 빠르고, 문제 정의와 제안 방향에 대한 초기 buy-in을 얻기에 적합합니다.
QA 테스트 계획 생성기(QA Test Plan Generator)
새 기능이나 릴리스를 위한 포괄적인 QA 테스트 계획을 생성하는 프롬프트입니다. 기능 테스트, edge case, regression, cross-browser/device, accessibility check까지
스프린트 플래닝 진행자(Sprint Planning Facilitator)
팀과 함께 효과적인 스프린트 플래닝 세션을 운영하게 해주는 프롬프트입니다. sprint goal 준비, 스토리 선택 및 추정, dependency 식별, capacity를 고려한 commitment 설정까지 돕습니다
엔지니어링 팀을 위한 기술 부채 협상 케이스(Technical Debt Negotiation Case)
엔지니어링은 '기술 부채 스프린트'를 계속 요청하지만 비즈니스 임팩트를 설명하지 못하고, 리더십은 '지금은 안 돼'를 반복합니다. 이 프롬프트는 기술 부채를 비즈니스 언어 — 출시 속도, 사고 리스크, 기회비용 —
기능 명세 문서(Feature Specification Document)
엔지니어링 팀이 바로 구현할 수 있을 정도로 상세한 기능 명세를 작성하는 프롬프트입니다. user flow, edge case, API contract, error state, acceptance criteria까지
사용자 스토리(user story)를 위한 강력한 수락 기준(acceptance criteria) 작성하기
팀이 스프린트(sprint) 시작 시점에 수락 기준(acceptance criteria) 대신 테스트 케이스를 작성하고 있고, QA에서 표면화되는 이슈의 상당수가 사전에 합의되지 않은 범위 모호함에서 비롯됩니다. 이
one-team-one-roadmap 통합 설계하기(Design a one-team-one-roadmap consolidation)
영업은 영업 로드맵이 있고, CS는 CS 로드맵이 있고, 마케팅은 마케팅 로드맵이 있고, 제품도 따로 로드맵이 있는데 이들이 하나도 맞지 않을 때 쓰는 프롬프트입니다. 다섯 개의 shadow roadmap을 하나의
엄밀한 A/B 테스트 프로그램 처음부터 설계하기(Design a rigorous A/B testing program from scratch)
팀이 가끔 실험은 하지만 체계가 없어서 테스트가 겹치고, 샘플 수는 감으로 잡고, 결과는 보고 싶은 것만 선택할 때 쓰는 프롬프트입니다. 가설 템플릿, 통계적 엄밀성, 의사결정 프레임워크를 갖춘 구조화된 실험 프로그
90일 런치 지표 리뷰 설계하기(Design a 90-day launch metric review)
출시 직후 주간 activation 목표는 달성했지만, 90일이 지나도 아무도 그 기능이 실제로 의미 있었는지 설명하지 못할 때 쓰는 프롬프트입니다. 지속 사용, 비즈니스 영향, 유지 비용까지 포함한 90일 리뷰를
제품 변경 이력 및 릴리즈 노트 작성기(Product Changelog & Release Notes Writer)
raw commit log, ticket list, sprint summary를 바탕으로 polished하고 user-friendly한 release note와 changelog를 생성하는 프롬프트입니다. in-ap
제품 분석 구현 계획(Product Analytics Implementation Plan)
어떤 이벤트, 속성, 사용자 속성을 계측해야 하는지 정의하는 product analytics tracking plan을 만드는 프롬프트입니다. 팀이 제품 의사결정에 필요한 데이터를 정확히 수집할 수 있게 해줍니다.
rolling roadmap 분기별 re-plan 실행하기(Run a rolling roadmap quarterly re-plan)
연간 로드맵이 2분기쯤 되면 사실상 죽어버릴 때 쓰는 프롬프트입니다. 전략 기둥은 유지하되, 실제로 배운 내용을 바탕으로 다음 두 분기를 다시 순서화해, 항상 최신 상태를 유지하는 rolling 6개월 뷰를 만듭니다
제품 로드맵 생성기(Product Roadmap Generator)
Now / Next / Later 또는 분기별 theme 기준으로 정리된 전략적 제품 로드맵을 만드는 프롬프트입니다. 우선순위 근거, dependency, 리소스 요구사항, stakeholder communicati
Shape Up 스타일의 6주 사이클 킥오프 진행하기(Run a Shape Up style 6-week cycle kickoff)
2주 스프린트가 깊이 있는 작업 대신 얕은 결과물과 끝없는 ceremony만 만들고 있을 때 쓰는 프롬프트입니다. shaped pitch, appetite 점검, 소규모 팀 배정, hill chart baseline
테크 부채 triage 프레임워크 만들기(Build a technical debt triage framework)
팀은 "tech debt sprint"를 원하고 리더십은 "기능을 내라"고 할 때 쓰는 프롬프트입니다. 둘 다 틀렸습니다. 이 프롬프트는 각 부채를 이자율(향후 배포를 얼마나 느리게 만드는지)로 정량화하고, 별도 허
머지 충돌 근본 원인 분석 수행하기
팀이 매주 머지 충돌 해결에 몇 시간을 쓰고 있고, 모두가 다른 팀 탓을 하고 있습니다. 이 프롬프트는 최근 30일의 충돌을 구조적으로 분석해, 그 충돌을 만들어내는 코드 영역 2~3곳과 워크플로 패턴을 찾아내고 보
Diligence 점수화로 DRICE 우선순위 세션 돌리기(Run a DRICE prioritization session with diligence scoring)
RICE가 순위 리스트를 줬지만 — 상위 베팅 셋이 지난 분기에 무너진 이유는 누구도 reach나 impact 숫자를 압력 테스트하지 않았기 때문일 때. DRICE는 점수화 전에 모든 R/I/C 입력에 대해 증거를
출시 전 readiness review 체크리스트 실행하기(Run a pre-launch readiness review checklist)
출시까지 5일 남았고 팀은 자신만만한데, 바로 그때 문제가 터집니다. 이 프롬프트는 product, engineering, support, sales, marketing, legal 전반에 걸친 pre-launch
cycle time 기반 shipping velocity 진단 설계하기(Design a shipping velocity diagnosis using cycle time)
리더십은 "우리는 느리다"고 하고 팀은 "충분히 많이 내고 있다"고 할 때 쓰는 프롬프트입니다. First commit부터 production까지의 cycle time을 작업 유형별로 나눠 측정해, 어디를 먼저 고쳐
비난 없는 인시던트 포스트모템 진행하기(Conduct a blameless incident post-mortem)
지난 인시던트(incident) 포스트모템(post-mortem)이 비난과 망신주기로 변해서 누구도 다음 회차를 돌리고 싶어하지 않을 때. 이 프롬프트는 근본 원인을 찾고, 담당자가 있는 지속 가능한 액션 아이템을
스프린트 플래닝 진행자 아젠다 만들기
당신의 스프린트 플래닝은 90분 동안 이어지고, 30분이 지나면 모두 집중이 풀리며, 결과물은 누구도 믿지 않는 백로그입니다. 이 프롬프트는 목표를 정렬하고, 필요한 만큼만 쪼개고, 현실적인 범위를 확정하며, 왜 각
팀 간 dependency mapping 실행하기(Run a dependency mapping exercise across teams)
로드맵에는 Q2라고 적혀 있지만 사실 세 팀이 서로의 작업에 조용한 dependency를 갖고 있을 때 쓰는 프롬프트입니다. 숨겨진 coupling을 드러내고, 가장 위험한 dependency를 우선순위화하며, 팀
kill-switch가 포함된 feature flag 롤아웃 계획 설계하기(Design a feature flag rollout plan with kill-switch)
"merge되면 바로 출시"는 용감해 보이지만 첫 회귀 버그가 프로덕션을 무너뜨리는 순간 이야기가 달라집니다. 이 프롬프트는 cohort-by-cohort 노출, metric 기반 승격, one-click kill이
베타 고객 모집과 성공 계획 돌리기(Run a beta customer recruitment and success plan)
4주 안에 실제 고객 10~20명을 베타에 올려야 하는데 CS 팀은 완전히 바쁠 때. 이 프롬프트는 모집 스펙, 스크리닝 기준, 성공 지표, 커뮤니케이션 주기를 만들어 — 베타 고객이 지원받는다고 느끼고 당신의 대역
버그 SLA 계층 시스템 설계하기(Design a bug SLA tiering system)
모든 버그가 긴급해 보이고 엔지니어링이 마지막 Slack 메시지에 반응할 때. 이 프롬프트는 버그 SLA 계층 시스템 — P0/P1/P2/P3과 명시적 정의, 응답 윈도우, 라우팅 규칙 — 을 설계해 트리아지가 5분
scope creep 방어 문서 만들기(Build a scope creep defense document)
6주 프로젝트를 시작했는데 4주 차가 되니 어느새 10주 프로젝트가 되어 있을 때 쓰는 프롬프트입니다. 추가된 항목마다 다 그럴듯한 이유가 있었겠지만, 이 문서는 실시간으로 scope creep를 드러내고, 미리 커
기능 sunset 계획 진행하기(Conduct a feature sunset plan)
기능이 0.5% 사용량을 가지고 분기에 엔지니어 2명을 유지에 비용으로 들 때. 서포트가 계속 티켓을 받을 때. 팀이 "sunset할 거야"라고 계속 말하지만 절대 안 할 때. 이 프롬프트는 명시적 sunset 계획
PM을 위한 엔지니어링 우수성 리뷰 설계하기(Design an engineering excellence review for PMs)
당신이 PM인데 엔지니어링 팀이 건강한지 안주하는지 알 수 없을 때. 이 프롬프트는 분기별로 돌릴 수 있는 엔지니어링 우수성 리뷰 — cycle time, 인시던트율, 테스트 커버리지 추세, 온콜 부하 — 를 설계해
business-impact scoring이 포함된 sprint retrospective 만들기(Build a sprint retrospective with business-impact scoring)
회고를 해도 2주마다 똑같은 액션 아이템 세 개만 반복되고 아무 학습도 누적되지 않을 때 쓰는 프롬프트입니다. 마지막 sprint에서 ship한 일의 business impact를 점수화해, 팀 dynamics보다
지표 체크인을 포함한 릴리스 회고 진행하기
출시 후 2주가 지나 팀은 이미 다음 일로 넘어갔지만, 출시 지표는 이제서야 익어가고 있습니다. 이 프롬프트는 출시 후 2주, 6주, 12주에 구조화된 릴리스 회고를 잡아, 기억이 생생할 때가 아니라 데이터가 진짜가
공용 인프라를 위한 cross-team kickoff 문서 만들기(Build a cross-team kickoff doc for shared infrastructure)
네 팀이 사용할 shared infrastructure를 만들고 있는데, 그중 세 팀은 킥오프에 참석조차 못했을 때 쓰는 프롬프트입니다. Contract, non-goal, SLA, consumer onboardin
go/no-go review 템플릿 설계하기(Design a go/no-go review template)
리더십은 분명한 go/no-go 결정을 원하지만 당신의 40슬라이드 status deck은 그 결론을 묻어버릴 때 쓰는 프롬프트입니다. Yes/no recommendation을 강제하고, 근거와 구체적 리스크를 명시
공개 출시 전 내부 런치 레디니스(launch readiness) 체크 작성하기
팀이 공개 출시 2주 전이고, 스탠드업에서 같은 질문이 반복됩니다. 정말로 준비되었는가? 이 프롬프트는 프로덕트, 엔지니어링, 서포트, 세일즈, 마케팅, 리걸을 같은 산출물 위에 두는 내부 런치 레디니스 체크를 작성