📕 428커밋의 기록이 상품이 됐습니다 →
agenwiki

프롬프트

기획·전략 프롬프트

PRD 초안·경쟁 분석·인터뷰 설계 등 기획 실무 프롬프트. 아래 4개를 한 화면에 모았습니다. 변수 자리({like_this})만 채우면 바로 쓸 수 있고, 각각 언제 쓰는지와 주의점을 함께 적었습니다.

general

경쟁 분석 프레임 프롬프트

내려야 할 결정에 맞춰 비교 축을 먼저 정하고, 확인한 사실과 추측을 구분해 경쟁 구도를 정리하는 프롬프트입니다.

복사 대상 프롬프트

당신은 경쟁 분석을 설계하는 전략 담당자입니다. {decision}을 판단하는 데 필요한 만큼만 분석하고, 그 결정과 무관한 항목은 넣지 마세요. 1단계 비교 축: 이 결정에 실제로 영향을 주는 비교 항목 5개를 먼저 고르고 왜 그 항목인지 한 줄씩. 2단계 비교표: 행은 비교 항목, 열은 우리 제품과 각 경쟁사. 각 칸에는 내용과 함께 근거 유형(공개 페이지·가격표·리뷰·직접 사용·추정)을 적고, 확인하지 못한 칸은 '미확인'으로 비워 둡니다. 3단계 구도: 경쟁사가 확실히 잘하는 것, 우리가 잘하는 것, 아직 아무도 제대로 못 하는 빈틈을 각각 2개씩. 4단계 시사점: 결정에 대한 권고 1개와 그 근거가 된 표의 칸을 짚어 줍니다. 5단계 확인 과제: 미확인 칸 중 결정을 뒤집을 수 있는 항목과 확인 방법(어디서 무엇을 보면 되는지). 규칙: 경쟁사의 가격·점유율·사용자 수·매출을 추측으로 채우지 말고 모르면 '미확인'이라고 씁니다. 추정을 적을 때는 무엇을 근거로 추정했는지 함께 적습니다. 우리 제품: {our_product} 경쟁사: {competitors}

언제 쓰나

기능 우선순위나 가격 정책처럼 경쟁 상황이 판단 근거가 되는 결정을 앞두고 씁니다. 경쟁 분석은 항목을 늘릴수록 결론에서 멀어지는데, 이 프롬프트는 결정을 먼저 못 박고 거기 필요한 축 5개로 범위를 묶습니다.

사용법

  1. {our_product} 에 우리 제품과 현재 포지션을 한두 줄로 적습니다.
  2. {competitors} 에 비교 대상을 적습니다. 3~4개가 적당하고, 각각 어떤 점에서 경쟁으로 보는지 덧붙이면 정확해집니다.
  3. {decision} 에 이 분석으로 내려야 할 결정을 적습니다. (예: "무료 요금제를 없앨지 말지", "다음 분기에 협업 기능을 만들지")
  4. 모델이 아는 정보만으로는 표가 '미확인'투성이일 수 있습니다. 경쟁사 가격 페이지나 리뷰를 함께 붙여넣으면 채워집니다.
  5. 5단계에 나온 확인 과제부터 처리한 뒤 표를 다시 채워 결론을 확정하세요.

사용 예시

입력

{our_product}: 소규모 팀용 업무 기록 도구. 월 9,900원 단일 요금제.
{competitors}: A사(대형 올인원 협업 툴), B사(무료 위주 메모 앱), C사(같은 규모의 신생 스타트업)
{decision}: 무료 요금제를 새로 만들지 말지

출력 (요약)

[비교 축]
1. 무료 제공 범위 — 결정의 핵심 변수
2. 유료 전환 유도 방식 — 무료가 매출을 갉아먹는지 판단
3. 주 사용자 규모 — 우리와 겹치는 층인지
4. 전환 비용(데이터 이전 난이도) — 무료로 들어온 사용자가 남는지
5. 지원 채널 — 무료 사용자 응대 부담 추정

[비교표] (발췌)
무료 제공 범위 | 우리: 없음(사실) | A사: 사용자 5명까지(공개 가격표) | B사: 대부분 무료(공개 페이지) | C사: 미확인
유료 전환 방식 | 우리: 해당 없음 | A사: 인원 제한(가격표) | B사: 저장 용량 제한(공개 페이지) | C사: 미확인

