PM을 위한 AI 워크스페이스: 명세, 리서치, 보고를 한 곳에서

PM의 한 주에서 AI가 실제로 들어맞는 자리

프로덕트 매니지먼트는 하나의 일정 안에 담긴 네 가지 다른 업무입니다. 피드백, 티켓, 녹취록, 분석 자료를 많이 읽고, 명세와 업데이트, 브리핑을 많이 쓰고, 퍼널과 코호트, 설문 결과를 조금 분석하고, 끊임없이 설득합니다. 각각은 서로 다른 모델에 어울리기 때문에, 단일 AI 구독은 업무의 대략 3분의 2만 커버하고 나머지는 싸움처럼 느껴지게 됩니다.

PM 업무	최적 모델	이유
PRD 서사, 문제 정의, 제품 업데이트	Claude	긴 논리를 유지하고 엔지니어가 실제로 읽을 만한 산문을 씁니다
피드백 테마 분류, 티켓 클러스터링, 구조화된 추출	GPT	엄격한 출력 형식과 일관된 카테고리 라벨에 강합니다
디스커버리 리서치, 경쟁사 스캔, 시장 맥락	Gemini	최신 웹 자료에 강하고 열어볼 수 있는 출처를 반환합니다
긴 녹취록, 리서치 자료, 100페이지 보고서	Gemini	100만 토큰 컨텍스트 창이라 전체 자료가 한 번에 들어갑니다
명세 비평과 엣지 케이스 찾기	그 명세를 쓰지 않은 모든 모델	독립된 독자가 작성자가 놓친 것을 잡아냅니다

이 중 어느 것도 무엇을 만들지에 대한 판단을 대신하지 않습니다. 다만 입력값을 확보하는 것과 실제로 글로 정리해 두는 것 사이의 거리를 좁혀 주며, 이 지점이 PM의 한 주 중 시간이 실제로 새는 곳입니다. 전환 비용도 저렴합니다. Whizi Pro에서는 Claude Sonnet 5 메시지 하나가 월 2,000 크레딧 한도 중 10 크레딧을 쓰고, GPT-5.6 Luna의 추출은 1 크레딧, Gemini 3.7 Flash의 녹취록 읽기는 메시지당 2 크레딧입니다.

엔지니어가 되돌려 보내지 않을 PRD 쓰기

AI가 작성한 명세 대부분은 같은 지점에서 실패합니다. 결정이 아니라 기능을 설명한다는 점입니다. 엔지니어링 팀은 고객이 왜 중요한지에 대한 문단이 필요한 게 아닙니다. 상태, 엣지 케이스, 호출이 실패했을 때 벌어지는 일이 필요합니다. 이를 명시적으로 요청하면 출력의 성격이 달라집니다.

프롬프트: 문제 정의부터

PRD의 문제 정의 섹션을 작성해줘. 내가 가진 근거: [지원 티켓, 분석 자료, 인터뷰 인용문 붙여넣기]. 해결책은 제시하지 마. 누가 이 문제를 겪는지, 얼마나 자주 겪는지, 지금은 대신 무엇을 하는지, 이것이 그들에게 어떤 비용을 발생시키는지, 해결되면 무엇이 달라질지를 반환해줘. 내가 붙여넣은 근거로 뒷받침되지 않는 주장에는 ASSUMPTION이라고 표시해줘.

프롬프트: 명세 본문

이것을 엔지니어링 팀을 위한 명세로 바꿔줘. 기능: [설명]. 다뤄야 할 사용자 상태: [목록]. 인수 기준이 붙은 사용자 스토리, 빈 상태와 로딩, 에러, 권한 거부를 포함한 모든 상태, 의존성이 사용 불가능할 때의 동작, 속성이 포함된 분석 이벤트, 미해결 질문을 반환해줘. 내가 말하지 않은 요구사항은 지어내지 마. 가정해야 했던 내용은 맨 끝에 별도 섹션으로 나열해줘.

프롬프트: 비평 단계

