한빛미디어

 이번에 사이드 프로젝트를 하면서 사실상 처음으로 PM을 맡게 되었다. 서비스 기획뿐만 아니라 협업을 위한 환경 세팅, 일정 산정뿐만 아니라 팀원이 개발에 집중할 수 있는 환경을 만들어주고 싶어 나름의 노력을 기울였다. PM 직무를 준비한다고 해놓고 정작 PM이 하는 일을 잘 몰랐던 것 같고 서비스 기획만 잘 한다고 좋은 PM이 되는 것은 아니라는 생각도 들었다. 프로젝트 막바지에 들어서 완독한 이 책, 한빛미디어 서평단 활동의 첫 책이 프로덕트 관리에 대한 것은 배움의 기회였던 것 같다. 책에서 인상적이었던 것은 프로덕트와 PM을 바라보는 저자의 시선이었다. 이제껏 기획 단계에서 배웠던 방법론을 완전히 깨부수는 느낌. 저자는 하나의 큰 방향성이나 목표를 갖고 가는 것은 중요하지만 언제 어디에서 일어날지 모르는 상황을 받아들이고 넘길 수 있는 유연함을 가지는 것이 PM의 역할이라고 말한다. 시니어의 관록이 묻어 나오는 느낌이랄까. 아직 커리어를 시작하기도 전인 주니어로서 이해하기 쉽지는 않았지만 배우고 싶은 마음가짐이다. 아래는 책을 읽으면서 내가 깨달은 세 가지!

1. 문서는 문서일 뿐이다

훌륭한 프로덕트 매니저는 로드맵을 자신의 노력과 중요성을 담은 성스러운 기념비가 아니라

팀에 도움이 되는 대화 시작점의 문서로 취급한다.

<프로덕트 매니지먼트의 기술> Chapter 9 中

프로덕트를 기획해 팀원에게 어필하기 위해선 그럴듯한 계획표가 있어야 한다. 이 프로덕트가 언제까지 이렇게 완성이 되어야 하고, 그렇기 위해선 매주 최소한 이만큼의 시간을 투자해야 한다고 강조해야 한다. 계획표를 빽빽하고 세심하게, 멋들어지게 작성하면 개발자에게 어필이 될 것이라고 믿었고, 실제로 나름의 효과를 발휘할 때도 있었다. 그러나 사람이 모여서 하나의 결과물을 만들 때 사람 일은 마음대로 되지 않는다. 예상하지 못한 상황이 일어나면 당황하고 급박해지는 내게 저자는 이런 일은 흔하니 받아들여야 한다고 말한다. PM은 판단하고 고민하는 직업이다. 그러나 사람과 함께하는 직업이기 때문에 소통하지 않으면 고민이 의미가 없어진다. 결국 소통이 먼저이며, PM은 저자의 말대로 상사가 아니다. 자신의 아이디어나 문서에 매몰된 PM에게 '메뉴는 음식이 아니다.'라고 말한 저자의 일갈이 기억에 남는다. 이론을 실제로 착각하고 사람을 존중하지 않으면 PM은 살아남을 수 없다. 이번 프로젝트에서 별일이 다 있었지만 서비스를 완성할 수 있었던 것은 기획안도 무엇도 아니라 채팅 기능을 완성하기 위해 새벽까지 에러를 고친 팀원들 덕분이었다. 대화하는 기획자가 되어야겠다.

2. 애자일도 서 꿰어야 보배다

중요한 점은 기존 체제에 도전할 만큼 인기가 있는 아이디어는 결국 기존 체제에서 채택한다는 것이다.

'다음 어떤 것'이 애자일처럼 인기를 얻게 되면

아마도 우리는 또 다른 '다음 것'이 필요하다는 말을 다시 하게 될 것이다.

<프로덕트 매니지먼트의 기술> 51p 中

 동아리 면접을 볼 때 '워터폴과 애자일 중 무엇을 선호하냐?'라는 질문을 받았다. 유니콘의 바람을 타고 애자일의 긍정적인 바람을 타는 추세였기 때문에 나도 그런 줄 알았다. 그래서 '서비스 론칭까지 해보고 싶기 때문에 애자일을 선호한다'라고 답했다. 면접관으로 질문해 주신 스터디장님께서 말씀하시길 정답은 없지만 애자일이 무조건 좋은 것은 아니라고 말씀하셨다. 단기간에 체계적으로 MVP를 완성하기엔 순차대로 개발하는 폭포수 방법이 나을 수도 있다고. 이상적으로 생각했던 방법이 무조건 어느 상황에나 들어맞는 게 아니라 프로덕트와 팀의 상황에 따라 유연하게 적용해야 효과가 있음을 깨닫게 되었다. 하나의 서비스를 완성하는데 완벽한 방법이 없고, 애자일 역시 칼같이 빠르게 일을 진행하기보다 회고를 가지며 팀을 점차 성장시키도록 노력하는 것이다. 하나의 방법론을 적용하는 데 있어 PM은 좋아 보이는 것을 무작정 추구하고 적용할 것이 아니라 팀과 전체적인 방향을 폭넓게 보고 소통하는 것이 먼저인 것 같다. 실제로 책 곳곳에 현직자의 오해나 대화를 부정하는 부분이 삽입되어 있는데 업무에 대한 고정관념을 타파하고 회고하기 좋은 부분이었다. 나는 애자일을 너무 대단한 것으로 생각했을지도.

