잘나가는 서비스 기획자 도그냥은 왜 PM PO가 되었을까? - IT 기획자에서 프로덕트 오너로 점프하기

“커리어 점프를 꿈꾸는 IT 기획자를 위한
랜선 사수 도그냥의 레벨업 가이드!”

문과생 IT 비전공자에서 서비스 기획자로, 서비스 기획자에서 PM/PO로

성장하는 1N년 차 현업 기획자의
프로덕트와 기획, 일과 성장에 관한 에세이

IT 서비스 기획자나 PM(프로덕트 매니저), PO(프로덕트 오너)가 되기를 꿈꾸지만 어디에서부터 어떻게 시작해야 할지 막막하다면? 카카오스타일 프로덕트 오너이자 브런치 100만 뷰 작가인 랜선 사수 도그냥과 함께 차근차근 가볍게 시작해 보자!

문과생 IT 비전공자에서 서비스 기획자로, 서비스 기획자에서 PM/PO로 끊임없이 커리어 점프를 이룩해 온 저자는 이 책에 IT 프로덕트팀 기획자의 사고방식부터 성장에 관한 리얼한 분투기까지 자신만의 유니크한 경험을 가감 없이 녹여 냈다. 사수가 없어 힘든 주니어 기획자는 물론 1N년 차 기획자로서 ‘나 잘하고 있는 걸까?’ 하는 생각이 드는 시니어라면, 이 책을 발판 삼아 자신만의 스킬을 단련하고 업그레이드해 보는 것은 어떨까?

저자는 책에서 ‘기획자’라는 일의 본질과 PM/PO 등 직무 간 핏(fit)의 차이를 집요하게 고찰하며 파고드는 한편, 변화하는 업계 트렌드와 실전 업무 팁도 최대한 쉽고 자세하게 소개한다. 팀의 장점을 살리는 유저 스토리는 어떻게 쓰는지, 메이커에게 더 높은 자유도를 선사하는 법은 무엇일지, 어떻게 Why로 시작하는 크로스펑셔널팀을 운영하는지 궁금하다면 얼른 이 책을 펼쳐 보자. 불분명하고 애매모호하게 느껴졌던 IT 업계의 생생한 현장을 내 것처럼 경험할 수 있을 것이다.

[목 차]

프롤로그

Chapter 01. 일잘러의 세상이 흔들렸다

01 우물 안 일잘러, 회사 밖에서도 일잘러를 꿈꾸다
02 누가 우물 안 일잘러를 만드나
03 우물 안 일잘러의 위기
04 우물 탈출을 방해하는 에고와의 싸움
05 터부시하는 부정적 감정이 성장을 만들어 낼 때


Chapter 02. 메타인지에서 시작한 프로덕트 오너로의 도전

06 헤드헌터보다 유능한 커피 한 잔_ 커피챗
07 우물 밖으로 점프_ 회사 내 프로세스 전환 또는 이직
08 점프하기 전 기 모으기_ 이직할 회사 정하기
● 돋보기 : 프로덕트 매니저, 프로덕트 오너, 서비스 기획자


Chapter 03. 우물 밖으로 점프! 프로덕트 오너로의 도약

09 우물로 돌아가려는 에고의 역습, “나를 증명하고 싶어!”
● 돋보기 : 애자일 사상과 스크럼 프레임워크
10 완결성이 아닌 효용성을 보는 세상_ 서비스 기획자에서 프로덕트 오너로
11 프로덕트 로드맵의 시작은 비전(Vision)으로부터
● 돋보기 : 폭포수 프로젝트와 애자일 프로젝트 방법론
12 프로덕트팀의 장점을 제대로 활용하려면 뭐가 필요하지?
13 드디어 Why로 시작하는 크로스펑셔널팀을 운영하다
● 돋보기 : 힘들게 깨달은 유저 스토리 작성 팁 4
14 모든 것은 정의로부터_ 교과서적인 프로덕트 오너 이해하기
● 돋보기 : 도그냥의 이상적 PO 되기 노션 페이지 목차 엿보기
15 성장과 성공의 관계_ 장르의 차이
● 돋보기 : 거대한 성공이 아닌 프로덕트의 일상적 성장 만드는 법
● 돋보기 : PM/PO/서비스 기획자 직무서를 보기 전 알아야 할 팁 2


