AI Prompts for Discovery
46 prompts available for product managers.
제품 의사결정(Product Decision Making)
이 프롬프트는 데이터, 가설, 실행 가능한 솔루션에 초점을 두고 구조화된 의사결정을 안내합니다. 복잡한 과제를 분석하고, 목표와 정렬을 맞추며, 이해관계자(stakeholder) 의견을 모아 명확하고 근거 기반의 보
고객 인터뷰 질문(Customer Interview Questions)
프로덕트 매니저가 심층 인터뷰를 통해 고객 니즈, 페인 포인트(pain point), 욕구를 발견하기 위한 구조화된 프롬프트입니다. 혁신과 개선의 기회를 식별하도록 도와주며, 제품 성장과 사용자 만족을 이끄는 인사이
ICE 우선순위화 도우미(ICE Prioritization Helper)
ICE 우선순위화 도우미 프롬프트는 ICE(Impact, Confidence, Ease) 점수를 자동으로 계산해 의사결정을 더 빠르고 일관되게 하도록 설계되었습니다. Itamar Gilad의 방법론에서 영감을 받은
디자인 씽킹(Design Thinking)
이 프롬프트는 깊은 공감(empathy)과 인간 중심 디자인 씽킹을 활용해 사용자 문제를 반복적으로 해결하는 어시스턴트를 정의합니다. 동적 사용자 입력(문제, 목표, 피드백, 컨텍스트)을 사용하며 공감, 반복적 탐색
프리모템(Pre-Mortem)
프리모템(Pre-Mortem)은 프로덕트 매니저가 제품 출시 전에 잠재 리스크를 드러내고 실행 가능한 대응 전략을 세우도록 돕습니다. Shreyas Doshi의 프레임워크에서 영감을 받아 리스크를 Tigers(실제
페르소나 기반 기능 피드백(Persona-Driven Feature Feedback)
상세한 사용자 페르소나(persona)를 만들고 제품 기능에 대한 컨텍스트 기반 피드백을 생성합니다. 이 프롬프트는 다양한 사용자 세그먼트가 새 아이디어에 어떻게 반응할지 시뮬레이션해 다양하고 현실적인 인사이트를 제
숨은 가정 찾아내기(Identifying Hidden Assumptions)
이 프롬프트는 숨은 가정(hidden assumption)을 드러내고, 도약 가정(Leap of Faith Assumption)을 식별하며, 효과적으로 검증하는 데 초점을 둔 Teresa Torres의 Continu
Jobs-to-be-Done(JTBD) 분석
JTBD 프롬프트 설명 — 이 프롬프트는 Customer Jobs, Pains, Gains를 분해하여 구조화된 Jobs-to-be-Done(JTBD) 분석을 안내합니다. 기능적 태스크, 사회적·감정적 니즈(needs
사용자 인터뷰 가이드(User Interview Guide)
이 프롬프트는 제품을 위한 사용자 인터뷰를 설계하고 진행하는 구조화된 가이드를 제공합니다. 효과적인 인터뷰 질문 준비, 참가자 선정, 인터뷰 프로세스 운영 같은 핵심 측면을 다룹니다. 제품 경험을 개선하기 위해 깊이
사용자 인터뷰: Teresa Torres 방식(User Interview - Teresa Torres Approach)
이 프롬프트는 Teresa Torres의 *Continuous Discovery Habits* 접근법을 기반으로 사용자 인터뷰를 설계하고 진행하는 구조화된 가이드를 제공합니다. 기회 매핑(opportunity map
인터뷰 스냅샷 통합 정리하기(Synthesizing interview snapshots)
이 프롬프트는 여러 인터뷰 스냅샷을 실행 가능한 인사이트로 통합 정리(synthesis)하기 위한 구조화된 프레임워크를 제공합니다. 입력값 검증, 패턴 발견, 사용자 여정 통합, 인사이트 생성 과정을 안내하며, 누락
고객 피드백 설문(Customer Feedback Survey)
이 프롬프트는 제품 릴리스(release) 이후 사용할 구조화된 고객 피드백 설문을 작성하도록 돕습니다. 사용성(usability), 만족도(satisfaction), 개선 영역에 대한 인사이트를 얻을 수 있도록 정
디스커버리 중심 테스트 및 실험 계획(Discovery-Focused Test & Experiment Plan)
이 프롬프트는 프로덕트 매니저가 제품 불확실성을 줄이기 위한 구조화되고 실행 가능한 테스트/실험 계획을 세우도록 돕습니다. 가장 위험한 가정(LoFA)을 식별하고, lean한 행동 기반 테스트로 이를 검증하고, 언제
인터뷰 스냅샷 어시스턴트(Interview snapshot assistant)
이 프롬프트는 Teresa Torres의 Continuous Discovery Habits를 바탕으로, 정성 인터뷰 데이터를 구조화된 Markdown 인터뷰 스냅샷으로 생성하는 product discovery ass
크로스 펑셔널 디스커버리 정렬 워크숍 진행하기(Facilitate a cross-functional discovery alignment workshop)
엔지니어링, 디자인, 비즈니스 이해관계자(stakeholder)를 함께 디스커버리(discovery) 프로세스로 데려오는 구조화된 워크숍을 계획하고 운영할 때 이 프롬프트를 사용하세요 — 팀이 사일로(silo)되어
지속적 디스커버리를 위한 Opportunity Solution Tree 그리기(Map an opportunity solution tree for continuous discovery)
팀이 고객 요청에서 곧바로 기능으로 점프하고 그 사이의 연결고리를 놓칠 때 사용하는 프롬프트입니다. 원하는 outcome에서 시작해 opportunity, solution, experiment까지 이어지는 oppor
RICE 점수화 프레임워크(RICE Scoring Framework)
RICE 우선순위화 프레임워크(Reach, Impact, Confidence, Effort)를 적용해 제품 아이디어를 객관적으로 점수화하고 순위를 매기는 프롬프트입니다. 팀 전체가 일관된 기준으로 점수를 매길 수 있
문제 정의 워크숍(Problem Statement Workshop)
팀이 솔루션으로 점프하기 전에 정말 맞는 문제를 풀고 있는지 확인하기 위한 problem statement 워크숍 프롬프트입니다. "How Might We" 프레임워크와 5 Whys 기법으로 문제 정의를 날카롭게 다
기회 사이징과 TAM 계산기(Opportunity Sizing & TAM Calculator)
제품 기회에 대한 TAM(Total Addressable Market), SAM(Serviceable Addressable Market), SOM(Serviceable Obtainable Market)을 계산합니다.
고객 여정 맵 빌더(Customer Journey Map Builder)
인지(awareness)에서 옹호(advocacy)까지 상세한 고객 여정 맵을 만듭니다. 사용자 경험의 각 단계에서 터치포인트(touchpoint), 감정, 페인 포인트(pain point), 기회를 식별합니다.
제품팀 헬스 체크를 돌리고 개선 계획 만들기(Run a product team health check and build an improvement plan)
기능은 계속 shipping하고 있지만 뭔가 어긋난 느낌이 들고, 회고는 식상하며, 사기는 떨어지고, 크로스펑셔널 협업이 점점 어려워질 때 쓰는 프롬프트입니다. 제품팀 효과성을 8개가 아니라 12개 세부 차원에서 구
제품-시장 적합성 설문을 돌리고 결과 진단하기(Run a product-market fit survey and diagnose the results)
MVP를 출시했고 활동 사용자도 조금 있지만, 실제로 product-market fit에 도달했는지 아니면 단지 "있으면 좋은" 무언가를 만든 건지 확신이 없을 때 쓰는 프롬프트입니다. 고전적인 "very disap
사용자 페르소나 생성기(User Persona Generator)
리서치 데이터, 분석, 고객 인터뷰를 바탕으로 데이터 기반 사용자 페르소나를 만드는 프롬프트입니다. 단순 인구통계를 넘어서 목표, 불만, 행동 패턴, 의사결정 기준까지 포착합니다.
사용성 테스트 스크립트(Usability Testing Script)
warm-up 질문, task scenario, 후속 probing 질문, scoring rubric까지 포함된 구조화된 usability testing 스크립트를 만드는 프롬프트입니다. moderated remot
MoSCoW 우선순위 방법(MoSCoW Prioritization Method)
MoSCoW 방법(Must have, Should have, Could have, Won't have)을 적용해 출시나 스프린트의 기능 우선순위를 매깁니다. 이해관계자(stakeholder) 정렬 연습과 트레이드오프
문제 발견을 위한 고객 인터뷰 가이드 설계하기(Design a customer interview guide for problem discovery)
이번 주에 고객 인터뷰 6건이 예정되어 있는데, 현재 초안 스크립트로는 이야기 대신 의견만 얻게 될 때 쓰는 프롬프트입니다. 고객이 지난번에 실제로 문제를 어떻게 해결했는지 끌어내는 behavioral intervi
만들기 전에 YC 스타일 제품 진단 돌리기(Run a YC-style product diagnostic before building)
유망해 보이는 기능 아이디어나 제품 컨셉이 있지만 아직 충분히 스트레스 테스트하지 않았을 때 쓰는 프롬프트입니다. 코드 한 줄 쓰기 전에 YC 파트너들이 실제 수요와 희망사항을 가르는 데 쓰는 forcing ques
새 시장을 위한 opportunity solution tree 설계하기(Design an opportunity solution tree for a new market)
새로운 시장이나 세그먼트에 진입하려는데 문제 공간을 이해하기 전에 특정 솔루션에 커밋하고 싶지 않을 때 쓰는 프롬프트입니다. 상단에 outcome, 중간에 opportunity, 하단에 solution을 두는 opp
경쟁사 UX teardown 실행하기(Conduct a competitive UX teardown)
경쟁사가 새 flow를 막 출시했고 CEO가 그 스크린샷을 보내왔을 때 쓰는 프롬프트입니다. jobs-to-be-done, 정보 구조, friction, 차별화 관점에서 구조화된 UX teardown을 돌려, 반응이
리텐션 분석을 돌리고 누수 지점 진단하기(Run a retention analysis and diagnose the leak)
리텐션 그래프가 빨간데 어디서 시작할지 누구도 모를 때. 이 프롬프트는 구조화된 리텐션 분석 — 코호트(cohort) 세분화, 이벤트 깔때기, 기능 사용 상관관계 — 을 돌려, 10개 개입을 동시에 토론하는 대신 가
행동 기반 코호트 진단 설계하기(Design a behavioral cohort diagnosis)
전체 리텐션 곡선은 평평해 보이는데 팀은 왜 그런지 전혀 모를 때 쓰는 프롬프트입니다. 유입 채널, 기능 사용, 행동 패턴별 코호트 분석을 통해 실제 수치를 움직이는 핵심 코호트 2-3개와 빠져나가는 코호트를 식별하
기능 채택 퍼널 audit 설계하기(Design a feature adoption funnel audit)
당신이 출시한 기능을 사용자 40%가 보긴 했지만 실제로 사용한 사람은 3%뿐일 때 쓰는 프롬프트입니다. Discover, try, use, retain으로 이어지는 adoption funnel을 점검해, 누수가 인
사용자 불만에 대한 5-whys 근본 원인 분석 돌리기(Run a 5-whys root cause analysis on a user complaint)
큰 고객 불만이 막 임원 받은편지함에 들어왔고 팀의 첫 본능이 증상을 패치하는 것일 때. 이 프롬프트는 불만을 구조적 원인으로 추적하는 5-whys 분석을 돌려 — 단순한 탈출구가 아니라 출처를 고치도록 합니다.
제품 이전 단계의 명확성을 위한 Foundation Sprint 설계하기(Design a Foundation Sprint for pre-product clarity)
유망한 아이디어와 작은 팀은 있지만 엔지니어를 투입하기 전까지 겨우 2주만 남아 있을 때 쓰는 프롬프트입니다. 전통적인 Design Sprint는 해법을 테스트하기 위한 것이지만, 아직 그 단계가 아니라면 먼저 고객
outcome-based user persona 만들기(Build an outcome-based user persona)
현재 persona가 인구통계 스케치 수준이라 제품 의사결정에 아무 영향도 주지 못할 때 쓰는 프롬프트입니다. 고객이 이루고 싶은 outcome, 현재 솔루션, 변화의 힘을 중심으로 outcome-based pers
기초적인 PMF 설문 분석 설계하기(Design a foundational product-market fit survey analysis)
Sean Ellis PMF 설문을 돌렸고 "매우 실망(very disappointed)" 38%를 받았는데 — 그게 통과인가? 이 프롬프트는 세분화, 자유 텍스트 패턴, 다음 단계 권고로 설문을 제대로 분석해 — 이
continuous discovery interview cadence 만들기(Build a continuous discovery interview cadence)
출시 직전에만 리서치를 몰아서 하고 그다음 몇 달은 다시 안 하는 패턴일 때 쓰는 프롬프트입니다. Recruiting pipeline, 주 4회 인터뷰, synthesis ritual을 포함한 주간 인터뷰 caden
보내기 전 설문 설계 리뷰 진행하기(Conduct a survey design review before you send)
20문항짜리 설문을 5,000명 고객에게 보내려는데 데이터가 아무 쓸모 없을 게 뻔할 때. 이 프롬프트는 보내기 전에 유도 언어, 나쁜 척도, 응답 피로, 분석 가능성에 대해 설문을 리뷰합니다 — 결과가 실제로 결정
Jobs-to-be-Done 전환 인터뷰 진행하기
고객이 당신의 제품으로 갈아탔지만, 왜 그랬는지 전혀 모릅니다. 이 프롬프트는 전환의 정확한 순간, 즉 트리거, 작용한 힘, 고통의 순간을 재구성하는 JTBD 전환 인터뷰를 진행해 같은 상황에 있는 더 많은 사람을
churn exit interview 프로그램 진행하기(Conduct a churn exit interview program)
Churn survey는 checkbox만 남기고 인사이트는 거의 주지 않을 때 쓰는 프롬프트입니다. 15분 통화, structured script, synthesis cadence가 있는 exit interview
고객 자문 위원회 헌장 만들기(Build a customer advisory board charter)
톱 고객이 로드맵에 더 많은 영향력을 원하고 팀이 충돌하는 요청을 만들어내는 1:1 콜을 계속 가질 때. 이 프롬프트는 고객 자문 위원회(Customer Advisory Board, CAB) 헌장 — 멤버십, 주기,
신기능을 위한 사용성 테스트 스크립트 진행하기(Conduct a usability testing script for new features)
디자이너는 흐름이 명백하다고 말하고 PM은 혼란스럽다고 말할 때. 5명 사용자 사용성 테스트 스크립트를 만들어 데이터로 토론을 해결합니다 — 태스크, 지표, 심각도 척도 — 그리고 일주일 안에 실행 가능한 수정을 만
market sizing sanity check 진행하기(Run a market sizing sanity check)
덱에는 시장 규모가 `$12B`라고 적혀 있는데 이사회는 회의적이고, 팀 내부에서도 그 숫자를 아무도 설명하지 못할 때 쓰는 프롬프트입니다. Top-down, bottom-up, analog라는 세 가지 독립 추정
사용자 리서치 합성 문서 만들기
인터뷰 12건을 진행했고, 이제 FigJam에는 400개의 스티키가 흩어져 있습니다. 이 프롬프트는 그것들을 테마, 근거 인용문, 제품 시사점이 담긴 리서치 문서로 합성해, 아무도 읽지 않는 문서가 아니라 실제 의사
B2B 제품-시장 적합성(PMF) 신호를 갱신과 영업 주기로 감사하기
B2B 프로덕트가 데모는 잘 하고 NPS도 괜찮은 편인데, CEO가 PMF에 도달했는지 묻고 있습니다. Sean Ellis 40 percent 테스트는 소비자 프로덕트용으로 만들어졌고 갱신 끌림, 확장 경제, 영업
활성화(activation) 지표를 후보 리스트에서 인과 증명까지 도달시키기
팀이 활성화(activation) 마일스톤을 추측만 하고 있고, 유지율(retention) 곡선이 움직이지 않습니다. 이 프롬프트는 후보 모멘트 브레인스토밍, 유지율과의 회귀 분석, 그리고 그 마일스톤이 단순 상관이