좋은 상세기획서란 무엇일까?
PM은 개발 착수 전 상세기획서를 씁니다.
요리사가 레시피를 정하고, 건축가가 설계도를 그리듯 PM은 상세기획서로 문제를 해결합니다. 이번 챕터에서는 PM이 하는 가장 전형적인 업무, 상세기획서 작성에 대해 알아보겠습니다.
1. 상세기획서란
상세기획서란 프로젝트의 구조를 정리한 백서입니다.
일종의 나무위키라고 하겠습니다. 프로젝트에 참여하는 전문가(사업, 디자인, 테크)들이 1) 문제 상황을 이해하고 2) 해결책을 합의하는 데 사용합니다. 위키, 노션, 워드, 피피티 등 어떤 툴을 사용하더라도 업무의 중심을 잡아주는 문서라면 상세기획서라 하겠습니다.
2. 상세기획서는 누가 읽을까?
상세기획서는 동료들이 읽습니다.
상세기획서 예상 독자첫째, 사업기획자는 시장 관점에서 읽습니다. 1) 제품이 시장의 상식과 일치하는지, 2) 출시 후 시장에 연착륙할 수 있을지, 3) 최종적으로 매출을 일으킬 수 있는지 따져봅니다. 같은 맥락에서 제품이 배포된 후 운영 상 끊임없이 튜닝할 수 있는 수단들을 요구합니다.(ex. 가격 조정, 지역 조정, 필터 조정 등)
둘째, 디자이너는 사용자 관점에서 읽습니다. 어색한 사용 흐름이 없는지 상상하고 피드백합니다. 이들은 상세기획을 디자인 툴을 통해 UX Flow(화면 구성)로 시각화하며, 흐름에 부족한 부분을 채워 넣습니다. PM이 기본 골격을 세우면 디자이너가 수정하고 살을 붙여 제품을 아름답게 만듭니다.
셋째, 개발자는 설계 관점에서 읽습니다. 기존 시스템과 어떻게 합칠지, 모순되는 부분은 없는지, 정책의 사각지대는 어디인지 확인합니다. 더 나아가 기존 시스템 관점에서 새로운 기획에 의문을 제기하기도 합니다. 예를 들어 PM이 ‘주소록 기능을 만듭시다’라고 한다면 ‘최신 주소 목록으로도 비슷한 게 가능하지 않나요?’ 반문하는 식입니다.
3. 상세기획서는 어떻게 쓸까?
상세기획서는 크게 5개 단계로 구성합니다.
1) 배경, 2) 목표, 3) 방향성, 4) 상세정책, 5) 마일스톤 순입니다. 예시로 ‘간식구독 서비스 홈페이지 리뉴얼’의 상세기획서를 작성해 보겠습니다.
상세기획서 구성1. 배경
왜 모였을까? (Why)
상세기획은 하나의 이야기입니다. 기승전결을 담습니다. PM은 모여있는 팀원들에게 구현 동화 하듯 상세기획을 설명합니다. [배경]이 맡은 역할은 ‘옛날 한 고을에 콩쥐가 살고 있었어요. 콩쥐는 어린 시절 어머니를 여의고 계모에게 괴롭힘을 받고 있었습니다.’와 비슷합니다.
배경은 크게 1) 현상과 2) 원인으로 나눕니다. 먼저 현상을 보여줍니다. 문제의 심각성을 드러낼 목적이며, 동료들이 공감하도록 하는 게 핵심입니다. 1) 하락하는 지표, 2) 이상한 사용행태, 3) 위협적인 경쟁환경 모두 현상입니다. 예시는 아래와 같습니다.
[간식구독 서비스 웹 리뉴얼]
배경
문제현상
1. 최근 6개월 고객사 상담 신청건수 (그래프)
2. 최근 6개월 콘텐츠 클릭 및 체류시간 분포 (분포도)
3. 네이버/구글 검색엔진 노출 결과 (흐름도)
4. 최근 6개월 고객사 상담 전환율 (지표)
5. 주요 경쟁사 웹사이트 레퍼런스 (사례)
현상을 공유할 때 동료들이 고객을 끄덕이며 약간 비장한(?) 표정까지 짓는다면 매우 성공적이라 할 것입니다.
다음은 원인을 짚습니다. 원인은 현상이 발생하는 근본적 이유를 설명합니다. 대개 가설의 형태로 쓰는데, 데이터나 현장 조사로 검증된 것들만 적습니다. (ex. 낮은 고객 전환율은 상담 신청 순서가 복잡하기 때문일 것이다.) 보통 복잡한 문제에는 여러 가지 가설이 있습니다.
예를 들어 ‘고객의 가입 상담 전환율이 낮다’고 한다면 아래와 같이 원인을 설명합니다.
1. 간식 구독에 관심 있는 고객에게 검색되지 않을 것이다.
→ 데이터 : 검색 트렌드 및 홈페이지 도달 고객 수
2. 상담 신청 퍼널이 너무 길고 복잡할 것이다.
→ 데이터 : 퍼널 별 이탈 비중 현황
3. 상담 신청 시 입력해야 하는 정보가 너무 많을 것이다.
→ 데이터 : 신청폼 작성 시 중도 이탈 비중
현상과 원인을 파악했다면 이제 목표로 넘어갑니다.
2. 목표
어디로 가나요? (Where)
목표는 프로덕트팀이 도달하려는 새로운 영역입니다. 선언적 목표와 정량적 목표를 씁니다.
선언적 목표는 프로젝트를 통해 탄생할 제품의 별칭입니다. 쉽게 생각하면 [상담웹 2.0]처럼 단순하게 쓸 수도 있고, [고객사들이 대량 유입되고, 쉽게 상담 신청할 수 있는 새로운 홈페이지]와 같이 구구절절 적어 볼 수도 있습니다.
정량적 목표는 선언적 목표를 달성했을 때 변화할 지표입니다. 등산로 초입에서 정상을 손으로 가리키며 ‘저-어기까지 올라갈 겁니다’ 말하는 것과 비슷합니다. 아래 표처럼 나열하는 방식도 가능하고, 북극성 지표를 달성하는 산식으로 써도 좋습니다. 정량목표는 PM의 예상보다 살짝 높게 잡습니다.
정량 목표 예시
목표 산식 예시3. 방향성
무엇을 할까요? (What)
방향성부터는 형식의 자유도가 확 올라갑니다. 큰 틀에서 ‘무슨 일을 할 건지’ 자기 스타일대로 쓰면 됩니다. 동료들과 아이데이션 하고 검증한 해결 방안만 잘 담고 있다면 충분합니다. 필요한 경우 방향성 항목에 프로젝트가 지켜야 할 원칙(ex. 확장성, 단순성 등)을 추가해 두기도 합니다.
방향성 작성 시 실무팁을 드리자면 처음에는 떠오르는 대로 다 적어 보는 것이 좋습니다. 최초부터 고정된 틀이 있다면 오히려 시간이 오래 걸릴 수 있습니다. 대부분의 사람은 뇌로 정리하는 것보다 눈으로 정리하는 것을 잘합니다. 생각을 일단 종이 위에 보이게 해야 합니다.
홈페이지 개편 과제라면 아래와 같은 과제들이 나올 수 있습니다.
1. 검색 엔진에 잘 걸리도록 콘텐츠를 만들자
2. 콘텐츠는 계속 추가할 수 있어야겠다
3. 어떤 검색어로 들어왔는지 알아내야지
4. 상담 신청 버튼의 적절한 위치는 어디지?
5. 상담 신청 시 입력 정보가 너무 많은 건 아닐까?
6. 상담이 부담스럽다면 견적만 받게 할까?
7. 상담 신청하면 쿠폰을 지급해 볼까?
8. 제휴 마케팅을 유연하게 하려면 어떻게 할까?
9. 고객사 사례들을 정리해서 보여줘야지 …
(이하 등등)
방향성 정리는 개미굴을 파는 것과 비슷합니다. 그리고 이리저리 파놓은 생각을 비슷한 것끼리 묶고 연결합니다. 예시의 과제는 아래처럼 묶어 볼 수 있습니다.
[1. 검색엔진 최적화]
1) 콘텐츠 추가 및 유지보수
2) 검색엔진 키워드 데이터 수집
[2. 상담신청 퍼널 단축]
1) 상담 신청 버튼 위치 조정
2) 견적서 신청 기능 추가
3) 상담 신청 시 입력 정보 단축
[3. 프로모션 관리]
1) 제휴사 마케팅 관리 기능 추가
2) 쿠폰 자동 발급 기능 추가
이제 위 방향성을 바탕으로 유저스토리를 씁니다. 제품에 필요한 기능을 컴퓨터의 언어로 바꾸기 전 문장 단위로 정제하는 작업입니다. 유저스토리에 대해서는 다음 챕터에서 따로 자세히 다루겠습니다. 유저스토리만 잘 써도 방향성 정돈이 깔끔하게 완료됩니다.
유저스토리 예시4. 상세정책
어떻게 할까요? (How)
상세정책은 방향성의 세부사항을 적습니다. 보통 전체 상세기획에서 50% 이상을 차지합니다. 크게 3가지를 기억합니다.
첫째, 관련 정책을 싹 찾아둡니다. PM은 항상 동료들의 앞길에 놓인 장애물을 치워줘야 합니다. 목표만 지시하고 뒤에서 팔짱 끼고 있다면 그건 보스이지 PM이라 할 수 없습니다. 예를 들어 첫 이용 쿠폰을 발급하는 기능을 추가한다면 현재 쿠폰 정책 체크는 기본입니다. 개발자들에게 “제가 확인해 보니 이미 쿠폰 API는 있고, 발급 조건 설정이 필요할 것 같아요”처럼 겸손하게 의견까지 제시한다면 베스트입니다.
둘째, 도식을 활용합니다. 다만, 꼭 필요한 경우만 씁니다. 일부 기획서를 보면 필요하지 않은 도식을 넣는 경우가 있습니다. 상세기획서는 최대한 단순해야 합니다. 도식은 글을 경제적으로 표현하기 위해 넣습니다. 아래 그림처럼 다양한 도식이 있고, 적절하게 채택해서 사용하면 됩니다. (도식 이름을 검색하면 좋은 예시들이 쏟아집니다.)
위키에서 사용하는 다양한 도식예를 들어 간식 구독 상담 신청 시 첫 이용 50% 할인 쿠폰을 지급하는 기능을 넣는다면 시퀀스 다이어그램으로 쿠폰 발급 프로세스를 정리해 둘 수 있습니다. 이런 과정 역시 글로 써도 되는 일이지만, 그림 하나로 글을 크게 단축할 수 있고 개발자의 관점에서 이해하기 쉽기 때문에 삽입합니다.
시퀀스 다이어그램 예시셋째, 열린 마음으로 적습니다. 그리고 자주 고칩니다. 상세정책은 개발 착수 직전까지 (혹은 개발 중에도) 계속 바뀔 수 있습니다. 대부분 PM은 천재가 아니기 때문에 모든 상황을 예견하지 못합니다. 어설픈 완벽주의는 동료들과 소통에 벽을 만듭니다. 완성된 문서를 공유하려 하지 말고, 한번 써보고 물어보고 고치고 하는 과정을 수십 번씩 반복해보세요.
5. 마일스톤
언제까지 할까요? (When)
마지막은 마일스톤입니다. 마일스톤에서 3가지 점을 지킵니다.
첫째, 대강 적습니다. 말이 좀 이상한데요. 그 이유는 어차피 일정을 WBS(Work Breakdown Structure)에서 다시 논의하기 때문입니다. (PM일을 하면 아시겠지만 일정이 계획대로 흘러가는 적은 거의 없습니다.) 상세기획서의 마일스톤이란 말 그대로 표지석입니다. “대략 언제까지 어느 정도 하겠다”만 가늠할 수 있다면 충분합니다.
둘째, 단계를 쪼개서 적습니다. PM은 상세기획서를 정리하며 일의 규모를 가늠할 수 있습니다. 많은 과제는 한 번에 처리하는 것보다 묶어서 진행할 때 효율이 좋습니다. 대나무가 마디마디 빠르게 자라는 것과 비슷합니다. PM은 마일스톤을 통해 과제를 Phase 단위로 갈라놓을 수 있습니다.
셋째, 솔직하게 적습니다. 사업상 필요 일정을 확인하고 투명하게 전달합니다. 간혹 디자이너, 개발자와의 마찰이 걱정되어 1) 일정을 늘여 잡거나, 2) 아예 잡지 않고 먼저 제시해 달라는 경우가 있습니다. 이렇게 하면 서로 헷갈립니다. PM은 사업과 매출 중심으로 일정을 선제시하고 동료들에게 귀만 열어두면 됩니다.
마일스톤 예시4. 상세기획서를 쓸 때 주의할 점
상세기획서를 쓸 때는 아래 3가지를 유념합니다.
작성 시 주의사항 3요소1. 가독성
상세기획서는 읽기 쉬워야 합니다. 일부 기획서는 깨알 같은 글씨로 일본 가전제품 설명서처럼 쓰여있습니다. 이런 상세기획서는 결코 좋은 문서가 아닙니다. PM이 만드는 모든 문서는 가독성이 최우선 가치입니다. 어려운 개념을 다루더라도 쉽게 이해시킬 수 있어야 합니다.
좋은 기획서는 읽고 싶은 마음이 들어야 합니다. 개발자, 디자이너 모두 똑같은 사람입니다. 이들도 재밌는 글, 쉬운 글, 예시가 많아 머리에 쏙쏙 들어오는 글을 읽고 싶어 합니다. 설령 구어체로 줄줄 쓰더라도 단순하고, 직설적으로 쓰세요. 때로는 아마추어 같이 친근한 기획서가 오히려 가장 프로다운 기획서입니다.
2. 유연성
상세기획서는 유연해야 합니다. 앞서 언급했지만 이 문서는 결코 한 번에 쓰지 않습니다. 최소 2차례, 많게는 4-5차례에 걸쳐 나눠 씁니다. PM은 보통 똑똑하지만 그렇다고 동료 모두를 압도할 만큼 똑똑하지도 않습니다. 시장조사와 데이터분석을 철저하게 했다고 하더라도 빈틈이 많습니다. 비판을 잘 흡수하는 유연성을 가져야 합니다.
3. 완결성
상세기획서는 정리를 잘해 두어야 합니다. 이 문서는 최초 개발 시에만 읽지 않습니다. 미래의 나와 동료들도 읽습니다. 갈무리를 안 하면 보통 1-2년 흐른 뒤 문제가 생깁니다. 당시에 무슨 생각으로 제품이 만들어졌는지 알기 어렵습니다. 개발이 시작되었다면 PM은 30분이라도 꼭 시간을 내어 최종안을 정리해두어야 합니다.
5. 좋은 상세기획서란
앞서 상세기획서의 구조를 설명했지만 이 문서상에는 정답이 없습니다. 회사마다, 팀마다, 사람마다 상세기획서를 쓰는 방식은 천차만별입니다. 여태 30명 이상 PM이 일하는 모습을 봐왔지만, 완전히 똑같은 양식은 한 번도 없었습니다. 각자 일을 배운 배경(네이버, 카카오, 라인, 쿠팡, 토스)에 따라 습관이 다릅니다.
다만 한 가지 확실한 점은 좋은 상세기획서들이 큰 틀에서는 비슷하다는 점입니다. 이해하기 쉽고, 논리적으로 납득되며, 상상력을 자극하고, 심지어 의욕까지 불러일으킨다면 형태의 다양성을 떠나 좋은 상세기획입니다. PM이 상세기획서를 잘 쓰면 조직 전체가 시간을 효율적으로 쓰고 활기차게 일할 수 있습니다.
yve.k