왜 기획서는 계속 수정될 수밖에 없나

왜 기획서는 계속 수정될 수밖에 없나

왜 기획서는 계속 수정될 수밖에 없나 오늘도 기획서를 고친다 출근했다. 슬랙 알림 37개. "K님, 어제 회의에서 말씀하신 플로우인데요, 이거 로그인 없이도 가능한 거 맞죠?" 아니다. 로그인 필수라고 했다. 분명히. 회의록 찾아봤다. 내가 잘못 적었다. 로그인 "선택"이라고 적혀 있다. 기획서 열었다. v2.3이다. 수정한다. v2.4가 된다. 9시 반인데 벌써 첫 수정이다.어제 대표님이 말했다. "이 기능, 경쟁사는 이렇게 하던데요?" 경쟁사 앱 켰다. 확인했다. 우리랑 다르다. 대표님: "우리도 이렇게 가는 게 어때요?" 나: "...검토해볼게요." 기획서 수정. v2.5. 오전 10시. 완벽한 기획서는 왜 없나 신입 때는 몰랐다. "기획서 완벽하게 작성하면 수정 안 하겠지." 6년 차가 되어서 안다. 불가능하다. 이유는 세 가지다. 첫째, 사람은 글보다 화면을 보고 의견이 바뀐다. 기획서 단계: "네, 좋습니다." 디자인 시안 단계: "근데 이거 좀 이상한데요?" 개발 완료 단계: "이거 아닌 것 같은데요." 당연하다. 인간은 시각적 동물이다. 글로 "버튼이 우측 하단에 위치"라고 쓰면 모두가 상상한다. 각자 다른 버튼을. 시안이 나오면 그제야 의견이 나온다. "생각보다 크네요", "색이 튀네요", "위치가 애매한데요". 개발자는 더하다. "이거 스크롤 안에 고정인가요, 밖에 있나요?" 기획서에 분명히 적었다. 하지만 각자 해석이 다르다. 수정한다. v2.6.둘째, 요구사항은 살아 움직인다. 월요일: 마케팅팀 "이벤트 배너 하나만 넣어주세요." 화요일: 마케팅팀 "배너 두 개로 늘려주세요." 수요일: 마케팅팀 "배너 슬라이드 형식으로요." 목요일: 마케팅팀 "자동 재생 되게요." 나: "..." 기획서는 그때마다 바뀐다. v2.7, v2.8, v2.9. 개발자가 묻는다. "스펙 확정된 거죠?" 나: "네, 확정이에요." 금요일: 마케팅팀 "배너 클릭하면 팝업이 뜨게..." 나: "..." 개발자: "..." 이게 현실이다. 셋째, 내가 놓친 게 있다. 기획서 쓸 때는 완벽하다고 생각한다. 모든 케이스를 다 적었다. 개발 들어간다. 개발자가 묻는다. "인터넷 끊겼을 때는요?" "동시에 두 명이 수정하면요?" "글자 수 제한은요?" "특수문자 입력은요?" "iOS랑 안드로이드 다르게 가나요?" 아. 생각 못 했다. 기획서 수정. v2.10, v2.11, v2.12. 그럼 처음부터 완벽하게 쓰면 되지 않나 안 된다. 시도해봤다. 신입 때. 기획서 50페이지 작성했다. 모든 예외 케이스 적었다. 엣지 케이스까지. 검토 회의 잡았다. 1시간 예정. 5분 만에 끝났다. 대표님: "너무 길어요. 핵심만 보여주세요." 개발자: "이거 다 읽을 시간 없는데요." 디자이너: "화면 정의서만 주시면 안 돼요?" 50페이지 기획서. 아무도 안 읽었다. 다시 썼다. 10페이지로. 핵심만. 질문이 쏟아졌다. "이 경우는요?", "저 경우는요?" 답했다. 기획서 수정했다. v1.1, v1.2, v1.3... 결론: 처음부터 완벽한 기획서는 불가능하다.그럼 어떻게 써야 하나 깨달았다. 3년 차쯤. 기획서는 "문서"가 아니다. "대화"다. 버전 1.0은 시작점이다. 완성본이 아니다. 중요한 건 두 가지다. 하나, 핵심은 흔들리지 않게. 수정되어도 괜찮은 것:UI 디테일 (버튼 위치, 색상, 크기) 텍스트 문구 예외 케이스 처리 방식 인터랙션 세부사항흔들리면 안 되는 것:이 기능의 목적 타겟 유저 해결하려는 문제 핵심 플로우예를 들어. 우리가 만드는 건 "쉬운 결제 기능"이다. 이건 안 바뀐다. 하지만 "결제 버튼이 파란색이냐 빨간색이냐"는 바뀔 수 있다. "카드 정보를 저장하느냐 마느냐"도 바뀔 수 있다. 하지만 "쉬운 결제"라는 목적은 안 바뀐다. 기획서 첫 페이지에 적는다. 목적: 3번의 탭으로 결제 완료 타겟: 40대 이상 비결제 전환 유저 문제: 현재 평균 7번의 탭 필요, 중간 이탈률 60% 성공 지표: 평균 탭 수 3회 이하, 이탈률 30% 이하이건 회의 때마다 보여준다. 누가 뭐라고 해도 이걸 기준으로 판단한다. "버튼 색 바꾸자" → 탭 수에 영향 없다 → OK "추가 인증 넣자" → 탭 수 늘어난다 → NO 명확해진다. 둘, 수정 이력을 남긴다. Confluence 쓴다. 버전 히스토리 남는다. 중요한 변경은 코멘트 단다. v2.4 → v2.5: 로그인 필수에서 선택으로 변경 사유: 테스트 유저 피드백, 비로그인 전환율 2배 높음 영향: 개발 공수 3일 추가, 릴리즈 일정 유지 가능 승인: 대표님, 개발팀장이렇게 적으면 나중에 "왜 이렇게 했죠?"라는 질문에 답할 수 있다. 히스토리가 있으면 신뢰가 생긴다. "K님 기획서는 변경 사유가 명확해요." 이 말 들으면 기분 좋다. 수정은 실패가 아니다 예전에는 기획서 수정할 때마다 자괴감 들었다. "내가 기획을 못하나." "처음부터 왜 이걸 생각 못 했지." "개발자한테 미안하다." 지금은 안다. 수정은 당연하다. 수정이 없는 기획서는 두 가지다.아무도 안 읽는 기획서 아무도 관심 없는 기능수정이 많다는 건 사람들이 관심 있다는 거다. 의견이 나온다는 건 함께 만들고 있다는 거다. 물론 한계는 있다. 개발 들어간 후 핵심 플로우 변경: 안 된다. 대표님이 갑자기 다른 기능 추가: 우선순위 논의 필요. 마케팅팀이 매일 배너 스펙 변경: 한 번에 정리하자고 말한다. 경계는 그어야 한다. 하지만 유연해야 한다. 균형이다. 지금도 기획서를 고친다 오늘 오후 4시. 디자이너가 묻는다. "이 버튼, 비활성 상태 디자인 있나요?" 기획서 본다. 없다. 추가한다. v2.16. 오후 5시. 개발자가 묻는다. "에러 메시지 문구 뭐로 할까요?" 기획서 본다. 대충 적혀 있다. "오류가 발생했습니다." 구체적으로 수정한다. "네트워크 연결을 확인해주세요." v2.17. 오후 6시. QA팀에서 이슈 올린다. "로딩 중일 때 버튼 비활성화 안 되어 있어요." 기획서 확인한다. 누락됐다. 추가한다. "로딩 중 버튼 비활성화, 스피너 표시" v2.18. 퇴근 전 커밋 로그 본다. 개발자가 질문 없이 구현한 부분이 보인다. 기획서와 다르다. 근데 더 낫다. 개발자한테 묻는다. "이거 왜 이렇게 하셨어요?" 개발자: "이렇게 하면 코드가 더 깔끔해서요. 사용자 경험은 똑같고요." 확인한다. 맞다. 더 낫다. 기획서 수정한다. 구현된 대로. v2.19. 퇴근한다. 오늘 기획서 수정 11번. 내일도 수정할 것이다. 수정되는 기획서, 흔들리지 않는 방향 기획서는 계속 바뀐다. 바뀔 수밖에 없다. 사람들의 생각이 모이는 과정이니까. 더 나은 방법을 찾는 과정이니까. 현실을 반영하는 과정이니까. 중요한 건 방향이다. 목적이 명확하면 수정해도 괜찮다. 핵심이 흔들리지 않으면 디테일은 바뀔 수 있다. 완벽한 기획서는 없다. 하지만 계속 나아지는 기획서는 있다. v1.0에서 v2.19로. 그리고 내일의 v2.20으로.퇴근했다. 내일 또 수정한다. 괜찮다.

