저는 예전에는 오후 전체를 잡아먹곤 했던 글쓰기 작업에 의외로 많은 시간을 소비하고 있습니다. 아무도 끝까지 읽지 않는 PRD (제품 요구 사항 문서), 예외 케이스(edge cases)를 놓치는 사용자 스토리(user stories), 중요한 인용구를 놓쳐버린 인터뷰 요약본, 그리고 작성된 다음 날 바로 구식이 되어버리는 로드맵 문서들이 바로 그것입니다.

지난 1년 동안 저는 이러한 업무의 판단(judgment)이 아닌 구조(structure)를 처리하는 작은 AI 프롬프트 세트를 구축했습니다. 프롬프트는 뼈대를 작성하고, 상용구(boilerplate)를 채우며, 제가 묻는 것을 잊어버린 질문들을 표면화합니다. 제품에 대한 결정은 여전히 제가 내립니다. 단지 그것들을 형식화하는 데 두 시간을 허비하지 않을 뿐입니다.

이 포스트는 바로 그 프롬프트들에 관한 것입니다. 티저가 아니라, 실제 프롬프트와 그 프롬프트가 만들어내는 실제 구조, 그리고 각 프롬프트가 왜 효과적인지에 대한 짧은 노트를 담고 있습니다. 유용하다면 가져다 쓰셔도 좋습니다. 제품 생애 주기 전체(discovery → PRD → delivery → launch → GTM)를 다루는 50개 이상의 전체 프롬프트 세트가 필요하시다면 하단에 링크를 남겨두겠습니다.

대부분의 "PM 프롬프트"가 나쁜 이유

제가 본 제품 관리자(product managers)를 위한 모든 AI 프롬프트 목록은 동일한 결함을 가지고 있습니다. 바로 프롬프트가 너무 모호하다는 점입니다. "기능을 위한 PRD를 작성해줘"라는 명령은 PRD를 유용하게 만드는 유일한 요소들, 즉 구체적인 문제, 구체적인 사용자, 트레이드오프(tradeoff)를 강제하는 구체적인 제약 조건을 놓친 채 일반적인 템플릿만을 생성합니다. 모델이 고장 난 것이 아닙니다. 최적화할 구체적인 대상을 주지 않았기 때문에, 모델은 학습된 모든 평범한 PRD들의 평균값에 맞춰 최적화할 뿐입니다.

아래의 모든 프롬프트는 동일한 4단계 구조를 따릅니다:

1. ROLE (역할)       — 모델이 연기하고 있는 대상.
2. CONTEXT (맥락)    — 구체적인 제품, 사용자 및 목표.
3. CONSTRAINTS (제약 사항)— 형식, 길이, 피해야 할 것, 포함해야 할 것.
...

모호한 프롬프트는 2번과 3번을 건너뛰기 때문에 실패합니다. 아래의 모든 프롬프트는 이 네 가지를 모두 갖추고 있습니다.

프롬프트 1 — 원페이지(one-page) PRD

대부분의 PRD는 너무 길기 때문에 사장됩니다. 원페이지(one-pager)는 무엇이 실제로 중요한지 결정하도록 강제합니다. 이 프롬프트는 구조를 초안 작성하며, 구체적인 내용은 여러분이 채워 넣습니다.

역할(ROLE): 당신은 한 페이지 분량의 PRD(제품 요구 사항 문서)를 작성하는 시니어 제품 관리자(Senior Product Manager)입니다.
맥락(CONTEXT): 기능 명칭은 [FEATURE NAME]입니다. 이 기능은 [SPECIFIC USER PERSONA]를 위해 [SPECIFIC PROBLEM]을 해결합니다. 주요 성공 지표(Success Metric)는 [METRIC]입니다.
...

작동 원리: "최대 한 페이지" 및 "정해진 순서에 따른 정확한 섹션"이라는 제약 조건은 12페이지에 달하는 장황한 PRD를 방지합니다. "비목표(Non-goals)를 명시적으로 나열"하도록 강제하는 것은 PRD 작성에서 가장 영향력이 큰 규율입니다. 대부분의 PRD 실패는 무엇을 하지 않을 것인지 명시하지 않음으로써 발생하는 범위 확장(Scope Creep) 때문입니다. 마지막에 배치된 "3가지 가장 위험한 가정(3 riskiest assumptions)"은 개발 전에 실제로 검증해야 할 사항이 무엇인지 드러내 줍니다.

