PM 사례 연구 빌더
이 스킬이 하는 일
사용자가 작업한 제품 이니셔티브를 — 완성도에 관계없이, 정교한 지표가 있든 없든 — 가져와서 PM의 사고를 보여주는 체계적이고 설득력 있는 사례 연구로 구성합니다. 목표는 마케팅 카피를 작성하는 것이 아닙니다. 어려웠던 결정, 그 결정을 어렵게 만든 맥락, 그리고 그 결과로 이어진 산출물을 표면화하는 것입니다.
좋은 사례 연구는 PM이 어떻게 생각하는지 보여주며, 단순히 무엇을 출시했는지 보여주지 않습니다.
1단계: 원자재 수집
다음 항목을 한 번의 프롬프트로 요청하세요. 이미 컨텍스트에 있는 항목은 건너뛰고 질문하지 마세요. 불완전한 정보도 괜찮습니다 — 주어진 정보를 가지고 작업하고, 막히기보다는 부족한 부분을 표시할 것입니다.
- 이니셔티브 — 무엇을 작업했습니까? (기능, 제품, 플랫폼, 리디자인, 0→1 구축, 전략 프로젝트, 중단, 등)
- 맥락과 제약 조건 — 어떤 회사, 어떤 단계, 팀 규모는? 어떤 제약 조건이 중요했습니까? (일정, 리소스, 기술 부채, 조직 역학)
- 해결하려던 문제 — 무엇이 고장 나 있거나, 없거나, 불명확했습니까? 누구의 문제였습니까?
- 당신이 한 일 — 내린 주요 결정, 고려했던 접근 방식, 주도한 작업
- 결과 — 무엇이 출시되었습니까? 무엇이 바뀌었습니까? 대략적인 지표라도 있습니까?
- 다르게 했을 점 — 선택 사항이지만, 이야기를 더 신뢰할 수 있게 만듭니다.
- 사용처 — 포트폴리오 사이트, 면접, LinkedIn, 내부 문서, 라이팅 샘플?
이 정보를 얻으면 진행하세요. 완벽한 정보를 기다리지 마세요.
2단계: 스토리 스파인 식별
작성 전에 이 사례 연구가 효과적으로 작동하도록 하는 내러티브 구조를 식별하세요. 모든 강력한 PM 사례 연구에는 다음이 있습니다:
- 신경 쓸 가치가 있는 문제 — 이것이 왜 중요했습니까? 누가 영향을 받았습니까?
- 비자명한 결정 — 여러 합리적인 경로가 존재했고 판단력이 필요했던 순간입니다. 이것이 사례 연구의 핵심입니다.
- 모든 것을 결정지은 제약 조건 — 무엇이 이것을 어렵게 만들었습니까? (기술 부채, 이해관계자 간 불일치, 모호한 데이터, 촉박한 일정, 경쟁 우선순위)
- 무언가를 증명하는 결과 — 단순히 "우리가 출시했다"가 아니라 세상에 어떤 변화가 생겼는지
작성 전에 이 네 가지 요소를 명시적으로 명명하세요. "비자명한 결정"을 찾을 수 없다면 사용자에게 물어보세요: "가장 어려웠던 결정은 무엇이었습니까?" 그것이 보통 진짜 이야기입니다.
3단계: 전체 사례 연구 작성
구조:
[이니셔티브 제목]
한 줄 요약: 무엇이었고 무엇을 바꾸었는지
문제
무엇이 고장 나 있거나 없었습니까? 누구의 문제였습니까? 해결할 가치가 있는 진짜 문제라는 것을 어떻게 알았습니까? (2~4문장. 회사 배경부터 시작하고 싶은 충동을 억제하세요.)
맥락
무엇을 가지고 작업했습니까? 팀 규모, 제품 단계, 중요했던 제약 조건. 핵심만 유지하세요 — 결정이 어려웠던 이유를 설명하는 맥락만 포함하세요.
내가 한 일
핵심 결정에 대한 내러티지이지, 활동 목록이 아닙니다. 이야기 형식으로 구조화하세요: 무엇을 시도했는지, 무엇을 배웠는지, 무엇을 바꾸었는지, 무엇을 결정했는지.
다음을 포함하세요:
- 가장 어려운 결정과 그 근거
- 고려하고 배제했던 것
- 불확실성이나 상충하는 신호를 어떻게 처리했는지
- 누구와 함께 일했으며 그것이 왜 중요했는지
다음은 포함하지 마세요:
- 일어난 모든 일 (하이라이트지 일기가 아닙니다)
- 판단력이 필요하지 않은 과정 단계 ("나는 스크럼을 운영했습니다")
- 기여 형식의 언어 ("나는 팀을 지원했습니다...")
결과
무엇이 출시되었습니까. 무엇이 바뀌었습니까. 가능하다면 지표 — 허영 지표가 아닌 실제 지표. 지표가 없다면 어떤 관찰 가능한 변화가 발생했는지 설명하세요.
다르게 했을 점
하나의 솔직한 관찰. 이야기를 현실감 있게 만들고, 배우는 PM이라는 신호를 줍니다. 사용자가 원하지 않으면 건너뛰세요.
4단계: 출력 형식 생성
전체 사례 연구를 작성한 후, 두 가지 추가 버전을 생성하세요:
LinkedIn 아티클 버전 (600~900단어)
동일한 구조, 더 간결한 문체. 배경이 아닌, 프로젝트를 흥미롭게 만든 통찰력이나 결정인 "그래서 뭐?"로 시작합니다. 명확한 시사점이나 열린 질문으로 끝맺음합니다. LinkedIn에 게시하기에 적합합니다.
요점 개요 (구술 스토리텔링용)
사용자가 면접이나 포트폴리오 워크스루를 위해 내면화할 수 있는 구조화된 개요:
- 한 문장 설정: "이것은 [맥락] 동안 [회사]에서 [문제 유형]이었습니다"
- 비자명한 결정: 무엇이었는지, 무엇을 고려했는지, 무엇을 결정했는지
- 결과: 어떻게 되었는지
- 교훈: 다르게 했을 점 또는 이것이 가르쳐준 것
5단계: 개선 제안
세 가지 형식을 모두 전달한 후, 다음을 제안하세요:
"각도를 조정하거나, 섹션을 다듬거나, 지표 프레이밍을 개선하거나, 특정 역할이나 회사에 맞게 조정해 드릴까요? 변경할 점을 말씀해 주세요."
일반적인 개선 사항:
- 특정 역할 맞춤화 — 대상 회사가 중시하는 부분에 따라 강조할 결정을 재구성
- 지표 코칭 — 사용자가 실제로 주장할 수 있는 숫자와 부분적이거나 간접적인 경우 정직하게 프레이밍하는 방법을 찾도록 도움
- 포트폴리오용 축약 — 2분 포트폴리오 워크스루를 위한 필수 내러티브로 축소
- 결정 내러티브 강화 — 사례 연구가 기능 발표처럼 읽힌다면 판단 호출을 중심으로 재구성
톤 및 보이스 가이드
사례 연구의 기본 보이스:
- 1인칭 능동태 — "팀이 결정했습니다"가 아닌 "저는 결정했습니다"
- 결정에 대해 구체적으로 — 결과뿐만 아니라 트레이드오프를 명명하세요
- 불확실성에 대해 솔직하게 — "우리는 X를 몰랐기 때문에 ...했습니다"가 모든 것이 계획되었다고 가정하는 것보다 강력합니다
- 간결하게 — 문장당 하나의 아이디어. 서두를 자르세요.
- 전문 용어 금지 — "마찰 없는 온보딩 최적화를 통해 사용자 참여를 개선했습니다"가 아닌 "리텐션을 개선했습니다"
사용자가 자신만의 보이스를 가지고 있다면 맞춰주세요. 특정 스타일을 원한다면 라이팅 샘플을 요청하세요.
PM 사례 연구의 강함과 약함
강함:
- 기능이 아닌 결정에 초점을 맞춤
- 어려웠던 점과 그 이유를 명시
- 불완전하더라도 구체적인 결과가 있음
- 판단력을 보여줌: 고려하고 배제한 것
- 사람처럼 읽히고, 직무 설명처럼 읽히지 않음
약함:
- 문제보다 회사 배경부터 시작
- 과정 단계를 설명하지만 왜 중요했는지는 설명하지 않음
- 어려운 결정을 건너뜀 — 단순히 "X를 출시했고 잘 작동했습니다"라고 말함
- 맥락 없는 일반 지표 ("NPS 개선")
- 수동태 문장 전체 ("팀은 ...할 수 있었습니다")
사용자가 제공한 원자재로 약한 사례 연구가 나올 것 같다면, 그 부족한 점을 지적하고 진짜 이야기를 끌어낼 올바른 질문을 하세요.