[구도]
경쟁사 강점: B사의 진입 장벽 없음 / A사의 브랜드 신뢰
우리 강점: 단일 요금제의 단순함 / 기록 검색 품질(직접 사용 기준)
빈틈: 무료에서 유료로 넘어갈 때의 데이터 이전 경험이 어느 쪽도 매끄럽지 않음

[시사점] 무료 요금제를 만든다면 인원 제한형이 용량 제한형보다 우리 구조에 맞습니다.
근거: '유료 전환 방식' 행의 A사·B사 칸과 우리 과금 단위

[확인 과제] C사의 무료 정책(가격 페이지 확인) — 같은 규모 경쟁사가 이미 무료를 열었다면 판단이 달라짐

(위 회사와 정책은 설명용 가상 예시입니다.)

  • 결정을 바꿔 가며 여러 번 돌리면 축이 매번 달라집니다. 같은 표를 재활용하지 말고 결정마다 새로 뽑는 편이 쓸모 있습니다.
  • 경쟁사 가격 페이지를 통째로 붙여넣으면 '미확인' 칸이 크게 줄어듭니다.
  • 결론이 마음에 들어도 5단계 확인 과제를 건너뛰지 마세요. 추정 위에 세운 권고는 뒤집히기 쉽습니다.

general

PRD 초안 작성 프롬프트

문제와 제약만 주면 목표·성공 지표·요구사항·비범위가 갖춰진 PRD 초안을 만들어 주는 프롬프트입니다.

복사 대상 프롬프트

당신은 제품 기획 문서를 쓰는 프로덕트 매니저입니다. 아래 정보로 PRD 초안을 작성하세요. 1 배경과 문제: 지금 무엇이 불편한지 서술하되, 확인된 사실과 아직 가정인 것을 각각 '[사실]' '[가정]'으로 구분해 표시합니다. 2 목표와 성공 지표: 목표 2~3개, 각 목표마다 측정 가능한 지표를 '지표명 / 현재값 / 목표값' 형식으로. 값을 모르면 '측정 필요'라고 씁니다. 3 사용자와 시나리오: {target_user}의 대표 시나리오 2개를 '상황 → 행동 → 기대 결과'로. 4 요구사항: 이번에 반드시 넣을 것과 이번엔 빼는 것을 나눠 표로 정리하고 각 항목에 이유 한 줄. 5 비범위: 오해를 막기 위해 이번에 하지 않는 일을 명시적으로. 6 리스크와 열린 질문: 결정이 필요한 항목과 누가 답해야 하는지. 규칙: 조사 결과나 지표 수치를 지어내지 말고 모르는 칸은 '확인 필요'로 남깁니다. 제약과 충돌하는 요구사항이 있으면 그 충돌을 6번에 적습니다. 제품: {product} 문제: {problem} 제약: {constraints}

언제 쓰나

기획 회의에서 나온 아이디어를 문서로 옮겨야 하는데 빈 화면 앞에서 막힐 때 씁니다. 초안의 목적은 완성이 아니라 빠진 곳을 드러내는 것이라, 이 프롬프트는 모르는 값을 그럴듯하게 채우지 않고 '확인 필요'로 남겨 논의할 지점을 보이게 만듭니다.

사용법

  1. {product} 에 제품·기능 이름과 한 줄 소개를 적습니다.
  2. {problem} 에 지금 벌어지는 문제를 적습니다. 근거가 있으면 함께 적으세요. (예: "가입 후 첫 주 이탈이 많다 — CS 문의 40건 중 12건이 초기 설정 관련")
  3. {target_user} 에 대상 사용자를 적습니다. (예: "혼자 운영하는 온라인 쇼핑몰 사장")
  4. {constraints} 에 일정·인력·기술 제약을 적습니다. (예: "개발 2명, 4주, 기존 결제 모듈 변경 불가")
  5. 나온 초안에서 '확인 필요'와 6번 열린 질문만 뽑아 회의 안건으로 쓰면 다음 논의가 빨라집니다.

사용 예시

입력

{product}: 소규모 쇼핑몰용 재고 알림 기능
{problem}: 품절을 뒤늦게 알아 주문 취소가 생깁니다. 지난달 취소 사유 중 재고 문제가 눈에 띄게 많았다고 CS 팀이 말했습니다.
{target_user}: 혼자 운영하는 온라인 쇼핑몰 사장
{constraints}: 개발 2명, 4주, 기존 알림 채널(이메일)만 사용

