Prompt Guides for Product Managers
244 in-depth guides on using AI prompts across product strategy, discovery, delivery, and storytelling. Each guide explains when to use the prompt, how it works, and what to watch out for.
Product Strategy
56 guides마켓플레이스 공급 성장의 5개 핵심 레버 감사하기
마켓플레이스에 수요 모멘텀이 있고 공급이 병목인데, 팀은 어떤 레버가 실제로 복리로 작용하는지 지도 없이 획득(acquisition) 레버만 당겨왔습니다. 이 프롬프트는 5개 핵심 공급 성장 레버(획득, 활성화, 용량, 유지, 밀도)를 감사하여 팀이 가장 시끄러운 채널을 쫓는 대신 수학이 맞는 곳에 투자하도록 합니다.
그로스와 재무가 함께하는 북극성 지표(North star metric) 토너먼트 운영하기
팀이 2년 동안 주간 활성 사용자(WAU)를 북극성이라고 불러왔는데, 6개월 전부터 그 지표가 성장을 예측하지 못하고 있습니다. 이 프롬프트는 토너먼트 형식으로 6-8개 후보 지표를 프로덕트, 그로스, 재무가 함께 4개 테스트(매출 예측, 고객 가치 포착, 팀이 움직일 수 있음, Goodhart에 저항)로 점수 매겨, 선택된 지표가 그 역할을 자격으로 얻게 만듭니다.
유지율 곡선이 평탄해지는 지점(retention smile) 찾기
유지율 차트가 천천히 새는 양동이처럼 보이고, 팀은 몇 달 동안 곡선을 움직이지 못하면서 온보딩만 개선해왔습니다. 실제로 필요한 레버는 곡선이 평탄해지는 날짜 또는 주(스마일 지점)와 그것을 만든 사용자 행동입니다. 이 프롬프트는 스마일을 식별하고, 그 행동을 추적하며, 다음 분기의 그로스 베팅으로 전환합니다.
제품의 switching cost 분석 만들기(Build a switching cost analysis for your product)
이탈률은 목표보다 높고, "더 좋은 제품을 만들자"는 말만으로는 계획이 되지 않을 때 쓰는 프롬프트입니다. 고객이 당신을 떠날 때 치러야 하는 switching cost를 매핑하고, 가장 load-bearing한 세 가지를 골라, 브랜드를 해치는 lock-in 선을 넘지 않으면서 분기별로 깊게 만드는 계획을 세웁니다.
연간 제품 계획에 대한 프리모템 실행하기(Run a pre-mortem on your annual product plan)
2026년 계획은 훌륭해 보이고 누구도 이의를 제기하지 않았습니다. 바로 그 점이 문제입니다. 이 프롬프트는 구조화된 프리모템을 통해 연말에 계획이 실패했다고 가정하고, 그 실패를 오늘 내리는 결정까지 거슬러 올라간 다음, 각 실패 모드를 지금 당장 적용할 수 있는 guardrail로 바꿔 계획을 확정하기 전에 리스크를 드러냅니다.
카테고리용 파괴적 혁신 레이더 구축하기
당신의 카테고리는 안정적이고, 현재 잘하고 있으며, 그래서 오히려 파괴자가 다가오는 것을 보지 못하고 있습니다. 바로 그런 순간에 파괴자가 등장합니다. 이 프롬프트는 저가형, 신시장형, 인접 기술형 파괴 벡터를 분기마다 스캔하는 레이더를 만들어, 대응 비용이 아직 낮을 때 위협을 포착하게 합니다.
제품 포트폴리오 pruning review 진행하기(Conduct a product portfolio pruning review)
당신이 14개의 SKU/기능/integration을 지원하고 있는데, 그중 3개가 매출의 80%를 만들고 4개는 zombie이며 7개는 "다음 분기쯤" 상태일 때 쓰는 프롬프트입니다. Customer success와 대화하기 전에 migration path와 revenue impact forecast가 담긴 structured portfolio review를 돌려 sunset plan을 만듭니다.
"우리가 하지 않을 일" 문서 설계하기(Design a "what we are NOT doing" document)
매 분기 새로운 아이디어가 로드맵에 슬며시 들어오고, 지난 분기에 왜 빠졌는지 아무도 기억하지 못할 때 쓰는 프롬프트입니다. 로드맵의 companion document로서 "우리가 하지 않을 일과 그 이유"를 명시적으로 남겨, 같은 주제가 다시 올라와도 5분 안에 대화를 끝낼 수 있게 합니다.
제품 경쟁 포지셔닝을 Kiviat 차트에 매핑하기(Map your product's competitive positioning on a Kiviat chart)
경쟁 분석이 스토리를 말하지 않는 기능 체크마크의 벽일 때. 6~8개 축의 Kiviat(스파이더) 차트는 한 프레임에 우위의 모양을 가시화합니다. 이 프롬프트는 바이어가 실제로 결정하는 축을 고르고, 증거로 점수화하고, 차트와 함께 갈 내러티브를 만들어냅니다.
three-horizons 제품 전략 맵 만들기(Build a three-horizons product strategy map)
당신의 로드맵이 100% Horizon 1(코어) 아니면 100% Horizon 3(문샷)만으로 채워져 있고, 리더십이 계속 균형을 요구할 때 쓰는 프롬프트입니다. Now, next, future bet을 명시적 자원 배분과 kill criteria와 함께 구조화해, 다음 operating review에서 왜 이런 포트폴리오인지 방어할 수 있게 합니다.
2년 제품 전략 수립을 위한 Strategy Blocks 스프린트 진행하기(Run a Strategy Blocks sprint to craft a 2-year product strategy)
팀은 계속 무언가를 출시하고 있지만 왜 이 프로젝트를 하고 다른 프로젝트는 하지 않는지를 두고 계속 논쟁합니다. Strategy Blocks는 준비, 전략 스프린트, 디자인 스프린트, 문서화, 롤아웃의 다섯 단계로 이루어진 운영 프레임워크로, 3개의 전략 기둥과 2년짜리 승리 지향점, 그리고 이해관계자 정렬을 마지막에 얹는 것이 아니라 과정 안에 강제로 포함시킵니다.
정체된 이니셔티브를 위한 kill-or-double 전략 메모 쓰기(Write a kill-or-double strategy memo for a stalled initiative)
이니셔티브가 엔지니어링 시간 2분기를 소비했고 지표가 평탄할 때. 리더십이 명확한 리셋이나 원칙적 정리를 원할 때. 이 프롬프트는 무엇이 테스트됐는지, 데이터가 실제로 무엇을 말하는지, 그리고 사전 약속된 기준이 있는 이진 권고를 펼치는 kill-or-double 메모를 만들어 — 결정이 다시 토론되는 것을 멈춥니다.
PLG에서 sales-assist 크로스오버 계획 설계하기(Design a product-led growth to sales-assist crossover plan)
PLG(Product-Led Growth) 모션이 개인 사용자를 가입시키지만 누구도 계정을 작업하지 않아 엔터프라이즈 딜이 정체될 때. 이 프롬프트는 정확한 크로스오버 — 트리거 기준, 핸드오프 스펙, 공동 보상 계획 — 를 설계해, sales-led로 다시 무너지지 않으면서도 PLG가 6자리 ACV를 테이블에 남기지 않도록 합니다.
제품의 network effect flywheel 매핑하기(Map your product's network effects flywheel)
리더십이 계속 "우리에겐 network effect가 있다"고 말하는데, 정작 아무도 그 flywheel을 설명하지 못할 때 쓰는 프롬프트입니다. 여덟 가지 network-effect archetype을 따라 실제로 어떤 루프가 존재하는지 진단하고, 각 루프를 강화하는 투자까지 포함한 flywheel diagram을 만듭니다.
순차형 Jobs-to-be-Done 제품 전략 만들기(Build a sequenced Jobs-to-be-Done product strategy)
JTBD 인터뷰 조각 40개는 있는데 어떤 job부터 제품화해야 할지 전혀 감이 없을 때 쓰는 프롬프트입니다. Raw switch-interview 데이터를 ranked job map으로 바꾸고, 먼저 이길 wedge job 하나를 고른 다음, 다음 해에 dilution 없이 확장할 adjacent job을 계획하게 합니다.
pricing positioning audit 진행하기(Conduct a pricing positioning audit)
Pricing page를 18개월째 그대로 두고 있고, discount rate는 올라가고, 경쟁사 대비 win rate는 떨어지고 있을 때 쓰는 프롬프트입니다. 가치 인식, 패키징 명확성, 경쟁 기준점 관점에서 pricing positioning을 감사하고, 기존 deal을 터뜨리지 않으면서 90일 안에 refresh할 계획을 만듭니다.
빌드 전에 네 가지 큰 제품 리스크 매핑하기(Map the four big product risks before you build)
기능은 spec review를 통과하고 ship까지 했는데 flop하고, post-mortem을 해보면 늘 테스트하지 않았던 똑같은 네 가지 리스크가 나올 때 쓰는 프롬프트입니다. Marty Cagan의 네 가지 리스크(value, usability, feasibility, business viability)를 각 리스크별 discovery action과 함께 점검해, launch가 아니라 2주 차에 문제를 잡게 합니다.
white-space opportunity scan 진행하기(Run a white-space opportunity scan)
당신이 속한 카테고리가 성숙하고 경쟁이 치열하며 성장도 둔화되고 있는데, 리더십은 "다음 큰 것"을 원할 때 쓰는 프롬프트입니다. underserved segment, emerging behavior, unbundling 기회를 구조적으로 스캔해, 오프사이트에서 제일 큰 소리로 말한 사람이 아니라 데이터 기반으로 다음 bet을 고르게 합니다.
제품 자기잠식(cannibalization) 가드레일 설계하기(Design a product cannibalization guardrail)
프리미엄 플랜을 자기잠식할 수도 있는 더 싼 티어를 출시하거나 — 코어를 먹을 수도 있는 새 제품을 출시할 때. 이 프롬프트는 자기잠식 모델을 만들고, 순(net)-양수 임계값을 설정하고, 매출 팀이 패닉하지 않으면서 출시할 수 있도록 가드레일을 설계합니다.
고객 집중도 리스크 완화 계획 만들기(Build a customer concentration risk mitigation plan)
세 고객이 ARR의 45%를 차지하고 있고, 이사회가 곧 "그중 하나가 떠나면 어떻게 되나요?"라고 물을 상황일 때 쓰는 프롬프트입니다. Dependency map, diversification target, 12개월 완화 계획이 담긴 concentration-risk 메모를 만들어, 구조적 변화 없이 단순히 "더 팔자"로 무너지지 않게 합니다.
10x vs 10% scope choice 프레임워크 실행하기(Run a 10x vs 10% scope choice framework)
팀이 incremental improvement(10% 개선, 익숙한 경로)와 rewrite(10배 기회, 불확실함) 사이에서 갈등할 때 쓰는 프롬프트입니다. Metric ceiling 기준으로 결정을 내리게 해, 회의실에서 누가 더 설득을 잘하느냐가 아니라 숫자로 scope 선택을 하게 합니다.
플랫폼 전략 로드맵 만들기(Build a platform strategy roadmap)
제품에 앱 하나가 있고 다음 질문이 "언제 우리가 플랫폼이 되나?"일 때. 이 프롬프트는 4개 플랫폼 원형(API, app, data, marketplace), 실제로 필요한 전제조건, 그리고 파트너 없이 플랫폼을 출시하지 않게 하는 12개월 시퀀싱 계획을 안내합니다.
제품 bet 우선순위 워크숍 진행하기(Run a product bets prioritization workshop)
임원진은 아이디어 14개를 갖고 있는데 분기 capacity는 하나뿐일 때 쓰는 프롬프트입니다. 익숙한 RICE 스프레드시트가 정치적인 칼싸움으로 변해버리지 않도록, 숨은 가정을 드러내고 단일 ranked list를 강제하며 잘라낸 항목마다 방어 가능한 서사를 남기는 90분 구조화 워크숍을 진행합니다.
제품 방어력에 대한 moat 분석 설계하기(Design a moat analysis for your product's defensibility)
당신이 제안한 기능을 보고 이사회 멤버가 "경쟁사가 3개월 안에 이걸 똑같이 내는 걸 무엇이 막죠?"라고 물을 때 쓰는 프롬프트입니다. Scale, network effects, switching costs, brand, regulatory, embedded data, proprietary tech라는 일곱 가지 moat archetype을 점검하고, 리더십에게 바로 전달할 수 있는 한 페이지짜리 방어력 메모를 만듭니다.
build-buy-partner decision matrix 설계하기(Design a build-buy-partner decision matrix)
리더십이 어떤 capability를 사내에서 만들지, 스타트업을 살지, incumbent와 파트너십을 할지 묻는데, 팀은 매번 처음부터 다시 싸우고 있을 때 쓰는 프롬프트입니다. 점수화된 criteria와 default decision rule이 있는 재사용 가능한 matrix를 만들어, 다음 build-buy-partner 결정이 분기 전체가 아니라 하루 만에 끝나게 합니다.
TAM/SAM/SOM 재보정 진행하기(Conduct a TAM/SAM/SOM re-calibration)
2023 덱이 누군가 블로그에서 인용한 숫자에 기반해 "$50B TAM"을 말했고, 이사회가 그렇게 큰 숫자에 비해 왜 성장이 정체됐는지 묻고 있을 때. 이 프롬프트는 실제 가격, ICP, 깔때기 전환에서 TAM, SAM, SOM을 재도출해 — 보여주는 숫자가 다음 5번 회의 동안 방어 가능하도록 합니다.
이해관계자 맵핑 및 영향력 전략(Stakeholder Mapping & Influence Strategy)
이해관계자를 영향력과 관심도로 맵핑하고, 각자에게 맞는 engagement 전략을 만드는 프롬프트입니다. 복잡한 조직 역학 속에서 움직이는 PM이 initiative에 대한 buy-in을 얻는 데 필수적입니다.
플랫폼 vs 기능 의사결정 프레임워크(Platform vs Feature Decision Framework)
기능을 직접 만들지, 서드파티 도구를 쓸지, 혹은 플랫폼/API로 만들지를 판단해야 할 때 사용하는 프롬프트입니다. 비용 모델링과 리스크 분석까지 포함해 build-vs-buy 의사결정을 구조적으로 평가합니다.
제품 현지화와 i18n 전략(Product Localization & i18n Strategy)
시장 우선순위 매트릭스, 현지화(localization) 요구사항, 단계별 롤아웃 전략으로 제품의 국제 확장을 계획합니다. 언어, 문화 적응, 컴플라이언스, GTM(go-to-market)을 다룹니다.
이탈 분석과 방지 전략(Churn Analysis & Prevention Strategy)
사용자 이탈(churn) 패턴을 분석하고 데이터 기반 리텐션(retention) 전략을 만듭니다. 이탈 세그먼트, 근본 원인, 선행 지표, 그리고 라이프사이클 단계별 개입 플레이북을 식별합니다.
제품 라이프사이클 단계 분석기(Product Lifecycle Stage Analyzer)
제품이 어느 단계(도입기, 성장기, 성숙기, 쇠퇴기)에 있는지 진단하고, 제품, 마케팅, 가격, 팀 초점에 대한 단계 적합 전략 권고를 받으세요.
블루오션 전략 캔버스(Blue Ocean Strategy Canvas)
블루오션 전략(Blue Ocean Strategy)을 적용해 경쟁 없는 시장 공간을 찾습니다. 핵심 가치 요소에 걸쳐 경쟁자와 자사 제공품을 시각적으로 비교하는 전략 캔버스를 만들고, 무엇을 제거(Eliminate), 감소(Reduce), 증가(Raise), 창조(Create)할지 식별합니다.
가치 제안 캔버스(Value Proposition Canvas)
제품의 value creator와 pain reliever를 고객의 구체적인 job, pain, gain에 대응시키는 Value Proposition Canvas를 만드는 프롬프트입니다. Strategyzer 프레임워크를 기반으로 합니다.
Lean Canvas 생성기(Lean Canvas Generator)
스타트업이나 신규 제품 이니셔티브를 위한 1페이지 비즈니스 모델인 Lean Canvas를 만드는 프롬프트입니다. problem, solution, unique value proposition, channel, revenue stream, cost structure, key metric, unfair advantage를 한 장에 담습니다.
시장 기회 추정기(Market Opportunity Estimator)
이 프롬프트는 제품이나 서비스의 잠재 시장 규모를 TAM(Total Addressable Market), SAM(Serviceable Addressable Market), SOM(Serviceable Obtainable Market)으로 분해해 평가하도록 돕습니다. 산업 수요, 경쟁 요인, 매출 예측을 평가하는 구조화된 프레임워크를 제공해, 데이터 기반 인사이트를 찾는 창업가, 제품 리더, 비즈니스 분석가에게 유용합니다.
변곡점 스트레스 테스트(Inflections Stress Test)
변곡점 스트레스 테스트(Inflections Stress Test)를 한 번에 완료하기 위한 프롬프트입니다. 정해진 형식에 따라 인사이트를 입력하면, AI가 상세한 요약표와 검토 의견을 만들어 아이디어를 검증하고 다듬는 데 도움을 줍니다.
경쟁사 분석(Competitor Analysis)
ChatGPT, Gemini, Perplexity 같은 서비스의 Deep Research 모드를 활용해 제품 아이디어 주변의 경쟁 구도를 탐색하세요. 이 프롬프트는 프로덕트 마케터 역할을 맡아 유사한 기능을 가진 또는 비슷한 사용자 니즈를 타깃하는 핵심 경쟁사를 식별하고 분석하도록 돕습니다.
시장 분석(Market Analysis)
이 임원급 시장 분석 프롬프트는 철저한 경쟁 평가, 시장 트렌드와 기회 식별, 그리고 실행 계획이 포함된 실행 가능한 권고안을 요구합니다. 데이터 출처에는 산업 보고서, 재무 공시, 소셜 리스닝(social listening)이 포함됩니다. 산출물은 성장을 위한 간결하고 데이터 기반의 전략적 청사진(blueprint)입니다.
제품 성장을 예측하고 진단하는 성장 모델 만들기(Build a growth model to forecast and diagnose product growth)
신규 사용자는 들어오고, 일부는 이탈하고, 매출은 오르거나 내리지만 왜 그런지 아무도 설명하지 못하는 블랙박스 같은 성장 상황에서 쓰는 프롬프트입니다. 성장을 구성 요소별 레버로 분해하는 bottom-up growth model을 만들어, 예측하고 진단하고 개입할 수 있게 합니다.
마켓플레이스 콜드 스타트 문제 평가와 출시 전략 설계(Assess your marketplace cold start problem and design a launch strategy)
마켓플레이스 또는 플랫폼을 만들고 있는데 닭과 달걀의 함정에 갇혔습니다 — 수요 없이는 공급 없고, 공급 없이는 수요 없음. 이는 콜드 스타트(cold start) 분석을 구조화하고 양면을 부트스트랩하는 시퀀싱된 출시 전략을 설계합니다.
제품을 위한 구독 가치 루프 설계하기(Design a subscription value loop for your product)
구독 제품이 유료 획득(paid acquisition)으로 자라고 있지만 리텐션은 평탄하고 CAC가 계속 오를 때. 이게 가치 루프(value loop)를 설계합니다 — 제품의 핵심 경험이 자연스럽게 전환, 리텐션, 오가닉 추천을 추동하게 해, 유료 마케팅 의존을 줄입니다.
제품의 North Star metric 정의하고 검증하기(Define and validate your product's North Star metric)
팀이 수십 개 지표를 보고 있지만 무엇이 가장 중요한지 합의하지 못하고, 로드맵 논쟁이 "내 지표 vs 네 지표" 싸움으로 흐를 때 사용하는 프롬프트입니다. 제품, 성장, 비즈니스 목표를 하나로 묶는 단일 North Star metric을 선택하고 검증하고 운영 체계에 녹여내도록 도와줍니다.
DHM 프레임워크로 제품 전략 날카롭게 다듬기(Apply the DHM framework to sharpen your product strategy)
팀이 제품이 왜 이기는지를 "기능이 더 좋아서" 이상으로 설명하지 못하고 있다면, 이 프롬프트를 사용하세요. Delight-Hard to Copy-Margin enhancing 프레임워크를 통해 현재 전략이 지속 가능한 경쟁우위(durable competitive advantage)를 만드는지, 아니면 잠깐의 차별화에 그치는지를 스트레스 테스트합니다.
제품 가격 및 패키징 감사 실행하기(Run a pricing and packaging audit for your product)
가격을 1년 넘게 손보지 않았거나, 큰 기능을 출시하면서 상위 티어에만 잠글지 고민 중일 때 쓰는 프롬프트입니다. 현재 가격 모델을 구조적으로 점검하고 패키징 공백을 찾은 뒤, 구체적인 개선안을 제시합니다.
강력한 제품 비전 정의하기(Defining a Strong Product Vision)
이 프롬프트는 시장 니즈(market needs)와 비즈니스 목표에 정렬되는 명확하고 영감을 주는 제품 비전을 만들도록 돕습니다. 고객 문제, 고유한 차별점, 성공 기준을 정의해 전략적 접근을 보장합니다. 제품 개발의 강한 토대를 마련하려는 PM에게 적합합니다.
PM Wheel 자기 진단과 성장 계획 수립(Run a PM Wheel self-assessment and build a growth plan)
이 프롬프트를 사용하면 Petra Wille의 8개 활동 기반 PM Wheel 프레임워크를 기준으로 자신의 프로덕트 매니지먼트 역량을 진단하고, 가장 약한 영역을 중심으로 구체적 액션이 담긴 개인 맞춤형 성장 계획을 만들 수 있습니다.
AI 기반 제품 분석을 위한 직교 컨텍스트 브리프 만들기(Build an orthogonal context brief for AI-powered product analysis)
AI에 제품 지표, 시장 위치, 또는 전략 옵션 분석을 요청하지만 계속 일반적이고 표면적인 응답만 받을 때 이 프롬프트를 사용하세요. 입력을 독립된 차원에 걸쳐 구조화함으로써, AI가 가장 흔한 패턴으로 떨어지는 대신 하나의 방어 가능한 해석으로 좁혀가도록 합니다.
Go-To-Market 전략(GTM Strategy)
이 구조화된 프롬프트로 성공적인 Go-To-Market(GTM) 전략을 설계할 수 있습니다. 타깃 고객을 식별하고, 차별화된 포지셔닝(positioning)을 정의하고, 최적의 획득 채널(acquisition channel)을 선택하고, 측정 가능한 성공 지표를 세우세요. 출시 전략을 다듬고 시장 임팩트(impact)를 극대화하려는 프로덕트 매니저, 마케터, 스타트업 창업자에게 적합합니다.
OKR 스파링 파트너(OKR Sparring Partner)
사용자가 초안 OKR을 비판적으로 평가할 수 있도록 돕는 프롬프트입니다. 명확성, 측정 가능성, 전략적 정렬, 가정, 표현을 평가하는 구조화된 다각도 프레임워크를 사용합니다. 사용자는 상세한 비평, 실행 가능한 개선 제안, 개선된 OKR 예시를 받아 전략적 명확성과 실행 우수성을 높일 수 있습니다.
가격 전략(Pricing Strategy)
이 프롬프트는 새 제품을 위한 세 가지 대안적 가격 전략을 설계하도록 돕습니다. 다양한 가격 모델(pricing model)을 중심으로 구조화된 사고를 유도해, 시장 포지셔닝, 고객이 느끼는 가치, 경쟁 구도에 맞는 여러 접근을 비교할 수 있게 합니다. 응답에는 cost-based, value-based, freemium, penetration, premium pricing 모델과 각 접근의 논리가 함께 포함될 수 있습니다. 가격 의사결정을 더 정교하게 최적화하려는 프로덕트 매니저와 비즈니스 전략가에게 적합합니다.
데이터 기반 사용자 리텐션 전략 수립(Build a Data-Driven User Retention Strategy)
이 프롬프트는 churn 리스크를 식별하고, engagement 전술을 최적화하고, 습관 형성(habit formation)을 강화함으로써 데이터 기반 사용자 리텐션(retention) 전략을 만들도록 돕습니다. 행동 분석(behavioral analytics), 세그먼트화(segmentation), AI 기반 개인화, 실험을 활용해 사용자 충성도(loyalty)를 높일 수 있습니다. 고객 유지율을 개선하고 churn을 효과적으로 줄이려는 프로덕트 매니저와 그로스 팀을 위해 설계되었습니다.
다중 렌즈 제품 계획 리뷰 파이프라인 설계하기(Design a multi-lens product plan review pipeline)
제품 계획이나 PRD를 작성했지만 자기 관점만 반영돼 있을 때. 자원을 약속하기 전에, 세 가지 독립된 렌즈 — CEO(야망과 비전), 엔지니어링(실현가능성과 아키텍처), 디자인(사용자 경험과 다듬음) — 으로 통과시켜 사각지대를 잡아내세요.
하이브리드 PLG + 세일즈 어시스트 GTM 모션 설계하기(Design a hybrid PLG and sales-assist go-to-market motion)
순수 self-serve에서 하이브리드 product-led sales 모델로 전환할 때 사용하는 프롬프트입니다. 제품이 리드를 선별하고, 세일즈가 고가치 계정에 전략적으로 개입하는 구조를 설계하도록 돕습니다.
AI 기반 경쟁 인텔리전스 대시보드 만들기(AI-Assisted Competitive Intelligence Dashboard)
경쟁사를 실시간으로 추적하는 체계적인 AI 기반 프로세스를 셋업해야 할 때 사용하세요 — 시장 신호를 수동으로 모으는 데 시간을 너무 많이 쓰는 PM에게 이상적입니다.
로드맵을 위한 'Boil the Lake' 완결성 감사 만들기(Build a 'Boil the Lake' completeness audit for your roadmap)
AI는 일을 철저하게 하는 비용을 무너뜨렸습니다. 제품 로드맵을 검토하면서 습관적으로 코너를 자르고 있다는 의심이 드는 상황 — 완전 버전이 한계 비용만 더 들 때 MVP를 출하하는 — 에서, 더 이상 말이 되지 않는 지름길에 대해 로드맵을 감사하세요.
이익 주도 제품 우선순위 프레임워크 만들기(Create a profit-driven product prioritization framework)
성장 우선에서 이익 우선 우선순위로 전환할 때 이 프롬프트를 사용하세요. 매출 임팩트와 비용 효율성으로 기능을 평가하도록 돕습니다.
Storytelling
30 guidesPM이 딜 콜에서 전달할 수 있는 세일즈 피치 만들기
세일즈가 고객 콜에 PM을 끌어들이고 있는데, 실제로 피치를 만들어둔 적이 없어서 데모가 산만해집니다. 이 프롬프트는 PM이 12분 안에 전달할 수 있는 7장 피치(문제, 현 상태 비용, 우리의 관점, 데모, 증거, 가격, 다음 단계)를 만들어, 콜이 열린 프로덕트 투어가 아니라 딜을 한 단계 진전시키게 합니다.
반복 갈등을 위한 cross-functional alignment ritual 만들기(Build a cross-functional alignment ritual for recurring conflicts)
엔지니어링과 제품 사이의 같은 싸움이 매 planning cycle마다 반복될 때 쓰는 프롬프트입니다. 반복 긴장 지점의 표면화, 팀 간 원칙, 명시적 escalation path를 포함한 상시 정렬 ritual을 설계해, 다음 논쟁은 3일이 아니라 20분 만에 끝나게 합니다.
제품 naming workshop 진행하기(Conduct a product naming workshop)
무언가를 출시하려는데 팀이 이름 때문에 Slack thread에서 3주째 싸우고 있을 때 쓰는 프롬프트입니다. 제약 조건, 아이디어 생성, 스트레스 테스트, 결정까지 포함된 90분짜리 워크숍을 한 번에 진행해, 최종 shortlist 3개와 그 이름을 방어할 rationale을 남깁니다.
새 기능을 위한 sales enablement one-pager 만들기(Build a sales enablement one-pager for a new feature)
기능은 출시됐는데 sales가 "이걸 어떻게 팔죠?"라고 묻고 있을 때 쓰는 프롬프트입니다. Buyer persona, pain trigger, objection handler, discovery question이 들어간 one-pager를 만들어, launch deck을 다시 읽지 않고도 어떤 콜에든 들고 들어갈 수 있게 합니다.
최소 이탈로 제품 폐기 발표문 쓰기(Write a product deprecation announcement with minimal churn)
고객의 12%가 의존하는 기능을 sunset 중이고 커뮤니케이션 팀이 이메일 초안을 요청할 때. 이 프롬프트는 손실이 아니라 마이그레이션으로 시작하는 폐기 발표문을 씁니다 — 명시적 날짜, 이름 붙은 마이그레이션 경로, 서포트 약속 — 이탈이 역사적 베이스라인 가까이 머물도록.
Amazon 스타일로 PR/FAQ 초안 작성하기(Draft a PR/FAQ in the Amazon style)
새 제품을 시작하고 누구도 코드를 쓰기 전에 명확성을 강제하고 싶을 때. 이 프롬프트는 working-backwards PR/FAQ — 보도 자료(press release) 먼저, FAQ 둘째 — 를 초안 작성해, 엔지니어링이 시작되기 전에 고객에게 실제로 무엇을 약속하는지 알게 합니다.
re-engagement를 만드는 release notes 템플릿 만들기(Build a release notes template that drives re-engagement)
릴리즈 노트가 늘 "버그 수정 및 성능 개선"으로 끝나고 아무도 열어보지 않을 때 쓰는 프롬프트입니다. Marquee item 하나, customer win 하나, behind-the-scenes 하나로 구성된 release notes 템플릿을 작성해, 사용자를 실제로 제품으로 다시 돌아오게 합니다.
투자자 덱용 why-now 섹션 초안 쓰기(Draft a why-now section for an investor deck)
투자자 덱에 제품은 좋은데 시급성이 전혀 보이지 않을 때 쓰는 프롬프트입니다. 투자 미팅의 성패를 자주 가르는 why-now 슬라이드를, 막연한 "AI가 크다"가 아니라 구체적인 시장 변화, 기술적 전환점, 행동 변화에 묶어 작성합니다.
기능 거절 응답 작성하기(Write a feature rejection response)
중요 고객이나 시니어 이해관계자의 기능 요청에 No를 말해야 할 때 쓰는 프롬프트입니다. 기본 이메일은 대개 dismissive하게 들리기 쉽습니다. 이 프롬프트는 필요를 인정하고, 결정을 설명하고, 대안을 제시하면서도 관계를 지키는 rejection response를 만듭니다.
4개 핵심 슬라이드로 이사회 업데이트 만들기(Craft a board update with the four key slides)
이사회 덱이 35장이고 이사회 멤버가 매번 같은 세 질문을 묻을 때. 이 프롬프트는 4-슬라이드 덱 — 지표, 하이라이트, 리스크, 요청 — 을 만들어 그들의 진짜 질문에 답하고 디테일은 부록에 남깁니다.
근거가 있는 제품 비전 문구 작성하기(Write a product vision statement with evidence)
제품 비전 문구가 막연한 시처럼만 들리고 팀이 그것을 기준으로 ship하지 못할 때 쓰는 프롬프트입니다. Target customer, problem, solution shape, proof point에 근거한 3년 비전을 써서, 엔지니어가 실제 tradeoff를 평가할 수 있게 합니다.
계층화된 깊이로 이해관계자 업데이트 주기 만들기(Build a stakeholder update cadence with tiered depth)
같은 업데이트를 세 번 쓰고 있을 때 — Slack용 짧게, 주간용 중간, 분기용 길게 — 그리고 그게 금요일을 잡아먹을 때. 이 프롬프트는 각 깊이에 템플릿이 있는 계층화된 주기를 만들어 매 글이 복리화되고 다시 편집을 멈추도록 합니다.
임원 팀을 위한 1-pager 제품 내러티브 쓰기(Write a one-pager product narrative for the exec team)
분기별 임원 업데이트가 핵심을 묻어버리는 15장짜리 덱으로 계속 자랄 때. 이 프롬프트는 진짜 1-pager — 베팅, 증거, 요청 — 를 만들어 임원 팀이 읽고 한 가지 날카로운 질문을 묻고 결정과 함께 나갈 수 있도록 합니다.
GAIN 프레임워크로 피드백 주기(Give feedback using the GAIN framework)
직원이 세 번째로 deliverable을 놓쳤거나, 협업 파트너가 계속 당신의 PRD를 다시 쓰고 있을 때 쓰는 프롬프트입니다. 이제 대화를 해야 하지만 "네가 뭘 잘못했는지 말해줄게" 식의 접근은 좋지 않게 받아들여질 걸 알고 있죠. GAIN 프레임워크(Goal, Actions, Impacts, Next actions)는 pain-framed 피드백을 gain-framed 피드백으로 전환하는 정확한 구조와 표현을 제공해, 상대가 공격이 아니라 초대로 받아들이게 합니다.
고객용 출시 공지 이메일 작성하기(Write a launch announcement email for customers)
당신의 출시 이메일은 고객의 20%만 열고, 5%만 읽고, 1% 미만만 행동할 가능성이 큽니다. 이 프롬프트는 고객 시간을 존중하는 출시 이메일을 씁니다. 구체적인 benefit, 하나의 CTA, 하나의 관심 이유만 남겨, 그 1% 미만의 반응을 유의미한 신호로 바꿉니다.
무료 사용자를 전환시키는 changelog 작성하기(Write a changelog that converts free users)
무료 사용자는 유료 티어 기능을 거의 보지 못하고, 업그레이드 경로도 보이지 않을 때 쓰는 프롬프트입니다. Paid feature를 tasteful한 upgrade prompt와 함께 담은 changelog를 작성해, free user가 가치를 발견하고 baseline 대비 2-3배 더 전환하게 합니다. 단, paywall spam처럼 보이지 않아야 합니다.
고객 성공 인수인계 내러티브 초안 작성하기
고객 계약은 막 체결되었고 이제 CS 팀으로 넘어가지만, CS는 내러티브 없이 8개의 스레드만 떠안게 됩니다. 이 프롬프트는 그 고객이 무엇을 샀고 왜 샀는지, 성공이 무엇인지, 상위 3개 리스크가 무엇인지를 요약한 인수인계 내러티브를 작성해 첫 CS 콜이 "그런데 귀사는 무슨 일을 하시죠?"로 시작되지 않게 합니다.
투자자 및 이사회용 제품 내러티브(Investor & Board Product Narrative)
투자자 미팅, 이사회 발표, 또는 펀드레이징 덱을 위한 설득력 있는 제품 내러티브를 만드세요. 제품 지표와 로드맵을 신뢰를 쌓는 전략적 스토리로 번역해줍니다.
크로스 펑셔널 킥오프 브리프(Cross-Functional Kickoff Brief)
개발이 시작되기 전에 엔지니어링, 디자인, 마케팅, 비즈니스 팀이 목표, 범위(scope), 타임라인, 역할, 커뮤니케이션 규범에 정렬되도록 만드는 프로젝트 킥오프 문서를 작성합니다.
임원 요약 및 이사회 업데이트(Executive Summary & Board Update)
전략적 진행, 핵심 지표, 필요한 결정을 전달하는 임원 요약과 이사회 수준 제품 업데이트를 작성합니다 — 모두 임원들이 선호하는 간결한 형식으로.
기능 요청 거절 템플릿(Feature Request Rejection Template)
고객, 세일즈 팀, 이해관계자와의 관계를 해치지 않으면서 기능 요청에 전문적으로 "no"라고 말할 수 있게 해주는 프롬프트입니다. 상황별 거절 템플릿과 objection 대응까지 포함합니다.
제품 업데이트 이메일 작성기(Product Update Email Writer)
고객, 내부 팀, 리더십, 투자자 등 각기 다른 청중을 위한 설득력 있는 제품 업데이트 이메일을 작성하게 해주는 프롬프트입니다. 각 형식은 해당 청중의 관심사와 집중 시간에 맞게 최적화되어 있습니다.
스티브 잡스처럼 발표하기(Announce Like Steve Jobs)
이 프롬프트는 스티브 잡스에게 영감을 받아 설득력 있고 감정을 자극하는 제품/기능 발표를 작성하도록 도와줍니다. 핵심은 단순함, 우아함, 그리고 그 기능이 사용자 경험을 어떻게 변화시키는지에 두는 강조입니다. 결과는 단순히 무엇(what)이 아니라 왜(why)를 부각하는 명확하고 매력적인 내러티브입니다.
제품 이름 제안(Product Name Suggestions)
이 프롬프트는 기존 브랜드의 정체성(identity), 가치(values), 톤앤보이스(voice)에 자연스럽게 녹아드는 제품명 또는 기능명을 만들도록 설계되었습니다. 브랜드의 성격(personality), 감정적 울림(emotional resonance), 시장 포지셔닝(market positioning)을 중심에 두고, 브랜드의 핵심 본질을 강화하면서도 경쟁 환경에서 돋보이는 독창적이고 기억하기 쉬운 이름을 만드는 과정을 안내합니다.
릴리스 노트(Release Notes)
이 프롬프트는 프로덕트 매니저, 개발자, 마케팅 팀이 명확하고 매력적인 릴리스 노트(release notes)를 만들 수 있도록 돕습니다. 구조를 핵심 요소로 분해해 주요 업데이트, 개선사항, 버그 수정이 타깃 청중(target audience)에게 효과적으로 전달되도록 합니다. 사용자 혜택과 간결한 언어에 초점을 맞춰, 전문적이면서도 설득력 있는 릴리스 노트를 작성할 수 있게 해주며, 사용자 참여(engagement)와 신기능에 대한 기대감을 끌어올립니다.
블로그 포스트(Blog Post)
개인 메모를 잘 다듬어진 블로그 포스트(blog post)로 바꿔주는 프롬프트입니다. 거친 아이디어를 입력하기만 하면, 고유한 보이스(voice)는 유지한 채 콘텐츠를 다듬어 블로그 글쓰기를 수월하고 진정성 있게 만듭니다.
슬라이드 덱을 대체할 제품 내러티브 메모(Product Narrative Memo)
제품 리뷰 미팅이 PowerPoint로 인한 죽음 — 40장의 슬라이드, 15장째에 이르면 아무도 핵심 인사이트를 기억하지 못함. 이 프롬프트는 명확한 사고와 구조화된 논증을 강제하는 Amazon 스타일의 내러티브 메모를 작성해, 60장의 슬라이드가 아니라 6페이지 안에 제품 방향을 이해시킵니다.
Competitive Wedge 방식으로 제품 포지셔닝 문장 쓰기(Write a product positioning statement using the competitive wedge method)
붐비는 시장에 들어가는데 메시지가 경쟁사와 다를 바 없게 들릴 때 쓰는 프롬프트입니다. competitive wedge 방법을 사용해, 단지 더 잘한다는 말이 아니라 무엇을 다르게 하는지 드러내는 포지셔닝 문장을 만들 수 있게 해줍니다. 그러면 잠재 고객은 왜 이 제품이 존재하는지 즉시 이해하게 됩니다.
크로스펑셔널 buy-in을 위한 이해관계자 정렬 브리프 작성하기(Craft a stakeholder alignment brief for cross-functional buy-in)
제품 initiative를 제안하려고 하는데 엔지니어링은 실현 가능성을 보고, 세일즈는 매출 영향을 보고, 디자인은 사용자 경험을 보는 상황에서 쓰는 프롬프트입니다. 각 청중의 우선순위에 맞춘 섹션을 가진 단일 브리프를 만들어줍니다.
이해관계자 정렬을 위한 설득력 있는 제품 내러티브 작성하기(Write a compelling product narrative for stakeholder alignment)
경영진, 엔지니어링, 크로스 펑셔널 팀이 공유된 비전과 행동의 시급성에 정렬되도록 만드는 전략적 제품 내러티브가 필요할 때 이 프롬프트를 사용하세요.
Delivery
54 guides공개 출시 전 내부 런치 레디니스(launch readiness) 체크 작성하기
팀이 공개 출시 2주 전이고, 스탠드업에서 같은 질문이 반복됩니다. 정말로 준비되었는가? 이 프롬프트는 프로덕트, 엔지니어링, 서포트, 세일즈, 마케팅, 리걸을 같은 산출물 위에 두는 내부 런치 레디니스 체크를 작성합니다. 행마다 명시적 통과/실패 조건이 있어, go 결정이 분위기가 되지 않습니다.
사용자 스토리(user story)를 위한 강력한 수락 기준(acceptance criteria) 작성하기
팀이 스프린트(sprint) 시작 시점에 수락 기준(acceptance criteria) 대신 테스트 케이스를 작성하고 있고, QA에서 표면화되는 이슈의 상당수가 사전에 합의되지 않은 범위 모호함에서 비롯됩니다. 이 프롬프트는 단일 스토리에 대한 명확한 수락 기준 — 테스트 가능한 통과/실패 조건, 엣지 케이스(edge case), 부정 기준(negative criteria) — 을 작성하여, 릴리즈 시점이 아닌 코드 시작 전에 팀이 '완료'에 합의하도록 합니다.
PM 팀 회의 감사하기(Conduct a PM team meetings audit)
PM 팀이 주당 18시간을 회의에 쓰는데 그 회의 때문에 무엇이 출시되고 있는지 누구도 말하지 못할 때. 이게 감사를 돌립니다 — 모든 회의의 목적, 참석 비용, 결정 산출물 — 그리고 PM당 주 6~10시간을 되돌릴 수 있도록 죽이거나 재설계할 리스트를 만듭니다.
one-team-one-roadmap 통합 설계하기(Design a one-team-one-roadmap consolidation)
영업은 영업 로드맵이 있고, CS는 CS 로드맵이 있고, 마케팅은 마케팅 로드맵이 있고, 제품도 따로 로드맵이 있는데 이들이 하나도 맞지 않을 때 쓰는 프롬프트입니다. 다섯 개의 shadow roadmap을 하나의 운영 로드맵으로 통합해 shared ownership을 만들고, 이해관계자가 제품팀이 지킬 수 없는 약속을 멈추게 합니다.
Product Hunt 출시 플레이북 실행하기(Run a Product Hunt launch playbook)
3-4주 안에 Product Hunt 출시를 앞두고 있는데 지난번에는 그냥 올리고 기대만 했다가 upvote 20개로 끝났을 때 쓰는 프롬프트입니다. hunter 선정, 사전 audience 워밍, 출시 당일 시프트 운영, 에셋 체크리스트까지 포함해, 부끄러운 런치가 아니라 실제 신호를 남기는 런치 플레이북을 만듭니다.
Diligence 점수화로 DRICE 우선순위 세션 돌리기(Run a DRICE prioritization session with diligence scoring)
RICE가 순위 리스트를 줬지만 — 상위 베팅 셋이 지난 분기에 무너진 이유는 누구도 reach나 impact 숫자를 압력 테스트하지 않았기 때문일 때. DRICE는 점수화 전에 모든 R/I/C 입력에 대해 증거를 강제하는 Diligence 단계를 추가해, 위로 올라온 아이디어가 그럴 자격이 있도록 하고 실험 승률이 희망 섞인 추측에 흔들리지 않도록 합니다.
기능 sunset 계획 진행하기(Conduct a feature sunset plan)
기능이 0.5% 사용량을 가지고 분기에 엔지니어 2명을 유지에 비용으로 들 때. 서포트가 계속 티켓을 받을 때. 팀이 "sunset할 거야"라고 계속 말하지만 절대 안 할 때. 이 프롬프트는 명시적 sunset 계획 — 기준, 마이그레이션, 통보 기간, kill 날짜 — 을 만들어 프로젝트가 실제로 출시되도록 합니다.
90일 런치 지표 리뷰 설계하기(Design a 90-day launch metric review)
출시 직후 주간 activation 목표는 달성했지만, 90일이 지나도 아무도 그 기능이 실제로 의미 있었는지 설명하지 못할 때 쓰는 프롬프트입니다. 지속 사용, 비즈니스 영향, 유지 비용까지 포함한 90일 리뷰를 설계해, 더 투자할지 sunset할지 결정할 수 있게 합니다.
Shape Up 스타일의 6주 사이클 킥오프 진행하기(Run a Shape Up style 6-week cycle kickoff)
2주 스프린트가 깊이 있는 작업 대신 얕은 결과물과 끝없는 ceremony만 만들고 있을 때 쓰는 프롬프트입니다. shaped pitch, appetite 점검, 소규모 팀 배정, hill chart baseline까지 포함한 Shape Up 킥오프를 구성해 6주 동안 방해 없는 몰입과 명확한 종료 조건을 만들 수 있게 해줍니다.
go/no-go review 템플릿 설계하기(Design a go/no-go review template)
리더십은 분명한 go/no-go 결정을 원하지만 당신의 40슬라이드 status deck은 그 결론을 묻어버릴 때 쓰는 프롬프트입니다. Yes/no recommendation을 강제하고, 근거와 구체적 리스크를 명시하며, 모든 리뷰가 "다음에 다시 보죠"가 아니라 이진 결론으로 끝나게 하는 2페이지 템플릿을 만듭니다.
출시 전 readiness review 체크리스트 실행하기(Run a pre-launch readiness review checklist)
출시까지 5일 남았고 팀은 자신만만한데, 바로 그때 문제가 터집니다. 이 프롬프트는 product, engineering, support, sales, marketing, legal 전반에 걸친 pre-launch review를 돌려, 고객보다 먼저 놓친 부분을 발견하게 해줍니다.
스프린트 플래닝 진행자 아젠다 만들기
당신의 스프린트 플래닝은 90분 동안 이어지고, 30분이 지나면 모두 집중이 풀리며, 결과물은 누구도 믿지 않는 백로그입니다. 이 프롬프트는 목표를 정렬하고, 필요한 만큼만 쪼개고, 현실적인 범위를 확정하며, 왜 각 항목이 들어갔는지 모두가 이해한 채 끝나는 45분짜리 구조화된 아젠다를 만듭니다.
kill-switch가 포함된 feature flag 롤아웃 계획 설계하기(Design a feature flag rollout plan with kill-switch)
"merge되면 바로 출시"는 용감해 보이지만 첫 회귀 버그가 프로덕션을 무너뜨리는 순간 이야기가 달라집니다. 이 프롬프트는 cohort-by-cohort 노출, metric 기반 승격, one-click kill이 있는 flag-gated rollout을 설계해, 더 빠르게 ship하면서도 blast radius를 줄이고 주니어 엔지니어도 war room 없이 위험한 기능을 끌 수 있게 합니다.
rolling roadmap 분기별 re-plan 실행하기(Run a rolling roadmap quarterly re-plan)
연간 로드맵이 2분기쯤 되면 사실상 죽어버릴 때 쓰는 프롬프트입니다. 전략 기둥은 유지하되, 실제로 배운 내용을 바탕으로 다음 두 분기를 다시 순서화해, 항상 최신 상태를 유지하는 rolling 6개월 뷰를 만듭니다.
scope creep 방어 문서 만들기(Build a scope creep defense document)
6주 프로젝트를 시작했는데 4주 차가 되니 어느새 10주 프로젝트가 되어 있을 때 쓰는 프롬프트입니다. 추가된 항목마다 다 그럴듯한 이유가 있었겠지만, 이 문서는 실시간으로 scope creep를 드러내고, 미리 커밋된 scope boundary를 강제하며, 모든 추가 요청이 일정 연장이 아니라 기존 항목과의 tradeoff가 되게 만듭니다.
cycle time 기반 shipping velocity 진단 설계하기(Design a shipping velocity diagnosis using cycle time)
리더십은 "우리는 느리다"고 하고 팀은 "충분히 많이 내고 있다"고 할 때 쓰는 프롬프트입니다. First commit부터 production까지의 cycle time을 작업 유형별로 나눠 측정해, 어디를 먼저 고쳐야 하는지와 그 개선이 실제로 어떤 속도 향상을 주는지까지 보여 줍니다.
머지 충돌 근본 원인 분석 수행하기
팀이 매주 머지 충돌 해결에 몇 시간을 쓰고 있고, 모두가 다른 팀 탓을 하고 있습니다. 이 프롬프트는 최근 30일의 충돌을 구조적으로 분석해, 그 충돌을 만들어내는 코드 영역 2~3곳과 워크플로 패턴을 찾아내고 보통 더 작은 스토리와 더 명확한 소유권 경계 같은 해결책까지 도출합니다.
PM을 위한 엔지니어링 우수성 리뷰 설계하기(Design an engineering excellence review for PMs)
당신이 PM인데 엔지니어링 팀이 건강한지 안주하는지 알 수 없을 때. 이 프롬프트는 분기별로 돌릴 수 있는 엔지니어링 우수성 리뷰 — cycle time, 인시던트율, 테스트 커버리지 추세, 온콜 부하 — 를 설계해, 모호한 "속도가 이상하다" 직감 대신 EM 파트너와 구조화된 대화를 하도록 합니다.
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 onboarding step을 문서화한 kickoff doc을 만들어, 모든 소비 팀이 같은 답을 받고 나중에 당신에게 막히지 않게 합니다.
비난 없는 인시던트 포스트모템 진행하기(Conduct a blameless incident post-mortem)
지난 인시던트(incident) 포스트모템(post-mortem)이 비난과 망신주기로 변해서 누구도 다음 회차를 돌리고 싶어하지 않을 때. 이 프롬프트는 근본 원인을 찾고, 담당자가 있는 지속 가능한 액션 아이템을 만들고, 팀이 신호로부터 도망치지 않고 신호로 달려가도록 심리적 안전(psychological safety)을 유지하는 비난 없는 포스트모템을 안내합니다.
버그 SLA 계층 시스템 설계하기(Design a bug SLA tiering system)
모든 버그가 긴급해 보이고 엔지니어링이 마지막 Slack 메시지에 반응할 때. 이 프롬프트는 버그 SLA 계층 시스템 — P0/P1/P2/P3과 명시적 정의, 응답 윈도우, 라우팅 규칙 — 을 설계해 트리아지가 5분 작업이 되고 팀이 우왕좌왕을 멈추도록 합니다.
테크 부채 triage 프레임워크 만들기(Build a technical debt triage framework)
팀은 "tech debt sprint"를 원하고 리더십은 "기능을 내라"고 할 때 쓰는 프롬프트입니다. 둘 다 틀렸습니다. 이 프롬프트는 각 부채를 이자율(향후 배포를 얼마나 느리게 만드는지)로 정량화하고, 별도 허락을 구하지 않아도 지속적으로 부채를 갚아 나갈 수 있는 운영 규칙을 만듭니다.
베타 고객 모집과 성공 계획 돌리기(Run a beta customer recruitment and success plan)
4주 안에 실제 고객 10~20명을 베타에 올려야 하는데 CS 팀은 완전히 바쁠 때. 이 프롬프트는 모집 스펙, 스크리닝 기준, 성공 지표, 커뮤니케이션 주기를 만들어 — 베타 고객이 지원받는다고 느끼고 당신의 대역폭을 모두 소진하지 않으면서 필요한 신호를 주도록 합니다.
팀 간 dependency mapping 실행하기(Run a dependency mapping exercise across teams)
로드맵에는 Q2라고 적혀 있지만 사실 세 팀이 서로의 작업에 조용한 dependency를 갖고 있을 때 쓰는 프롬프트입니다. 숨겨진 coupling을 드러내고, 가장 위험한 dependency를 우선순위화하며, 팀 간 명시적 handshake agreement를 만들 수 있게 합니다.
제품 변경 이력 및 릴리즈 노트 작성기(Product Changelog & Release Notes Writer)
raw commit log, ticket list, sprint summary를 바탕으로 polished하고 user-friendly한 release note와 changelog를 생성하는 프롬프트입니다. in-app, 블로그 글, 이메일, Slack 공지 등 여러 형식을 동시에 만듭니다.
제품 분석 구현 계획(Product Analytics Implementation Plan)
어떤 이벤트, 속성, 사용자 속성을 계측해야 하는지 정의하는 product analytics tracking plan을 만드는 프롬프트입니다. 팀이 제품 의사결정에 필요한 데이터를 정확히 수집할 수 있게 해줍니다.
인시던트 포스트모템 템플릿(Incident Post-Mortem Template)
제품 인시던트(incident) 후 비난 없는(blameless) 포스트모템을 작성합니다. 타임라인, 근본 원인, 임팩트 평가, 그리고 재발을 방지하는 구체적 액션 아이템을 포착하도록 구조화됐습니다.
QA 테스트 계획 생성기(QA Test Plan Generator)
새 기능이나 릴리스를 위한 포괄적인 QA 테스트 계획을 생성하는 프롬프트입니다. 기능 테스트, edge case, regression, cross-browser/device, accessibility check까지 포함합니다.
제품 브리프 템플릿(Product Brief Template)
전체 PRD를 쓰기 전에 이해관계자를 먼저 정렬시키는 1-2페이지짜리 간결한 product brief를 만드는 프롬프트입니다. PRD보다 빠르고, 문제 정의와 제안 방향에 대한 초기 buy-in을 얻기에 적합합니다.
기능 명세 문서(Feature Specification Document)
엔지니어링 팀이 바로 구현할 수 있을 정도로 상세한 기능 명세를 작성하는 프롬프트입니다. user flow, edge case, API contract, error state, acceptance criteria까지 다루며 PRD보다 한 단계 아래 레벨의 문서입니다.
스프린트 플래닝 진행자(Sprint Planning Facilitator)
팀과 함께 효과적인 스프린트 플래닝 세션을 운영하게 해주는 프롬프트입니다. sprint goal 준비, 스토리 선택 및 추정, dependency 식별, capacity를 고려한 commitment 설정까지 돕습니다.
제품 로드맵 생성기(Product Roadmap Generator)
Now / Next / Later 또는 분기별 theme 기준으로 정리된 전략적 제품 로드맵을 만드는 프롬프트입니다. 우선순위 근거, dependency, 리소스 요구사항, stakeholder communication plan까지 포함합니다.
원페이저 생성기(One-Pager Generator)
이 프롬프트는 핵심 메시지를 효과적으로 전달하는 간결하고 매력적이며 임팩트 있는 원페이저(one-pager) 작성을 돕습니다. 비즈니스 제안, 마케팅 전략, 프로젝트 요약 등 어떤 용도든 명확성과 구조를 보장해 아이디어를 효율적으로 전달하도록 안내합니다. 간결함과 일관성에 초점을 맞춰 복잡한 정보를 한 페이지짜리 설득력 있는 문서로 압축해 주의를 사로잡고 임팩트를 극대화할 수 있게 해줍니다.
바이럴 제품 성장 루프 설계(Design a Viral Product Growth Loop)
이 프롬프트는 바이럴 루프(viral loop)와 네트워크 효과를 구조화해, 추천(referral)과 참여 루프를 통해 유기적 사용자 획득을 견인하고 리텐션을 높이도록 돕습니다.
그로스 해킹 플레이북 만들기(Develop a Growth Hacking Playbook)
이 프롬프트는 AARRR 프레임워크(Acquisition, Activation, Retention, Revenue, Referral)를 사용하여 그로스 해킹 전략을 정의함으로써 지속 가능한 제품 성장을 보장합니다.
v0.dev PRD 작성기 — 프로 버전(v0.dev PRD Generator (Pro Ver.))
이 프롬프트는 제품 리더가 구조화된 PRD 전체를 v0.dev에 입력하고, 그 결과로 여러 파일로 나뉜 자동 모듈형 Next.js 19 스캐폴드(scaffold)를 받을 수 있게 해줍니다. v0.dev는 코드를 app/, components/, hooks/, lib/, tests/, Tailwind 테마 등 작은 단위 파일로 분해하고, 각 파일은 100 LOC 이하로 제한하며 `#file` 지시자(directive)를 붙여 바로 저장소에 붙여 넣을 수 있게 만듭니다. 생성 후에는 Supabase 프로젝트를 연결하라는 간단한 팝업이 뜰 수 있습니다. 그 경우 앱 내 안내를 따라 실제 백엔드를 연결하면 됩니다.
최적의 PM 툴 찾기(Discover the Best PM Tools)
이 프롬프트는 다양한 PM 업무에 맞춘 소프트웨어 솔루션 목록을 종합적으로 생성해, 꼭 필요한 개발 및 제품 관리 툴을 식별하도록 돕습니다. 각 툴의 핵심 기능, 장점, 활용 사례(use case)에 대한 인사이트를 제공해 프로덕트 매니저가 더 정보에 근거한 선택을 내릴 수 있게 합니다. 사용자가 특정 툴을 염두에 두고 있다면 함께 넣어 상세 비교와 추천을 받을 수도 있습니다. 로드맵, 분석, 사용자 피드백, 협업, 워크플로우 관리를 위한 적절한 툴을 찾는 프로덕트 매니저에게 적합합니다.
기술 개념 분해(Technical Concept Breakdown)
이 프롬프트는 초보자, 중급 학습자, 전문가 등 사용자가 원하는 이해 수준에 맞춰 기술 개념을 설명하도록 돕습니다. 명확한 헤더와 중첩된 불릿 구조를 사용해 과도한 단순화 없이도 명료성과 정확성을 유지합니다. Feynman technique 같은 효과적인 학습 방법을 활용해 복잡한 아이디어를 소화 가능한 구성요소로 나눕니다. 맞춤형이고 구조화되어 있으며 몰입감 있는 설명이 필요한 학습자에게 적합합니다.
v0.dev PRD 작성기 — 심플 버전(v0.dev PRD Generator (Simple Ver.))
이 프롬프트는 제품 리더가 구조화된 v0.dev 최적화 템플릿을 통해 공유 가능한 PRD(Product Requirements Document)를 만들도록 안내합니다. 목표, 사용자 스토리, 기능 명세, UX, 지표, 통합을 위한 명확한 섹션을 배치하면서, v0.dev 컨벤션에 맞는 코드 생성 스니펫(snippet)을 강조합니다. 이를 사용하면 정렬과 전달을 가속하는 일관되고 고품질의 PRD가 보장됩니다.
제품 출시 속도가 떨어지는 이유 진단하기(Diagnose why your product's shipping velocity is declining)
팀 규모는 5명에서 15명으로 늘었는데 분기당 출시 기능 수는 오히려 줄고 있을 때 쓰는 프롬프트입니다. 스탠드업은 형식적이고, PR은 며칠씩 리뷰에 묶이며, 스프린트 약속은 계속 어긋나는 상황에서 진짜 병목이 프로세스인지, 아키텍처인지, 사람인지 구조적으로 진단합니다.
GTM 시퀀싱이 있는 제품 런칭 체크리스트(Product Launch Checklist with GTM Sequencing)
메이저 기능 런칭 2주 전인데, 제품, 마케팅, 세일즈, 서포트 사이의 조율된 계획이 없다는 걸 깨달았다고 합시다. 이 프롬프트는 베타 테스트부터 런칭 후 모니터링까지 무엇도 빠지지 않도록 보장하는 순차적 런칭 체크리스트를 만듭니다.
엔지니어링 팀을 위한 기술 부채 협상 케이스(Technical Debt Negotiation Case)
엔지니어링은 '기술 부채 스프린트'를 계속 요청하지만 비즈니스 임팩트를 설명하지 못하고, 리더십은 '지금은 안 돼'를 반복합니다. 이 프롬프트는 기술 부채를 비즈니스 언어 — 출시 속도, 사고 리스크, 기회비용 — 로 번역하는 데이터 기반 케이스를 만들어, 양쪽이 현실적인 상환 계획에 합의할 수 있게 합니다.
리텐션 중심의 온보딩 최적화 계획 수립하기(Build a retention-focused onboarding optimization plan)
회원가입 후 활성화까지의 전환율이 낮고 사용자가 제품의 핵심 가치를 경험하기 전에 이탈할 때 사용하는 프롬프트입니다. 온보딩 퍼널을 단계별로 해부해 정확한 이탈 지점을 찾고, 리텐션 개선에 직접 연결되는 우선순위 최적화 계획을 만듭니다.
엄밀한 A/B 테스트 프로그램 처음부터 설계하기(Design a rigorous A/B testing program from scratch)
팀이 가끔 실험은 하지만 체계가 없어서 테스트가 겹치고, 샘플 수는 감으로 잡고, 결과는 보고 싶은 것만 선택할 때 쓰는 프롬프트입니다. 가설 템플릿, 통계적 엄밀성, 의사결정 프레임워크를 갖춘 구조화된 실험 프로그램을 세팅합니다.
SRS(Software Requirements Specification) 작성기
이 프롬프트는 프로덕트 매니저가 명확하고 실행 가능하며 전략적인 SRS(Software Requirements Specification)를 작성하도록 돕습니다. 문제 정의, AI 활용, 비즈니스 목표, 기능 명세, 이해관계자 정렬 같은 핵심 영역을 다루는 13개 섹션 구조를 제공합니다. 각 섹션에는 명확성과 팀 간 협업을 지원하는 상세 예시와 형식이 포함되어 있습니다. 복잡한 제품이나 AI 기반 제품에 특히 적합하며, 높은 수준의 아이디어를 구조화되고 실행 준비가 된 계획으로 바꾸는 데 도움을 줍니다.
사용자 스토리(User Story)
Head of Product가 사용자 니즈와 비즈니스 목표를 크로스 펑셔널 팀(cross-functional team)의 실행 가능한 작업으로 효과적으로 옮기는 사용자 스토리(user story)를 작성하도록 안내하는 프롬프트입니다. 사용자 스토리, 목표(objectives), 수락 기준(acceptance criteria), 명확한 완료 정의(definition of done)를 위한 구조화된 프레임워크로 명확성, 가치 중심, 전략 목표와의 정렬(alignment)을 강조합니다.
PRD 작성기(PRD Generator)
이 프롬프트는 프로덕트 매니저(Product Manager)가 Head of Product 관점에서 명확하고 전략적인 PRD(Product Requirements Document, 제품 요구사항 문서)를 작성할 수 있도록 돕습니다. 목표(objectives), 타깃 고객(target customer), 전략적 적합성(strategic fit), 핵심 가설(key hypotheses), 솔루션 원칙(solution principles)을 다루는 구조화된 프레임워크를 제공해 회사 목표와 정렬되도록 보장합니다. 성공 지표(success metrics)나 타임라인 같은 섹션을 추가해 자신의 상황에 맞게 커스터마이징할 수 있어 유연성이 높습니다. 이 접근은 아이디어를 실행 가능한 계획으로 바꾸어 제품 개발의 성공을 이끕니다.
Jira 이슈 작성(Write Jira Issues)
제품 기능을 위한 명확하고 간결한 Jira 티켓(ticket)을 만들어주는 프롬프트입니다. 기능의 목적과 동작을 설명하기만 하면, 팀이 곧바로 시작할 수 있는 실행 가능한(actionable) 티켓으로 포맷팅됩니다. 빡빡한 양식이나 과도한 디테일 걱정 없이 아이디어를 빠르게 문서화하는 데 적합합니다.
우리 팀에 맞는 딜리버리 방법론 설계하기(Design a fit-for-purpose delivery methodology for your team)
팀이 경직된 Scrum이나 Waterfall을 넘어, 자신들의 프로젝트 맥락에 맞는 맞춤형 딜리버리(delivery) 접근 방식을 설계해야 할 때 이 프롬프트를 사용하세요.
핵심 제품 지표(Key Product Metrics)
이 프롬프트는 핵심 제품 지표(product metric)를 정의하고 비즈니스 목표와 정렬시키는 것을 돕습니다. 솔루션 임팩트, 사용자 인게이지먼트(engagement), 성장을 측정하는 데이터 기반 접근을 보장합니다.
아마존 스타일 1-Pager(Amazon-style 1-Pager)
이 프롬프트는 아마존(Amazon)의 침묵 독해(silent reading) 형식을 사용하여 전략적이고 실행 중심의 1-Pager 작성을 안내합니다. 명확성, 논리, 진실 추구를 중심으로 제품 제안을 구조화하며, 고객 문제, 제안 솔루션, 핵심 지표, 액션 아이템을 다루는 명확한 섹션을 갖춥니다. 제품 팀이 우선순위를 정렬하고 빠른 의사결정을 가능하게 합니다.
비즈니스 임팩트 점수가 있는 가치 중심 스프린트 회고(Value-Driven Sprint Retrospective)
팀 프로세스를 넘어 스프린트 결과를 비즈니스 가치와 명시적으로 연결하는 회고를 진행하는 프롬프트입니다 — 산출물(output) 중심에서 결과(outcome) 중심 딜리버리로 팀을 전환시킵니다.
Career & Interview
24 guides레벨링이 주관적이지 않도록 PM 커리어 패스 다시 쓰기
PM 조직이 사람을 분위기로 레벨링하고, 같은 종류의 일이 한 팀에서는 L4, 다른 팀에서는 L6로 불립니다. 이 프롬프트는 PM 커리어 패스를 4개의 관찰 가능한 축(문제 복잡도, 영향 범위, 자율성, 리더십)과 레벨별 한 줄 루브릭으로 다시 작성하여 캘리브레이션(calibration) 논쟁을 끝내고 다음 승진을 글로 방어할 수 있게 만듭니다.
이해관계자 전략을 위한 PM 영향력 맵 만들기(Build a PM influence map for stakeholder strategy)
직접 보고하는 인원은 없지만, 세 개 기능 조직에 걸친 여덟 명이 로드맵에 commit해야 하는 상황을 위한 프롬프트입니다. 누가 결정하고, 누가 추천하고, 누가 막을 수 있고, 누가 누구에게 영향을 주는지 보여주는 stakeholder influence map을 만들어, 제한된 대면 시간을 실제로 결정을 움직이는 사람에게 집중하게 해줍니다.
매니저를 관리하는 운영 리듬 만들기(Build a managing-managers operating rhythm)
PM을 직접 관리하던 역할에서 PM 매니저를 관리하는 역할로 승진했는데, 예전처럼 IC와 1:1을 하고 roadmap를 직접 리뷰하고 launch를 디버깅하려다 모든 것이 두 단계 아래로 내려간 상황에 쓰는 프롬프트입니다. managing-managers 역할에 맞는 주간, 월간, 분기 운영 리듬을 설계해, 직접 끼어드는 대신 매니저를 통해 리드하게 만듭니다.
BATNA를 포함한 보상 협상 스크립트 초안 만들기(Draft a compensation negotiation script with BATNA)
오퍼를 받았고 instinct상 빨리 수락하고 싶을 때 쓰는 프롬프트입니다. BATNA(best alternative), anchor, fallback position까지 포함한 협상 스크립트를 만들어, 감이 아니라 구체적인 기준으로 협상하고 12개월 뒤 돌아봐도 아쉬움 없는 comp로 마무리하게 합니다.
step-down 또는 lateral move 대화 초안 만들기(Draft a step-down or lateral move conversation)
관리 트랙이 자신과 맞지 않는다는 걸 깨닫고 IC로 돌아가고 싶거나, 다른 PM scope로 lateral move하고 싶을 때 쓰는 프롬프트입니다. 이 대화를 매니저와 어떻게 시작할지 초안을 만들어, 후퇴가 아니라 사려 깊은 커리어 명확성으로 들리게 합니다.
매니저 exit interview 아웃라인 만들기(Build a manager exit interview outline)
회사를 떠나기 전 금요일에 매니저와 exit interview가 잡혀 있을 때 쓰는 프롬프트입니다. 다리를 태우지 않으면서도 유용한 피드백을 남길 수 있는 아웃라인을 만들어, 무엇이 잘 됐고 무엇이 안 됐는지, 다음 PM이 무엇을 알면 좋을지 정리하게 합니다.
PM 인터뷰용 회사 리서치 브리프 만들기(Build a PM interview company research brief)
5일 뒤 PM 인터뷰가 있고 준비 시간은 2시간뿐일 때 쓰는 프롬프트입니다. 제품, 전략, 지표, 팀, 최근 뉴스까지 묶은 리서치 브리프를 만들어, 내부 지원자보다 더 회사에 대해 잘 알고 온 것처럼 보이게 합니다.
새 PM 역할을 위한 30-60-90 day plan 만들기(Run a 30-60-90 day plan for a new PM role)
새 PM 역할에 막 합류했거나 곧 합류할 예정인데 매니저가 30-60-90 계획을 요청했을 때 쓰는 프롬프트입니다. 30일은 듣고, 60일은 검증하고, 90일은 리드하는 식으로 구체적인 계획을 만들어, 새 팀이 보기에 생각이 정리된 사람처럼 보이게 합니다.
PM 구직을 위한 개인 브랜드 진단하기
이제 막 구직을 시작하려는데, 온라인 존재감은 3년째 방치된 상태입니다. 이 프롬프트는 LinkedIn, 포트폴리오, 컨퍼런스 발표, 글쓰기까지 개인 브랜드를 점검해, 채용 담당자와 리크루터가 당신의 이름을 검색했을 때 일관된 이야기를 보게 합니다.
product sense 인터뷰 연습 루프 설계하기(Design a product sense interview practice loop)
Product sense 답변이 follow-up probing 앞에서 자꾸 무너질 때 쓰는 프롬프트입니다. Question bank, timed answer, self-critique rubric, mock partner를 포함한 practice loop를 만들어, 인터뷰 자리에서가 아니라 그 전에 근육을 만들게 합니다.
PM 커리어 성장 대화 템플릿 만들기
다음 1:1은 그동안 미뤄온 커리어 대화입니다. 이 프롬프트는 현재 레벨, 성장 영역, 근거, 요청 사항을 담은 구조화된 템플릿을 만들어, 막연한 격려가 아니라 데이터에 기반해 대화를 주도하고 문서화된 성장 계획을 가지고 나오게 합니다.
peer-360 피드백 synthesis 진행하기(Conduct a peer-360 feedback synthesis)
동료 리뷰 5개를 받았는데 같은 360 안에서 "너무 전술적"이라는 말과 "너무 전략적"이라는 말이 함께 나와 신호가 엇갈릴 때 쓰는 프롬프트입니다. 리뷰를 근거 있는 주제로 묶고, 실제로 행동할 신호 2개를 고르고, 정중하게 무시할 신호를 결정하게 합니다.
리뷰 전에 매니저 피드백 세션 진행하기(Conduct a manager feedback session before your review)
공식 리뷰까지 4주 남았고 surprise를 줄이고 싶을 때 쓰는 프롬프트입니다. 매니저에게 중간 피드백을 능동적으로 요청하는 세션을 설계해, 서면 리뷰가 폭로가 아니라 이미 조정된 내용의 확인이 되게 만듭니다.
측정 가능한 임팩트 bullet로 PM 포트폴리오 만들기(Build a PM portfolio with measurable impact bullets)
이력서의 "제품을 관리했다" 수준 bullet이 아무 말도 못 할 때 쓰는 프롬프트입니다. bullet을 action, context, measurable outcome, scope가 포함된 임팩트 문장으로 다시 써서, 리크루터는 실제 성과를 이해하고 시니어 PM도 수준을 바로 알아보게 만듭니다.
IC-to-lead 전환을 위한 성장 계획 설계하기(Design a growth plan for an IC-to-lead transition)
최고의 IC PM이었고 막 lead로 승진했는데, 예전 본능인 직접 ship하기, 스스로 증명하기, 막히면 내가 뛰어들기 같은 습관이 이제는 오히려 틀린 본능이 된 상황에서 쓰는 프롬프트입니다. 명시적인 행동 전환이 담긴 90일 성장 계획을 만들어, IC 시절의 comfort zone으로 회귀하지 않고 전환을 해내게 합니다.
PM 이력서의 수치화 리라이트 작성하기(Write a PM resume quantification rewrite)
PM 이력서에 스토리는 있는데 숫자가 없을 때 사용하는 프롬프트입니다. 각 스토리를 방어 가능한 수치가 들어간 bullet로 다시 쓰고, 정확한 수치를 공개하기 어려울 때는 범위나 대체 신호를 사용해 시니어 리뷰어가 기대하는 수준의 impact 표현으로 맞춰줍니다.
PM 연봉 협상 플레이북(PM Salary Negotiation Playbook)
레벨과 시장 상황에 맞춘 데이터 기반 협상 포인트, 카운터오퍼 스크립트, 협상 전략으로 PM 연봉 협상을 준비하게 해주는 프롬프트입니다. base, equity, sign-on, 비금전적 레버까지 다룹니다.
PM 모의 인터뷰 시뮬레이터(PM Mock Interview Simulator)
product sense, execution, behavioral, strategy까지 포함한 풀 PM 모의 인터뷰를 시뮬레이션하는 프롬프트입니다. 45분 인터뷰의 실제 리듬과 후속 질문, 상세 scorecard까지 재현합니다.
PM 이력서 & 포트폴리오 최적화기(PM Resume & Portfolio Optimizer)
ATS와 채용 매니저 모두에게 더 잘 읽히도록 PM 이력서를 최적화하는 프롬프트입니다. bullet point를 정량화된 임팩트 중심으로 다시 쓰고, 경험을 PM competency model에 매핑하며, 보완해야 할 공백을 찾아줍니다.
프로덕트 매니지먼트로 전환하는 방법(How to Transition into Product Management)
프로덕트 매니지먼트로 커리어 전환을 원하는 사람을 위한 구조화된 가이드입니다. 현재 배경을 분석하고, transferable skill을 식별하고, 구체적인 액션 아이템이 포함된 개인 맞춤형 전환 로드맵을 만듭니다.
PM 인터뷰: 전략과 케이스 스터디(PM Interview: Strategy & Case Study)
제품 전략 케이스 스터디 — 가장 어려운 PM 인터뷰 질문 유형 — 를 연습합니다. 시장 진입, 경쟁 대응, 가격 책정, 성장 전략 케이스를 사고를 구조화할 프레임워크와 함께 다룹니다.
PM 인터뷰: Behavioral STAR Method
STAR 방식(Situation, Task, Action, Result)으로 설득력 있는 behavioral interview 답변을 준비하는 프롬프트입니다. 리더십, 크로스펑셔널 협업, 임팩트를 보여주는 기억에 남는 PM 스토리로 경험을 구조화해줍니다.
PM 인터뷰: 페르미 추정 연습(Fermi Estimation Practice)
PM 인터뷰에서 흔히 묻는 추정과 시장 사이징 질문을 연습하세요. 프롬프트가 현실적인 페르미 추정(Fermi estimation) 문제를 생성하고, 명확한 가정과 계산으로 푸는 구조화된 접근을 안내합니다.
PM 인터뷰: 제품 감각 연습(PM Interview: Product Sense Practice)
상위 테크 기업에서 사용하는 product sense 인터뷰 질문을 연습할 수 있습니다. 이 프롬프트는 실제 인터뷰어처럼 제품을 설계하거나 개선하라는 질문을 던지고, Google, Meta, Amazon PM loop의 평가 기준을 바탕으로 구조화된 피드백을 제공합니다.
AI & Automation
34 guidesPRD 작성 전 PM 주도 AI 프로토타이핑 스프린트 진행하기
아직 작동하는 모습을 본 적 없는 기능에 대한 PRD를 쓰려는 참인데, 그 스펙이 증거 없는 가정으로 팀을 묶어 둘 것입니다. 이 프롬프트는 PM이 AI 도구로 클릭 가능한 프로토타입을 만들고, 5명 사용자에게 건네고, 상상한 반응이 아닌 실제 반응을 근거로 PRD를 다시 쓰는 3일 프로토타이핑 스프린트를 운영합니다.
런칭한 기능을 위한 계층형 AI 평가(eval) 프로그램 설계하기
바이브 체크로 LLM 기반 기능을 출시했는데 이제 실제 사용자가 테스트한 적 없는 실패를 표면화하고 있습니다. 이 프롬프트는 해당 기능을 위한 계층형 평가(eval) 프로그램을 만듭니다. 판단이 필요한 영역에는 사람 리뷰, 결정론적 체크에는 코드 기반 평가, 손으로 채점할 수 없는 열린 결과물에는 LLM 저지(judge)를 씁니다.
다음 세션을 위한 AI 핸드오프(handoff) 문서 작성
AI 에이전트(agent) 세션이 컨텍스트(context) 한도에 도달했거나, 작업 중간에 기기를 바꿔야 합니다. 핸드오프 문서가 없으면 다음 세션이 이미 내린 결정을 다시 논의하고 실패한 시도를 또 반복합니다. 이 프롬프트는 처음 보는 사람도 그대로 이어받을 수 있는 구조화된 HANDOFF 문서를 만들어 줍니다.
제품 팀을 위한 공유 AI glossary 초안 만들기(Draft a shared AI glossary for your product team)
팀이 "agent"라고 말하면서 각자 전혀 다른 뜻을 가리키고, planning 중에 "RAG"가 나와도 절반은 이해한 척만 하고 있을 때 쓰는 프롬프트입니다. 교과서 정의가 아니라 당신의 제품에서 실제 운영상 어떤 의미로 쓰는지를 담은 1페이지짜리 AI glossary를 만들어, 모든 planning conversation이 공통 어휘에서 시작되게 합니다.
golden dataset으로 AI 기능 eval 실행하기(Run an AI feature eval with golden dataset)
AI 기능의 품질을 객관적으로 측정해야 하는데 느낌이나 출시 주간 데모에 의존하고 싶지 않을 때 쓰는 프롬프트입니다. Golden dataset, blind human scoring, 통계적 유의성 검정을 포함한 eval을 설계해, "품질"을 인상이 아니라 숫자로 보고할 수 있게 합니다.
대화형 AI interaction flow 설계하기(Design a conversational AI interaction flow)
사용자가 AI 채팅을 열고도 무엇을 물어봐야 할지 모를 때 쓰는 프롬프트입니다. Suggested start, progressive disclosure, recovery path, graceful refusal까지 포함한 interaction flow를 설계해, 첫 사용 성공률을 50% 이상으로 끌어올리고 사용 습관까지 만들게 합니다.
AI 보조 PRD 비평 워크플로우 만들기(Build an AI-assisted PRD critique workflow)
시니어 PM이 모든 draft를 직접 읽어야 해서 PRD 리뷰가 병목일 때 쓰는 프롬프트입니다. 체크리스트 프롬프트, quality gate, high-stakes 항목에 대한 human review를 결합해, 사람이 보기 전에 초안 품질을 끌어올리고 시니어는 진짜 어려운 문제에 집중하게 만듭니다.
고객 피드백을 자동 triage하는 PM 워크플로 만들기(Build a PM workflow that auto-triages customer feedback)
Intercom, NPS, Slack, 이메일 등에서 주당 500개의 고객 피드백을 받는데 팀이 실제로 읽는 건 30개 남짓일 때 쓰는 프롬프트입니다. AI triage workflow를 만들어 분류, 클러스터링, 신호 표면화를 자동화해, PM은 중요한 것만 리뷰하게 합니다.
사용자를 위한 AI 제품 고지 패턴 설계하기
당신의 AI 기능이 결과물을 생성하지만, 사용자는 그것을 얼마나 신뢰해야 할지 잘 모릅니다. 이 프롬프트는 AI가 개입했음을 알리고, 신뢰도 표시, 출처 링크, 오버라이드 경로를 포함한 고지 패턴을 설계해, 사용자가 과신도 과소신뢰도 하지 않도록 돕습니다.
AI 기능 신뢰 보정 audit 진행하기(Conduct an AI feature trust calibration audit)
사용자가 당신의 AI를 과신해선 안 되는 출력에 그대로 행동하거나, 반대로 충분히 맞는 출력도 무시해 버릴 때 쓰는 프롬프트입니다. 사용자 테스트, 시나리오 프로브, 행동 데이터를 통해 신뢰 보정이 어긋난 지점을 드러내고, 이를 바로잡을 개입 방안을 설계합니다.
PM 업무를 위한 자동화 기회 스캔 만들기(Build an automation opportunity scan for PM work)
PM으로 일하면서 한 주의 절반을 회의, 후속 조치, 요약, 문서 수정에 쓰고 있을 때 사용하는 프롬프트입니다. 최근 2주를 돌아보며 반복적이고, 시간이 많이 들고, 판단 비중은 낮은 작업을 찾아 자동화 후보를 뽑고, 가장 먼저 자동화할 2-3개를 골라 주당 몇 시간을 되찾게 합니다.
출시 전 AI 기능 평가 루브릭 설계하기(Design an AI feature evaluation rubric before shipping)
AI 기능을 출시하려는데 유일한 평가가 "팀 보기에 좋아 보임"일 때. 이 프롬프트는 적절한 평가 루브릭 — 태스크 셋, 점수화 기준, 골든 답안, 회귀 가드레일 — 을 설계해 자신감으로 출시하고 나중에 드리프트를 잡도록 합니다.
AI 액션당 비용 모니터링 대시보드 만들기(Build an AI cost-per-action monitoring dashboard)
AI 기능은 잘 동작하지만 비용이 사용자 수보다 더 빠르게 커지고 있을 때 쓰는 프롬프트입니다. 사용자당 비용, 성공 결과당 비용, 시간에 따른 비용 드리프트를 추적하는 대시보드를 설계해, 재무팀이 먼저 문제를 지적하기 전에 runaway cost를 포착할 수 있게 합니다.
AI 기능을 위한 human-in-the-loop 안전망 설계하기(Design a human-in-the-loop safety net for an AI feature)
AI 기능이 꽤 잘 작동하지만 고위험 작업을 완전히 맡길 만큼은 아닐 때 쓰는 프롬프트입니다. Review gate, confidence threshold, escalation trigger를 포함한 human-in-the-loop 안전망을 설계해, AI가 대부분의 작업을 처리하되 중요한 지점에서는 사람이 개입하게 만듭니다.
AI vs. non-AI ROI 비교 수행하기(Conduct an AI vs. non-AI ROI comparison)
AI 기반 버전의 기능을 만들려 하는데, 몇 달을 쓰기 전에 정말 ROI가 맞는지 확인하고 싶을 때 쓰는 프롬프트입니다. AI cost, non-AI 대비 quality delta, risk premium을 비교해, AI가 실제로 이기는지 아니면 데모에서만 그럴듯한지 판단하게 합니다.
PM 워크플로를 위한 LLM prompt library 만들기(Build an LLM prompt library for PM workflows)
팀이 PRD 초안, 경쟁사 분석, 인터뷰 synthesis에 AI를 쓰고 있는데 각자 프롬프트가 달라 결과 품질이 들쭉날쭉할 때 쓰는 프롬프트입니다. 버전 관리되고 테스트된 공유 prompt library를 만들어, 한 사람이 개선한 결과를 모두가 재사용하게 합니다.
팀을 위한 5단계 AI 도입 플레이북 만들기(Build a 5-step AI adoption playbook for your team)
경영진이 "AI-first"를 선언했지만 팀은 모호한 지시, procurement 병목, 어떤 워크플로우부터 자동화해야 하는지에 대한 가이드 부재에 막혀 있을 때 쓰는 프롬프트입니다. 방법을 설명하고, 추적하고 보상하고, 레드테이프를 줄이고, 열성 사용자를 교사로 만들고, 고임팩트 업무를 우선순위화하는 이 다섯 단계 플레이북은 Shopify, Ramp, Duolingo, Zapier, Intercom, Whoop이 쓴 전술을 순서 있는 계획으로 정리해 이번 주 안에 리더십 앞에 올릴 수 있게 해줍니다.
모델 업그레이드 migration runbook 설계하기(Design a model upgrade migration runbook)
새 모델 버전이 나왔고 팀은 내일 바로 올리고 싶어 할 때 쓰는 프롬프트입니다. Eval 비교, 비용 차이, cohort rollout, rollback criteria를 담은 migration runbook을 만들어, 사용자가 의존하는 프로덕션 동작을 깨뜨리지 않고 모델 업그레이드를 배포하게 합니다.
prompt regression testing suite 실행하기(Run a prompt regression testing suite)
프롬프트를 조금 손봐서 버그 하나는 고쳤는데, 다른 세 가지 동작이 조용히 회귀했을 때 쓰는 프롬프트입니다. Gold test set, 자동 diff, pass/fail threshold를 포함한 regression testing suite를 설계해, 모든 prompt 변경을 ship 전에 검증하게 합니다.
AI 기능 환각(hallucination) 감사 돌리기(Run an AI feature hallucination audit)
사용자가 그럴듯하게 들리지만 틀린 AI 출력에 불평하고 있을 때. 이 프롬프트는 구조화된 환각 감사 — 실제 사용자 로그, 분류, 근본 원인 — 를 돌려, 모델이 어디서 사실을 지어내는지 이해하고 올바른 수정(prompt, retrieval, fine-tune, 또는 scope)을 적용할 수 있도록 합니다.
AI 제품 지표 대시보드 설계자(AI Product Metrics Dashboard Designer)
제품 유형과 단계에 맞는 제품 지표 대시보드를 설계하게 해주는 프롬프트입니다. North Star → primary → secondary → guardrail로 이어지는 metric hierarchy를 정의하고, 데이터 소스와 모니터링 계획까지 함께 만듭니다.
AI PRD 검토 및 개선(AI PRD Review & Improvement)
PRD에 대한 AI 기반 검토를 받으세요 — 완결성, 명확성, 기술 실현 가능성 격차, 누락된 엣지 케이스를 점검합니다. 구체적 개선 제안이 담긴 스코어카드를 반환합니다.
AI 스프린트 리포트 생성기(AI Sprint Report Generator)
완료된 스토리, velocity, 버그, blocker 같은 raw sprint data로부터 정돈된 sprint report를 자동 생성하는 프롬프트입니다. 팀용 상세 리포트와 경영진용 요약을 모두 만듭니다.
AI 경쟁 모니터링 리포트(AI Competitive Monitoring Report)
경쟁사의 업데이트, 제품 출시, 가격 변화, 시장 움직임을 분석해 구조화된 경쟁 인텔리전스 리포트를 만드는 프롬프트입니다. Perplexity나 ChatGPT Deep Research 같은 AI 리서치 도구와 함께 쓰기에 적합합니다.
AI 고객 피드백 분류기(AI Customer Feedback Classifier)
지원 티켓, NPS 코멘트, 앱 리뷰, 소셜 미디어 등 여러 채널에서 들어오는 고객 피드백을 제품이 바로 행동으로 옮길 수 있는 카테고리로 자동 분류하고, 심각도 기준으로 우선순위를 매기게 해주는 프롬프트입니다.
AI 회의록을 액션 아이템으로(AI Meeting Notes to Action Items)
어수선한 회의 메모나 트랜스크립트를 구조화된 액션 아이템, 결정 사항, 미해결 질문, 이해관계자 후속 조치로 변환합니다. 스프린트 계획, 제품 리뷰, 크로스 펑셔널 싱크에 완벽합니다.
AI 사용자 리서치 합성기(AI User Research Synthesizer)
인터뷰, 설문, 지원 티켓 같은 원시 사용자 리서치 데이터를 AI로 구조화된 인사이트로 바꾸는 프롬프트입니다. theme, sentiment pattern, 실행 가능한 추천을 자동으로 뽑아냅니다.
AI 기반 일일 PM 워크플로우(AI-Powered Daily PM Workflow)
PM이 가장 많은 시간을 쓰는 업무인 standup 준비, stakeholder 업데이트, metric 요약, inbox triage를 AI로 자동화하는 일일 워크플로우를 설계하는 프롬프트입니다. 하루 2-3시간 절약을 목표로 합니다.
제품 최적화를 위한 자율 실험 루프 설계하기(Design an autonomous experiment loop for product optimization)
온보딩 카피, 가격 페이지 레이아웃, 알림 타이밍처럼 제품 안의 무언가를 더 좋게 만들 수 있다는 건 알지만, A/B 테스트를 수동으로 돌리기엔 너무 느리고 충분한 변형을 시도하지 못할 때 쓰는 프롬프트입니다. Karpathy의 autoresearch 패턴(https://github.com/karpathy/autoresearch)을 적용해, 각 반복이 이전 실험 위에 쌓이는 구조화된 실험 루프를 설계합니다.
AI 기반 사용자 리서치 synthesis 워크플로우 구축(Build an AI-powered user research synthesis workflow)
여러 개의 사용자 인터뷰 transcript나 피드백 소스가 있고, AI가 패턴, 테마, 실행 가능한 인사이트를 자동으로 식별하길 원할 때 이 프롬프트를 사용하세요.
제품 의사결정을 위한 개인 AI 사고 파트너 만들기(Build a personal AI thinking partner for product decisions)
제품 의사결정을 두고 계속 오락가락하고 있어, 이해관계자에게 가져가기 전에 자신의 논리를 구조적으로 압박 테스트하고 싶을 때 쓰는 프롬프트입니다. 가정을 흔들고, blind spot를 드러내고, 더 근거 있는 결론에 도달하도록 도와주는 AI sparring partner를 세팅합니다.
AI 오케스트레이션 QA와 출시 체크리스트 설정하기(Set up an AI-orchestrated QA and ship checklist)
기능을 출시하려는데 수동 테스트를 넘어서는 종합 사전 출시 체크리스트가 필요할 때. AI 보조 QA가 표준이 되면서, 리뷰-테스트-출시 파이프라인이 실제로 무엇을 다뤄야 하는지 정의 — 코드 리뷰부터 배포 후 카나리(canary) 모니터링까지.
어떤 제품 artifact든 최적화하는 autoresearch loop 실행하기(Run an autoresearch loop to optimize any product artifact)
landing page copy, onboarding script, email sequence, pricing page처럼 어느 정도는 작동하지만 아직 훌륭하진 않은 제품 artifact가 있을 때 쓰는 프롬프트입니다. 무엇을 고쳐야 할지 감으로 추측하지 말고, Karpathy의 autoresearch loop(https://github.com/karpathy/autoresearch)를 적용해 variant 생성 → metric 점수화 → 유지/폐기 → 반복을 수렴할 때까지 실행하게 합니다.
PM 운영을 자동화하는 AI 에이전트 워크플로우 설정하기(Set up an AI agent workflow to automate PM operations)
반복적인 PM 업무(티켓 triage, backlog grooming, status reporting)를 자율적으로 실행하는 AI 에이전트에 위임하고 싶을 때 이 프롬프트를 사용하세요.
Discovery
46 guidesB2B 제품-시장 적합성(PMF) 신호를 갱신과 영업 주기로 감사하기
B2B 프로덕트가 데모는 잘 하고 NPS도 괜찮은 편인데, CEO가 PMF에 도달했는지 묻고 있습니다. Sean Ellis 40 percent 테스트는 소비자 프로덕트용으로 만들어졌고 갱신 끌림, 확장 경제, 영업 주기 단축을 잡지 못합니다. 이 프롬프트는 B2B 특화 신호를 감사하여 답이 느낌이 되지 않게 합니다.
활성화(activation) 지표를 후보 리스트에서 인과 증명까지 도달시키기
팀이 활성화(activation) 마일스톤을 추측만 하고 있고, 유지율(retention) 곡선이 움직이지 않습니다. 이 프롬프트는 후보 모멘트 브레인스토밍, 유지율과의 회귀 분석, 그리고 그 마일스톤이 단순 상관이 아니라 인과적임을 증명하는 실험 설계까지 팀을 안내합니다.
제품 이전 단계의 명확성을 위한 Foundation Sprint 설계하기(Design a Foundation Sprint for pre-product clarity)
유망한 아이디어와 작은 팀은 있지만 엔지니어를 투입하기 전까지 겨우 2주만 남아 있을 때 쓰는 프롬프트입니다. 전통적인 Design Sprint는 해법을 테스트하기 위한 것이지만, 아직 그 단계가 아니라면 먼저 고객, 문제, 차별화에 대한 힘든 결정을 내려야 합니다. Foundation Sprint는 이틀 동안 그 핵심 선택을 강제해 다음 스프린트가 first principle을 다시 논쟁하지 않게 만듭니다.
리텐션 분석을 돌리고 누수 지점 진단하기(Run a retention analysis and diagnose the leak)
리텐션 그래프가 빨간데 어디서 시작할지 누구도 모를 때. 이 프롬프트는 구조화된 리텐션 분석 — 코호트(cohort) 세분화, 이벤트 깔때기, 기능 사용 상관관계 — 을 돌려, 10개 개입을 동시에 토론하는 대신 가장 중요한 1~2개 누수 지점을 찾도록 합니다.
사용자 불만에 대한 5-whys 근본 원인 분석 돌리기(Run a 5-whys root cause analysis on a user complaint)
큰 고객 불만이 막 임원 받은편지함에 들어왔고 팀의 첫 본능이 증상을 패치하는 것일 때. 이 프롬프트는 불만을 구조적 원인으로 추적하는 5-whys 분석을 돌려 — 단순한 탈출구가 아니라 출처를 고치도록 합니다.
기능 채택 퍼널 audit 설계하기(Design a feature adoption funnel audit)
당신이 출시한 기능을 사용자 40%가 보긴 했지만 실제로 사용한 사람은 3%뿐일 때 쓰는 프롬프트입니다. Discover, try, use, retain으로 이어지는 adoption funnel을 점검해, 누수가 인지도인지, 의도인지, activation인지, 가치 전달인지 찾아냅니다.
보내기 전 설문 설계 리뷰 진행하기(Conduct a survey design review before you send)
20문항짜리 설문을 5,000명 고객에게 보내려는데 데이터가 아무 쓸모 없을 게 뻔할 때. 이 프롬프트는 보내기 전에 유도 언어, 나쁜 척도, 응답 피로, 분석 가능성에 대해 설문을 리뷰합니다 — 결과가 실제로 결정을 추동하도록.
고객 자문 위원회 헌장 만들기(Build a customer advisory board charter)
톱 고객이 로드맵에 더 많은 영향력을 원하고 팀이 충돌하는 요청을 만들어내는 1:1 콜을 계속 가질 때. 이 프롬프트는 고객 자문 위원회(Customer Advisory Board, CAB) 헌장 — 멤버십, 주기, 형식, 입력, 결정 경계 — 을 만들어 톱 고객이 구조화된 입력을 갖고 로드맵이 분열되지 않도록 합니다.
기초적인 PMF 설문 분석 설계하기(Design a foundational product-market fit survey analysis)
Sean Ellis PMF 설문을 돌렸고 "매우 실망(very disappointed)" 38%를 받았는데 — 그게 통과인가? 이 프롬프트는 세분화, 자유 텍스트 패턴, 다음 단계 권고로 설문을 제대로 분석해 — 이터레이션할지, 피벗할지, 스케일할지 알려줍니다.
문제 발견을 위한 고객 인터뷰 가이드 설계하기(Design a customer interview guide for problem discovery)
이번 주에 고객 인터뷰 6건이 예정되어 있는데, 현재 초안 스크립트로는 이야기 대신 의견만 얻게 될 때 쓰는 프롬프트입니다. 고객이 지난번에 실제로 문제를 어떻게 해결했는지 끌어내는 behavioral interview guide를 만들어, 제안한 기능에 대한 피상적 의견 수집으로 무너지는 일을 막습니다.
새 시장을 위한 opportunity solution tree 설계하기(Design an opportunity solution tree for a new market)
새로운 시장이나 세그먼트에 진입하려는데 문제 공간을 이해하기 전에 특정 솔루션에 커밋하고 싶지 않을 때 쓰는 프롬프트입니다. 상단에 outcome, 중간에 opportunity, 하단에 solution을 두는 opportunity solution tree를 만들어, 하나의 opportunity마다 여러 solution을 먼저 생성한 뒤에 결정하게 합니다.
outcome-based user persona 만들기(Build an outcome-based user persona)
현재 persona가 인구통계 스케치 수준이라 제품 의사결정에 아무 영향도 주지 못할 때 쓰는 프롬프트입니다. 고객이 이루고 싶은 outcome, 현재 솔루션, 변화의 힘을 중심으로 outcome-based persona를 만들어, 실제 행동과 맞닿고 기능 우선순위에도 영향을 주게 합니다.
사용자 리서치 합성 문서 만들기
인터뷰 12건을 진행했고, 이제 FigJam에는 400개의 스티키가 흩어져 있습니다. 이 프롬프트는 그것들을 테마, 근거 인용문, 제품 시사점이 담긴 리서치 문서로 합성해, 아무도 읽지 않는 문서가 아니라 실제 의사결정을 움직이는 아티팩트를 만듭니다.
churn exit interview 프로그램 진행하기(Conduct a churn exit interview program)
Churn survey는 checkbox만 남기고 인사이트는 거의 주지 않을 때 쓰는 프롬프트입니다. 15분 통화, structured script, synthesis cadence가 있는 exit interview 프로그램을 설계해, 고객이 왜 떠나는지와 그중 어떤 이유는 우리가 고칠 수 있었는지를 실제로 배우게 합니다.
신기능을 위한 사용성 테스트 스크립트 진행하기(Conduct a usability testing script for new features)
디자이너는 흐름이 명백하다고 말하고 PM은 혼란스럽다고 말할 때. 5명 사용자 사용성 테스트 스크립트를 만들어 데이터로 토론을 해결합니다 — 태스크, 지표, 심각도 척도 — 그리고 일주일 안에 실행 가능한 수정을 만들어냅니다.
continuous discovery interview cadence 만들기(Build a continuous discovery interview cadence)
출시 직전에만 리서치를 몰아서 하고 그다음 몇 달은 다시 안 하는 패턴일 때 쓰는 프롬프트입니다. Recruiting pipeline, 주 4회 인터뷰, synthesis ritual을 포함한 주간 인터뷰 cadence를 만들어, 별도의 특별 프로젝트 없이도 늘 신선한 고객 인사이트를 갖게 합니다.
Jobs-to-be-Done 전환 인터뷰 진행하기
고객이 당신의 제품으로 갈아탔지만, 왜 그랬는지 전혀 모릅니다. 이 프롬프트는 전환의 정확한 순간, 즉 트리거, 작용한 힘, 고통의 순간을 재구성하는 JTBD 전환 인터뷰를 진행해 같은 상황에 있는 더 많은 사람을 찾고 같은 의사결정 지점을 위해 제품을 설계하도록 돕습니다.
market sizing sanity check 진행하기(Run a market sizing sanity check)
덱에는 시장 규모가 `$12B`라고 적혀 있는데 이사회는 회의적이고, 팀 내부에서도 그 숫자를 아무도 설명하지 못할 때 쓰는 프롬프트입니다. Top-down, bottom-up, analog라는 세 가지 독립 추정 방식을 교차 검증해, 단일 출처가 아니라 triangulated evidence가 있는 숫자를 만들게 합니다.
경쟁사 UX teardown 실행하기(Conduct a competitive UX teardown)
경쟁사가 새 flow를 막 출시했고 CEO가 그 스크린샷을 보내왔을 때 쓰는 프롬프트입니다. jobs-to-be-done, 정보 구조, friction, 차별화 관점에서 구조화된 UX teardown을 돌려, 반응이 복붙으로 무너지지 않게 해줍니다.
행동 기반 코호트 진단 설계하기(Design a behavioral cohort diagnosis)
전체 리텐션 곡선은 평평해 보이는데 팀은 왜 그런지 전혀 모를 때 쓰는 프롬프트입니다. 유입 채널, 기능 사용, 행동 패턴별 코호트 분석을 통해 실제 수치를 움직이는 핵심 코호트 2-3개와 빠져나가는 코호트를 식별하게 해줍니다.
기회 사이징과 TAM 계산기(Opportunity Sizing & TAM Calculator)
제품 기회에 대한 TAM(Total Addressable Market), SAM(Serviceable Addressable Market), SOM(Serviceable Obtainable Market)을 계산합니다. 명확한 가정과 함께 톱다운(top-down)과 보텀업(bottom-up) 접근을 모두 사용합니다.
문제 정의 워크숍(Problem Statement Workshop)
팀이 솔루션으로 점프하기 전에 정말 맞는 문제를 풀고 있는지 확인하기 위한 problem statement 워크숍 프롬프트입니다. "How Might We" 프레임워크와 5 Whys 기법으로 문제 정의를 날카롭게 다듬습니다.
사용성 테스트 스크립트(Usability Testing Script)
warm-up 질문, task scenario, 후속 probing 질문, scoring rubric까지 포함된 구조화된 usability testing 스크립트를 만드는 프롬프트입니다. moderated remote 테스트와 대면 테스트 모두에 바로 사용할 수 있습니다.
사용자 페르소나 생성기(User Persona Generator)
리서치 데이터, 분석, 고객 인터뷰를 바탕으로 데이터 기반 사용자 페르소나를 만드는 프롬프트입니다. 단순 인구통계를 넘어서 목표, 불만, 행동 패턴, 의사결정 기준까지 포착합니다.
고객 여정 맵 빌더(Customer Journey Map Builder)
인지(awareness)에서 옹호(advocacy)까지 상세한 고객 여정 맵을 만듭니다. 사용자 경험의 각 단계에서 터치포인트(touchpoint), 감정, 페인 포인트(pain point), 기회를 식별합니다.
MoSCoW 우선순위 방법(MoSCoW Prioritization Method)
MoSCoW 방법(Must have, Should have, Could have, Won't have)을 적용해 출시나 스프린트의 기능 우선순위를 매깁니다. 이해관계자(stakeholder) 정렬 연습과 트레이드오프(trade-off) 문서화를 포함합니다.
RICE 점수화 프레임워크(RICE Scoring Framework)
RICE 우선순위화 프레임워크(Reach, Impact, Confidence, Effort)를 적용해 제품 아이디어를 객관적으로 점수화하고 순위를 매기는 프롬프트입니다. 팀 전체가 일관된 기준으로 점수를 매길 수 있도록 calibration 가이드도 포함합니다.
고객 피드백 설문(Customer Feedback Survey)
이 프롬프트는 제품 릴리스(release) 이후 사용할 구조화된 고객 피드백 설문을 작성하도록 돕습니다. 사용성(usability), 만족도(satisfaction), 개선 영역에 대한 인사이트를 얻을 수 있도록 정량 질문과 정성 질문의 균형 잡힌 구성을 보장합니다. 향후 iteration을 다듬기 위한 실행 가능한 피드백을 원하는 제품 팀, UX 리서처, 마케터에게 적합합니다.
디자인 씽킹(Design Thinking)
이 프롬프트는 깊은 공감(empathy)과 인간 중심 디자인 씽킹을 활용해 사용자 문제를 반복적으로 해결하는 어시스턴트를 정의합니다. 동적 사용자 입력(문제, 목표, 피드백, 컨텍스트)을 사용하며 공감, 반복적 탐색, 협업적 사고, 실행 가능한 인사이트의 핵심 원칙을 따릅니다. 응답은 사용자 이해, 문제 재정의, 솔루션 프로토타이핑(prototyping), 지속적 피드백을 통한 아이디어 정제를 강조하도록 구조화됩니다.
고객 인터뷰 질문(Customer Interview Questions)
프로덕트 매니저가 심층 인터뷰를 통해 고객 니즈, 페인 포인트(pain point), 욕구를 발견하기 위한 구조화된 프롬프트입니다. 혁신과 개선의 기회를 식별하도록 도와주며, 제품 성장과 사용자 만족을 이끄는 인사이트를 보장합니다.
사용자 인터뷰 가이드(User Interview Guide)
이 프롬프트는 제품을 위한 사용자 인터뷰를 설계하고 진행하는 구조화된 가이드를 제공합니다. 효과적인 인터뷰 질문 준비, 참가자 선정, 인터뷰 프로세스 운영 같은 핵심 측면을 다룹니다. 제품 경험을 개선하기 위해 깊이 있는 사용자 인사이트를 모으고자 하는 제품 팀, UX 리서처, 디자이너에게 적합합니다.
제품팀 헬스 체크를 돌리고 개선 계획 만들기(Run a product team health check and build an improvement plan)
기능은 계속 shipping하고 있지만 뭔가 어긋난 느낌이 들고, 회고는 식상하며, 사기는 떨어지고, 크로스펑셔널 협업이 점점 어려워질 때 쓰는 프롬프트입니다. 제품팀 효과성을 8개가 아니라 12개 세부 차원에서 구조적으로 진단하고, 목표가 있는 개선 계획을 만듭니다.
지속적 디스커버리를 위한 Opportunity Solution Tree 그리기(Map an opportunity solution tree for continuous discovery)
팀이 고객 요청에서 곧바로 기능으로 점프하고 그 사이의 연결고리를 놓칠 때 사용하는 프롬프트입니다. 원하는 outcome에서 시작해 opportunity, solution, experiment까지 이어지는 opportunity solution tree를 만들어, 출시하는 모든 기능이 실제 고객 니즈에 연결되게 합니다.
제품-시장 적합성 설문을 돌리고 결과 진단하기(Run a product-market fit survey and diagnose the results)
MVP를 출시했고 활동 사용자도 조금 있지만, 실제로 product-market fit에 도달했는지 아니면 단지 "있으면 좋은" 무언가를 만든 건지 확신이 없을 때 쓰는 프롬프트입니다. 고전적인 "very disappointed" 설문을 돌리고 응답을 세분화해, 무엇을 고쳐야 하는지 정확히 알려줍니다.
ICE 우선순위화 도우미(ICE Prioritization Helper)
ICE 우선순위화 도우미 프롬프트는 ICE(Impact, Confidence, Ease) 점수를 자동으로 계산해 의사결정을 더 빠르고 일관되게 하도록 설계되었습니다. Itamar Gilad의 방법론에서 영감을 받은 구조화되고 증거 기반의 프레임워크를 통해 아이디어를 평가할 수 있습니다. 임팩트(impact), 구현 용이성(ease), 신뢰도(confidence) 수준(여러 증거 유형 기반) 같은 핵심 정보를 입력하면 우선순위 점수뿐 아니라 접근 방식을 다듬기 위한 맞춤형 피드백도 함께 받게 됩니다. 개선을 위한 실행 가능한 제안과 전략적 다음 단계까지 제공하므로, 팀과 개인이 높은 우선순위의 기회를 찾고, 사각지대를 발견하고, 혁신 속도를 높이는 데 도움이 됩니다. 기능, 프로젝트, 전략 무엇을 우선순위화하든 이 프롬프트는 더 데이터 기반이고 임팩트 있는 판단을 하도록 돕습니다.
Jobs-to-be-Done(JTBD) 분석
JTBD 프롬프트 설명 — 이 프롬프트는 Customer Jobs, Pains, Gains를 분해하여 구조화된 Jobs-to-be-Done(JTBD) 분석을 안내합니다. 기능적 태스크, 사회적·감정적 니즈(needs), 핵심 과제, 개선 기회를 식별하도록 돕습니다. 프로덕트 매니저(Product Manager)와 전략가에게 적합하며, 제품을 다듬고, 기능 우선순위를 정하고, 사용자 경험(UX)을 강화하는 실행 가능한 인사이트를 제공합니다.
만들기 전에 YC 스타일 제품 진단 돌리기(Run a YC-style product diagnostic before building)
유망해 보이는 기능 아이디어나 제품 컨셉이 있지만 아직 충분히 스트레스 테스트하지 않았을 때 쓰는 프롬프트입니다. 코드 한 줄 쓰기 전에 YC 파트너들이 실제 수요와 희망사항을 가르는 데 쓰는 forcing question으로 아이디어를 검증합니다.
사용자 인터뷰: Teresa Torres 방식(User Interview - Teresa Torres Approach)
이 프롬프트는 Teresa Torres의 *Continuous Discovery Habits* 접근법을 기반으로 사용자 인터뷰를 설계하고 진행하는 구조화된 가이드를 제공합니다. 기회 매핑(opportunity mapping), 가정 테스트, 지속적 학습을 강조해 실행 가능한 인사이트를 끌어냅니다. 가이드는 효과적인 인터뷰 질문 준비, 참가자 선정, 편향 없는 인터뷰 진행, 인사이트 종합 같은 핵심 측면을 다룹니다. 데이터 기반 제품 결정을 내리고자 하는 제품 팀, UX 리서처, 디자이너에게 적합합니다.
페르소나 기반 기능 피드백(Persona-Driven Feature Feedback)
상세한 사용자 페르소나(persona)를 만들고 제품 기능에 대한 컨텍스트 기반 피드백을 생성합니다. 이 프롬프트는 다양한 사용자 세그먼트가 새 아이디어에 어떻게 반응할지 시뮬레이션해 다양하고 현실적인 인사이트를 제공하며, 피드백이 관련성 있고 실행 가능하며 사용자 중심이 되도록 보장합니다.
숨은 가정 찾아내기(Identifying Hidden Assumptions)
이 프롬프트는 숨은 가정(hidden assumption)을 드러내고, 도약 가정(Leap of Faith Assumption)을 식별하며, 효과적으로 검증하는 데 초점을 둔 Teresa Torres의 Continuous Discovery Habits 프레임워크에서 영감을 받았습니다. 구조화된 5단계 프로세스를 따르면 제품 아이디어를 비판적이고 체계적으로 평가하게 되어, 솔루션에서 가장 위험한 부분을 일찍 다루게 됩니다.
인터뷰 스냅샷 어시스턴트(Interview snapshot assistant)
이 프롬프트는 Teresa Torres의 Continuous Discovery Habits를 바탕으로, 정성 인터뷰 데이터를 구조화된 Markdown 인터뷰 스냅샷으로 생성하는 product discovery assistant를 훈련합니다. 필수 메타데이터, 행동 기반 스토리, 여정 맵, 인사이트를 포함하는 엄격한 스키마를 강제하며, 누락된 데이터는 placeholder로 처리합니다. 그 결과 사용자 행동, pain point, opportunity를 찾는 데 도움이 되는 일관되고 실행 가능한 리서치 산출물이 만들어집니다.
인터뷰 스냅샷 통합 정리하기(Synthesizing interview snapshots)
이 프롬프트는 여러 인터뷰 스냅샷을 실행 가능한 인사이트로 통합 정리(synthesis)하기 위한 구조화된 프레임워크를 제공합니다. 입력값 검증, 패턴 발견, 사용자 여정 통합, 인사이트 생성 과정을 안내하며, 누락되었거나 일관되지 않은 데이터는 명확히 표시하도록 돕습니다. 결과물은 제품 전략을 위한 기회(opportunity), 핵심 인사이트, 다음 리서치 단계를 강조하는 표준화된 증거 기반 synthesis입니다.
프리모템(Pre-Mortem)
프리모템(Pre-Mortem)은 프로덕트 매니저가 제품 출시 전에 잠재 리스크를 드러내고 실행 가능한 대응 전략을 세우도록 돕습니다. Shreyas Doshi의 프레임워크에서 영감을 받아 리스크를 Tigers(실제 위협), Paper Tigers(과대평가된 우려), Elephants(숨겨진 위협)로 구분합니다. 가정(assumption), 장애물, 경쟁 구도를 함께 분석함으로써 제품 성공 가능성을 높이고 예상치 못한 실패를 줄이기 위한 실질적인 해법과 명확한 다음 단계를 제공합니다.
제품 의사결정(Product Decision Making)
이 프롬프트는 데이터, 가설, 실행 가능한 솔루션에 초점을 두고 구조화된 의사결정을 안내합니다. 복잡한 과제를 분석하고, 목표와 정렬을 맞추며, 이해관계자(stakeholder) 의견을 모아 명확하고 근거 기반의 보고서를 만들어내도록 돕습니다. 전략적 문제 해결에 관여하는 누구에게나 적합합니다.
디스커버리 중심 테스트 및 실험 계획(Discovery-Focused Test & Experiment Plan)
이 프롬프트는 프로덕트 매니저가 제품 불확실성을 줄이기 위한 구조화되고 실행 가능한 테스트/실험 계획을 세우도록 돕습니다. 가장 위험한 가정(LoFA)을 식별하고, lean한 행동 기반 테스트로 이를 검증하고, 언제 정식 가설 실험으로 넘어가야 하는지 판단하도록 안내합니다. 중요도가 높은 제품 의사결정을 다루는 디스커버리 중심 팀에 적합합니다.
크로스 펑셔널 디스커버리 정렬 워크숍 진행하기(Facilitate a cross-functional discovery alignment workshop)
엔지니어링, 디자인, 비즈니스 이해관계자(stakeholder)를 함께 디스커버리(discovery) 프로세스로 데려오는 구조화된 워크숍을 계획하고 운영할 때 이 프롬프트를 사용하세요 — 팀이 사일로(silo)되어 있거나 고객 문제에 정렬이 안 됐을 때 결정적입니다.