이해관계자 미팅, 기획서 없이 가면 안 되는 이유

이해관계자 미팅, 기획서 없이 가면 안 되는 이유

기획서 없이 간 미팅의 참사 작년 10월이었다. 마케팅팀 요청으로 잡힌 미팅. 이벤트 배너 위치 조정 건이었다. "간단한 거니까 구두로 설명하면 되겠지." 착각이었다. 회의실에 들어갔다. 마케팅팀 3명, CS팀 2명, PM 1명. 총 6명. 나는 맨손이었다. 노트북도 안 가져갔다. "배너를 메인에서 서브로 옮기려고요." 마케팅팀장이 물었다. "왜요?" "클릭률이 낮아서요." "얼마나 낮은데요?" "음... 한 0.3% 정도?" "그게 낮은 건가요?" 대답 못 했다. 벤치마크 데이터가 없었다. CS팀에서 또 물었다. "옮기면 문의 늘지 않나요?" "아니요, 괜찮을 거예요." "근거가?" 없었다. 30분 동안 질문만 받았다. 하나도 제대로 답 못 했다. 미팅 끝나고 PM이 말했다. "다음엔 자료 가져와." 얼굴이 화끈거렸다.기획서는 방패다 그 뒤로 자료 없이 미팅 간 적 없다. 기획서가 있으면 공격당하지 않는다. 정확히는 공격을 막을 수 있다. "왜 이렇게 기획했어요?" 기획서 3페이지 펼친다. "유저 리서치 결과 보시면, 73%가 현재 플로우에서 이탈했습니다." "개발 공수는요?" 기획서 5페이지. "백엔드 3일, 프론트 2일, QA 1일 예상입니다." "경쟁사는 어떻게 하는데요?" 기획서 7페이지. "토스, 카카오, 네이버 3사 비교표 첨부했습니다." 질문이 나올 때마다 기획서 넘긴다. 답이 다 있다. 미팅이 30분 만에 끝난다. 결정도 빠르다. 기획서는 방패이자 무기다. 지난달 경영진 보고 때였다. 신규 기능 기획안 발표. 대표님이 물었다. "이거 만들면 매출 오르나요?" 기획서 10페이지 띄웠다. "예상 전환율 개선 15%, 월 예상 매출 증가 2300만원입니다." "근거는?" "A/B 테스트 결과와 유사 케이스 벤치마킹입니다. 상세 계산식은 11페이지에 있습니다." 대표님이 고개 끄덕였다. "좋아요, 진행하세요." 5분 만에 승인났다. 자료 없었으면 한 시간 설득해도 안 될 일이었다.이해관계자는 말을 안 믿는다 마케팅팀, CS팀, 경영진. 모두 다르게 생각한다. 마케팅팀은 노출을 원한다. 배너 크게, 버튼 눈에 띄게. CS팀은 문의 감소를 원한다. UI 명확하게, 설명 자세하게. 경영진은 매출을 원한다. 전환율 높이고, 비용 줄이고. 기획자는 그 중간에 있다. 모두를 만족시킬 순 없다. 그래서 기획서가 필요하다. "이 기능은 마케팅 효율을 15% 높이지만, CS 문의는 5% 늘 수 있습니다. 하지만 FAQ 보강으로 대응 가능합니다." trade-off를 명시한다. 선택지를 준다. "A안은 개발 2주, 매출 효과 중. B안은 개발 1개월, 매출 효과 대. 어떤 걸 선택하시겠습니까?" 결정권자가 판단한다. 나는 정보를 제공한다. 기획서 없이 말로만 하면? "그냥 이게 좋을 것 같아요." 신뢰 제로다. 지난주 CS팀 미팅. 환불 프로세스 개선 건. CS팀장이 말했다. "환불 버튼 더 숨겨주세요. 악용 사례가 많아요." 나는 기획서를 펼쳤다. "환불 클릭 중 실제 악용은 3%입니다. 97%는 정당한 사유입니다. 버튼 숨기면 정상 유저 불편도가 40% 상승합니다." 데이터를 보여줬다. CS팀장이 인정했다. "그럼 악용 방지는 어떻게 하죠?" "2단계 인증과 사유 작성 필수로 가겠습니다. 예상 악용 감소율 60%입니다." 기획서 다음 페이지에 있었다. CS팀장이 동의했다. 데이터를 믿었다. 말은 안 믿는다. 숫자는 믿는다. 기획서에 들어갈 것들 매번 같은 구조로 작성한다. 이해관계자가 예측 가능하게. 1. 배경 (Background) 왜 이 기획을 하는가. 한 문장으로. "현재 결제 이탈률 38%, 업계 평균 22% 대비 16%p 높음." 문제를 정의한다. 숫자로. 2. 목표 (Goal) 무엇을 달성할 것인가. 측정 가능하게. "결제 이탈률 38% → 25% 감소. 예상 매출 증가 월 4500만원." 목표가 애매하면 미팅이 산으로 간다. 3. 현황 분석 (AS-IS) 지금 어떤 문제가 있는가. 유저 플로우, 스크린샷, 데이터. "현재 결제 페이지 로딩 4.2초. 이탈 지점 76%가 로딩 중." 문제를 시각화한다. 4. 개선안 (TO-BE) 어떻게 바꿀 것인가. 와이어프레임, 플로우 차트. "로딩 1.5초로 단축. 진행 상태 표시 추가. 간편결제 우선 노출." before-after 비교. 한눈에 보이게. 5. 예상 효과 (Expected Impact) 바꾸면 뭐가 좋아지나. 정량적, 정성적. "예상 이탈률 13%p 감소. 월 결제 건수 2200건 증가. 유저 만족도 상승." 숫자가 있으면 설득력 100배. 6. 일정 및 리소스 (Timeline & Resources) 언제, 누가, 얼마나 걸리나. "백엔드 5일, 프론트 3일, 디자인 2일, QA 2일. 총 12일. 개발자 김OO, 디자이너 이OO 투입." 일정 없으면 '언제 돼요?' 질문 폭탄. 7. 리스크 및 대응 (Risk & Mitigation) 뭐가 잘못될 수 있나. 어떻게 대응하나. "외부 결제 모듈 지연 가능성. → 대체 모듈 사전 검토 완료." 리스크 언급 안 하면 나중에 책임진다. 이 구조로 작성하면 30분 미팅이 10분이 된다.구두 설명이 위험한 이유 작년에 마케팅팀이랑 일했다. 신규 이벤트 페이지 기획. 미팅에서 구두로 합의했다. "메인 배너 넣고, 타이머 달고, 공유 버튼 추가하죠." 다들 고개 끄덕였다. 회의록도 썼다. 2주 뒤 개발 완료. 마케팅팀한테 공유했다. "어? 이거 아닌데요." "네? 미팅에서 합의한 거잖아요." "타이머는 상단에 달라고 했는데, 이건 하단이잖아요." 회의록 다시 봤다. "타이머 추가"라고만 써있었다. 위치는 없었다. "그리고 공유 버튼은 이미지도 같이 공유되게 해달라고 했는데요." 그런 얘기 없었다. 아니, 있었나? 기억 안 났다. 결국 재작업. 개발자 3일 추가 투입. 개발자가 나한테 말했다. "다음엔 기획서에 다 적어줘." 내 잘못이었다. 구두 설명은 휘발된다. 사람마다 이해도 다르게 한다. "버튼을 크게 만들어주세요." 마케팅팀 생각: 화면의 30% 차지하는 버튼. 내 생각: 기존 버튼의 1.5배. 개발자 생각: 폰트 사이즈만 키우면 되나? 같은 말을 다르게 이해한다. 기획서에 적으면? "버튼 크기: 가로 280px, 세로 56px. 패딩 16px. 폰트 18px Bold." 오해할 여지가 없다. 지금은 모든 미팅에 기획서를 가져간다. 회의 중에도 바로 수정한다. "아, 타이머 위치는 상단이 맞죠? 지금 기획서에 반영할게요." 화면 공유하고 실시간으로 고친다. 다같이 확인한다. "네, 이거 맞습니다." 미팅 끝나면 기획서 링크 공유. Notion 또는 Confluence. "오늘 합의한 내용입니다. 내일까지 최종 검토 부탁드립니다." 24시간 안에 이의 제기 없으면 확정. 그 뒤론 "그런 거 아니라고 했는데요" 없다. 이해관계자별 맞춤 전략 같은 기획서를 모두에게 보여주지 않는다. 버전을 나눈다. 경영진용1페이지 요약본. Executive Summary. 목표, 예상 효과, 일정, 비용. 세부 기획은 부록. 대표님은 디테일 안 본다. 결론만 본다.지난달 신규 기능 보고. 1페이지: "예상 MAU 15% 증가, 월 매출 3200만원 증가, 개발 기간 6주." 대표님 반응: "좋아요, 진행하세요." 30초 만에 승인. 마케팅팀용유저 플로우 중심. 어떻게 유입되고, 어디서 전환되나. 경쟁사 사례. 측정 지표: CTR, CVR, ROAS.지난주 이벤트 페이지 기획. 마케팅팀한테는 유저 여정 5단계로 설명. "랜딩 → 관심 유도 → 참여 → 공유 → 전환." 각 단계별 예상 전환율 명시. 마케팅팀 만족. "이해 쉽네요." CS팀용유저 불편 포인트 해결 중심. FAQ 변경사항. 예상 문의 증감. 대응 가이드.환불 프로세스 개선 때. CS팀한테는 문의 시나리오 10개 작성해서 공유. "이런 경우엔 이렇게 답변하시면 됩니다." CS팀장: "이거면 충분하겠네요." 개발팀용기능 명세 상세. API 스펙, 데이터 구조, 예외 처리. 와이어프레임, 인터랙션 정의. 개발 우선순위.개발자한테는 테크 스펙 문서 별도. "이 필드는 필수, 저 필드는 선택. 에러 코드는 400, 401, 403..." 개발자: "이 정도면 작업 가능." 같은 내용, 다른 포커스. 이해관계자가 원하는 걸 준다. 기획서 작성 시간은 투자다 기획서 한 건 쓰는 데 보통 하루 걸린다. 8시간. 적지 않다. "기획서 쓸 시간에 개발자랑 얘기하는 게 빠르지 않아요?" 신입 기획자가 물었다. "아니." 기획서 8시간 쓰면, 미팅 시간 20시간 줄어든다.이해관계자 설득 미팅: 2시간 → 30분 개발 커뮤니케이션: 3시간 → 1시간 수정 요청 대응: 5회 → 1회 재작업: 3일 → 0일기획서 없으면 모든 게 늘어난다. 일정, 비용, 스트레스. 지난해 프로젝트 복기했다. 기획서 있던 프로젝트: 평균 일정 준수율 87%. 기획서 없던 프로젝트: 평균 일정 준수율 43%. 2배 차이. 기획서는 시간 낭비가 아니다. 시간 절약이다. 요즘은 템플릿을 만들어뒀다. Notion에 12개.신규 기능 기획서 템플릿 개선 기획서 템플릿 A/B 테스트 기획서 템플릿 이해관계자 보고서 템플릿복붙하고 내용만 채운다. 2시간 안에 초안 완성. 효율이 오른다. 구두 합의는 합의가 아니다 법적으로도 문서가 우선이다. "미팅에서 그렇게 하기로 했잖아요." "회의록에 없는데요?" 끝이다. 회사에서도 마찬가지다. 구두 합의는 합의가 아니다. 기록된 합의만 합의다. 작년에 프로젝트 하나 엎어질 뻔했다. 마케팅팀이랑 합의한 기능. 구두로만. 개발 80% 진행됐을 때 마케팅팀장이 바뀌었다. 새 팀장: "이거 왜 만들어요?" "전임 팀장님이랑 합의했습니다." "문서 있어요?" 없었다. "그럼 필요 없는 거 아니에요? 중단하죠." 3주치 개발이 날아갈 뻔했다. 다행히 슬랙 대화 기록이 있었다. 그걸 증거로 제시했다. "합의 내용입니다." 겨우 프로젝트 살렸다. 그 뒤론 모든 합의를 문서화한다. 미팅 끝나면 바로 회의록 공유. "오늘 합의 사항입니다. 48시간 내 이의 없으면 확정으로 간주합니다." 이의 제기 없으면 스크린샷 찍어서 보관. 나를 지키는 무기다. 기획서는 커뮤니케이션 비용을 줄인다 개발자가 10명이면, 10명한테 다 설명해야 한다. 1명당 30분. 총 5시간. 다음 날 또 물어본다. "그거 어떻게 하기로 했죠?" 다시 설명. 또 5시간. 기획서 하나 쓰면? "여기 보세요." 링크 하나. 10초. 질문 오면 문서 섹션 링크. "4번 항목 보시면 됩니다." 설명 반복 제로. 지난달 신규 기능 개발. 백엔드 3명, 프론트 2명, 앱 2명. 총 7명. 기획서 공유하고 질문 받았다. 슬랙에 7개 질문 왔다. 모두 기획서에 답 있었다. "3페이지 두 번째 단락 보시면 됩니다." 링크만 7번 보냈다. 커뮤니케이션 시간 90% 감소. 기획서는 자동응답 봇이다. 나를 지키는 기획서 기획은 모호하다. 정답이 없다. "이게 최선인가요?" "더 나은 방법은 없나요?" 항상 의심받는다. 기획서는 내 결정을 정당화한다. "왜 이렇게 기획했어요?" 기획서를 펼친다. "유저 리서치 32명, 경쟁사 분석 5개사, A/B 테스트 결과 반영했습니다." 프로세스를 보여준다. "감으로 한 거 아니에요?" "데이터 기반입니다. 8페이지 참고하세요." 감이 아님을 증명한다. 지난주 경영진 미팅. CFO가 물었다. "이 기능 꼭 필요한가요? 비용이 만만치 않은데." 기획서 12페이지 띄웠다. "없으면 월 예상 손실 5200만원입니다. ROI 계산식은 여기 있습니다." CFO가 계산기 두드렸다. 10초 뒤 고개 끄덕였다. "알겠습니다." 기획서가 나를 지켰다. 기획서 없었으면? "그냥 필요할 것 같아서요." 신뢰 제로. 승인 제로. 기획자는 증명해야 하는 직업이다. 기획서는 증명서다.기획서는 선택이 아니다. 생존이다. 다음 미팅엔 꼭 가져가라.