출력 (요약)

1. 배경과 문제
[사실] CS 팀이 재고 관련 취소 문의를 다수 보고
[가정] 판매자가 품절 시점을 즉시 알면 취소를 줄일 수 있다
[확인 필요] 지난달 취소 건 중 재고 사유 비율

2. 목표와 성공 지표
- 품절로 인한 주문 취소 감소 / 현재값 확인 필요 / 목표값 확인 필요
- 품절 인지까지 걸리는 시간 단축 / 측정 필요 / 1시간 이내

3. 시나리오
상황: 오전에 주문이 몰림 → 행동: 재고 임계치 도달 시 이메일 수신 → 기대 결과: 판매 중지 또는 재입고 처리

4. 요구사항
[이번에 함] 상품별 임계 수량 설정 — 알림의 최소 조건
[이번에 함] 임계 도달 시 이메일 발송 — 제약상 채널은 이메일뿐
[이번엔 뺌] 자동 재주문 — 공급처 연동 필요, 4주 초과

5. 비범위: 문자·카카오 알림, 재고 예측

6. 리스크와 열린 질문
- 이메일이 스팸함으로 갈 경우 알림 실패 → 대응 방식 결정 필요(담당: 개발)
- 임계 수량 기본값을 누가 정하는가(담당: 운영)

(위 사례와 수치는 설명용 가상 예시입니다.)

  • 초안이 길게 나오면 "4번 요구사항 표만 다시, 항목을 5개 이하로 줄여서"처럼 섹션 단위로 다시 요청하세요.
  • 제약을 빡빡하게 적을수록 요구사항이 현실적으로 나옵니다. 인력과 기간을 비워 두면 범위가 커집니다.
  • 사용자 근거가 부족하다면 사용자 인터뷰 질문 설계 프롬프트로 먼저 가정을 확인하는 편이 낫습니다.

general

설문 문항 설계 프롬프트

알고 싶은 것을 측정 항목으로 바꾸고, 유도 질문과 이중 질문을 걸러낸 설문 문항을 설계해 주는 프롬프트입니다.

복사 대상 프롬프트

당신은 설문을 설계하는 리서치 전문가입니다. 아래 목적에 답하는 데 필요한 최소한의 문항만 만드세요. 1단계 목적 분해: 알고 싶은 것을 측정 가능한 항목 3~5개로 바꾸고, 각 항목의 결과가 어떤 의사결정에 쓰이는지 한 줄씩 적습니다. 결정에 쓰이지 않는 항목은 여기서 버립니다. 2단계 문항: 항목별 문항을 {length} 안에 들어가도록 배치합니다. 문항마다 유형(단일선택·복수선택·5점 척도·주관식)과 보기를 함께 적고, 보기는 서로 겹치지 않으면서 빠지는 경우가 없게 구성하며 필요하면 '해당 없음'을 넣습니다. 3단계 순서: 답하기 쉬운 문항부터 민감한 문항 순으로 배열하고 응답자 분류 문항은 맨 뒤에 둡니다. 4단계 품질 점검: 만든 문항 중 유도 질문·이중 질문(한 문항에 두 가지를 묻는 것)·전문용어가 섞인 것을 스스로 찾아 표시하고 수정안을 제시합니다. 5단계 분석 계획: 응답을 모은 뒤 볼 교차표 2개와 각각에서 확인할 것. 규칙: 응답 결과나 예상 분포를 지어내지 말고, 문항 수가 목적보다 많아지면 잘라냅니다. 목적: {research_goal} 응답자: {respondents}

언제 쓰나

만족도 조사, 기능 우선순위 조사처럼 여러 사람에게 같은 질문을 던져야 할 때 씁니다. 설문은 한 번 뿌리면 고칠 수 없어서 문항의 품질이 곧 결과의 품질인데, 이 프롬프트는 문항을 만든 뒤 스스로 유도 질문과 이중 질문을 찾아내는 점검 단계를 강제합니다.