견적 산정 전에 이 명세를 검토하는 수석 엔지니어처럼 행동해줘. 문제만 나열해줘. 정의되지 않은 동작, 누락된 상태, 상충되는 요구사항, 숨겨진 마이그레이션 작업, 그리고 리파인먼트 단계에서 후속 질문을 만들어낼 만한 것들. 명세를 다시 써주지는 마.

이 세 번째 프롬프트는 그 명세를 쓰지 않은 모델에서 실행하세요. 팀이 리파인먼트에서 어차피 제기했을 세 가지 질문을 안정적으로 드러내며, 이를 미리 답해 두는 것이 20분짜리 그루밍 세션과 50분짜리 그루밍 세션의 차이를 만듭니다.

원시 피드백을 우선순위를 매길 수 있는 것으로 바꾸기

프로덕트 매니지먼트에서 레버리지가 가장 큰 AI 작업은 글쓰기가 아닙니다. 400건의 피드백을 실행 가능한 형태로 읽어내는 것입니다. 수작업으로 하면 반나절이 걸립니다. 모델을 제대로 활용하면 20분이면 되고, 품질은 거의 전적으로 안정적인 카테고리를 강제했는지에 달려 있습니다.

프롬프트: 1차 테마 분류

여기 원시 고객 피드백이 있어. 테마별로 클러스터링해줘. 각 테마마다 라벨, 항목 개수, 표현에서 드러나는 심각도, 정확히 그대로 복사한 대표 인용문, 그리고 그 테마가 버그, 누락된 기능, 사용성 문제, 기대 불일치 중 무엇인지 반환해줘. 문구가 비슷해 보여도 근본 원인이 다른 테마는 합치지 마. 인용문을 바꿔 쓰지 마. 피드백: [붙여넣기].

프롬프트: 고정된 분류 체계에 대한 2차 분류

같은 피드백을 오직 이 카테고리만 사용해서 다시 분류해줘: [기존 분류 체계 붙여넣기]. 맞지 않는 것은 설명과 함께 UNCLASSIFIED로 분류해줘. 카테고리, 개수, 비율의 표를 반환해줘.

두 단계 구조가 중요합니다. 1차 분류는 데이터에 실제로 무엇이 있는지 알려줍니다. 2차 분류는 그 결과를 지난 분기와 비교 가능하게 만들어주며, 이것이 우선순위 회의에서 그저 흥미로운 자료가 아니라 실제로 쓸 수 있는 자료가 되게 만드는 지점입니다.

요청할 것	얻는 것	쓸모
개수가 붙은 테마	문제 영역의 순위 목록	로드맵 입력, 분기 계획
인용문만	각색되지 않은 고객의 언어	카피, 포지셔닝, 경영진 설득
심각도와 빈도 분리	통증 대 물량의 2x2 매트릭스	무엇을 먼저 고칠지 결정
상충 사항	세그먼트가 서로 반대되는 것을 원하는 지점	거짓 합의를 조기에 포착

마지막 행은 고정 프롬프트로 만들어 둘 가치가 있습니다. 이 피드백에서 서로 다른 사용자들이 양립할 수 없는 것을 원하는 지점은 어디야? 세그먼트와 트레이드오프를 명시해줘. 테마 목록은 불일치를 평평하게 만들어버리는데, 그 불일치야말로 데이터에서 보통 가장 쓸모 있는 부분입니다.

디스커버리, 경쟁사, 그리고 시간이 늘 부족한 리서치

디스커버리는 출시가 늦어질 때 가장 먼저 잘려나가는 업무이며, 바로 그때가 나쁜 결정의 비용이 가장 커지는 시점입니다. 모델 지원 스캔이 고객과 직접 대화하는 일을 대체하지는 않지만, 눈감고 결정을 내려야 할 핑계는 없애줍니다.

프롬프트: 경쟁사 분석

[경쟁사]가 [해결하려는 과제]를 어떻게 다루는지 분석해줘. 그들 자신의 언어로 표현된 포지셔닝, 그들의 헬프 센터에 문서화된 플로우, 공개된 경우의 가격, 최근 12개월간 날짜와 함께 바뀐 점, 공개 리뷰에서 보이는 불만 테마를 다뤄줘. 모든 주장에 URL을 인용해줘. 회사가 밝힌 내용과 제3자가 관찰한 내용을 구분해줘.