목요일 저녁 백로그 정리, 내일의 스프린트를 결정한다

목요일 저녁 백로그 정리, 내일의 스프린트를 결정한다

목요일 저녁 백로그 정리, 내일의 스프린트를 결정한다 목요일 오후 5시 30분 회의가 끝났다. 개발팀은 퇴근 준비 중이다. 나는 이제 시작이다. 내일이 금요일이다. 스프린트 플래닝이 10시다. 준비 안 하면 내일 1시간 회의가 3시간 된다. 경험으로 안다. 지라를 켠다. 백로그 티켓 47개. 우선순위 없음이 23개다. 웃긴다.실패한 스프린트의 공통점 지난 3개월 데이터를 봤다. 실패한 스프린트 5번. 공통점이 있다. 목요일에 백로그 정리를 안 했다. 금요일 아침에 즉흥으로 뽑았다. 결과:스토리 포인트 추정 2배 차이 개발 중 스펙 질문 폭탄 스프린트 중간에 티켓 교체 번다운 차트는 계단식데일리에서 "이거 왜 하는 거죠?"가 나오면 끝이다. 목요일의 30분이 2주를 결정한다. 백로그 정리 루틴 5시 반부터 시작한다. 순서가 있다. 1단계: 현실 파악 (10분) 이번 스프린트 남은 티켓 확인. Done: 12개, In Progress: 5개, To Do: 3개. Progress 중인 것들 상태 확인. 슬랙으로 개발자한테 물어본다. "내일까지 되나요?" 대부분 "힘들 것 같아요"다. 알았다. 다음 스프린트로 넘긴다.2단계: 백로그 우선순위 (20분) 백로그 상단부터 본다. 우선순위 기준은 명확하다.대표님이 언급한 것 (어쩔 수 없다) 유저 불편 티켓 (CS 3건 이상) 기술 부채 (개발팀 요청) 신규 피처 (데이터 있는 것부터)'하면 좋은 것'은 과감히 뺀다. 백로그 하단으로 보낸다. 아카이브 직전이다. 우선순위 태그를 단다. P0, P1, P2. P3는 사실상 안 한다는 뜻이다. 3단계: 스토리 스플릿 (30분) 큰 티켓을 쪼갠다. '회원 정보 수정 기능'은 너무 크다. 쪼개면:닉네임 변경 (2포인트) 프로필 사진 업로드 (3포인트) 비밀번호 변경 (5포인트, 보안 검토 필요)각각 독립적으로 배포 가능하게. MVP 마인드다. 억셉턴스 크리테리아를 명확히 쓴다. "언제 이게 완료된 건가요?" 기준이다. [완료 조건] - 사용자가 닉네임 입력 시 중복 체크 완료 - 특수문자 제한 (한글, 영문, 숫자, _, - 만) - 변경 완료 시 토스트 메시지 노출 - 프로필 화면에 즉시 반영이렇게 써야 개발자가 "됐습니다" 할 수 있다.개발자랑 사전 싱크 7시다. 백엔드 리드가 아직 있다. 슬랙을 보낸다. "내일 플래닝 전에 5분만 주세요" 이게 핵심이다. 금요일 회의 전에 개발 리드랑 미리 본다. "이 티켓들 다음 스프린트에 넣으려는데, 공수 어떠세요?" 리드가 대략 본다. "이건 3포인트보다 5포인트일 것 같은데요. API 새로 만들어야 해서." 좋다. 미리 알았다. 내일 회의에서 시간 안 뺏긴다. "이건 순서 바꾸면 안 돼요? 인증 기능 먼저 해야 이게 가능해요." 아. 의존성을 놓쳤다. 티켓 순서를 바꾼다. 이 5분이 내일 30분을 아낀다. 플래닝 회의가 1시간 안에 끝난다. 스프린트 골 초안 작성 백로그 정리가 끝났다. 이제 스프린트 골을 쓴다. 막연하게 "기능 개발"이 아니다. 측정 가능하게 쓴다. 이번 스프린트 골 (2주) 1. 회원 정보 수정 기능 배포 (닉네임, 프로필 사진) → 목표: 주 활성 유저 중 10% 이상이 프로필 편집 경험2. 검색 결과 필터링 개선 → 목표: 검색 후 이탈률 현재 45% → 35%로 감소3. 기술부채: 레거시 API 3개 마이그레이션 → 목표: 응답속도 평균 1.2초 → 0.8초구체적이다. 2주 후에 "했다/못했다"가 명확하다. 이걸 컨플루언스에 써둔다. 내일 회의 시작하면서 이걸 먼저 공유한다. "이번 스프린트 우리 목표입니다. 이거 동의하시나요?" 여기서 동의가 나와야 한다. 목표 없이 시작하면 2주 뒤에 "뭐 했지?" 상태다. 커뮤니케이션 사전 정리 8시다. 마지막 단계다. 관련 부서에 헤드업을 준다. 디자인팀 슬랙: "내일 스프린트에 프로필 편집 기능 들어가요. 디자인 시안 최종 컨펌 부탁드려요." 마케팅팀 이메일: "2주 후 검색 필터 개선 배포 예정입니다. 공지 필요하면 말씀해주세요." CS팀 슬랙: "회원정보 수정 기능 다음 스프린트에 개발합니다. 관련 문의 패턴 있으면 공유 부탁드려요." 이렇게 미리 알린다. 스프린트 중간에 "어? 몰랐는데요?" 안 나온다. QA팀한테는 테스트 케이스 초안을 보낸다. 어차피 개발 끝나고 보내면 늦다. 지금 보내서 피드백 받는다. 내일을 위한 체크리스트 노션에 체크리스트를 만든다. [금요일 스프린트 플래닝 준비 완료] ✅ 백로그 우선순위 정렬 (P0 7개, P1 12개) ✅ 큰 티켓 스플릿 완료 (3개 → 9개) ✅ 억셉턴스 크리테리아 작성 ✅ 개발 리드 사전 싱크 완료 ✅ 스프린트 골 초안 작성 ✅ 관련 팀 헤드업 발송 ✅ 의존성 티켓 순서 조정 ⬜ 회의실 예약 확인 (내일 아침)8개 중 7개 체크. 회의실은 내일 아침에 확인한다. 목요일이 금요일을 만든다 8시 반이다. 퇴근한다. 동료가 본다. "백로그 정리해요? 내일 아침에 하면 되는데." 안 된다. 내일 아침은 슬랙 폭탄이다. 목요일 저녁 1시간이 금요일을 결정한다. 준비 안 하고 플래닝 들어가면:티켓 설명하는데 20분 우선순위 토론 30분 "이거 왜 해요?" 질문에 횡설수설 포인트 추정 왔다갔다 회의 3시간, 결론은 애매준비하고 들어가면:스프린트 골 공유 5분 티켓 훑기 20분 포인트 추정 20분 질문 대응 10분 회의 1시간, 모두 명확차이는 목요일 저녁이다. 집에 간다. 내일은 9시 반 출근이다. 9시 50분까지 커피 마시고. 10시 정각에 회의 시작. "이번 스프린트 목표부터 볼까요?" 회의는 딱 1시간 걸릴 것이다. 목요일의 내가 만들어놓은 길이다.목요일의 1시간이 2주를 구한다. 준비는 즉흥을 이긴다.