Notion을 기획팀의 뇌로 만드는 방법

Notion을 기획팀의 뇌로 만드는 방법

Notion을 기획팀의 뇌로 만드는 방법 지라는 개발, 노션은 기획 개발팀은 지라를 산다. 티켓 단위로 움직이고, 스프린트로 숨 쉰다. 깔끔하다. 근데 기획팀은? 우리 자산은 어디 있지? 피그마 링크는 슬랙 어딘가, 회의록은 컨플루언스, 기획서는 구글독스, 레퍼런스는 북마크 500개. 찾으려면 30분. "그때 그 기획서 어디 있죠?" 이 질문에 매번 검색창을 연다. 비효율의 극치다. 3개월 전 결정했다. 노션을 기획팀의 뇌로 만들겠다고. 모든 기획 자산을 한곳에.지금 우리 팀 노션은 살아있다. 신입이 와도 3일이면 적응한다. 과거 기획 의도를 찾는 데 5분이면 충분하다. 어떻게 만들었나. 구체적으로 공유한다. 노션 구조부터 잡아야 한다 처음엔 페이지만 마구 만들었다. 3주 후 쓰레기장이 됐다. 구조가 없으면 노션도 혼돈이다. 우리 팀 구조는 이렇다. 1단계: Product (제품별)앱 A, 웹 B, 내부 툴 C 제품 단위로 최상위 분류2단계: Area (영역별)기획 자산 회의록 분석 자료 레퍼런스3단계: Type (문서 타입)기획서 PRD (Product Requirements Document) 유저 플로우 와이어프레임 링크예를 들면 이렇다. 📱 앱 A └ 📋 기획 자산 └ 🎯 2024 Q1 로그인 개편 PRD └ 📝 회의록 └ 2024-01-15 로그인 개선 회의 └ 📊 분석 자료 └ 경쟁사 로그인 플로우 분석처음엔 복잡해 보인다. 근데 2주 쓰면 자동으로 손이 간다.핵심은 일관성이다. 모든 기획서가 같은 템플릿을 따른다. 찾기 쉽다. 템플릿이 생산성을 결정한다 매번 기획서를 백지에서 시작하면 지친다. 템플릿을 만들었다. PRD 템플릿 구조: ## 📌 한 줄 요약 (30자 이내로 이 기획의 핵심)## 🎯 목표 - 비즈니스 목표 - 유저 목표 - 핵심 메트릭 (MAU +10%, 전환율 +5%)## 🤔 문제 정의 - 현재 상황 (AS-IS) - 문제점 (데이터 기반) - 유저 페인 포인트## 💡 솔루션 - 개선 방향 (TO-BE) - 핵심 기능 3가지 - 우선순위와 이유## 🗺️ 유저 플로우 (피그마 링크 또는 임베드)## 📋 기능 명세 | 기능 | 설명 | 우선순위 | 공수 | |------|------|----------|------|## 🔗 관련 자료 - 지라 에픽 링크 - 디자인 시안 - 분석 보고서 - 참고 레퍼런스## 📅 일정 - 기획 완료: 2024-02-01 - 개발 시작: 2024-02-05 - QA: 2024-02-26 - 릴리즈: 2024-03-04## ✅ 체크리스트 - [ ] 개발팀 리뷰 - [ ] 디자인팀 싱크 - [ ] 데이터팀 메트릭 셋업 - [ ] QA 시나리오 작성## 💬 Discussion (팀원 코멘트, Q&A)이 템플릿을 노션 데이터베이스로 만들었다. 새 기획서는 'New' 버튼 하나.개발팀이 좋아한다. "이전보다 스펙이 명확해졌어요." 이 말을 들으면 보람 있다. 데이터베이스로 관리해야 산다 노션의 진짜 힘은 데이터베이스다. 페이지만 쌓으면 죽은 문서. 데이터베이스로 만들면 살아 움직인다. 우리 팀 핵심 DB 3개. 1. 기획 자산 DB프로퍼티: 제품, 상태, 담당자, 분기, 우선순위, 지라 링크 뷰: 진행 중, 완료, 분기별, 담당자별 필터: 내가 담당한 것만, Q1 기획만매주 월요일 스크럼 때 '진행 중' 뷰를 본다. 누가 뭘 하는지 한눈에. 2. 회의록 DB프로퍼티: 날짜, 참석자, 태그(기획/개발/디자인), 관련 PRD 자동으로 최신순 정렬 태그로 검색하면 관련 회의 다 나옴"저번에 로그인 관련 회의록 어디 있죠?" → 태그 '로그인' 클릭. 3초. 3. 레퍼런스 DB경쟁사 분석, 벤치마킹, 영감 자료 프로퍼티: 플랫폼, 카테고리, 한 줄 메모 갤러리 뷰로 보면 시각적으로 좋다새 기획 시작할 때 여기서 먼저 찾는다. 바퀴를 다시 발명하지 않는다. 뷰를 잘 쓰면 같은 DB가 5개 용도로 쓰인다. 테이블 뷰, 보드 뷰, 캘린더 뷰. 상황에 맞게. 지라와 연결해야 완성이다 노션만 쓰면 반쪽이다. 개발팀은 지라를 산다. 연결이 답이다. 우리 방식: 1. PRD에 지라 에픽 링크 필수 모든 기획서 맨 위에 지라 에픽 URL. 클릭 한 번에 개발 상황 확인. 2. 지라 티켓에 노션 PRD 링크 역으로 지라 에픽 Description에 노션 PRD URL 붙인다. 개발자가 맥락을 이해한다. 3. 일정 동기화 노션 PRD의 일정 섹션과 지라 스프린트 일정 맞춘다. 수동이긴 한데 매주 월요일 10분 투자. 4. 상태 동기화는 포기 자동 동기화 시도했다. Zapier, Make 다 써봤다. 결론: 번거롭다. 수동으로 주 1회 업데이트가 현실적이다. 개발자 입장: "기획 의도는 노션, 구현 스펙은 지라" 내 입장: "큰 그림은 노션, 세부 태스크는 지라" 역할 분담이 명확하니 충돌 없다. 검색이 되어야 쓸모있다 자료를 쌓아도 못 찾으면 소용없다. 노션 검색을 제대로 쓰는 법. 1. 제목 규칙 통일나쁜 예: "로그인 기획", "로그인 개선" 좋은 예: "[앱A] 2024 Q1 로그인 개편 PRD"제품명, 분기, 키워드 포함. 검색 한 방에 뜬다. 2. 태그 시스템 프로퍼티에 '태그' 필드 만들어서 일관되게 붙인다.#인증 #결제 #홈화면 #온보딩 태그 검색하면 관련 문서 다 나옴3. 관계형 연결 PRD에서 회의록 연결, 회의록에서 분석 자료 연결. Relation 프로퍼티 활용. 한 문서에서 관련 자료까지 타고 들어간다. 맥락을 잃지 않는다. 4. 자주 쓰는 거 즐겨찾기 사이드바에 자주 보는 DB 고정. 클릭 횟수 줄인다. 검색창 단축키 Cmd+K (윈도우는 Ctrl+K). 손에 익히면 마우스 안 쓴다. 팀원들이 안 쓰면 의미없다 혼자 열심히 해도 팀원이 안 쓰면 실패다. 우리 팀 정착 과정. 1주차: 저항 "또 새로운 툴이야?" "컨플루언스 있는데?" 반발 있었다. 2주차: 템플릿 공유 PRD 템플릿 하나 만들어서 내가 먼저 써봤다. 공유하니 "이거 편한데?" 반응 나왔다. 3주차: 같이 만들기 회의 때 노션 화면 공유하면서 실시간으로 회의록 작성. 다같이 보니 집중도 올라갔다. 4주차: 루틴화 매주 월요일 스크럼 = 노션 '진행 중' 뷰 리뷰 회의 끝나면 = 노션에 회의록 바로 작성 루틴이 되니 습관이 됐다. 핵심은 강요 말고 편리함 보여주기. "노션 안 쓰면 안 돼!" → 반발 "이렇게 하니까 찾기 쉽더라" → 자발적 참여 지금은 신입이 와도 자동으로 노션 쓴다. 문화가 됐다. 유지보수도 기획이다 노션을 만들어놓고 끝이 아니다. 관리 안 하면 다시 쓰레기장 된다. 우리 팀 관리 방식: 매주 금요일 오후 4시: 정리 타임안 쓰는 페이지 아카이브 태그 정리 링크 깨진 거 수정 30분 투자분기마다: 구조 리뷰이 구조가 여전히 효율적인가? 불필요한 DB는 없나? 새로운 니즈는?3개월마다 한 번씩 개선한다. 작은 변화들이 쌓인다. 담당자 지정 우리 팀은 돌아가면서 '노션 지기' 한다. 1주일씩. 그 주는 내가 노션 관리 책임. 주인의식 생긴다. "내 주엔 깔끔하게 유지해야지" 생각하게 된다. 방치하면 죽는다. 꾸준히 손봐야 산다. 3개월 후 달라진 것들 노션 시스템 정착 후 체감하는 변화들. 회의 시간 30% 감소 "지난번에 뭐라고 했죠?" 질문이 사라졌다. 회의록 검색하면 나온다. 기획서 작성 시간 단축 템플릿 덕분에 백지 공포 없다. 구조만 채우면 된다. 평균 2시간 절약. 신입 온보딩 빨라짐 과거엔 일주일 걸렸다. 지금은 "노션 여기 보세요" 하면 3일. 개발팀과 소통 개선 "스펙이 명확하지 않아요" 지적 80% 감소. PRD 구조가 잡혀있으니까. 내 스트레스 감소 "그거 어디 있죠?" 질문에 더 이상 헤매지 않는다. 검색하면 나온다. 의사결정 속도 향상 과거 데이터 찾기 쉬워서 "저번에 왜 A안 선택했죠?" 질문에 바로 답한다. 숫자로 증명하긴 어렵다. 근데 체감은 확실하다. 팀이 더 매끄럽게 돌아간다. 실패했던 것들도 공유한다 완벽하지 않다. 시행착오도 많았다. 실패 1: 너무 복잡한 구조 처음엔 5단계 깊이로 만들었다. 찾기 힘들었다. 3단계로 줄였다. 실패 2: 자동화 집착 Zapier로 지라-노션 완전 자동화 시도. 셋업에 일주일, 유지보수 지옥. 수동이 낫다. 실패 3: 모든 걸 노션에 슬랙 대화, 이메일까지 다 옮기려 했다. 무리다. 핵심 자산만 노션에. 실패 4: 권한 관리 소홀 모두에게 편집 권한 줬더니 중요 페이지 실수로 삭제됨. 템플릿은 읽기 전용으로. 실패 5: 완벽주의 완벽한 구조 만들려고 2주 소비. 결국 쓰면서 개선하는 게 빠르다. 실패도 자산이다. 다음엔 안 실수한다. 노션은 도구일 뿐이다 노션을 쓴다고 기획이 잘되는 건 아니다. 도구일 뿐. 중요한 건:기획 자산을 정리하는 습관 팀과 공유하는 문화 과거를 참고하는 자세노션은 이걸 쉽게 만들어줄 뿐이다. 우리 팀 슬랙에 이런 메시지 올라왔다. "예전엔 기억에 의존했는데, 이제 노션에 의존해요. 훨씬 믿음직스럽죠." 기획팀의 뇌를 외부화한 거다. 개인 기억에서 팀 기억으로. 지라가 개발팀 워크플로우라면, 노션은 기획팀 지식 베이스다. 당신 팀 기획 자산, 어디 흩어져 있나? 한번 모아봐. 3개월 후 달라진 걸 느낀다.노션 정리하니 머리가 가벼워졌다. 찾는 시간이 줄어든 게 제일 크다. 이제 기획에 집중한다.