출력 예시 (가상의 알림 기능의 경우):

문제 (Problem)

보고서를 시작한 주간 활성 사용자(WAU)의 38%가 보고서를 완료하지 못합니다. 세션 녹화(Session recordings) 결과, 사용자들이 "팀과 공유" 단계에서 이탈하는 것으로 나타났습니다. 보고서가 검토 준비가 되었음을 팀원에게 알릴 방법이 현재 없습니다.

사용자 (Users)

주요 사용자: 비동기 검토가 필요한 보고서 작성자(분석가, 팀 리드). 보조 사용자: 현재 채팅을 통해 공유된 보고서를 놓치고 있는 검토자.

목표 (Goal)

• 8주 이내에 보고서 완료율을 62%에서 75%로 높입니다.
• 비목표 (Non-goals): 모바일 푸시(v1은 웹 전용), Slack/Teams 연동(범위 외), 요약 이메일(Digest emails).

제안된 솔루션 (Proposed solution)

• 보고서 완료 시 제품 내 "검토를 위해 알림" 버튼 제공.
• 수신자는 앱 내 알림과 딥 링크(Deep link)가 포함된 이메일을 받음.
• 발신자는 읽음 확인(Read receipts)을 볼 수 있음.

성공 지표 (Success metrics)

• 주요 지표: 보고서 완료율 (목표 +13%p).

미결 질문 (Open questions)

• v1이 웹 전용이더라도, 검토자들이 모바일에서 알림에 반응하기를 원하는가?
• 알림을 일괄 처리(Batch/Digest)해야 하는가, 아니면 실시간으로 보내야 하는가?
• 수신자가 팀원이 아닌 경우 어떻게 처리할 것인가 — 공유 링크로 대체할 것인가?

가장 위험한 가정 (Riskiest assumptions): (1) 이탈 원인이 보고서 품질이 아닌 알림의 부재 때문이라는 점; (2) 검토자들이 알림을 무음 처리하지 않고 실제로 참여할 것이라는 점; (3) 이메일이 수용 가능한 전달 채널이라는 점.

비목표 (non-goals) 섹션이 실제로 핵심적인 역할을 수행합니다. 이 섹션이 없다면, 이 PRD는 알림 플랫폼(notifications platform)으로 비대해졌을 것입니다.

프롬프트 2 — 예외 케이스(edge cases)를 놓치지 않는 사용자 스토리 (User stories)

"사용자로서, 나는 X를 하고 싶다, 그래야 Y할 수 있다"는 하나의 형식(format)일 뿐, 명세(specification)가 아닙니다. 이 형식은 누락된 수용 기준 (acceptance criteria), 오류 상태 (error states), 그리고 예외 케이스 (edge cases)를 숨깁니다. 이 프롬프트는 스토리뿐만 아니라 대부분의 PM들이 잊어버리는 케이스들까지 초안을 작성해 줍니다.

역할 (ROLE): 당신은 엔지니어링 팀을 위해 사용자 스토리 (user story)를 작성하는 제품 관리자 (product manager)입니다.
컨텍스트 (CONTEXT): 기능은 [FEATURE]입니다. 사용자는 [PERSONA]입니다. 트리거 (trigger)는 [WHEN THEY DO WHAT]입니다. 해피 패스 (happy path)는 [WHAT SHOULD HAPPEN]입니다.
...

작동 원리: 네 가지 예외 케이스("빈 입력 (empty input), 권한 거부 (permission denied), 타임아웃 (timeout), 동시 편집 (concurrent edit)")는 프로덕션 버그의 80%를 유발하며, 주니어 PM들이 체계적으로 놓치는 케이스들입니다. "그것들을 해결하지 말고 — 단지 명시만 하라"고 강제함으로써, 스토리가 '어떻게 (HOW)'가 아닌 '무엇을 (WHAT)'에 집중하도록 유지합니다. "범위 외 (out of scope)" 섹션은 스프린트 계획 (sprint planning) 중 범위 확장 (scope creep)을 방지합니다.

출력 예시 ("임시 저장" 스토리에 대한 경우):

보고서 초안 자동 저장

스토리 (Story): 보고서 작성자로서, 나는 브라우저가 충돌하더라도 작업 내용을 잃지 않도록 30초마다 초안이 자동으로 저장되기를 원한다.

수용 기준 (Acceptance criteria):