월요일 아침 데일리 스크럼, 효율적으로 진행하기

월요일 아침 데일리 스크럼, 효율적으로 진행하기

월요일 9시 30분 출근했다. 월요일이다. 팀원들 얼굴이 다 죽어있다. 나도 마찬가지다. 10시에 데일리 스크럼이 잡혀있다. 금요일 6시 이후로 처음 만나는 거다. 주말 동안 슬랙은 조용했다. 평화로웠다. 그런데 지라를 열었다. 티켓 12개가 In Progress 상태다. 금요일에 In Progress였던 그 티켓들이다. 일주일째 같은 자리다.데일리가 길어질 것 같다는 예감이 든다. 15분 회의가 1시간 되는 거. 매주 월요일마다 반복되는 일이다. 15분이 1시간 되는 이유 작년까지는 그냥 진행했다. "어제 뭐 했어요? 오늘 뭐 할 거예요? 블로커 있어요?" 정석대로 물었다. 그런데 월요일은 다르다. "어제"가 금요일이다. 이틀이 지났다. 사람들 기억이 안 난다. 개발자A: "저는... 금요일에... 음... API 작업했던 것 같은데..." 나: "지라 보면서 얘기해주세요." 개발자A: "아 네. 지라 켜볼게요. 잠깐만요." 1분이 지나간다. 개발자B: "저도 지라 로그인이 안 되는데요." 나: "..." 3분이 지나간다. 개발자C: "저는 금요일에 PR 올렸는데 아직 리뷰 안 달렸어요." 개발자D: "아 그거요? 주말에 봤는데 코멘트 남기려고요." 개발자C: "그럼 지금 리뷰해주실 수 있어요?" 개발자D: "지금요? 음... 화면 공유할까요?" 10분이 지나간다. 디자이너: "그 화면 관련해서 제가 금요일에 수정본 올렸는데 확인하셨어요?" 개발자C: "어디 올렸는데요?" 디자이너: "피그마요. 링크 다시 드릴게요." 15분이 지나간다. 이렇게 해서 1시간이 된다. 매주 반복이다. 금요일에 하는 것들 3개월 전부터 바꿨다. 월요일 데일리를 금요일에 준비한다. 금요일 5시쯤 슬랙에 쓴다. "내일 데일리 전 체크 부탁드립니다.이번 주 완료한 티켓 Done으로 변경 다음 주 진행할 티켓 Assignee 확인 블로커 있으면 미리 슬랙 스레드에 공유"처음엔 아무도 안 했다. "금요일 5시에 그걸 왜 해요?" "주말 전인데요." 이해한다. 나도 금요일 5시는 퇴근 모드다. 그래서 이렇게 바꿨다. "다음 주 월요일 데일리 10분 만에 끝내려고 합니다. 금요일에 5분만 투자해주세요. 그럼 월요일 아침 50분 벌 수 있습니다." 계산이 맞다. 금요일 5분 vs 월요일 50분. 팀원들도 동의했다. "그럼 해볼게요."첫 주는 3명만 했다. 두 번째 주는 5명이 했다. 세 번째 주부터는 다 했다. 효과가 보였으니까. 월요일 데일리가 20분으로 줄었다. 월요일 9시 50분에 하는 것 데일리 10분 전이다. 나는 9시 50분에 지라를 연다. 스프린트 보드를 체크한다.Done: 지난주 완료된 티켓들 In Progress: 아직도 진행 중인 것들 (이게 문제다) To Do: 이번 주 할 것들In Progress 티켓을 하나씩 본다. 금요일부터 업데이트 없으면 체크한다. 개발자E 티켓: "로그인 API 연동" Last Updated: 5일 전 Comment: 없음 이건 물어봐야 한다. 진짜 진행 중인지, 잊은 건지. 별도 노트에 적는다. "E님 - 로그인 API 상태 확인" 이렇게 3~4개 나온다. 이것들만 데일리에서 집중적으로 물어본다. 나머지는? "나머지는 지라에 이미 업데이트돼있으니 스킵하겠습니다." 시간이 절반으로 준다. 데일리에서 하지 않는 것 리스트를 만들었다. "데일리에서 절대 하지 않을 것"코드 리뷰 디자인 피드백 새 기능 논의 스펙 확인 버그 재현이건 데일리가 아니다. 별도 시간을 잡는다. 개발자가 "이 부분 어떻게 구현할지 물어보고 싶은데요" 하면. 나: "30분 뒤에 따로 10분 잡을게요." 디자이너가 "피드백 받고 싶은데요" 하면. 나: "화면 공유 필요하죠? 데일리 끝나고 바로 할게요." 처음엔 차갑다고 생각했다. 지금은 모두가 좋아한다. 시간이 명확하니까.데일리는 상태 체크다. "뭐 하고 있고, 막힌 거 있나?" 3분 안에 끝낸다. 세부 논의는 필요한 사람들만. 5명 전체 잡아둘 필요 없다. 블로커는 즉시 "블로커 있어요?" 이 질문이 제일 중요하다. 블로커가 있으면 바로 처리한다. "언제 해결될까요?" 묻지 않는다. "지금 같이 봅시다" 한다. 개발자F: "API 스펙이 명확하지 않아서 못 하고 있어요." 나: "어떤 부분이요?" 개발자F: "request body 구조요." 여기서 멈추면 안 된다. "확인해볼게요" 하면 또 내일이다. 나: "노션 문서 링크 주세요. 지금 같이 보죠." 개발자F: (링크 공유) 나: "이 부분이죠? 이렇게 수정하면 되나요?" 개발자F: "네 그러면 작업 가능합니다." 나: "지금 수정했어요. 확인해주세요." 3분 걸렸다. 이게 월요일에 해결 안 되면. 화요일, 수요일 넘어간다. 스프린트 끝나고 "시간 없었어요" 나온다. 아니다. 월요일에 3분 썼으면 됐다. 타이머는 켠다 15분 타이머를 켠다. 화면에 보이게. "15분 안에 끝내겠습니다." 선언하고 시작한다. 처음엔 "빡빡한 거 아니에요?" 나왔다. "급하게 하면 놓치는 거 있을 수 있어요." 맞는 말이다. 그래서 이렇게 했다. "15분 넘으면 제가 점심 쏩니다." 게임처럼 만들었다. 팀원들 반응이 달라졌다. "15분 안에 끝내야지." 3주 연속 15분 안에 끝났다. 내가 점심 쏜 적 없다. 타이머가 10분 지나면. "5분 남았습니다. 마무리하죠." 남은 사람들 빠르게 돌아간다. 집중도가 올라간다. 월요일이 달라졌다 작년 월요일:데일리 1시간 점심 먹고 지라 정리 오후 2시부터 실제 업무지금 월요일:데일리 15분 10시 15분부터 실제 업무 점심 전에 이미 많이 진행됨4시간이 생겼다. 한 주가 4시간 길어진 거다. 팀원들 만족도도 올랐다. "월요일 아침이 덜 무겁다." "데일리 스트레스가 줄었다." 개발자G는 이렇게 말했다. "예전엔 데일리 때문에 월요일 9시 출근이 싫었어요. 지금은 괜찮아요. 어차피 15분이니까." 효율의 문제가 아니었다. 심리적 부담이었다. 실패한 것들 다 잘된 건 아니다. 시도1: "서서 하는 데일리"목적: 빨리 끝내려고 결과: 다들 불편해함. 2주 만에 포기.시도2: "슬랙으로만 하는 비동기 데일리"목적: 회의 자체를 없애기 결과: 아무도 안 씀. 1주 만에 포기.시도3: "개인별 1분 타이머"목적: 한 명당 1분씩만 결과: 너무 빡빡함. 말 자르게 됨. 3주 만에 포기.지금 방식이 베스트는 아니다. 우리 팀한테 맞는 거다. 다른 팀은 다를 수 있다. 비동기가 맞는 팀도 있다. 30분이 적당한 팀도 있다. 중요한 건 계속 개선하는 거다. "이게 최선이야" 하면 거기서 멈춘다. 월요일 10시 15분 데일리가 끝났다. 13분 걸렸다. 개발자H: "오늘 빨랐네요." 나: "네, 금요일에 다들 준비 잘해주셔서요." 블로커 2개 나왔다. 데일리 끝나고 바로 처리했다. 10분 걸렸다. 10시 25분. 실제 업무 시작이다. 주말 이후 첫 만남치고 나쁘지 않다. 서로 상태 확인했다. 이번 주 방향 맞췄다. 블로커 해결했다. 그리고 무엇보다. 다들 짜증 안 났다. 월요일 아침 1시간짜리 회의. 그거 하나 없애니까. 한 주가 달라진다.월요일 데일리, 준비는 금요일에. 15분 타이머 켜고. 세부 논의는 따로.