대표님이 갑자기 던지는 피처 요청에 대처하는 법

대표님이 갑자기 던지는 피처 요청에 대처하는 법

대표님이 갑자기 던지는 피처 요청에 대처하는 법 목요일 오후 3시, 슬랙 폭탄 "K님, 30분 뒤에 대표님이랑 회의 잡혔어요." 마케팅팀장 메시지다. 갑자기? "무슨 안건이에요?" "글쎄요, 대표님이 갑자기 보자고." 이런 메시지 받으면 심장이 쿵 내려앉는다. 경험상 좋은 소식은 없다. 서둘러 맥북 챙기고 회의실로 갔다. 대표님은 이미 와 있었다. 노트북 켜놓고 뭔가 보고 계셨다. "앉아요. K님, 이거 봤어요?" 경쟁사 앱 화면이었다. 새로 업데이트된 피처. 소셜 공유 기능. "네, 어제 업데이트됐더라고요." "우리도 이거 해야 할 것 같은데. 다음 스프린트에 넣을 수 있어요?"이미 시작된 스프린트 머릿속이 하얘졌다. 다음 스프린트? 지금 현재 스프린트도 빡빡한데. "대표님, 지금 진행 중인 게 결제 시스템 개편이고, 다음 스프린트는 알림 개선으로 확정됐는데..." "그게 우선순위가 높나요? 경쟁사는 이미 했는데." 이 순간 기획자는 두 가지 선택지가 있다. 첫 번째, "네, 알겠습니다" 하고 개발팀한테 가서 죄송하다고 하기. 두 번째, 지금 논리적으로 설득하기. 나는 두 번째를 택했다. 항상은 아니지만, 오늘은 할 수 있을 것 같았다. "대표님, 10분만 시간 주시면 현재 상황 공유드릴게요." 맥북을 열었다. 지라 보드를 띄웠다. 숫자로 말하기 "지금 진행 중인 스프린트 번다운 차트입니다." 그래프를 보여드렸다. 예정보다 속도가 느렸다. "결제 시스템은 이번 분기 핵심 목표였고, 지금 70% 진행됐어요. 여기에 새 피처 넣으면 일정이 최소 2주 밀립니다." 대표님이 그래프를 보셨다. "그럼 알림 개선을 미루고?" "가능은 한데, 알림 개선은 CS 문의 30% 감소 목표예요. 지금 하루 100건 넘게 들어와요." 숫자를 말했다. 100건. 구체적으로. "소셜 공유는 어느 정도 임팩트 예상하세요?" 대표님 질문이었다. 예상했던 질문. "경쟁사 사례 찾아봤는데, MAU의 5% 정도가 사용하더라고요. 우리 기준으로 월 1500명 정도. 알림 개선은 전체 유저 3만 명에게 영향 줍니다." 1500명 vs 3만 명. 숫자는 강력하다.대안 제시하기 "하지만 소셜 공유가 중요한 건 맞아요." 아니라고만 하면 안 된다. 대표님 의견을 무시하는 게 아니라, 더 나은 방법을 찾는 거다. "MVP로 먼저 가면 어떨까요? 카카오톡 공유만. 개발 2일이면 됩니다." 개발팀장이랑 미리 얘기해뒀다. 이런 상황 올 줄 알았으니까. "전체 소셜 공유는 다다음 스프린트에 제대로 기획해서 넣고요." 대표님이 고개를 끄덕였다. "그게 나을 것 같네요. 카카오톡만 우선." 일단 고비는 넘겼다. "그런데 K님, 이런 요청 자주 들어오면 어떻게 해요?" 솔직하게 말했다. "스트레스받죠. 근데 이해는 돼요. 시장이 빠르게 움직이니까." 대표님이 웃으셨다. "미안해요. 근데 우리가 이렇게라도 안 하면 뒤처지잖아요." "알아요. 그래서 제가 우선순위 판단 기준을 만들고 있어요." 우선순위 프레임워크 회의 끝나고 자리로 돌아왔다. 노션을 켰다. 며칠 전부터 만들고 있던 문서. "피처 우선순위 판단 기준" 4가지 축이었다.비즈니스 임팩트 (매출/전환율) 사용자 수 (몇 명이 쓸 것인가) 개발 공수 (얼마나 걸리나) 전략적 중요도 (장기 로드맵)각 항목에 1~5점. 총 20점 만점. 소셜 공유를 넣어봤다.비즈니스 임팩트: 2점 (직접 매출 연결 약함) 사용자 수: 2점 (5% 정도 사용) 개발 공수: 3점 (2주 소요, 역순) 전략적 중요도: 3점 (있으면 좋지만 필수는 아님)총 10점. 20점 만점에 10점이면 중간. 알림 개선은?비즈니스 임팩트: 4점 (CS 비용 감소) 사용자 수: 5점 (전체 유저) 개발 공수: 3점 (2주 소요) 전략적 중요도: 4점 (리텐션 개선)총 16점. 훨씬 높다. 이 프레임워크를 대표님한테 공유했다. 슬랙으로. "다음부터 새 요청 들어오면 이 기준으로 평가해보면 어떨까요?" 답장이 왔다. "좋네요. 다음 주 전사 회의 때 공유해주세요."다음 날 아침, 개발팀과 "어제 대표님이랑 회의했어." 개발팀장이 먼저 물었다. "또 뭐 추가하래?" "응. 소셜 공유." 한숨 소리가 들렸다. "근데 일단 카카오톡만 하기로 했어. 2일이면 되지?" "2일? 그 정도면 괜찮은데." "다음 스프린트에 제대로 넣을게. 지금은 MVP." 개발팀장이 고마워했다. "네가 막아줘서 다행이야. 안 그랬으면 또 일정 터졌을 거야." 막는 게 아니다. 조정하는 거다. "나도 대표님 입장 이해해. 경쟁사 보면 불안하잖아." "그래도 현실을 알아야지. 2주짜리를 3일 만에 하라는 건..." "맞아. 그래서 내가 숫자로 보여드렸어. 임팩트랑 공수." 기획자의 역할이 여기 있다. 비즈니스와 개발 사이. 둘 다 이해하고, 둘 다 설득해야 한다. 2주 후, 회고 스프린트 회고 시간이었다. "이번 스프린트는 어땠어요?" 개발자 한 명이 말했다. "갑작스러운 변경이 적어서 좋았어요." 디자이너도. "카카오톡 공유 디자인도 빠르게 나왔고." 대표님도 참석하셨다. "다음에도 이렇게 우선순위 기준 가지고 판단하죠. K님이 만든 프레임워크 좋더라고요." 뿌듯했다. 하지만 여기서 끝이 아니다. 다음 주에도, 다다음 주에도 갑작스러운 요청은 올 거다. 그때마다 이 과정을 반복해야 한다. 숫자로 말하기. 대안 제시하기. 팀 설득하기. 기획자의 생존 전략 정리하면 이렇다. 1. 항상 백업 플랜을 가져라 갑작스러운 요청? 이미 예상했다. MVP 버전 생각해놨다. 2. 숫자로 무장하라 "중요해요"보다 "3만 명에게 영향 줍니다"가 강하다. 3. 거절하지 말고 조정하라 "안 됩니다"가 아니라 "이렇게 하면 됩니다". 4. 프레임워크를 만들어라 주관적 판단을 객관적 기준으로. 그래야 설득력 있다. 5. 개발팀을 먼저 챙겨라 그들이 지치면 아무것도 안 된다. 그들의 편이 돼라. 지난주 금요일이었다. 퇴근하면서 개발팀장이 말했다. "요즘 K님 덕분에 일하기 편해졌어." "무슨 소리야." "예전엔 대표님 요청 그냥 내려왔잖아. 지금은 네가 필터링해주니까." 필터링. 맞다. 기획자는 필터다. 모든 요청을 그대로 통과시키는 게 아니라, 중요한 것만 골라내는. 그게 우리 역할이다. 집에 가는 지하철에서 생각했다. 다음에 또 갑작스러운 요청 오면? 숫자 찾고, 대안 만들고, 설득할 거다. 매번 그렇듯이. 그게 기획자니까.갑작스러운 요청은 막을 수 없다. 조정할 수 있을 뿐이다.

