언제 쓰나
기획 회의에서 나온 아이디어를 문서로 옮겨야 하는데 빈 화면 앞에서 막힐 때 씁니다. 초안의 목적은 완성이 아니라 빠진 곳을 드러내는 것이라, 이 프롬프트는 모르는 값을 그럴듯하게 채우지 않고 '확인 필요'로 남겨 논의할 지점을 보이게 만듭니다.
사용법
{product}에 제품·기능 이름과 한 줄 소개를 적습니다.{problem}에 지금 벌어지는 문제를 적습니다. 근거가 있으면 함께 적으세요. (예: "가입 후 첫 주 이탈이 많다 — CS 문의 40건 중 12건이 초기 설정 관련"){target_user}에 대상 사용자를 적습니다. (예: "혼자 운영하는 온라인 쇼핑몰 사장"){constraints}에 일정·인력·기술 제약을 적습니다. (예: "개발 2명, 4주, 기존 결제 모듈 변경 불가")- 나온 초안에서 '확인 필요'와 6번 열린 질문만 뽑아 회의 안건으로 쓰면 다음 논의가 빨라집니다.
사용 예시
입력
{product}: 소규모 쇼핑몰용 재고 알림 기능
{problem}: 품절을 뒤늦게 알아 주문 취소가 생깁니다. 지난달 취소 사유 중 재고 문제가 눈에 띄게 많았다고 CS 팀이 말했습니다.
{target_user}: 혼자 운영하는 온라인 쇼핑몰 사장
{constraints}: 개발 2명, 4주, 기존 알림 채널(이메일)만 사용
출력 (요약)
1. 배경과 문제
[사실] CS 팀이 재고 관련 취소 문의를 다수 보고
[가정] 판매자가 품절 시점을 즉시 알면 취소를 줄일 수 있다
[확인 필요] 지난달 취소 건 중 재고 사유 비율
2. 목표와 성공 지표
- 품절로 인한 주문 취소 감소 / 현재값 확인 필요 / 목표값 확인 필요
- 품절 인지까지 걸리는 시간 단축 / 측정 필요 / 1시간 이내
3. 시나리오
상황: 오전에 주문이 몰림 → 행동: 재고 임계치 도달 시 이메일 수신 → 기대 결과: 판매 중지 또는 재입고 처리
4. 요구사항
[이번에 함] 상품별 임계 수량 설정 — 알림의 최소 조건
[이번에 함] 임계 도달 시 이메일 발송 — 제약상 채널은 이메일뿐
[이번엔 뺌] 자동 재주문 — 공급처 연동 필요, 4주 초과
5. 비범위: 문자·카카오 알림, 재고 예측
6. 리스크와 열린 질문
- 이메일이 스팸함으로 갈 경우 알림 실패 → 대응 방식 결정 필요(담당: 개발)
- 임계 수량 기본값을 누가 정하는가(담당: 운영)
(위 사례와 수치는 설명용 가상 예시입니다.)
팁
- 초안이 길게 나오면 "4번 요구사항 표만 다시, 항목을 5개 이하로 줄여서"처럼 섹션 단위로 다시 요청하세요.
- 제약을 빡빡하게 적을수록 요구사항이 현실적으로 나옵니다. 인력과 기간을 비워 두면 범위가 커집니다.
- 사용자 근거가 부족하다면 사용자 인터뷰 질문 설계 프롬프트로 먼저 가정을 확인하는 편이 낫습니다.