• 초안을 편집 중일 때, 변경 사항이 있는 상태로 30초가 지나면, 눈에 보이는 표시 없이 초안이 서버에 저장된다.
• 저장이 성공했을 때, 페이지를 새로고침하면 최신 변경 사항이 반영되어 있어야 한다.
• 저장에 실패했을 때 (네트워크 오류), 재시도 또한 실패하면, 수동 "지금 저장" 버튼이 포함된 비차단형 (non-blocking) 경고 배너가 나타난다.
• 오프라인 상태일 때, 편집을 계속하면 변경 사항이 localStorage에 대기열로 저장되며, 연결이 복구되면 동기화된다.

예외 케이스 (Edge cases):

• 두 개의 탭에서 동일한 초안을 동시에 편집하는 경우 (동시 편집 충돌 (concurrent edit conflict)).
• 초안이 저장 용량 제한을 초과하는 경우.
• 편집 도중에 사용자가 로그아웃하는 경우.
• 서버가 60초 이상 5xx 에러를 반환하는 경우.

범위 외 (Out of scope): 버전 히스토리 (version history), 다중 사용자 실시간 협업 (multi-user real-time collaboration), 충돌 해결 UI (conflict resolution UI).

동시 편집 (concurrent-edit) 에지 케이스 (edge case)는 만약 사용자 스토리 (story) 단계가 아닌 QA 단계에서 발견되었다면, 한 스프린트(sprint) 분량의 재작업 비용을 발생시켰을 사례입니다.

프롬프트 3 — 인용구를 보존하는 사용자 인터뷰 요약

사용자 인터뷰에서 가장 유용한 결과물은 요약본이 아닙니다. 실제 고통(pain)을 포착하는 있는 그대로의 인용구 (verbatim quote)입니다. 대부분의 AI 요약은 인용구를 쓸모없게 재진술 (paraphrase) 해버립니다. 이 프롬프트는 인용구를 그대로 유지하며 그 주변을 구조화합니다.

역할 (ROLE): 당신은 사용자 인터뷰를 요약하는 제품 연구원 (product researcher)입니다.
맥락 (CONTEXT): 인터뷰 대상은 [PERSONA]입니다. 주제는 [TOPIC]이었습니다.
목표는 [LEARNING GOAL]을 배우는 것이었습니다. 원본 노트/전사 데이터 (transcript)는 다음과 같습니다:
...

작동 원리: "있는 그대로 (Verbatim), 재진술 (paraphrase) 하지 마시오"라는 제약 조건이 결과물을 살려냅니다. 재진술된 인용구는 리서치 저장소 (research repository)에서 가치가 없습니다. 6개월이 지나면, 그 고통이 사용자의 실제 말이었는지 아니면 PM의 해석이었는지 아무도 알 수 없기 때문입니다. "관찰된 행동 (behaviors observed, 무엇을 말했는가가 아니라 무엇을 했는가)" 섹션은 명시된 선호 (stated preference)와 드러난 선호 (revealed preference)를 구분해 주며, 바로 이 지점에 대부분의 제품 인사이트 (product insights)가 존재합니다.

프롬프트 4 — 경쟁사 기능 분석 (Competitor feature teardown)

기능을 그리드 형태로 나열한 경쟁사 매트릭스 (competitor matrix)는 쓸모가 없습니다. 그것은 무엇이 존재하는지는 알려주지만, 무엇이 좋은지는 알려주지 않기 때문입니다. 이 프롬프트는 배울 가치가 있는 실제 제품 결정 사항들을 드러내는 분석 (teardown) 결과를 생성합니다.

역할 (ROLE): 당신은 경쟁사 기능을 분석 (teardown)하는 제품 분석가 (product analyst)입니다.
맥락 (CONTEXT): 경쟁사는 [COMPETITOR]입니다. 기능은 [FEATURE]입니다.
나는 이를 사용해 보았으며, 나의 관찰 결과는 다음과 같습니다:
...

작동 원리: "훔칠 가치가 있는 3가지 제품 결정 사항 (3 product decisions worth stealing)"이라는 항목은 단순히 기능을 목록화하는 대신 전이 가능한 인사이트 (transferable insight)를 추출하도록 강제합니다. "그것이 암시하는 트레이드오프 (What tradeoff it implies)"는 모든 결정에 숨겨진 비용을 드러냅니다. 모든 UI 선택은 명확성을 위해 속도를 희생하거나, 모든 기본값 (default)은 유연성을 위해 주관성 (opinionation)을 희생합니다. 트레이드오프를 명시하는 것이 분석 (teardown)을 단순한 부러움이 아닌 유용한 도구로 만드는 핵심입니다.