기획은 누구나 할 수 있다는 말에 대해

기획은 누구나 할 수 있다는 말에 대해

기획은 누구나 할 수 있다는 말에 대해 어제 들은 말 "기획이요? 솔직히 누구나 할 수 있지 않나요?" 신입 개발자가 던진 말이다. 악의는 없었다. 순수하게 궁금해서 물은 거였다. 나도 안다. 그래도 순간 멍했다. 6년이다. 6년 동안 뭘 배웠나 싶었다. 점심시간에도 그 말이 맴돌았다. 퇴근길에도. 집에 와서도. 그래서 쓴다. 정리하고 싶다. 나한테도 설명하고 싶다.누구나 할 수 있다는 착각 처음 듣는 말은 아니다. 대학생도 말한다. 마케터도 말한다. 심지어 대표님도 가끔. "이거 기획서 간단한데 왜 이렇게 오래 걸려?" 간단해 보인다는 거다. 화면 몇 개 그리고. 버튼 위치 정하고. 그게 전부 아니냐고. 맞다. 결과물만 보면 간단하다. A4 20장. 피그마 파일 하나. 그게 전부처럼 보인다. 근데 그 뒤에 뭐가 있는지 모른다. 안 보인다. 안 보이니까 없는 줄 안다. 작년에 결제 플로우 개선 기획했다. 최종 산출물은 화면 8개. 간단해 보였다. 근데 그 전에:경쟁사 7개 앱 결제 플로우 분석 (이틀) 유저 인터뷰 12건 (일주일) CS 데이터 분석 300건 (사흘) 이탈률 구간별 분석 (이틀) 개발 공수 산정 3번 (각각 다른 방식) 법률 검토 (PG사 담당자 미팅 2번) 디자이너랑 와이어프레임 10번 수정 이해관계자 설득 미팅 4번총 3주 반. 화면 8개 나오는 데 3주 반. 이게 보이나. 안 보인다. 결과물만 본다. 그래서 쉬워 보인다.기획이 아니라 의사결정이다 기획자가 하는 일. 화면 그리는 게 아니다. 의사결정이다. 매일 수십 개 결정한다:이 기능 넣을까 말까 A안 B안 중 뭘 선택할까 이번 스프린트에 들어갈까 우선순위가 높을까 낮을까 개발 공수 대비 효과가 있을까 유저가 진짜 원하는 걸까 비즈니스 목표와 맞을까하나하나가 결정이다. 그리고 각각 근거가 필요하다. "왜 이렇게 기획했어요?" 이 질문에 답해야 한다. 매번. 개발자한테. 디자이너한테. 대표님한테. PM한테. "그냥요"는 없다. "느낌상요"도 없다. 데이터 보여줘야 한다. 로직 설명해야 한다. 지난주 상품 상세 개편 기획했다. 리뷰 섹션을 위로 올릴지 말지. 간단한 결정 같다. 근데:현재 리뷰 클릭률 8.2% 리뷰 본 유저의 구매 전환율 23% (안 본 유저 12%) 스크롤 도달률 상위 3개 섹션 분석 경쟁사 5곳 리뷰 배치 비교 A/B 테스트 시나리오 2가지 개발 공수 각각 3일, 5일이 정도 준비하고 회의 들어간다. 그래야 "그냥 위로 올려보면 어때요?"라는 질문에 답할 수 있다. 누구나 할 수 있나. 이런 결정을. 보이지 않는 6년 1년 차 때는 몰랐다. 화면만 그렸다. 예쁘게 그리면 됐다. 2년 차. 개발자가 물었다. "이거 예외 케이스는요?" 뭔 예외. 그냥 로그인하면 되지. 근데 아니었다:비밀번호 틀리면? 계정 잠금되면? 소셜 로그인 토큰 만료되면? 네트워크 끊기면? 기기 변경했으면? 탈퇴 후 재가입이면?로그인 하나에 경우의 수가 20개였다. 그때 알았다. 기획이 화면 그리기가 아니라는 걸. 3년 차. 데이터 보기 시작했다. SQL 배웠다. 쿼리 짜는 건 못해도 읽을 순 있다. 유저 행동 데이터 보니까 달랐다. 내가 생각한 플로우로 안 움직인다. 메인에서 상세로 간다고 생각했다. 근데 30%는 검색에서 바로 상세로 간다. 20%는 푸시 알림에서. 15%는 URL 직접 접근. 시작점이 다르면 컨텍스트가 다르다. 같은 화면이어도 다르게 기획해야 한다. 4년 차. 우선순위를 배웠다. 다 중요하다. 근데 다 못 한다. 개발 리소스는 한정됐다. 이번 분기 목표는 정해졌다. 뭘 먼저 할까. RICE 스코어링 배웠다. ICE 모델도. 근데 공식만으론 안 됐다. 정치도 있다. 파워게임도. CEO가 원하는 기능. 개발팀이 싫어하는 기능. 유저는 원하는데 매출은 안 나는 기능. 어떻게 조율할까. 어떻게 설득할까. 이게 기획자 일이었다. 5년 차. 실패를 배웠다. 기획한 기능 3개 중 2개는 실패다. 쓰레기 기능 만들었다. 아무도 안 쓴다. DAU 0.8%. 개발 3주 걸렸는데. 왜 실패했나. 가설이 틀렸다. 유저 니즈를 착각했다. 검증 없이 밀어붙였다. 이것도 배움이다. 실패 안 해본 기획자 믿기 힘들다. 6년 차. 지금. 시스템으로 본다. 한 기능이 다른 기능에 영향 준다. 푸시 알림 하나 추가하면:알림 센터 UI 수정 알림 설정 메뉴 추가 푸시 발송 로직 개발 CS 응대 가이드 작성 앱 용량 증가 (SDK 추가) 배터리 소모 테스트 개인정보처리방침 수정하나가 아니다. 연결돼 있다. 전체를 봐야 한다. 이게 6년이다. 보이지 않는 6년.전문성이라는 것 의사가 "의학은 누구나 할 수 있다"고 들으면 어떨까. 변호사가 "법률은 간단하다"고 들으면. 개발자가 "코딩은 쉽다"고 들으면. 화낼 거다. 당연히. 근데 기획자는 참는다. 웃으면서 "네, 쉬워 보이죠"라고 한다. 왜. 왜 우리는 전문성을 주장 못 할까. 코드는 보인다. 복잡함이 보인다. 법률 용어는 어렵다. 의학 용어는 더 어렵다. 근데 기획은 한글이다. 평범한 말로 쓴다. 그래서 쉬워 보인다. 여기에 함정이 있다. 쉬운 말로 복잡한 걸 설명하는 게 기획이다. 어렵게 쓰면 못하는 거다. 좋은 기획서는 중학생도 이해한다. 근데 그 기획서 나오기까지는 중학생이 못 한다. 전문성은 결과물의 복잡함이 아니다. 과정의 깊이다. 설명하는 법을 배워야 한다 어제 그 신입 개발자. 오늘 다시 만났다. "어제 그 말, 기분 나빴으면 미안해요." "아니다. 괜찮다." 근데 괜찮지 않았다. 그래서 말했다. "기획이 쉬워 보이는 거, 이해한다. 근데 한 번 해볼래?" "네? 제가요?" "다음 주 소셜 공유 기능. 기획해봐. 화면 3개면 된다. 간단하다." 얼굴이 굳었다. "저는... 기획 안 해봐서..." "누구나 할 수 있다며." 침묵. 길었다. "농담이다. 근데 진짜 해봐. 도와줄게. 뭐가 어려운지 직접 느껴보면 좋겠다." "...해볼게요." 이게 답이다. 말로 설명 안 된다. 직접 해봐야 안다. 기획자의 전문성. 말로 증명 안 된다. 포트폴리오로 보여줘야 한다. "이 기능 제가 기획했는데요, MAU 30% 올랐어요." "이거 제가 개선해서 이탈률 15% 줄었어요." "A/B 테스트 10번 돌려서 이 안 찾았어요." 숫자로 말해야 한다. 결과로 보여줘야 한다. 그래도 배워야 하는 것들 6년 차인데도 모르는 게 많다. SQL 더 잘하고 싶다. 쿼리 직접 짜고 싶다. 개발자 괴롭히기 싫다. 데이터 분석 더 배우고 싶다. 코호트 분석. 퍼널 분석. 툴만 다루는 게 아니라 인사이트 뽑고 싶다. UX 리서치 제대로 배우고 싶다. 유저 인터뷰 더 잘하고 싶다. 편향 없이 질문하고 싶다. 비즈니스 감각 키우고 싶다. 매출 구조 이해하고 싶다. 단가, 마진, LTV, CAC. 숫자로 말하고 싶다. 개발 프로세스 더 알고 싶다. API 구조. 데이터베이스 설계. 그래야 현실적인 기획 나온다. 배울 게 산더미다. 6년 했는데도. 12년 차 선배 보면 더 멀다. 누구나 할 수 있다고? 6년 배우고도 부족한데. 인정받는 방법 결국 실력이다. 말로 안 된다. 좋은 기획 하나가 백 마디 설명보다 낫다. 성공한 프로젝트 하나가 증명이다. 그래서 열심히 한다. 경쟁사 앱 분석한다. 유저 리뷰 읽는다. 데이터 본다. 주말에 PM 책 읽는다. 온라인 강의 듣는다. 사이드 프로젝트 기획한다. 이게 전문성이다. 계속 배우는 것. 계속 고민하는 것. "기획은 누구나 할 수 있다"는 말. 반은 맞다. 누구나 시작할 수 있다. 맞다. 진입장벽이 낮다. 맞다. 근데 잘하는 건 다르다. 지속하는 건 다르다. 깊이 파는 건 다르다. 누구나 피아노 칠 수 있다. 건반 누르면 소리 난다. 근데 피아니스트는 아무나 못 된다. 누구나 글 쓸 수 있다. 한글 안다. 근데 작가는 아무나 못 된다. 기획도 같다. 누구나 할 수 있다. 근데 잘하는 건 다르다. 오늘의 결론 그 신입 개발자. 사실 고맙다. 질문 던져줘서. 덕분에 정리했다. 내가 뭘 배웠는지. 뭘 하는지. 6년. 길다면 길다. 짧다면 짧다. 근데 분명 배운 게 있다. 의사결정하는 법. 우선순위 정하는 법. 데이터 읽는 법. 사람 설득하는 법. 실패 받아들이는 법. 이게 기획자다. 화면 그리는 사람 아니다. 의사결정하는 사람이다. 내일 출근하면 또 듣겠지. "이거 왜 이렇게 기획했어요?" 괜찮다. 답할 수 있다. 근거 있다. 데이터 있다. 그게 전문성이다. 6년이 준 것. 누구나 할 수 있다고? 해봐. 해보고 말해.기획은 쉽지 않다. 그래서 계속 배운다.