팀원 300명 회사의 조직 문화 - 스타트업 vs 중견기업

팀원 300명 회사의 조직 문화 - 스타트업 vs 중견기업

팀원 300명 회사의 조직 문화 - 스타트업 vs 중견기업 300명이라는 애매한 숫자 우리 회사 직원이 300명이다. 스타트업이라고 하기엔 크고, 중견기업이라고 하기엔 작다. 시리즈 B 받고 3년째다. 채용 공고에는 "스타트업의 역동성과 안정성을 모두"라고 쓴다. 입사하고 보니 둘 다 반쪽이다. 스타트업처럼 빠르지도, 대기업처럼 체계적이지도 않다. 예전 회사는 50명이었다. 대표님이 내 자리까지 왔다. "K님, 이거 어떻게 생각해요?" 3초 만에 결정났다. 지금은 다르다. 대표님 얼굴 본 지 두 달됐다. 결정은 회의 3번 거쳐야 난다.의사결정의 속도 50명 회사 때. 기능 추가 제안했다. 대표님한테 슬랙 보냈다. 30분 후 "ㄱㄱ" 답장 왔다. 다음 날 개발 들어갔다. 일주일 후 배포됐다. 실패하면? 다시 빼면 됐다. 지금은? 기획서 쓴다. 5페이지. 팀장님께 보고한다. "임원진 공유해볼게요." 일주일 후. "전략실이랑 먼저 얘기해보래요." 전략실 미팅 잡는다. 2주 걸린다. 미팅 가면 질문 폭탄이다. "시장 규모는요?" "경쟁사 벤치마크는요?" "예상 MAU는요?" 답변서 쓴다. 10페이지 됐다. 다시 검토 들어간다. "데이터팀이랑 검증 필요해요." 한 달 지났다. 아직 개발 안 들어갔다. 그새 경쟁사가 비슷한 거 냈다.협업의 복잡도 50명 때는 단순했다. 기획자 3명, 개발자 15명, 디자이너 4명. 다 알았다. 이름도, 성향도. "민수님 이거 가능해요?" "어, 2일이면 돼요." 끝이었다. 지금은? 서비스기획팀 8명. 개발본부 80명. 4개 팀으로 나뉨. 디자인실 12명. 앱, 웹, 브랜드로 분리. 기능 하나 추가하려면. 먼저 어느 팀 업무인지 파악한다. 백엔드인지, 프론트인지, 둘 다인지. 그 다음 담당자 찾는다. 지라에서 이름 검색한다. 조직도 열어본다. 슬랙 DM 보낸다. "안녕하세요, 서비스기획팀 K입니다." 처음 보는 사람이니까 정중하게. 답장이 온다. "저희 팀 업무 아닌 것 같은데요." "XX팀 YY님께 여쭤보세요." YY님 찾는다. 또 DM 보낸다. 이게 3번 반복된다. 결국 찾았다. "이거 공식 요청으로 올려주세요." 지라 티켓 생성한다. 기획서 첨부한다. 스펙 명세서도 쓴다. 우선순위 협의한다. 백로그 쌓인다. 일정 조율한다. 다른 팀 일정이랑도 맞춰야 한다. 미팅 잡는다. 참석자가 6명이다. 30분 회의에 6시간 투입되는 셈이다.정치의 시작 50명 때는 정치가 없었다. 다 똑같이 바쁘고 똑같이 야근했다. 목표도 하나였다. 살아남기. 300명은 다르다. 부서가 생겼다. 부서마다 이해관계가 다르다. 서비스기획팀은 신기능 원한다. 개발팀은 안정화 원한다. CS팀은 버그 수정 원한다. 다들 우선순위가 다르다. 회의 때 티격태격한다. "이건 우리가 먼저예요." 임원진도 쪼갠다. CTO는 기술 부채 해결 밀어붙인다. CPO는 신규 피처 요구한다. 중간에 낀 우리는? 눈치 본다. 어느 쪽이 더 센지. 어떤 팀은 예산 많다. 어떤 팀은 헤드카운트 늘어난다. 우리 팀은? 그대로다. 불만 쌓인다. "왜 저 팀만 지원해줘요?" 커피챗에서 푼다. 누가 승진했다는 소식 들린다. 내가 아는 그 사람이다. 일은 나만큼 안 했는데. "발표를 잘하더라." "임원진이랑 친하더라." 이런 말이 돈다. 나도 모르게 계산한다. 이 프로젝트 하면 누구한테 보일까. 이 회의엔 누가 참석할까. 예전엔 안 그랬다. 일만 잘하면 됐다. 이제는 보여줘야 한다. 프로세스라는 이름의 족쇄 50명 때는 프로세스가 없었다. 필요하면 만들었다. 불편하면 바꿨다. 지금은 프로세스가 먼저다. "절차 따라주세요." "승인 받으셨어요?" 기획서 템플릿이 있다. 10페이지 분량이다. 빈칸 다 채워야 한다. "이거 꼭 써야 해요?" "네, 규정이에요." 누가 만든 규정인지는 모른다. 코드 리뷰 프로세스 생겼다. 2명 이상 승인 받아야 한다. 긴급 버그 수정도 마찬가지다. 장애 나면? 장애 보고서 쓴다. 회고 미팅 잡는다. 재발 방지 대책 수립한다. 좋은 건 안다. 체계가 필요한 거. 근데 가끔은 답답하다. "일단 빠르게 해보는 게 어때요?" "프로세스 무시하면 나중에 문제 돼요." 맞는 말이긴 한데. 정보의 비대칭 50명 때는 다 알았다. 회사 상황. 다음 분기 계획. 누가 그만둔다는 것도. 전체 회의가 한 달에 한 번 있었다. 다 모였다. 대표님이 직접 얘기했다. "이번 달 매출 3억입니다." "다음 달 목표는 4억입니다." "투자 유치 진행 중입니다." 투명했다. 질문하면 바로 답해줬다. 숨길 게 없었다. 지금은? 전체 회의 분기에 한 번이다. 300명이 한 곳에 못 모인다. 온라인으로 한다. 발표 자료는 PPT 50장이다. 각 본부장이 돌아가며 발표한다. 우리 본부 차례 때만 집중한다. 질문? 사전에 받는다. 선별해서 답한다. 민감한 건 "오프라인에서 따로"다. 매출이 얼마인지 모른다. 우리 팀 예산이 얼마인지도 모른다. 회사 전체 로드맵은 더 모른다. 내 업무에만 집중한다. 터널 비전이다. 옆 팀이 뭐 하는지도 잘 모른다. 정보는 위에서 내려온다. 필요한 것만. 필터링돼서. 장점도 있긴 하다 불평만 한 건 아니다. 300명의 장점도 분명하다. 50명 때는 불안했다. 다음 달 월급 나올까. 투자 못 받으면 어쩌지. 지금은 좀 안정적이다. 월급은 제때 나온다. 4대 보험도 빠짐없다. 복지가 생겼다. 점심 식대 지원된다. 휴게실에 간식 있다. 연차도 눈치 안 보고 쓴다. 전문성도 높아졌다. 50명 때는 기획자가 다 했다. 디자인도 조금, 개발도 조금. 지금은 각자 역할이 명확하다. 나는 기획만 한다. 대신 기획을 깊게 한다. 배울 사람도 많다. 시니어 기획자가 3명이다. 질문하면 답해준다. 시스템도 갖춰졌다. 데이터 대시보드 있다. 지표 보면서 일한다. 감이 아니라 데이터로. 50명 때는 맨땅에 헤딩이었다. 지금은 레일이 깔려 있다. 그 위에서 달린다. 느리긴 해도 안전하다. 혼자 삽질할 일은 없다. 누군가는 답을 안다. 어느 쪽이 나을까 자주 생각한다. 50명으로 돌아갈까. 300명에 남을까. 50명의 짜릿함. 빠른 실행. 내 손으로 직접 만드는 느낌. 300명의 안정감. 체계. 전문성. 둘 다 맞는 말이다. 둘 다 틀린 말이기도 하다. 50명은 성장이 불안하다. 언제 죽을지 모른다. 올인하기 무섭다. 300명은 답답하다. 내 영향력이 작다. 톱니바퀴 하나 같다. 결국 타이밍이다. 20대 초반이면 50명이다. 실패해도 괜찮다. 배우는 게 많다. 30대 초반인 지금은? 300명이 맞는 것 같다. 커리어도 쌓이고. 월급도 괜찮고. 근데 가끔 그립다. 50명 때의 속도. 회의 30분에 결정 나던 때. 대표님이랑 직접 얘기하던 때.300명은 어정쩡하다. 스타트업의 속도도, 대기업의 체계도 반쪽이다. 근데 이게 현실이다. 회사는 계속 커진다. 나는 적응한다.