프롬프트 5 — 오래 지속되는 로드맵 (The roadmap that ages well)

대부분의 로드맵은 약속(commitments)으로 작성되기 때문에 거짓을 담게 됩니다. 유용한 로드맵은 명시적인 가설 (assumptions)을 포함한 베팅 (bets)의 형태로 작성됩니다. 이 프롬프트는 베팅 스타일의 로드맵 초안을 작성합니다.

역할 (ROLE): 당신은 분기별 로드맵을 작성하는 제품 관리자 (product manager)입니다.
맥락 (CONTEXT): 제품은 [PRODUCT]입니다. 북극성 지표 (north-star metric)는 [METRIC, 현재 값 X]입니다. 이번 분기의 테마는 [THEME]입니다. 팀의 역량 (capacity)
...

작동 원리: "모든 베팅에는 중단 기준 (kill criteria)이 있어야 한다"라는 제약 조건이 로드맵을 정직하게 만듭니다. 중단 기준이 없는 로드맵은 위시리스트 (wishlist)에 불과하지만, 중단 기준이 있는 로드맵은 정의된 출구 (exits)를 가진 베팅 포트폴리오가 됩니다. "가설 (Hypothesis)" 열은 기능 목록 (feature-list) 중심의 사고 대신 인과 관계 중심의 사고 ("만약 우리가 X를 출시하면, Z 때문에 지표 Y가 움직일 것이다")를 강제합니다. Now/Next/Later 그룹화 (Shape Up / JTBD 관행에서 유래)는 거짓된 날짜의 정밀함을 피하게 해줍니다.