사용법

  1. {research_goal} 에 이 설문으로 알고 싶은 것을 결정과 함께 적습니다. (예: "다음 분기 개발 우선순위를 정하기 위해 어떤 기능이 실제로 막혀 있는지 알고 싶다")
  2. {respondents} 에 응답자를 적습니다. (예: "가입 후 3개월 이상 쓴 유료 사용자")
  3. {length} 에 분량을 적습니다. (예: "10문항 이내", "응답 3분")
  4. 4단계 점검 결과에서 지적된 문항은 원문이 아니라 수정안을 쓰세요.
  5. 5단계 분석 계획을 보고 "이 교차표로 결정을 내릴 수 있나"를 자문해 보세요. 아니라면 문항이 잘못 설계된 것입니다.

사용 예시

입력

{research_goal}: 다음 분기 개발 우선순위를 정하기 위해, 유료 사용자가 실제로 어디서 막히는지 알고 싶습니다.
{respondents}: 가입 후 3개월 이상 사용한 유료 사용자
{length}: 8문항 이내, 응답 3분

출력 (요약)

[목적 분해]
1. 최근에 실제로 겪은 불편 지점 — 개발 항목 후보 도출에 사용
2. 그 불편의 빈도 — 우선순위 정렬에 사용
3. 현재 우회 방법 — 급한 정도 판단에 사용
4. 사용 규모(분류) — 세그먼트별 차이 확인에 사용

[문항]
Q1. 최근 한 달 사이 이 서비스를 쓰다 막혔던 순간이 있었나요? (단일선택: 있었다 / 없었다 / 기억나지 않는다)
Q2. (Q1 '있었다') 어떤 상황이었는지 짧게 적어 주세요. (주관식)
Q3. 그런 상황은 얼마나 자주 있나요? (단일선택: 거의 매일 / 주 1~2회 / 월 1~2회 / 그보다 드묾)
Q4. 막혔을 때 어떻게 하셨나요? (복수선택: 직접 우회 / 고객센터 문의 / 다른 도구 사용 / 그냥 포기 / 해당 없음)
Q5. 아래 항목의 현재 만족도를 표시해 주세요. (5점 척도, 항목 3개)
Q6~Q8. 사용 기간·팀 규모·주 사용 기능 (분류 문항, 맨 뒤)

[품질 점검]
- 초안의 "속도가 느리고 화면이 복잡해서 불편하셨나요?" → 이중 질문 + 유도 질문
  수정: 속도와 화면 구성을 별도 문항으로 분리하고 중립 척도로 전환
- "온보딩 퍼널" 같은 내부 용어 제거

[분석 계획]
- Q3(빈도) × Q6(사용 기간): 오래 쓴 사용자일수록 특정 문제가 누적되는지
- Q4(대응) × Q5(만족도): 우회 방법이 있는 문제와 없는 문제의 만족도 차이

(위 문항과 설정은 설명용 가상 예시입니다.)

  • 주관식은 1~2문항이면 충분합니다. 많으면 응답률이 떨어지고, 적으면 예상 못 한 답을 놓칩니다.
  • 문항이 8개를 넘어가면 "결정에 직접 쓰이지 않는 문항을 삭제해 줘"라고 이어서 요청하세요.
  • 설문으로 '왜'까지 알아내려 하지 마세요. 이유는 사용자 인터뷰 질문 설계 프롬프트로 따로 파는 편이 정확합니다.

general

사용자 인터뷰 질문 설계 프롬프트

검증할 가설을 넣으면 유도 질문을 걸러낸 인터뷰 질문지를 순서까지 짜서 만들어 주는 프롬프트입니다.

복사 대상 프롬프트

당신은 사용자 리서치를 설계하는 UX 리서처입니다. 아래 가설을 검증할 인터뷰 질문지를 만드세요. 1단계 가설 쪼개기: 가설을 인터뷰로 확인 가능한 질문거리 3개로 나눕니다. 확인이 불가능한 부분이 있으면 그것도 밝힙니다. 2단계 질문지: {duration} 분량에 맞춰 도입(긴장을 푸는 질문 2문항) → 맥락(최근 경험을 여는 질문 3문항) → 핵심(질문거리별 3문항) → 마무리(2문항) 순서로 배치하고, 각 질문 옆에 무엇을 알아내려는 질문인지 한 줄로 표시합니다. 3단계 꼬리 질문: 핵심 질문마다 구체적 사례를 끌어낼 후속 질문 1개씩. 4단계 위험한 표현: 이 주제에서 유도 질문이 되기 쉬운 문장 3개를 예로 들고 중립적으로 바꾼 대안을 함께 제시합니다. 규칙: 모든 질문은 과거의 실제 행동과 경험을 묻는 형태로 씁니다. '있으면 쓰시겠어요' 같은 가정형·미래 의향 질문과 예·아니오로 끝나는 질문은 쓰지 않습니다. 우리 제품이나 해결책을 먼저 설명하는 질문도 넣지 않습니다. 가설: {hypothesis} 인터뷰 대상: {interviewee}