6년차 기획자의 진급 고민

6년차 기획자의 진급 고민

6년차 기획자의 진급 고민 6년이 됐다 어제 캘린더를 보다가 깨달았다. 내가 기획자로 첫 출근한 게 2019년 3월이었다. 지금 2025년 1월. 정확히 6년 차다. 신입 때는 와이어프레임 하나 그리는 것도 떨렸는데. 지금은 전체 서비스 구조를 혼자 설계한다. 개발팀 스프린트 계획도 내가 리드한다. 대표님한테 "이건 왜 안 되냐"는 질문에 데이터 들고 설득도 한다. 그런데 요즘 자주 생각한다. 이제 뭐지? 다음 단계가 뭔지 모르겠다.현실적인 선택지는 세 가지 점심 먹으면서 선배 기획자한테 물었다. "저 이제 어떻게 해야 돼요?" 선배가 웃으면서 말했다. "리드 기획자, 프로덕트 매니저, 아니면 이직." 집에 와서 노트에 정리해봤다. 1. 리드 기획자 (Lead Planner)우리 팀 구조상 가능한 직급 3명 정도 관리하면서 계속 기획 연봉은 7500만원 정도? 하지만 여전히 실무자2. 프로덕트 매니저 전환PM은 더 넓게 본다. 비즈니스까지. 데이터 분석 더 잘해야 함 사업부 리더들이랑 싸워야 함 솔직히 겁난다3. 큰 회사로 이직네이버, 카카오급 가면 시스템 배운다 연봉은 더 오를 수도 근데 나이 31살, 이직 타이밍?세 개 다 장단점이 있다. 답이 안 나온다. 지금 회사에서의 현실 화요일에 대표님이 나를 불렀다. "K씨, 우리 새 서비스 기획 맡아줄 수 있어요? 예산 확보됐어요." 좋은 기회다. 근데 질문을 했다. "제가 PM으로 하는 건가요, 아니면 기획자로 하는 건가요?" 대표님이 잠깐 멈췄다. "음... 일단 기획으로 시작하고, 성과 나오면 PM 검토해볼게요." 나왔는데 기분이 묘했다. 성과 나오면, 이라는 말이 계속 걸린다. 6년 동안 런칭한 기능이 8개다. 월 활성 사용자 20만 만든 기능도 있다. 그래도 아직 '검토'다. 우리 회사 구조상 기획자 위에는 사업부장이다. PM 직급이 없다. 만들어지려면 조직 개편이 필요하다. 언제? 모른다. 현실적으로 여기서는 리드 기획자가 천장이다.다른 기획자들은 어떻게 하나 목요일 저녁, PM/기획자 커뮤니티 모임 갔다. 7년 차 언니가 있었다. 최근에 PM으로 전환했다고 한다. "어떻게 했어요?" "회사 옮겼지. 기획자로는 한계 느껴서." 5년 차 오빠도 있었다. "나는 리드로 만족해. PM은 정치 싸움이더라. 난 기획이 좋아." 8년 차 선배는 프리랜서 했다. "월 500 받고 외주 기획 해. 자유롭고 좋아. 근데 불안하긴 해." 다들 다르다. 정답이 없다는 게 더 답답하다. 집에 와서 맥주 마시면서 생각했다. 나는 뭘 원하는 거지? 내가 정말 원하는 건 뭔가 금요일 퇴근하고 남자친구 만났다. 고민 이야기했다. "너는 뭐가 제일 재밌어?" 질문이 단순했는데 대답이 안 나왔다. "음..." 생각해봤다. 유저 플로우 그릴 때? 재밌다. 새 기능 기획할 때? 재밌다. 데이터 보고 가설 세울 때? 약간 재밌다. 근데 제일 싫은 건? 이해관계자 조율. 일정 압박. 의사결정권 없는 것. "나는 기획은 좋은데, 권한이 없는 게 싫은 것 같아." 남자친구가 웃었다. "그럼 PM 해야지. 그게 의사결정자잖아." 맞는 말이다. 근데 PM 되려면 숫자를 봐야 한다. 매출, 전환율, 리텐션, CAC, LTV. 지금도 보긴 하는데 주도적으로는 아니다. 그리고 PM은 실패하면 책임진다. 기획자는... 솔직히 좀 숨을 수 있다. 무섭다.6개월 실험을 하기로 했다 주말 내내 고민했다. 일요일 밤, 결론 냈다. 당장 결정하지 말자. 6개월 실험하자. 실험 1: PM 역량 키우기데이터 분석 강의 듣기 (SQL 마스터) 비즈니스 지표 공부 (매출, 마케팅) 실제 숫자로 의사결정 연습실험 2: 리더십 경험 쌓기신입 기획자 멘토링 자원하기 프로젝트 리드 해보기 팀 회고 진행해보기실험 3: 시장 조사PM 채용공고 매주 체크 이직 상담 2곳 받아보기 연봉 시장가 파악6개월 후, 2025년 7월. 그때 가서 다시 판단한다. 지금 회사에서 PM 가능성 있나? 없으면 이직 준비. 있으면 협상. 리드 기획자로 만족할 수 있나? 있으면 여기 남기. 없으면 큰 회사로. 프리랜서 해볼까? 재정 계산해보고 결정. 일단 6개월. 움직이면서 답을 찾는다. 6년 차의 진급은 실력만으론 안 된다 월요일 출근했다. 새 서비스 기획 맡기로 했다. 대표님한테 말했다. "이번엔 PM 역할로 해보고 싶어요. 비즈니스 지표까지 책임지고 싶습니다." "오, 좋아요. 그럼 매출 목표도 같이 세워볼까요?" 떨렸다. 근데 "네" 했다. 이게 내 실험의 시작이다. 6년 차 진급 고민의 진짜 문제는 이거다. 실력만으로는 안 올라간다. 기획 능력? 있다. 와이어프레임? 잘 그린다. 협업? 잘한다. 근데 그걸로는 PM 못 된다. 필요한 건:비즈니스 이해 데이터 기반 의사결정 리더십 경험 실패 책임지는 용기 타이밍마지막 타이밍이 제일 중요하다. 회사가 성장하는 시점, 조직이 확장되는 시점, 내 성과가 증명된 시점. 이 세 개가 맞아떨어져야 한다. 그래서 6개월 실험이다. 타이밍을 만들거나, 찾는다.지금 당장 답이 없어도 괜찮다. 움직이면서 찾는다. 6개월 후에 다시 쓴다.