프롬프트 6 — 이해관계자의 시간을 낭비하지 않는 업데이트 (Stakeholder update that doesn't waste their time)

임원진과 교차 기능 파트너 (cross-functional partners)들은 단 하나의 질문에 답하기 위해 당신의 업데이트를 읽습니다: "내가 해야 할 일이 있는가?" 만약 그 답이 네 번째 문단에 파묻혀 있다면, 당신은 그들의 시간과 당신의 시간을 모두 낭비한 것입니다. 이 프롬프트는 요청 사항을 앞부분에 배치합니다.

역할 (ROLE): 당신은 주간 이해관계자 업데이트 (stakeholder update)를 작성하는 제품 관리자 (product manager)입니다.
맥락 (CONTEXT): 프로젝트는 [PROJECT]입니다. 이번 주 상태: [정상 (ON TRACK) / 위험 (AT RISK) / 차단 (BLOCKED)]. 이 청중에게 내가 요구하는 단 한 가지는
...

작동 원리: 요청 사항을 첫 번째 줄에 배치합니다. 왜냐하면 대부분의 독자는 그 줄까지만 읽기 때문입니다. "우리 (We)" 사용 금지 규칙은 일기장처럼 읽히는 수동적인 상태 업데이트 ("우리는 디자인 팀과 만났습니다... 우리는 사양을 검토했습니다...")를 제거합니다. "동사 또는 명사"로 문장을 시작하도록 강제하면 "사양 승인 완료 (Spec approved by design)"와 같은 표현이 생성되어, "우리가 사양 승인을 받았습니다 (We got the spec approved)"보다 정보량은 같으면서 단어 수는 절반으로 줄어들고 자아 (ego)는 배제됩니다.

프롬프트 7 — 모호한 피드백을 실행 가능한 입력값으로 재구성하기 (Reframe vague feedback into actionable input)

"이건 좀 헷갈리네요." "더 직관적이어야 할 것 같아요." "좀 더 눈에 띄게 만들 수 없을까요?" 이와 같은 피드백은 말 그대로만 보면 실행 불가능하지만(unactionable), 보통 실제적인 문제를 가리키고 있습니다. 이 프롬프트는 모호한 피드백을 구체적이고 테스트 가능한 가설로 재구성합니다.

역할(ROLE): 당신은 모호한 이해관계자(stakeholder)의 피드백을 실행 가능한 가설로 번역하는 제품 관리자(product manager)입니다.
맥락(CONTEXT): 피드백 내용은 다음과 같습니다: "[원문 피드백 그대로]". 이 피드백은 ... 에서 전달되었습니다.

작동 원리: 순위가 매겨진 세 가지 해석은 당신의 첫 번째 읽기가 틀렸을 수도 있다는 점을 강제로 고려하게 만듭니다. 이해관계자의 말은 종종 당신의 직관과는 다른 해석을 뒷받침하곤 합니다. 단 하나의 명확한 질문만을 던지도록 제한하는 제약 조건은, 하나의 모호한 코멘트를 일정 예약으로 만들어버리는 "정렬을 위해 30분간 회의를 잡읍시다"라는 반사적인 반응을 방지합니다. 해결책을 제안하기 전에 문제를 날카롭게 다듬는 것이 바로 PM(Product Manager)과 티켓 작성자(ticket-writer)를 가르는 차이점입니다.

프롬프트 8 — 월요일 아침에도 살아남는 출시 체크리스트 (The launch checklist that survives Monday morning)

출시 체크리스트가 실패하는 방식은 두 가지입니다. 자신이 수행하지 않은 단계를 잊어버린 한 사람이 작성하거나, 너무 일반적이어서 실제 출시 상황에 적용할 수 없는 경우입니다. 이 프롬프트는 특정 기능과 회사에 특화된 체크리스트를 초안으로 작성합니다.

역할(ROLE): 당신은 출시 체크리스트를 작성하는 제품 관리자(product manager)입니다.
맥락(CONTEXT): 기능은 [기능명]입니다. 출시일은 [날짜]입니다. 이 기능은 다음 영역에 영향을 미칩니다: [목록 — 예: 웹 앱, 모바일, API, 문서, 결제].
...

작동 원리: T-5 / T-1 / 출시(Launch) / T+1의 리듬은 출시가 실제로 실패하는 방식과 일치합니다. 대부분의 실패는 출시 당일의 버그가 아니라, 준비 항목의 누락(분석 도구 미구현, 지원 팀 브리핑 누락 등)에서 발생합니다. T+1 시점에 "결정: 유지 / 반복 / 롤백(roll back)"을 강제함으로써, 출시 다음 날의 스탠드업 미팅을 단순한 상태 보고 회의가 아닌 의사결정 회의로 바꿉니다. 모든 항목을 산문이 아닌 체크박스 형태로 만드는 것은 체크리스트를 막연한 희망 사항이 아닌 실제로 사용 가능한 도구로 만듭니다.

프롬프트 9 — 단 하나의 의사결정을 만들어내는 회고 (The retro that produces one decision)

대부분의 회고(Retrospective)는 포스트잇이 가득 붙은 벽만 남길 뿐, 실제 의사결정은 전혀 이끌어내지 못합니다. 유용한 결과물은 다음 스프린트(Sprint)에서 팀이 시도할 한두 가지의 구체적인 변화이며, 여기에는 담당자와 검토 날짜가 포함되어야 합니다. 이 프롬프트는 바로 그 내용을 초안으로 작성해 줍니다.

역할(ROLE): 당신은 스프린트 회고(Sprint Retrospective)를 진행하는 프로덕트 매니저(Product Manager)입니다.
맥락(CONTEXT): 이번 스프린트의 목표는 [GOAL]이었습니다. 우리는 목표를 달성했습니다 / 달성하지 못했습니다 / 부분적으로 달성했습니다. 팀의 가공되지 않은 회고 입력값(잘된 점, 안 된 점, 아이디어 등)
...

작동 원리: "단 하나의 실험"이라는 제약 조건이 회고를 통해 실제로 행동을 변화하게 만듭니다. 8개의 실행 항목(Action items)이 있는 회고는 그중 아무것도 실행하지 못하지만, 단 하나의 항목이 있는 회고는 그것을 실행하고 검토합니다. "[날짜]까지 [신호(signal)]가 나타난다면 성공한 것으로 간주하겠다"라는 프레임워크는 모호한 의도("더 일찍 소통하기")를 테스트 가능한 변화("범위(Scope)가 변경되면 화요일 업무 종료 시까지 Slack으로 미리 알림을 보내겠습니다. 다음 두 번의 회고 동안 엔지니어가 '너무 늦게 알게 되었다'라고 말하지 않는다면 성공한 것으로 간주하겠습니다")로 바꿔줍니다. "그만해야 할 일(Stop doing)" 항목은 종종 "시작해야 할 일(Start doing)" 항목보다 더 높은 레버리지(Leverage)를 가집니다.

이 프롬프트들을 테스트한 방법