언제 쓰나

기능을 만들기 전에 "이 문제가 진짜 있는가"를 확인해야 할 때 씁니다. 인터뷰가 실패하는 이유는 대부분 질문이 나빠서인데, 특히 "이런 기능 있으면 쓰시겠어요?"류의 질문은 거의 항상 "네"를 받아 오고 아무것도 알려주지 않습니다. 이 프롬프트는 그런 문장을 원천적으로 막습니다.

사용법

  1. {hypothesis} 에 검증할 가설을 문장으로 적습니다. (예: "소상공인은 재고를 엑셀로 관리하다가 품절을 놓친다")
  2. {interviewee} 에 인터뷰 대상을 적습니다. 구체적일수록 좋습니다. (예: "직원 없이 혼자 온라인 쇼핑몰을 3년 이상 운영한 사장")
  3. {duration} 에 인터뷰 길이를 적습니다. (예: "30분", "60분")
  4. 4단계에 나온 위험한 표현 목록은 인터뷰 전에 따로 읽어 두세요. 현장에서 즉흥적으로 던지는 질문이 대개 그 형태입니다.

사용 예시

입력

{hypothesis}: 혼자 쇼핑몰을 운영하는 사장은 재고를 엑셀로 관리하다가 품절 시점을 놓쳐 주문 취소를 겪는다.
{interviewee}: 직원 없이 온라인 쇼핑몰을 3년 이상 운영한 사장
{duration}: 30분

출력 (요약)

[가설 쪼개기]
1. 실제로 어떤 도구로 재고를 관리하는가
2. 품절을 언제, 어떻게 알아채는가
3. 품절로 인한 취소가 실제로 발생했는가, 그때 무엇을 했는가

[질문지 — 30분]
도입(3분)
- 요즘 하루 일과가 어떻게 되시나요? / 업무 맥락 파악
맥락(7분)
- 가장 최근에 주문이 몰렸던 날 이야기를 처음부터 해주시겠어요? / 실제 상황 재현
핵심(15분)
- 지금 재고 수량은 어디에 적어 두시나요? 화면을 함께 보여주실 수 있을까요? / 도구 확인
  꼬리: 그 파일을 마지막으로 고친 게 언제였나요?
- 최근에 품절을 알아챈 순간을 기억나시는 대로 말씀해 주세요. / 인지 시점 확인
  꼬리: 그때 무엇을 보고 아셨나요?
- 그 뒤에 어떻게 처리하셨나요? / 실제 대응 행동
  꼬리: 그날 시간이 얼마나 걸렸나요?
마무리(5분)
- 오늘 이야기 중 제가 놓친 게 있을까요?

[위험한 표현]
- "재고 알림 기능 있으면 쓰시겠어요?" → "지금 품절을 알아채는 방법을 그대로 말씀해 주세요"
- "엑셀 관리가 불편하시죠?" → "엑셀로 관리하실 때 마지막으로 곤란했던 순간이 언제였나요?"
- "이런 기능이 도움이 될까요?" → "이 문제를 해결하려고 지금까지 시도해 보신 게 있나요?"

(위 가설과 대상은 설명용 가상 예시입니다.)

  • 인터뷰 후에는 녹취록을 회의록 정리 프롬프트에 넣지 말고, 인터뷰마다 "가설 1~3 각각에 대해 이 사람이 실제로 한 말"만 뽑아 정리하세요. 요약은 신호를 뭉갭니다.
  • 같은 질문지로 5명 이상 만나야 패턴이 보입니다. 사람마다 질문을 바꾸면 비교가 불가능해집니다.
  • 가설이 틀렸다는 답이 나오면 그게 성공한 인터뷰입니다. 만들기 전에 알았기 때문입니다.

다른 묶음

관련 글

뉴스레터 구독

AI 에이전트, 도구, 프롬프트 업데이트를 정리해 보냅니다. 지난 호 보기 →