PM이랑 기획자, 결국 뭐가 다른가요?

PM이랑 기획자, 결국 뭐가 다른가요?

PM이랑 기획자, 결국 뭐가 다른가요? 오늘도 받은 질문 점심 먹다가 또 들었다. "너 PM이야? 기획자야?" 남자친구 회사 사람이랑 같이 먹었는데, 그 분이 물었다. 마케터 출신이라 잘 모르신다고. "기획자요. 서비스 기획자." "아, 그럼 PM은 아니고?" "음... 애매한데..." 설명하다가 국 식었다. 이 질문, 올해만 열 번은 받은 것 같다. 면접에서도 물어봤고, 신입 디자이너도 헷갈려했고, 심지어 우리 대표님도 두 단어를 섞어서 쓴다. 퇴근하고 정리해본다. 나한테도, 앞으로 물어볼 사람들한테도.회사마다 다르다는 함정 일단 전제부터. 회사마다 정의가 다르다. 우리 회사는 PM이 따로 있다. 팀장급. 전략 세우고, 로드맵 그리고, 이해관계자 조율한다. 나는 그 아래서 실행 기획한다. 화면 그리고, 스펙 쓰고, 개발팀이랑 붙어있다. 근데 전 회사는 달랐다. 거기선 내가 PM이었다. 기획자라는 타이틀 없이 PM이 전부 했다. 전략부터 실행까지. 스타트업 친구들 보면 또 다르다. 거기선 PM이 코드도 본다. 기획자는 아예 없고. 그러니까 "PM이 뭐고 기획자가 뭐냐"는 회사 조직도부터 봐야 한다. 근데 그래도. 일반적인 차이는 있다. 내가 6년 일하면서 본 패턴. PM은 Why, 기획자는 What & How 제일 많이 쓰는 설명. PM은 "왜 이걸 만드나?"를 고민한다. 기획자는 "뭘, 어떻게 만드나?"를 고민한다. 구체적으로 보자. PM의 하루:사업 목표 확인 (이번 분기 MAU 20% 증가) 유저 데이터 분석 (이탈률이 어디서 튀나) 경쟁사 동향 파악 (저기 새 기능 나왔네) 우선순위 결정 (A 기능 먼저, B는 다음 분기) 로드맵 그리기 (Q1에 이거, Q2에 저거) 이해관계자 설득 (CFO한테 예산 받기, 영업팀이랑 조율)기획자의 하루:PM이 정한 기능 받아오기 유저 플로우 그리기 (로그인부터 결제까지) 화면 정의서 작성 (이 버튼 누르면 이 팝업) 디자이너랑 협업 (이 영역 너무 좁아요) 개발자랑 스펙 논의 (API 어떻게 줄 거예요?) 테스트 케이스 작성 (예외 상황 20가지) QA 참여 (이거 버그 아닌가요?)PM은 숲을 본다. 기획자는 나무를 본다. PM은 지도를 그린다. 기획자는 길을 낸다. 이렇게 말하면 이해가 빠르다.실제 프로젝트에서 작년에 '구독 서비스' 만들 때. PM(우리 팀장님)이 먼저 움직였다. "구독 모델 도입하면 ARPU 30% 올릴 수 있어. 경쟁사는 이미 작년부터 하고 있고, 우리 유저 중 20%는 프리미엄 기능 원한다는 설문 결과 있어. 다음 분기 핵심 과제로 가자." CEO한테 발표했다. 예산 받았다. 개발 리소스 확보했다. 그 다음이 내 차례. "구독 상품 3가지 티어로 갈게요. 베이직, 스탠다드, 프리미엄. 각 티어별 제공 기능 정리했고요, 가격은 9900원, 19900원, 39900원. 첫 결제 플로우는 이렇게, 갱신은 자동으로, 해지는 여기서. 쿠폰 적용 로직은..." 화면 30개 그렸다. 스펙 문서 50페이지 썼다. 개발팀이랑 2주 논의했다. PM은 "구독을 왜 해야 하나"를 증명했다. 나는 "구독을 어떻게 구현하나"를 설계했다. 둘 다 없으면 프로젝트 안 돌아간다. 책임 범위가 다르다 PM은 결과에 책임진다. "이 기능 만들었는데 MAU 안 올랐어요." → PM 문제. "목표 달성 못 했어요." → PM 문제. "예산 초과했어요." → PM 문제. 기획자는 실행에 책임진다. "스펙이 애매해서 개발이 두 번 했어요." → 기획자 문제. "버그가 너무 많이 나왔어요." → 기획자 문제. "런칭 일정 늦었어요." → 기획자 문제. 물론 겹치는 부분도 있다. 근데 최종 책임자는 다르다. 우리 회사 평가 시스템 보면 명확하다. PM 평가 항목:사업 목표 달성률 로드맵 실행률 이해관계자 만족도 시장 대응력기획자 평가 항목:프로젝트 일정 준수 스펙 완성도 크로스 팀 협업 결과물 품질다르다.소통 대상도 다르다 PM이 주로 만나는 사람들:CEO, CFO (전략 보고) 영업팀장 (시장 피드백) 마케팅팀장 (프로모션 조율) 데이터 분석가 (지표 분석) 타 팀 PM (리소스 조율)기획자가 주로 만나는 사람들:개발자 (매일, 하루 종일) 디자이너 (화면 검토, 수정) QA (테스트 케이스) CS팀 (유저 이슈) 다른 기획자 (스펙 리뷰)PM 미팅은 회의실에서 빔프로젝터 켜고. 기획자 미팅은 개발자 자리 가서 모니터 같이 보면서. PM은 파워포인트 많이 만든다. 기획자는 지라 티켓 많이 만든다. 우리 팀장님(PM) 캘린더 보면 미팅이 빡빡하다. 하루 종일 회의. 내 캘린더는 "작업 시간" 블록이 많다. 기획서 쓸 시간 확보해야 해서. 그럼 누가 더 높나요? 이것도 자주 받는 질문. 답은: 직급 체계마다 다르다. 우리 회사는 PM이 리더급이다. 팀장. 기획자는 팀원. 근데 어떤 회사는 PM과 기획자가 동급이다. 역할만 다를 뿐. 또 어떤 곳은 기획자가 시니어 되면 PM으로 전환한다. 높고 낮음이 아니다. 역할이 다른 거다. 축구로 치면 감독이랑 코치 같은 느낌? 감독이 전략 짜면 코치가 선수들이랑 훈련한다. 둘 다 중요하다. 커리어 패스도 다르다 PM 루트:Associate PM → PM → Senior PM → Lead PM → Head of Product → CPO기획자 루트:주니어 기획자 → 기획자 → 시니어 기획자 → 리드 기획자 → (여기서 갈림길) PM으로 전환 기획 스페셜리스트 PO (Product Owner)나는 지금 기획자 4년차에서 시니어 가는 중. 앞으로 선택해야 한다. PM 갈 건지, 기획 깊게 팔 건지. PM 가면: 전략, 사업, 숫자에 집중. 실무는 줄어듦. 기획 유지하면: 계속 손으로 만듦. 깊이는 더 깊어짐. 아직 모르겠다. 둘 다 매력 있다. 필요한 스킬셋 PM한테 필요한 것:비즈니스 감각 (이게 돈이 되나?) 데이터 분석 (숫자로 설득) 전략적 사고 (3년 뒤를 본다) 커뮤니케이션 (CEO부터 인턴까지) 의사결정력 (A와 B 중 고른다)기획자한테 필요한 것:논리적 사고 (플로우가 빈틈없나) 문서화 능력 (스펙 명확히) 디테일 집착 (예외 케이스 20개) 협업 능력 (개발자 언어로 말하기) 실행력 (빠르게 프로토타입)물론 겹치는 것도 많다. 근데 강조점이 다르다. PM은 "설득"을 많이 한다. 기획자는 "조율"을 많이 한다. 내가 기획자인 이유 면접 때 물어봤다. "PM 포지션도 있는데 왜 기획자 지원했어요?" 솔직하게 말했다. "저는 만드는 게 좋아요. 직접 화면 그리고, 플로우 짜고, 개발자랑 논의하면서 완성해가는 거요. 전략은... 아직 자신 없어요. 숫자로 설득하는 것도 배워야 하고요." 붙었다. 3년 지난 지금도 그렇다. 나는 만드는 사람이다. "이 버튼 여기 있으면 유저가 더 편할 텐데." "이 플로우 두 단계 줄일 수 있지 않나?" "여기 로딩 들어가면 답답하니까 스켈레톤 UI로." 이런 거 고민할 때 제일 재밌다. PM 팀장님은 다르다. "이번 분기 핵심 지표가 뭐지?" "경쟁사 저 기능 대응해야 하나?" "개발 리소스 부족한데 우선순위 어떻게 조정하지?" 이런 고민 하신다. 둘 다 필요하다. 근데 나는 전자가 맞다. 협업할 때 PM과 기획자가 잘 맞으면 최강이다. 우리 팀장님이랑 나는 케미가 좋다. 팀장님이 "이번 분기에 리텐션 올릴 기능 필요해. 유저 분석 보니까 3일 차 이탈이 많더라. 여기 온보딩 강화하면 어떨까?" 그럼 나는 "온보딩 튜토리얼 추가할게요. 3단계로 나눠서, 각 단계마다 리워드 주고. 스킵 옵션도 넣고요. 개발 2주면 될 것 같은데, 디자인 리소스 확인해볼게요." 팀장님: "좋아. 근데 리워드 원가 계산 필요하니까 재무팀이랑 먼저 체크해줘." 나: "넵, 내일 미팅 잡을게요." 이게 잘 굴러가는 모습. 근데 어떤 팀은 PM이 너무 디테일까지 관여한다. "이 버튼 색깔은 파란색으로." 그러면 기획자가 할 게 없다. 또 어떤 팀은 PM이 방향만 던지고 사라진다. "알아서 해." 그럼 기획자가 전략까지 짜야 한다. 밸런스가 중요하다. 직무 전환 기획자에서 PM 되는 사람 많다. 우리 회사 Head of Product도 기획자 출신. 실무 경험 쌓고 → 시야 넓히고 → PM 전환. 반대는 드물다. PM에서 기획자로는 잘 안 간다. 이유는 간단하다. PM이 더 시니어 역할이니까. 근데 "더 높다"는 게 아니다. "더 넓다"에 가깝다. 나도 언젠가는 PM 할 것 같다. 근데 아직은 아니다. 지금은 프로토타입 만들고, A/B 테스트하고, 유저 리서치하고 싶다. 손으로 만드는 게 좋다. 채용공고 볼 때 헷갈리는 게 당연하다. 어떤 회사는 PM 공고에 기획자 업무 쓴다. 어떤 회사는 기획자 공고에 PM 역할 요구한다. 그래서 나는 이렇게 본다. 직무명 말고 JD(Job Description) 본다. "전략 수립, 로드맵 기획, 이해관계자 관리" → PM이다. "화면설계, 스펙 작성, 개발 협업" → 기획자다. "둘 다 다 써있으면?" → 스타트업이거나, 애매한 회사다. 면접 때 꼭 물어본다. "PM과 기획자 역할이 어떻게 나뉘어 있나요?" "제가 맡을 주요 책임은 뭔가요?" "의사결정권은 어디까지인가요?" 이거 안 물어보면 입사해서 혼란스럽다. 대외적으로 소개할 때 명함에 뭐라고 쓰나 고민했다. "Service Planner" "Product Manager" "Product Owner" 다 써봤다. 지금은 "Service Planner"로 통일. 영어로는 "Product Planner" 쓴다. 해외에서 PM은 프로덕트 매니저를 의미하니까. 혼동 피하려고. 링크드인 프로필도 명확히 했다. "Responsible for feature planning, user flow design, and cross-functional collaboration. Working closely with developers and designers to ship products." 이렇게 쓰면 대충 이해한다. 결론 PM과 기획자, 뭐가 다른가? PM은 전략과 결과에 집중한다. 기획자는 실행과 품질에 집중한다. 회사마다 정의는 다르다. 근데 본질은 비슷하다. PM은 나침반을 잡는다. 기획자는 항해를 한다. 둘 다 없으면 배는 못 간다. 높고 낮음이 없다. 필요한 역할이 다를 뿐. 나는 항해하는 게 좋다. 바람 읽고, 돛 조정하고, 암초 피하고. 목적지는 PM이 정해준다. 가는 길은 내가 만든다. 그게 내 일이다."PM은 Why, 기획자는 What & How. 둘 다 필요하다."