​

3. 나(PM)를 쓸모없는 존재로 만들어라

조직 관리에 탁월한 프로덕트 매니저는 "지금 당장 무엇을 해야 하나요?"라는 팀원의 질문을 무언가 잘못된 신호로 받아들인다. (...중략)

조직을 생각하는 프로덕트 매니저는 문제가 발생하면 '지금 당장 이 문제를 어떻게 해결할 수 있을까?'라고

고민하는 데 그치지 않고 '어떻게 하면 이런 일이 다시 발생하지 않도록 할 수 있을까?'라고 고민한다.

<프로덕트 매니지먼트의 기술> 52p 中

 내가 어떤 것을 이끌거나 나의 아이디어를 기반으로 하는 일이라면 '내가 아니면 안 돼.'라는 사고방식이 생기는 것 같다. 그래서 사실 이번 프로젝트가 불안했다. 기획안을 작성하고 개발 파트장을 선정해 파트 중심으로 개발 과정이 운영되도록 했는데, 'OO 기능 구현되었습니다!', 'API 연결하는 중입니다!'라는 메시지를 받아보는 것 외엔 내가 할 게 없었다. PM이라는 타이틀에 맞지 않게 기여도가 낮다는 판단이 들어 불안했다. 그러나 저자는 PM에게 팀원이 팀 내부 업무에 대해 물으면 가장 심각하고 좋지 않은 사례라고 말한다. 그러니 나에게 별말이 없는 게 오히려 프로젝트가 잘 돌아가고 있다는 것이었다. PM으로서 사람과 리소스를 효율적으로 분배하는 것 역시 PM의 중요한 역할 중 하나임을 깨닫게 된다. 나는 팀 내 시스템이 자체적으로 잘 돌아가기 위해 어떤 노력을 기울여야 할까? 많은 팀을 만나보고 많은 시스템을 눈으로 본다면 나에게 맞는 리더십의 형태를 찾을 수 있지 않을까. 취준생인 현재 신분으로선 더 많은 프로젝트와 더 많은 회사를 볼 기회가 필요한 것 같다. 책 챕터에는 무언가 연습이나 회고가 필요한 사람이 자신을 돌아볼 수 있도록 체크리스트를 제공하고 있다. 자신의 커리어에 TO DO List가 필요한 취준생, 초기 PM이라면 이 목록이 아주 유용할 것 같다.

당신의 로드맵은 당신만의 로드맵이 아니며, 프로덕트 스펙 문서는 프로덕트가 아니며, 사용자 스토리는 사용자가 아니다.

세상에서 가장 인상적이고 훌륭한 '메뉴'를 만들려고 하지 말고 맛있는 '음식'을 만드는 데 집중하자.

<프로덕트 매니지먼트의 기술> 191p 中

 결국 중요한 것은 그 어떤 것이든 지금의 팀과 프로덕트에 실질적으로 효과를 발휘하는지 고민하는 것이다. 아무리 좋은 것이라도 현실에 살지 않으면 쓸모가 없다. 그동안 실무 경험보단 사이드 프로젝트를 병행하며 MVP 조건을 충족하는 행복한 결말만 생각하면서 현실을 보지 못했을지 모른다. <프로덕트 매니지먼트의 기술>은 현실에서 PM이 팀원과 성공의 경험을 어떻게 나눌 수 있을지, 사용자의 일상에서 프로덕트를 어떻게 녹아들 수 있게 할지 움직여야 한다. 아주 치밀하게 움직여야 하는 듯 보이지만 꺾이지 않되 부러지지 않게 이리저리 흔들리는 유연함도 보여야 한다. 물론 저자의 이론서이기 때문에 실무에서는 이것을 어떻게 적용할 수 있을지 고민될 법한데, 저자가 인터뷰한 PM들을 비롯해 국내 대기업부터 스타트업까지 다양한 업무 상황에서 좋은 프로덕트를 만들기 위해 노력하는 PM들의 인터뷰를 접할 수 있다. 오늘도 좋은 서비스를 만들기 위해 노력하는 IT 업계의 모든 사람들, 그리고 PM들에게 존경과 감사를 표한다.