주니어 서비스 기획자, PM을 위한 15권의 책 추천
내돈내산 + 다 읽어본 사람의 추천도서
서비스기획/PM/PO 직무 서적은 별로 없다. 보통 닷컴버블과 벤처기업 시대의 웹기획자를 1세대, 스마트폰 이후의 기획자를 2세대라고 하는데, 국내 모바일 비즈니스는 2014년 이후 급성장했기 때문이리라. 같은 직군이라고 해도 도메인, 회사 등 스펙트럼이 너무 다양한 까닭도 있다. 게다가 빠르게 변하는 기술과 시장에 적응하고 있는 과정이기도 하다. 교과서가 나오기 어려운 환경이다.
코로나 이후, 개발자 모셔가기 전쟁(?)의 후광 덕에 PM도 선호하는 직업이 되었다. 그러나 PM 채용공고는 대부분 경력자를 대상으로 한다. 일을 가르쳐주는 사람도 없고, 신입을 뽑는 곳도 적으니 참 난감한 직무다. 그런 시장의 수요를 반영하여 2020년 이후 많은 직무 도서들이 등장했다. 바쁘게 일을 하면서도 저술활동을 하신 모든 저자분들이 존경스럽다.
PM 지망생들을 대상으로 멘토링과 강의를 하다 보면 항상 나오는 질문이다.
책 추천 해주세요
읽어보지도 않은 책을 추천할 수는 없지 않겠는가? 그래서 틈틈이 시간 내어 읽었다. PM 직무에 도전하고 싶은 꿈나무들을 위한 추천도서 리뷰다. 무려 15권이다.
붙여놓은 날짜는 초판 1쇄 발행일이다.추천도서는 세 가지로 분류해 볼 수 있었다. (출간 순서로 정렬)
1. 서비스기획/PM/PO 직무
처음부터 다시 배우는 웹 기획 / 정재용, 최준호, 조영수 / 2016.07
조직을 성공으로 이끄는 프로덕트 오너 / 김성한 / 2020.03
현업 기획자 도그냥이 알려주는 서비스 기획 스쿨 / 이미준(도그냥) / 2020.06
코딩 몰라도 됩니다 / 이미준(도그냥) / 2021.09
서비스를 성공시키는 기획자의 비법노트 / 조이 / 2022.05
서비스 기획자로 일하고 있습니다 / 강승훈 / 2022.09
제품의 탄생 / 오이카와 다쿠야, 소네하라 하루키, 고시로 구미코 / 2022.12
프로덕트 매니저는 무슨 일을 하고 있을까 / 개점휴업, 최민 / 2023.01
2. IT 교양
거의 모든 IT의 역사 / 정지훈 / 2020.11
비전공자를 위한 이해할 수 있는 IT지식 / 최원영 / 2020.07
오늘도 개발자가 안 된다고 말했다 / 김중철, 김수지 / 2021.04
오늘부터 IT를 시작합니다 / 고코더 / 2022.08
3. 전략
편집광만이 살아남는다 / 앤드류 S. 그로브 / 2021.06
디커플링 / 탈레스 S. 테이셰이라 / 2019.09
규칙 없음 / 리드 헤이스팅스 / 2020.09
취업/이직준비로 바쁜 취준생, 주니어들이 이 책을 몽땅 읽기는 어려울 터. 나름대로의 기준으로 우선순위를 정해서 추천해보고자 한다.
IT/플랫폼/스타트업 : 프로덕트 매니저, 프로덕트 오너
1) 서비스 기획자로 일하고 있습니다
2) 프로덕트 매니저는 무슨 일을 하고 있을까
3) 프로덕트 오너
4) 제품의 탄생
이커머스/금융/제조 등 : 서비스 기획자
1) 서비스 기획자로 일하고 있습니다
2) 서비스를 성공시키는 기획자의 비법노트
3) 현업 기획자 도그냥이 알려주는 서비스 기획 스쿨
4) 프로덕트 매니저는 무슨 일을 하고 있을까
5) 처음부터 다시 배우는 웹 기획
프로덕트가 사업 그 자체인지, 부수적인지에 따라 PM의 역할과 일하는 방식이 다르다고 생각하여 두 가지로 나눠 보았다. 최근 채용공고만 봐도 IT는 PM 직군으로 채용하고 있지만, 다른 곳에서는 서비스 기획자가 더 많다. IT업계에서는 목적 조직을 운영하는 경우도 많고, PM의 권한과 책임이 상대적으로 높은 편이다.
PM 직무는 최근에 변화가 많았기 때문에, 신간에 더 높은 우선순위를 두었다. 1~2번은 2022년 이후 출간된 책들이다. 둘 다 1순위가 '서비스 기획자로 일하고 있습니다'인데, 읽기가 쉽고 내용이 컴팩트한 데다 알차기 때문이다. 적절한 사례와 노하우, 이직을 위한 경험 정리법 등을 구체적으로 제시하고 있다. 시작하기에 딱 좋은 책이다. 2순위는 일하는 방식이 구체적으로 서술된 책들을 선정했다. 1~2번은 필독, 3번부터는 권장이라고 생각하면 좋겠다. 물론 모든 책이 훌륭하니 가능하면 나처럼 모두 읽어보도록 하자.
읽고 느낀 점과 인상 깊었던 부분들을 발췌해 보았다.
1. 서비스기획/PM/PO 직무
처음부터 다시 배우는 웹 기획 / 정재용, 최준호, 조영수 / 2016.07
직무 관련 책이 없던 시절 유일무이한 가이드다. 1세대 선배님들이지만 여전히 활발하게 활동 중이시며, 나는 이분들의 카카오톡 오픈채팅방과 브런치를 통해 인사이트를 얻고 있다. PM의 일하는 방식은 많이 달라졌지만, 본질은 과거와 다르지 않다는 점이 놀랍다.
p.36
실무 기획자들은 종종 UI/UX를 기획 본연의 일로 생각합니다. (중략) 기획자에게 UI/UX는 스킬, 그 이상도 이하도 아니라는 점을 분명히 인식하고 있어야 하며, 스킬을 익히기 이전에 현재 만들어야 할 제품의 가치를 찾고 그것을 이용하는 고객들을 이해하기 위한 학습과 노력이 선행되어야 한다는 점은 꼭 기억하시기 바랍니다.
p.252
이메일을 보낼 때나 스토리보드를 작성할 때 디스크립션 영역에 디자이너, 개발자가 이해하기 쉽도록 기획 내용을 정리해서 전달하고, 회의록을 작성할 때 전반적인 회의 내용을 요약하는 형태로 정리하는 등, 작문 능력은 일상적인 업무와도 연관성이 많습니다. 이러한 작문 능력을 키우려면 책을 많이 읽는 한편 직접 글을 써야 합니다.
p.274
흔히 기획자의 가장 큰 힘은 문서와 근거라고 이야기합니다. 한 마디로 '왜 해야 하는가?'를 뜻하는데 각 IT 종사자들과의 소통에서 기획자는 근거가 있는 가치, 콘셉트, 전략적인 부분으로 접근해야 하며, 그것을 효율적으로 전달하고 정리할 수 있는 문서를 가지고 소통해야 합니다.
p.276
샌드위치 소통으로 정의하는 이 전략은 긍정적인 반응과 의도하고자 하는 목적에 다시 방향을 제시하는 구조의 커뮤니케이션입니다. 예를 들어 "이 디자인 정말 괜찮은데요? 그런데 여기에 색상을 조금 바꾸면 더 낫지 않을까요?"와 같이 디자인이 정말 괜찮다는 긍정적 반응과 색상을 조금만 바꾸면이라는 목적, 그리고 더 낫지 않을까 하는 방향 제시를 함으로써 기획자가 원하는 의도를 전달함과 동시에 상대의 자존감을 높여서 원활한 작업수행을 이끌 수 있습니다. (중략) 커뮤니케이션을 잘하는 기획자는 상대를 이기려는 기획자가 아닙니다. 파트너십을 가지고 소통하는 기획자가 커뮤니케이션을 잘하는 기획자로 발전할 수 있습니다.
p.294
기획자가 작성하는 문서를 살펴보면 크게 두 가지 형태로 구분됩니다. 첫 번째 형태는 보고서, 기획서, 제안서와 같은 보고를 목적으로 한 문서입니다. 보고용 문서는 의사결정을 위한 기본자료로 객관적인 사실을 전달하거나 특정 주제에 대한 방향성 및 해결책을 제시하여 의사결정권자의 판단을 이끌어냅니다. (중략) 두 번째 형태는 정책 문서, 플로차트, 스토리보드와 같은 커뮤니케이션 문서입니다. 커뮤니케이션 문서는 협업을 위한 문서로서 협업 대상자 모두가 쉽게 이해할 수 있도록 작성되어야 합니다. (중략) 좋은 문서는 예쁘게 디자인하고 잘 포장하는 것이 아니라 핵심 가치의 유무와 함께 그 가치가 얼마나 잘 전달되었는가로 판단합니다.
p.296
기획 도구는 전달하고자 하는 메시지를 효과적으로 전달하기 위한 보조 수단에 불과합니다. 실력 좋은 목수는 연장 탓을 하지 않듯이 실력 좋은 기획자도 기획 도구에 의존하지 않습니다. 다만 메시지를 더욱 명확하게 전달하고 완성도 높은 문서를 작성하기 위해 기획 도구를 적절히 사용할 뿐입니다.
조직을 성공으로 이끄는 프로덕트 오너 / 김성한 / 2020.03
PO가 없는 회사에서도 큰 인기를 얻었던 책이다. 담당하고 있는 프로덕트에 오너십을 가지고 있는 새로운 직군에 대한 이야기가 흥미로웠다. 최근에는 쿠팡도 PO 채용 공고가 없어서 의아하긴 하다. 직접 가설을 설정하고 요구사항의 우선순위를 다룬다. 권한은 없지만 책임이 많다는 점이 인상적이다. 커뮤니케이션의 중요성을 상기하게 해 준다.
p.25
극단적으로 전혀 다른 경험을 원하는 고객 집단이 하나로 모여 있을 때, 과연 회사는 누구의 의견을 수렴해줘야 할까? (중략) PO는 이런 상황에서 고객을 대신해서 고민한다. (중략) 우선순위를 정했으면, 그게 회사가 추구하는 사업 목적과 부합하는지도 확인하라.
p.32
PO는 독재자처럼 군림해서는 안된다. (중략) 아무리 급해도 결정을 일방적으로 통보하는 태도로 임한다면, 장기적으로 다른 이들에게 존중받기 어렵다. (중략) PO는 최대한 많은 맥락을 설명해줘야 한다. (중략) 사실, CEO보다 '미니 CEO'로 불리는 PO가 하는 일이 더 어려울 수도 있다. 왜냐하면 주어진 권한이 전혀 없기 때문이다. 그래서 PO는 늘 명확한 사실과 데이터를 가지고 설득해야 한다.
p.40
PO는 권한이 거의 없다. 특히 인사 권하는 아예 없다고 봐야 한다. (중략) PO는 그렇게 지시할 수 없다. 늘 설득의 연속이다. (중략) 단기간에 이들의 마음을 얻는 것은 매우 힘들지만, PO는 책임감 있는 모습을 보여주면서 함께 일하는 동료들과 고객이 존중하는 사람이 되려고 노력한다. (중략) 나는 지시처럼 들리는 어휘 대신 질문을 자주 사용한다. "당장 롤백해 주세요"가 아니라, "이전 버전으로 롤백해 주시겠어요?"라고 물어본 후, 이유까지 바로 설명해 준다. 현장에서 일단 사용할 수 있도록 대처하고, 원인은 나중에 함께 찾자고 덧붙이면서. (중략) 오히려 건강한 관계를 유지하기에는 PO에게 권한이 없는 편이 낫다. 다른 이들에게 일방적으로 지시하기보다는, 더 효율적으로 협업하기 위한 방법을 찾을 수 있기 때문이다. (중략) 부여된 책임감은 많지만, 권한이 없는 PO는 언제나 겸손해야 한다.
p.52
PO가 이행해야 하는 가장 중요한 의무 중 하나는 고객에게 집착하는 것이다. 현장이 있으면 현장으로, 공장이 있으면 공장으로, 판매처가 있다면 판매처, 심지어 단순하게 고객센터에 가서 전화 통화를 옆에서 들어도 도움이 된다. 그리고 각각의 고객이 무엇을 불편하게 여기는지, 어떤 경험을 원하는지 등을 데이터까지 분석하며 파악한다.
p.91
논의 끝에 회사에서 반대할 경우, PO는 바로 수긍해야 한다. PO는 회사의 성장 전략과 비용 관리 등을 하는 역할이 아니기 때문이다. 전문가의 판단 하에 특정 프로덕트에 대한 투자를 단행할 수 없다고 결정되면, PO는 그 방법을 제외하도록 한다. 어디까지나 PO는 주어진 자원을 활용하여 프로덕트를 개선해야 하는 책임이 있기 때문이다. (중략) 고객에게 더 나은 가치를 제공하기 위해 집착하는 PO이지만, 회사가 정한 방향성과 목표를 절대로 잊어서는 안 된다. (중략) 고객에게 계속 최상의 경험을 제공하려면, 회사가 건강한 상태여야 한다. (중략) 고객의 목소리에 귀 기울이는 것만큼 회사가 정한 목표와 의견에도 집중하도록 하자. 회사가 없으면 고객에게 더 나은 경험을 제공할 기회까지 사라지기 때문이다.
p.99
PO라면 자신에게 주어진 데이터를 그대로 받아들여서는 안 된다.
p.195
개발에 필요한 공수 산정은 개발자와 개발 매니저에게 맡겨라. 디자인 시안에 필요한 공수 산정 또한 디자이너에게 맡긴다. 하지만 무조건 그들의 의견에 귀 기울여 개발 완료 일자를 정해서는 안 된다. 존중하고 참고하되, PO는 고객에 선보여야 하거나 회사가 꼭 달성해야 하는 목표를 위해 일정을 최종적으로 조율해야 한다. PO가 범하기 쉬운 실수 중 하나가 일방적으로 완료 예정 시간(ETA)을 개발 조직에 강요하거나, 혹은 반대로 개발 조직의 의견에만 의존하여 ETA를 역으로 산정하는 것이다.
p.198
개발자가 직접 고객과 소통하거나 유관 부서와 협의하는 상황이 발생해서는 안 된다. 개발자와 디자이너가 최대한 본연의 업무에 집중할 수 있도록, PO가 대신 소통을 책임지는 것이다. (중략) PO는 개발자나 디자이너가 그 어떤 질문이든 편하게 물어볼 수 있는 환경을 조성해야 한다. (중략) 나는 단 한순간도 개발이 정체되는 것을 스스로 용납하지 않는다. 상황이 애매하거나, 고객의 요구사항이 부정확하거나, 개발 착수를 위해 필요한 게 있다면 최대한 빨리 해결하려고 한다. 내가 병목이 되어서는 안 되고, 함께 일하는 팀원들이 불필요한 것에 대해 고민하지 않길 바라기 때문이다. (중략) 팀원들이 언젠가 물어볼 것 같은 질문을 미리 예상하고 답을 마련하라. 단 1초라도 허비하지 않고 계획된 스프린트 플래닝에 맞춰 나아갈 수 있도록 말이다.
p.247
PO가 가설을 설정하고, 테스트하고, 새로운 기능을 선보일 때마다, 그 과정을 "펀딩 받았다"라고 표현하기도 한다. 회사로부터 펀딩, 즉 투자받았으니 테스트도 할 수 있는 것이다. 만약 회사가 PO에게 그 자원을 허용하지 않았더라면, 모든 게 불가능해진다. 따라서 PO는 가설을 세울 때마다 신중해야 한다. 그리고 개발 조직과 디자이너에게 티켓을 할당하면서, 회사를 대신하여 귀중한 자원을 투자하는 것이라는 사실을 명심해야 한다.
p.285
이미 정해진 전략을 이행하는 직무는 PO가 할 일이 아니다. (중략) 조직 구조 자체가 수직적 위계구조 형태라 윗선에서 시킨 내용을 그대로 이행해야 하거나, PO가 계속해서 기획 및 보고를 해야 한다면 절대로 PO를 채용해서는 안 된다. 신속하게 가설을 설정하고 MVP를 만든 후 테스트를 진행해서 검증하는 걸 지속적으로 할 수 있는 환경이어야 한다. (중략) 만약 가설만 설정하고 보고서만 작성하는 직무라면, PO를 채용할 필요가 없다. 그리고 내부 개발 조직이 없어서 외주 업체를 활용해야 한다면, 그 또한 PO가 필요 없다. (중략) 한 공간에 PO와 개발 조직을 한데 모아 전적으로 오너십을 줄 수 있어야 한다.
p.294
PO에게는 오너십이 제일 중요하다. 이 오너십의 개념이 무너지면, PO는 힘을 잃게 된다. PO가 자신의 프로덕트에 대한 직접적인 가설 설정과 요구사항을 정의할 수 없다면, 그 누구도 그 PO의 오너십을 인정하지 않을 것이다.
현업 기획자 도그냥이 알려주는 서비스 기획 스쿨 / 이미준(도그냥) / 2020.06
나와 같은 도메인과 비슷한 직장 경력이지만, 책도 3권이나 쓰신 데다가, 강의에 유튜브에 브런치까지... 쉬는 시간은 있으신지 궁금한 분이다ㅋㅋ 이 책은 2세대 서비스 기획의 바이블이다. 기획 프로세스가 체계적으로 정리되어 있고, PM 지망생들을 위한 역기획 방법론도 자세히 제시하고 있다. 챕터마다 있는 기획자 다이어리가 꿀잼이다. (지난 후기는 아래 링크 참고)
코딩 몰라도 됩니다 / 이미준(도그냥) / 2021.09
제목과 내용이 이질적인 책이다. 이커머스 도메인 속의 기획자에 대한 내용이 많아 공감했다. 프로덕트가 본질인 곳이어야만 서비스의 성장이 가능하다고 짚었던 점이 인상 깊었다. 내가 이직을 결심했던 이유와 맞닿아있었기 때문이리라.
p.47
최근 몇 년 사이 온라인 기업들이 성장하면서 다른 도메인의 영역까지 적극적으로 범위를 확장해 가며 하나의 기업이 여러 개의 도메인을 운영하는 형태로 바뀌어가고 있다. 이렇게 도메인의 영역이 흐려지는 현상을 '빅블러(Big blur) 현상'이라고 한다. (중략) 이런 상황이라면 여러 가지 도메인으로 빠르게 확장하고자 하는 곳이 가장 성장할 확률이 높은 회사라고 할 수 있다.
p.66
누군가 나에게 어떤 이커머스 기업을 선택하면 좋겠냐고 묻는다면, 나는 기업의 '운영 방식'을 주의 깊게 보라고 하고 싶다. (중략) 온라인 서비스를 만드는 IT 조직을 '전산실' 개념으로 보는 회사들이 종종 있다. (중략) 이커머스를 운영해야 하는 상황에서 여전히 IT 조직을 전산실 개념으로 운영하는 것은 서비스의 성장을 가로막는 일이다.
p.111
어떤 기업은 이커머스를 주로 서비스하는 기업이지만 스스로를 IT 회사가 아닌 유통 회사로 정의하기도 한다. 스스로를 유통 회사로 정의하는 이커머스는 IT 부서를 생각하는 태도 자체가 일반적인 IT 기업과는 다르다. 앞서 이야기했던 것처럼 유통 회사에서 IT란 유통 사업을 영위하기 위한 지원 조직의 일부처럼 여겨진다. 내부 인원보다는 외주를 통해서 필요한 시기에만 인력을 투입하려고 하거나, IT 기술에 대해서도 긴 시간을 투자하지 않고 단기간 내에 성과를 보고 싶어 한다. (중략) 이커머스 기업을 선택할 때 기업이 IT 부서를 어떻게 생각하는지나 IT 인원을 적절하게 보유하고 있는지를 파악해 봄으로써 진짜 정체성을 파악하는 것이 중요하다.
p.129
기존의 오프라인 유통업은 거대한 소싱 파워와 유통 매장의 입지 같은 이길 수 없는 파워게임이 있었다면 이커머스는 상황이 다르다. (중략) 온라인에는 판매자가 선택할 수 있는 이커머스 기업이 무수히 많다. (중략) 플랫폼은 판매자도 구매자도 우리 서비스로 오게 하기 위해서 많은 노력을 하게 된다. (중략) 중요한 포인트는 플랫폼이 항상 갑이 아니라는 사실이다.
p.155
프로덕트의 개념을 명확히 가진 IT 회사는 '프로덕트가 본질'이라는 개념을 모두가 암묵적으로 이해하고 있다. 프로덕트는 그 자체로 우리 사업의 매장이자, 사업의 형태이자, 접객 방식이자, 서비스를 제공하는 접점이자 사실상 우리 회사의 그 자체다. 그래서 IT 기업인 이커머스에서 일한다는 것은 전 직원들이 프로덕트를 잘 만들기 위해서 일한다고 해도 과언이 아니다. 이 가치를 잘 안다면, 우리의 사업을 최종적으로 만들어내는 소중한 개발자들을 외부 인원으로만 쓰는 모험은 감히 할 수가 없다.
p.228
서비스 기획자가 알아야 하는 내용은 코딩 언어가 어니라 '개발하는 사람들의 생각 구조'에 해당하고, 그러한 논리를 이해하고 문제 상황을 함께 해결할 수 있는 수준이면 된다.
p.241
역기획에 대한 오해부터 풀어야 한다. 가장 대표적인 오해는 두 가지다. 첫째, 베스트 프랙티스를 '학습하는 것'이라고 오해한다. (중략) 다른 회사의 좋은 서비스를 복제하는 것을 마치 역기획이라고 잘못 생각하는 경우도 있다. 하지만 프로덕트를 만들 때는 항상 우리 회사의 전략과 우리 서비스의 사용자를 기준으로 생각해야 한다. 이 부분에서는 안타깝게도 정답이 없다. (중략) 둘째, 좋은 UI나 UX만 분석하는 것이라고 오해한다. (중략) 좋은 UI의 뒤에는 복잡한 정책 설계와 일하는 방식이 숨어 있다. (중략) 일잘러들은 주어진 상황에서 최선의 방식을 찾아낸다. 나만의 해결책을 잘 찾아내려면, 최고의 상황에서 최고를 찾아내는 것이 아니라 내가 처한 상황에서 부족한 부분과 그 이유를 찾아낼 수 있어야 한다.
p.252
이커머스의 인재가 되는 두 번째 방법은 '배운 것을 기록으로 남기는 것'이다. 직접 조사한 것과 현직자에게 들은 내용, 공부한 내용들을 자신의 것으로 만드는 가장 쉬운 방법은 글로 다시 쓰면서 기록을 재생산하는 것이다.
서비스를 성공시키는 기획자의 비법노트 / 조이 / 2022.05
발췌한 부분이 없는 이유가 이 책이 별로여서는 아니다. 기획자가 되기부터 리서치, 문제 정의, 상위기획, 개발, 테스트, 론칭, 운영, 포트폴리오 만들기, 공부법 등 없는 내용이 없는 실무 중심 책이다. 다만 시니어인 내 관점에서는 건너뛸 수 있는 부분이 많기 때문이다. 정말 좋은 책이므로 꼭 사서 읽어보자.
서비스 기획자로 일하고 있습니다 / 강승훈 / 2022.09
여러 측면에서 가장 추천하는 책이다. 간결한 글 솜씨, 적절한 사례와 보조 자료, 커리어 조언 등등 좋은 내용으로 가득하다. 1순위 책으로 손색이 없다. 특히 기록하는 습관에서 배울 점이 많았다. 역시 경험을 잘 기록하는 사람이 좋은 책도 쓸 수 있구나 생각했다.
p.11
서비스 기획자는 소통관 역할을 해야 하기 때문에 '귀차니즘'이 일상화된 사람들에게는 권하지 않는 직업 중 하나입니다. 각기 다른 부서와 고객에게서 전달된 애로점을 취합하여 개발자와 디자이너에게 전달하는 역할을 하다 보면 다양한 유형의 요구사항들이 쏟아지게 됩니다. 기획자로서 이러한 것들을 정리하지 않고 그대로 디자인이나 개발에 필요한 다른 업무 파트너에게 전달하기만 한다면, 이들은 메신저와 다를 바 없습니다.
p.55
기획자가 개발에 필요한 개발지식이 있어야 하는 이유를 다시 정리해 보면 개발자와 소통을 원활하게 함으로써 내가 작성한 기획서를 좀 더 쉽게 설득할 수 있고, 설사 개발자가 불가능하다고 하더라도 개발 가능한 범위에서 기획서를 수정할 수 있기 때문이다. 그리고 새로운 기술을 도입하거나 솔루션을 활용할 때 이것을 우리 서비스와 접목시킬 수 있는 방안을 도출해 낼 수도 있다. 즉, '개발자로서의 개발'이 아닌 '기획을 잘하기 위한 개발', '개발자와 원활한 소통을 위한 개발'에 초점을 맞춰야 한다. 이를 위해 가장 기초가 되는 개발용어는 크게 5가지다. 클라이언트와 서버, DB, API, 그리고 백오피스라는 용어의 뜻만 정확히 이해하고 있으면 개발자와의 회의에서 최소한 헤멜 일은 없을 것이다.
p.163
스토리보드 작성과 데이터 분석 등 기획자가 하는 일련의 업무를 살펴보면 '여러 사람의 생각을 정리하고 결과를 도출해 구조화시키는 것'이라고 볼 수 있다. MBTI로 친다면 기획자는 좋든 싫든 'T'의 역량을 길러내야 한다는 것을 반증한다. 그리고 이런 기획자의 노력은 서비스를 만들어 가는 이해관계자들의 시간과 에너지를 아껴줄 수 있다. 따라서 개발지식을 숙지하는 것은 물론 뒤죽박죽 섞인 현업부서의 요구사항을 편하고 이해하기 쉽게 글로 정리하는 것, 온오프라인을 넘나들며 수많은 사람들 속에서 이슈 포인트를 도출하고 프로세스의 비효율화를 제거할 수 있는 역량이 필요하다. 이렇게 기획자의 협업은 말과 글에서 결정된다고 해도 과언이 아니다.
p.238
지극히 개인적인 의견이지만, 학교나 학위는 기획자로 일하는데 큰 의미가 없어 보인다. (중략) 배울 기회가 멈췄다고 생각하기 전에 '내가 회사에서 더 배울 수 있는 부분은 없는가?'를 먼저 고민하는 것이 우선시 되어야 한다. (중략) SI 등 에이전시의 장점은 여러 개의 프로젝트를 단기간에 경험할 수 있어 연차가 쌓였을 때 이직의 폭이 넓다는 장점이 있다. (중략) 다만 운영을 비롯한 기획 경험이 부족할 수밖에 없다. (중략) 인하우스 기업은 기획부터 구축, 운영을 경험할 수 있어 한 서비스에 대한 이해도를 높일 수 있다.
p.242
기획자가 되려면 기획 업무에 가까워질 수 있는 부서로 전환배치를 한 뒤, 운영과 기획, 그리고 개발에 대한 이해를 쌓아가는 것이 필요하다는 것이다.
제품의 탄생 / 오이카와 다쿠야, 소네하라 하루키, 고시로 구미코 / 2022.12
일본 책 특유의 구성이 있다. 챕터 구분 상세하고, 도표와 그림이 많다. 백과사전처럼 다양해서, 모르는 부분이 있을 때 찾아보기 좋을 것 같았다. 우리나라와 달리, 팀 빌딩이나 리더십에 대한 내용도 많다. 해외는 PM이 팀 매니저인 경우가 많은 것 같다.
p.222
작은 CEO라고도 불리는 PM이 CEO와 가장 다른 점은 권력과 보상을 활용한 리더십을 발휘할 수 없다는 것이다. (중략) 한편 PM은 자신의 팀 조직 휘하에 부하 직원들을 거느리긴 하지만 엔지니어나 디자이너 등 프로덕트 팀 구성원에 관한 인사권을 행하는 경우는 드물며, 명시적 권한이 주어지지 않는 경우가 대부분이다. (중략) 이러한 상황에서 PM이 영향력을 행사하기 위해서는 신뢰, 열정, 공감, 논리라는 4가지 능력이 필요하다.
프로덕트 매니저는 무슨 일을 하고 있을까 / 개점휴업, 최민 / 2023.01
분량이 많지 않은데도 핵심을 참 잘 다루고 있다. 특히 목적 조직에 대해 구체적으로 서술한 점이 흥미로웠다. 내게는 자기 계발 방법을 서술한 챕터 9가 가장 도움이 많이 되었다.
p.28
개발자도 담당하는 제품의 영역에 따라 업무 범위가 각기 다르다. 우선은 사용자와 가장 가까운 단면을 담당하는 프런트엔드 개발자가 있다. 세부적인 구분으로는 웹 담당과 앱 담당을 구분할 수 있고 앱의 경우, 안드로이드와 iOS로 나뉠 수 있다. 프런트엔드와 한 쌍인 백엔드 개발자는 데이터베이스, 서버, API, 인프라 등 세부적인 담당에 따라 나뉘기도 한다. 백엔드는 '무엇을' 사용자에게 보여주거나 제공할지를 고민하고 프런트엔드는 '어떻게' 보여줄지에 대해서 다룬다고 생각하면 쉽다.
p.37
한국은 인터넷이 상용화된 지 채 30년이 되지 않았고 개인이 스마트폰을 보유하게 된 것도 15년이 되지 않았다. (중략) 2013년 당시에는 '기획자는 필요 없다'는 기획자 무용론이 업계에서 한참 유행했다. (중략) 사업이나 내부 요구사항을 취합하여 그것을 시스템으로 구현하는 말하자면 해달라는 대로 하는 식의 업무가 많았다. (중략) 2015년 즈음 웹 기획자라는 표현을 대체하는 서비스 기획자라는 표현을 쓰기 시작했다. (중략) 2018년부터는 프로덕트 매니저라는 호칭을 적극적으로 사용하기 시작했다. (중략) 단순히 일정 관리나 화면 설계서 작성을 하는 것이 아니라 제품 전반을 책임지는 역할로 프로덕트 매니저 업무의 범주와 위상이 달라졌다. (중략) 데이터 기반의 의사결정 방식이 크게 인기를 끌면서 그로스해커로서의 역량이나 기본적인 데이터 독해 능력 역시 프로덕트 매니저가 갖추어야 하는 능력 중 하나가 되었다.
p.51
IT 업계에서 프로덕트 매니저가 하는 일은 적절한 시기에 의도한 대로 적당한 규모의 제품 또는 기능을 출시하고 다음 이터레이션에서는 사용자에게 보다 유의미한 가치를 전달할 수 있도록 노력하는 것이다.
p.54
요구사항 정의서가 방향을 정하는 것이라면 실제로 어떻게 그 방향으로 나아갈지를 결정하는 것은 화면 설계서이다. 두 문서는 서로 영향을 주고받기 때문에 하나의 문서로 작성되는 경우가 잦다. (중략) 주니어 프로덕트 매니저라면 당장 기획서를 작성해야 할 때 자신의 스타일이나 커뮤니케이션 방식이 적립되어 있지 않기 때문에 두려울 수 있다. 그렇다면 가장 먼저 해야 하는 일은 속한 조직에서 사용하는 문서를 확인하는 것이다. 조직에서 통용되는 문서의 종류와 기준은 회사의 조직문화가 강하게 연결되어 있다. 가장 효율적인 커뮤니케이션 방식은 기존의 방식이다.
p.55
기획서의 본질은 커뮤니케이션이라는 점을 상기하자. (중략) 프로덕트 매니저의 역할은 기획서 작성 그 자체가 아니라 기획서를 통해서 전달하고 싶은 바를 전달하고 이에 대한 합의를 이끌어내어 최종적으로 제품을 만드는 과정을 반복하는 것이다.
p.65
요구사항 정의서는 작성하는 것이 논의의 시작이다. 이 문서를 기준으로 동료와 협의를 거쳐 최종 합의점에 도달하는 것이 궁극적인 목표이다. 따라서 내용 자체를 완성도 있게 만드는 것도 중요하지만 이에 대한 전달과 공유도 염두에 둘 부분이 있다. (중략) 프로덕트 매니저가 작성하는 다수의 문서는 피드백을 빨리 받을수록 좋다. 프로덕트 매니저는 제품 구현의 전반을 담당하기 때문에 문서 작성보다 빠른 합의를 이루는 데에 집중하는 것이 좋다. 많은 동료가 빠르게 문서를 파악할 수 있도록 가독성을 높 인 문서를 작성하자. (중략) 요구사항 정의서는 논의의 토대이기 때문에 여지를 열어 놓는 것이 중요하다. (중략) 나의 의견과 사용자의 의견이 다를 수 있다는 것을 항상 전제로 하고 의견을 제시할 수 있도록 하자.
p.66
요즘 업계에서 데이터 기반의 의사결정 방식이 화두가 되면서 데이터 독해력에 대한 중요성이 높아졌다. 제품의 성패를 결정하는 사용자를 파악할 수 있는 방법 중 하나이기도 하고 일부 의사결정권자의 직감으로는 더 이상 제품 혁신을 할 수 없기 때문이기도 하다. (중략) 사용자가 무엇을 원하고 필요로 하는지 알아내는 수많은 접근 방법 중 하나가 데이터이다.
p.183
프로덕트 매니저가 작성하는 문서와 제시하는 의견이 정답일 필요가 없다는 사실을 상기하자. (중략) 일방이 정답을 제시하고 그대로 구현을 하는 것이 아니라 협업을 통해 최상의 해결책을 찾아간다. 그러므로 가능하다며 완벽해야 한다는 부담감을 줄이고 제품팀과의 매끄러운 커뮤니케이션 방식을 습득하는 것이 좋다. 지시하는 방식의 커뮤니케이션이 아니라 논의의 토대를 만들고 보다 많은 사람이 의견을 내고 그중에서 유효한 의견을 골라내고 선별하는 능력을 신장하자.
p.185
프로덕트 매니저는 제품팀이 전략에 대하여 공감하고 믿을 수 있으며 궁금한 점이 있을 때 언제나 물어볼 수 있는 환경을 구성할 책임이 있다. (중략) 외향적이거나 사람과 어울리는 것을 즐기는 사람만이 좋은 프로덕트 매니저가 되는 것이 아니다. (중략) 이따금 완벽주의적 성향 뒤편에는 부정적인 피드백을 수용하지 못하는 거부감이 있을 수 있다.
2. IT 교양
거의 모든 IT의 역사 / 정지훈 / 2020.11
2010년 11월에 출간된 책을 개정한 버전이다. 스티브 잡스, 팀 쿡, 빌 게이츠, 세르게이 브린, 래리 페이지, 마크 주커버그, 제프 베조스, 일론 머스크 등 지금도 권좌(?)를 지키고 있는 창업가와 기업가들의 이야기가 흥미진진하다.
비전공자를 위한 이해할 수 있는 IT지식 / 최원영 / 2020.07
처음 PM이 되면 좌절하게 되는 포인트가 개발자들의 외계어이다. 예전에는 시간이 해결해 줬지만, 요즘은 가르쳐주는 사람이 없어서 괴로워하는 초보 기획자들이 많다. 이 책은 클라이언트와 서버, API, JSON, 웹, 데이터베이스, 프레임워크와 라이브러리 등을 알기 쉽게 정리해 준다. 적절한 시기에 적절한 제목으로 출간되어 많이 팔린 책이다. PM 추천 도서 목록에 항상 있을 만큼 도움 되는 책이다.
오늘도 개발자가 안 된다고 말했다 / 김중철, 김수지 / 2021.04
자극적인 제목이라 출간되자마자 구매했던 기억이 난다. 기획자와 디자이너가 공동저자이다 보니 막상 우리가 듣고 싶은 개발자 코너가 빈약하다. 4명의 개발자와 인터뷰한 내용뿐이다. 그래도 기획과 디자인에 대해서 쉽게 알려주고 있어서 추천할만하다. 커뮤니케이션과 협업 매너를 고민하는 직군은 항상 기획자뿐이라는 것이 조금 씁쓸하다.
p.85
화면 설계서는 개발 진행 시에 발생할 수 있는 이슈나 정책 보완점을 미리 고려하고 문제 발생 시에 다른 우회 방안을 찾는 등 협업자들의 의견을 수렴하고 개선하는 커뮤니케이션을 위한 문서다. (중략) 신입 기획자가 많이 하는 실수 중 하나는 화면 설계서에 아이디어를 담는데 온 신경이 쏠려있다는 것이다.
p.93
설계서를 자세히 읽고 리뷰에 참여하는 개발자들은 10명 중 5명이 될까 말까 한다. 협업은 목적과 의도를 공유하는 것부터가 시작이라고 했다. 리뷰를 요청할 때도 마찬가지로 이유나 목적을 함께 설명해주어야 한다. 이와 더불어서 원활한 리뷰를 진행할 수 있도록 하는 팁이 있다. 리뷰를 요청하기 전에 틈틈이 중간 과정을 공유하는 것이다. (중략) 기본적으로 개발자를 설득의 대상으로 보는 것이 좋다. 개발자는 기획 의도에 공감하지 못하면 목표 의식이 약해진다. 실제 리뷰와 개발을 진행하기 전에 배경을 설명해 주면 커뮤니케이션이 편해진다. (중략) 또 한 가지 중요한 것은 리뷰를 요청할 때는 항상 정중하게 부탁하는 입장으로 요청하는 것이다. 기본이지만 잘못 쓴 단어 하나가 개발자의 기분을 상하게 하기도 한다. 텍스트는 오해하기 쉽다는 점을 기억하자. 부탁의 자세는 자신을 낮추는 게 아니라 예의이자 처세술이다.
오늘부터 IT를 시작합니다 / 고코더 / 2022.08
읽는 내내 글을 참 예쁘게 쓰는 분이라는 생각이 들었었다. IT의 역사와 흥미로운 주제들을 잘 풀어냈다. EBS의 지식채널-e 같은 느낌으로, 모르는 것을 찾아볼 때 좋다. 일반인들도 편하게 읽을 수 있다.
3. 전략
편집광만이 살아남는다 / 앤드류 S. 그로브 / 2021.06
인텔의 전설적인 CEO, 앤디 그로브가 쓴 책이다. 세상이 너무 빨리 변하니 최신 트렌드와 사례에만 집중하는데, 이 책은 오래되었지만 지금도 통하는 맥락이 있다. 1988년에 집필했던 책이 2021년 6월 번역된 것은 좀 의아하다. 전략적 변곡점에서 메모리 사업 철수와 CPU 집중을 결정했고, 이것이 전설의 시작이었다. 1990년대 닷컴 버블, 2010년 전후의 스마트폰 혁명, 현재의 AI 기술까지 와닫는 것이 많았다. 좁게는 내가 속한 이커머스 경쟁 판도 변화 속에서 기존 사업자들이 속수무책으로 당하는 것을 보고 위기감을 느꼈었다. 275 페이지에서 '당신의 커리어가 당신의 사업이다'라는 문구를 보고 머리를 한 대 맞은 느낌이었다. 전략적 변곡점은 개인의 커리어에서도 적용된다. 나는 이 책으로 커리어를 대하는 자세가 달라졌다.
p.68
전략적 변곡점이란 구조, 사업 방식, 경쟁 방식이 옛것에서 새것으로 전환되면서 힘의 균형이 이동할 때를 가리킨다. 전략적 변곡점에 이르기 전에는 모든 것이 예전과 다를 바 없지만, 그것을 지나면 새로운 양상이 펼쳐진다.
p.179
최근의 경영 이론을 살펴보면 반드시 데이터에 근거해 논쟁을 벌여야 한다는 주장을 발견할 수 있다. (중략) 그러나 데이터는 과거에 관한 것이고 전략적 변곡점은 미래에 관한 것이다. (중략) 최근 떠오르는 트렌드를 다룰 때는 합리적인 데이터를 대입하려들기보다는 경험적 관찰과 본능에 의존하는 편이 낫다.
p.200
많은 스포츠 경기에서 보듯 '타이밍이 전부'다. 일찍 행동을 취하면 효과를 발휘한다. 하지만 동일한 행동이라도 뒤늦게 실행하면 미흡한 결과를 얻는 경우가 많다.
p.275
직장인이든 자영업자든 각 개인은 개별 사업체라는 생각을 나는 오랫동안 가지고 있다. 당신의 커리어는 곧 당신의 사업이고, 당신은 그 사업의 CEO다. 대기업 CEO와 마찬가지로 당신은 시장의 힘에 대처해야 하고, 경쟁자와 맞서 싸워야 하며, 보완자의 강점을 활용해야 하고, 현재의 일이 다른 방식으로 이루어질 가능성을 늘 경계해야 한다. 커리어에 손상이 가지 않도록 하고 경영 환경의 변화로부터 이익을 얻도록 스스로를 이끄는 것은 당신의 책임이다. (중략) 가장 중요한 것(그리고 가장 어려운 것)은 자신이 처한 환경에서 일어나는 변화에 늘 경계를 늦추지 않는 태도다.
p.281
커리어 변곡점을 성공적으로 헤쳐 나가느냐 여부는 타이밍 감각에 달려 있다. (중략) 실제로 기존 일자리의 안전한 거품 속에서 시도하는 변화, 즉 상황이 좋을 때 시도하는 변화는 당신의 커리어가 파탄 나기 시작하고 나서야 시도하는 변화에 비하면 별로 고통스럽지 않을 것이다. (중략) 불길한 징조를 예감한 때부터 커리어 변곡점이 닥치기 전까지 기간은 소중한 시간이다. 달리기 선수가 경주를 위해 몸을 만들듯이 이 기간은 변화를 위해 몸을 만들 시간이다. (중략) 실험은 변화를 준비하기 위한 핵심 방법이다. (중략) 새로운 세계에 적응하고, 활발히 활동하는데 필요한 스킬을 배우고, 업적을 이루는 데 모든 에너지를 쏟아라.
디커플링 / 탈레스 S. 테이셰이라 / 2019.09
전통적인 기업에서 플랫폼 기업으로 이직을 마음먹은 가장 큰 계기가 된 책이다. 기존 강자들이 파괴적 혁신 기업들에게 뜯어 먹히고 있지만, 근본적인 변화를 이끌어내기 힘들다고 판단했기 때문이다. 경쟁 환경이 바뀌었기 때문에, '동종업계'라는 기준이 무너졌다. 저자는 그 근간에 고객의 욕구가 있다고 주장한다. 특히 혁신 기업들에게 공격받고 있는 산업 속에서, 전통 기업에 근무하고 있다면 꼭 읽어보길 권하고 싶은 책이다.
p.20
내가 이 책을 쓰기로 마음먹은 이유는 하버드 경영대학원에서 10년 동안 교수로 재직하면서 들어온 말 때문이다. 학자와 경영인, 컨설턴트들은 판에 박힌 듯 소매업, 교통, 의료를 비롯해 소비재와 공산품에 이르기까지 다양한 시장에서 발생하는 파괴의 주요 원인으로, 그리고 파괴에 대응할 수 있는 해결책으로 기술을 강조했다. 하지만 내가 20여 개 산업을 대상으로 연구한 결과로는, 카메라 업계 변화가 보여주듯, 기술이 아닌 고객이 시장 파괴의 주범이었다. (중략) 나는 고객을 진정으로 이해할 수 있도록 고객 가치사슬(CVC)을 세심하게 그려볼 것을 제안한다. 그런 다음 고객 가치사슬을 디커플링, 즉 분리할 것을 제안한다. (중략) 결국 고객이 원하는 것은 가치다. 기업은 고객이 원하는 가치를 다음 세 가지 중 하나로 제공할 수 있다. 가치 창출 활동을 하거나, 가치 잠식 활동을 제거하거나, 가치에 대한 대가 부과 활동을 줄이는 것이다.
p.51
그토록 위협적이라는 파괴적 기업들이 기존 기업의 모든 사업 부분을 대체하는 것이 아니라 사업의 작은 일부만을 대상으로 삼고 있단 사실이었다.
p.55
파괴자들은 CVC의 단계들을 이어주는 '연결고리의 일부를 깨트린 후' 그다음에는 자기가 그 자리를 차지하기 위해 하나 또는 몇 개의 단계를 '훔쳐가는' 방식으로 위협을 가한다는 점이다.
p.128
현대 비즈니스 전략은 회사의 초점을 정조준한 채 경쟁 구도와 전망을 평가하고 경쟁사에 대응한다. (중략) 전통적인 경쟁 전략 프레임워크는 고객이 얼마나 중요한 역할을 하는지에 대해 크게 주목하지 않았다. (중략) 고객보다 경쟁사를 강조한 이유는 분명 데이터의 접근성, 그리고 해석과 관련이 있다. 자기가 속한 시장에서 경쟁사가 무엇을 하는지 알아내기는 비교적 쉬운 반면 고객의 동기와 행동을 파악하기란 상당히 힘들다. (중략) 하지만 오늘날의 시장에서 여러 산업에 걸쳐 있는 기존 기업 입장에서는, 규모가 크고 예측 가능한 상대 한두 곳이 아니라 수십 곳이 넘는 소규모의 민첩하고 예측하기 힘든 도전자들과 맞서야 할 때가 종종 있다.
p.159
디지털 디스럽션이라는 흐름에는 공통 패턴이 있다. 파괴를 주도하는 주체는 기술이 아니다. 상품과 서비스의 구입 부담을 줄이려는 고객의 욕구다. 기술이 중요하지 않다는 말이 아니다. 다만 기술은 파괴를 일으키는 주범이 아니라 파괴를 가능하게 하는 조력자 역할에 그치는 경우가 종종 있다는 뜻이다.
규칙 없음 / 리드 헤이스팅스 / 2020.09
지금은 이래저래 어려움을 겪고 있지만, 2022년까지 엄청나게 성장했던 넷플릭스의 조직문화 이야기를 담은 책이다. 인재 밀도 높이기, 규칙 없애기, 즉각적이고 공개적으로 피드백하기 등 모든 것이 놀라웠지만, 만약 내가 이 회사에 간다면 잘 적응할 수 있을지는 회의적이었다. 끊임없는 혁신, 누구보다 빠른 속도를 추구해야만 하는 회사라면 분산 의사결정 구조가 적합하고, 이를 위해서는 최고의 인재들이 규칙 없는 환경에서 일해야 한다는 사고방식과 실행력이 대단하다.
어떤 책이 좋은지 나쁜지를 평하는 것은 무의미하다. 모든 책에는 반드시 내가 모르는 내용이 하나라도 있기 마련이다. 책에는 어떤 분야에서 성공한 사람들의 정수가 담겨있다. 글 한 줄도 쓰기 어려운데, 책을 쓴다는 것은 얼마나 많은 경험과 지식, 노력이 필요하겠는가. 그래서 나는 콘텐츠 생산자들을 존경한다. 특히 책을 쓴 저자들은 더더욱.
이렇게 귀한 책들을 쓰신 분들 마음처럼, 이 글도 누군가가 읽고 도움 받는다면 뿌듯할 것 같다.