프롬프트: 인터뷰 종합

이 인터뷰 녹취록을 읽어줘. 사용자가 이루려는 일, 그들이 만들어낸 우회 방법, 정확한 인용문과 함께 좌절을 표현한 순간들, 그리고 사용자가 말한 것과 그들이 실제로 했다고 설명한 행동이 모순되는 지점을 반환해줘. 녹취록 범위를 넘어서 일반화하지 마. 어떤 패턴이 세 건 미만의 인터뷰에서만 나타난다면 패턴이 아니라 단일 관찰로 표시해줘.

그 마지막 제약이 PM이 가장 자주 잊는 부분입니다. 모델은 깔끔한 패턴을 만들어내고 싶어 하고, 두 건의 인터뷰에서 나온 깔끔한 패턴은 존재하지 않는 고객을 위한 로드맵으로 이어지는 지름길입니다. 모든 주장에 개수를 함께 요청하세요.

경영진 보고와 출시 커뮤니케이션

같은 내용이 네 가지 고도에서 존재해야 합니다. 엔지니어링을 위한 명세, 팀을 위한 업데이트, 경영진 리뷰를 위한 한 문단, 고객을 위한 출시 노트입니다. 고도 사이를 오가며 다시 쓰는 일은 이 직무에서 가장 기계적인 작업이자 가장 넘기기 쉬운 작업입니다.

프롬프트: 고도 전환

이것을 [대상 독자]를 위해 다시 써줘. 그들은 [구체적인 관심사]에 신경 써. 이 제품 영역에 대해 [수준] 정도의 배경지식이 있어. 모든 사실 주장은 그대로 유지해줘. 길이: [제약]. 배경이 아니라 결정이나 결과로 시작해줘. 초안: [붙여넣기].

프롬프트: 경영진 문단

이 업데이트를 한 번 읽고 말 임원을 위해 120단어로 압축해줘. 구조: 무엇이 바뀌었는지, 우리가 약속한 지표에 어떤 의미인지, 그들에게서 무엇이 필요한지, 그들이 주목해야 할 단 하나의 리스크. 측정되지 않은 형용사는 쓰지 마.

프롬프트: 사전 부검

6개월 후 이 출시가 실패했다고 가정해줘. 아래 계획에만 근거해서 가능성이 높은 순서로 가장 그럴듯한 설명 세 가지를 써줘. 각각에 대해 우리가 지켜볼 수 있는 초기 신호를 명시해줘. 계획: [붙여넣기].

네 가지 고도를 모두 같은 Whizi 스레드 안에 유지하세요. 출시 노트는 명세와 피드백 분석의 맥락을 그대로 물려받으므로, 청중이 바뀔 때마다 기능을 다시 설명할 필요가 없어집니다.

AI가 프로덕트 매니저를 특히 잘못 이끄는 지점

세 가지 실패 유형이 다른 어떤 직무보다 이 일에서 더 중요합니다.

조작된 인용문. 모델을 원본 텍스트에 고정하지 않고 대표 인용문을 요청하면, 어떤 고객도 말한 적 없는 그럴듯한 문장을 받게 되는 경우가 있습니다. 항상 인용문은 정확히 그대로 복사하고, 바꿔 쓰지 마라고 지시하고, 슬라이드에 들어가기 전에 그중 세 개를 원본 데이터와 대조해 확인하세요.

소규모 표본에서 오는 거짓 확신. 모델은 지원 티켓 8건을 800건과 똑같은 확신으로 테마 분류합니다. 모든 테마에 개수를 요청하고, 몇 건에 불과한 사례는 신호가 아니라 관찰로 취급하세요.

로드맵 연극. 모델에게 백로그 우선순위를 매겨달라고 요청하면, 티켓 안의 단어 말고는 아무 근거도 없는 자신만만한 순위가 나옵니다. 여러분의 전략, 여력, 기술 부채, 다음 분기에 성사되는 거래에는 전혀 접근할 수 없습니다. 트레이드오프를 구조화하는 데는 쓰되, 결정을 내리는 데는 절대 쓰지 마세요.