Chapter 04. 경계 없는 일잼러의 탄생을 위해

16 고연차의 성장은 스킬에서 일어난다
17 직업인으로서의 기획자의 성장

에필로그

[본 문]

이 책은 나름의 자부심을 가지고 일하던 나의 성장에 대한 이야기다. 우물 안에서 잘난 척하고 살던 내가 우물 밖으로 나가 새로운 삶에 적응하고 나만의 기준을 만들기까지, 하루하루 애쓰고 노력했던 날들의 기록이다. 온라인 서비스 기획자라는 특정 직무에서나 일어난 큰 변화에 대한 글이라고 생각할 수 있겠지만, 사실 이러한 변화와 그로 인한 고민은 누구에게나, 언제든 찾아올 수 있다. 특히 10년쯤 일을 하게 되면 반드시 우물 안을 벗어나야 할 때가 온다. 그게 내 직업처럼 시대적인 변화를 맞이해서든, 아니면 회사나 개인의 발전과 관련해서든, 하던 대로만 해서는 성과가 나지 않는 순간이 반드시 온다.
_프롤로그 중에서


한번은 기존 기업에서 엄청난 직무 성과를 많이 올려 왔다고 자랑하는 기획자를 만난 적이 있다. 사내의 굵직한 서비스를 모두 본인이 만들었다고 했다. 아무리 생각해 봐도 그 기간 내에 혼자서 다 기획하고 프로젝트 실무까지 진행할 수는 없는 범위였다. 자세히 물어보니 외주에 발주하고 관리하는 역할만 했던 사람이었다. 물론 회사마다 업무의 범주는 다를 수 있다. 그 회사에서 필요한 기획자의 역량은 딱 거기까지였을 것이다. 하지만 그의 경력은 실무로서 직접 프로젝트를 수행할 수 있는 사람이 필요한 곳에서는 의미 없는 경력이 되고 만다. 자신이 일했던 회사의 기준이 아니라, 내가 하고 있는 이 직무의 커리어패스에서 필요한 수준을 올바로 정의하고 있었다면 어땠을까? 관계적 정의가 아닌, 스스로 객관적인 기준을 세워 자신의 현 상태에서 한계와 차이를 아는 것이 중요하다.
_<누가 우물 안 일잘러를 만드나> 중에서


내가 목표한 키워드는 단 하나. ‘크로스펑셔널팀’. 기존의 기업들과 다르게 일하는 것으로 가장 유명한 회사 몇 군데를 찾아서 이 질문을 해 보기로 결심했다. 한 회사에서는 사내의 탤런트 애퀴지션(Talent acquisition. 사내 헤드헌트 부서의 일종)의 리크루터를 만났고, 또 다른 회사에서는 나와 같은 직무의 사람을 찾았다. 그리고 그들에게 이직에 대해 묻는 대신, 가벼운 커피챗(coffee chat)을 요청했다.
커피챗이란 IT 업계에서 많이 사용하는 용어로 커피를 마시면서 수다를 떠는 가벼운 만남을 이야기한다. 커피챗이 사전 면접처럼 작용한다고 부담감을 느끼는 사람도 많지만, 사실은 그저 서로 ‘간을 보는 자리’이기 때문에 커피챗 후에 꼭 입사를 지원해야 할 필요는 없다. 내 경우에는 당장 지원해 봤자 떨어질 것이 뻔했기에, 정말 가벼운 마음으로 대화해 보면서 무엇을 준비할지 큰 그림을 그릴 수 있었다. 먼저 유명 이커머스의 리크루터 두 명을 만났는데, 마침 한 블록 옆 건물이었기에 점심시간을 쪼개서 인근 커피숍에서 만남을 가졌다.

“PO(프로덕트 오너)가 크로스펑셔널팀으로 일하나요? 조직 구성은 어떻게 되나요?”
“그 회사에 계신 분이 쓰신 글에서 본 일하는 방식이 사내에서 표준적으로 일하는 방식인가요?”
“PO는 서비스 기획자보다 의사 결정 권한이 많다는데, 의사 결정을 하고 나서 책임을 지는 방식은 어떻게 진행되나요?”
“저처럼 서비스 기획자로 대기업에서 일하다가 넘어온 사람들 중에 적응에 실패한 사람이 있나요? 실패한 사람은 어떤 점을 힘들어했나요?”

짧은 30분 동안의 대화에서 막연하게 품고 있던 질문들을 했다. 크로스펑셔널팀이 가져야 하는 생각이나, 그런 팀에서 일하는 기획자가 갖춰야 할 차별성이 무엇인지 알 수 있을 만한 질문들이었다. 일하는 방식이 달라진다는 것은 사실 프로세스 변경만을 의미하지 않는다. 일하는 방식이 다를 때는 분명 그것을 뒷받침하는 이론이나 배경이 있을 테니 그것을 알고 싶었다.
_<헤드헌터보다 유능한 커피 한 잔_ 커피챗> 중에서


상품 시스템을 새로 만들어야 한다는 미션에서 나는 내 경험을 기반으로 필요한 모든 상품 항목들을 열거했다. 그런데 팀원들과 리뷰하는 과정에서는 ‘비즈니스 임팩트’를 위해 꼭 필요한 항목을 정해서 그것만으로 오픈할 수 있어야 첫 오픈 시점을 맞출 수 있다는 데 이야기가 모아졌다. 나는 여기서 첫 번째 큰 차이를 정의할 수 있었다.

‘기능의 완결성과 기능의 효용성 중 무조건 후자를 택하는 세상에 온 거구나.’

기능의 완결성을 추구한다는 것은, 그 기능을 사용하는 모든 사용자의 이용 케이스와 발생 가능한 데이터적 케이스를 모두 고려하여 그에 맞는 정책을 빠짐없이 기획하는 것을 뜻한다. 그만큼 개발과 디자인해야 할 케이스가 많다. 여기서 한 단계 더 나아가면 내가 처음에 서비스 기획을 시작했을 때 들었던 그 단어, ‘확장 가능성’에 대한 부분까지 나아가게 된다. 기능의 확장 가능성이란 예를 들어 나중에 이 기능에서 지금은 제외되었지만 추가적인 기능을 만들 수도 있으니까 그걸 개발 설계에 녹여 달라고 하는 것에 해당한다. 이렇게 기획을 할 때는 120%를 상상하고 그중 20%는 버려질 수 있다는 것을 감안하고 기획해야 한다. 어차피 과도한 기획이라 다 수용하지 못하는 것이 당연시되는 상황이기에, 가능한 더 많은 양을 내세워서 합의 가능한 수준을 높이려고 한다. 그래야 완결성을 조금이나마 높이게 되니까. (중략)
그렇다면 기능의 효용성을 중요시하며 일하는 세상은 어떤 것일까. 이커머스에서 만들 수 있는 10가지의 상품 종류가 있다면, 당장 오픈 시키려고 하는 단 한 가지의 상품 종류에 최적화해서 확장성을 고려하지 않고 프로덕트를 만들어 내는 것이다. 그리고 그 최적화의 과정에서 ‘확장 가능성’에 대한 부분도 배제한다. 다만 나중에 아홉 가지 종류가 들어올 때를 대비해서, 미리 만들기보다는 한 가지씩 항목이 추가될 때 기존시스템을 다시 부수고 새로 필요한 만큼 확장해서 만들어 낸다는 약속이 존재한다.
_<완결성이 아닌 효용성을 보는 세상_ 서비스 기획자에서 프로덕트 오너로> 중에서