신입PM 포트폴리오 리뷰(6): 산출문서가 중요할까?

화면설계서, IA, WBS는 핵심이 아니다

  이름이 뭐가 그리 대수인가요

   세간엔 여전히 PM이 무엇이며 PO가 무엇인지, 무엇이 PM의 일이며 무엇이 아닌지, 그 기원이 무엇인지 등의 분석 또는 갑론을박이 이어진다. 솔직한 심정으론 그게 뭐 대수인가 싶다. 어차피 역할도 이름도 조직에 따라 다 다른 것을.

   어느 물리학 교수님의 유튜브에서 유사한 결의 Q&A가 오고 갔다. "왜 진공 상태에서의 빛의 속도를 하필 초속 30만 km라고 부르냐고요? 초속 1m라고 불러도 전혀 상관없습니다. 전혀요. 대신 우리 주변의 속도를 뭐라고 부르기가 어려워지겠죠." 비단 PM뿐만이 아니다. 분석가도, 사업개발자도, 디자이너도 다르지 않다. 이름도, 척도도, 역할과 책임도 절대적인 건 없다.

   그럼에도 사회적으로 통용되는 업의 본질 또는 조직의 수요를 생각해 보면 무엇이 조금 더  PM으로서 중요한 역할과 역량인지, 그러므로 부트캠프 등을 통해 신입 PM으로의 취업을 희망하는 지원자로서 포트폴리오에 강조하고나 강조할 필요가 없는 건 무엇인지는 생각해 볼 수 있다.

프로덕트 > 매니저

   프로덕트 매니저로서의 PM은 문자 그대로 제품과 관리를 담당한다. 제품이란 고객의 문제를 해결하고 가치를 제공하는 수단 또는 매개물이며, 이를 위해 제품을 기획 및  제작하고 고객에게 전달하기까지의 일련의 과정과 그 과정에 참여한 구성원을 조율하는 게 관리다.

   현실 업무에서야 무엇하나 중요하지 않은 건 없지만 그럼에도 하나를 꼽자면 제품이라고 생각한다. 모든 관리 업무의 시작이자 끝이 제품이니까. 애당초 제품이 없는데 관리할 게 무엇이 있을까. 물론 관리가 엉망이라면 제품 역시 좋을 리 없겠지만, 최소한 제품이 있는데 관리가 없다는 건 현실에선 성립하지 않는다

포트폴리오에 산출물이 중요하지 않은 이유

   그런 관점에서 봤을 때, 각종 강의며 도서, 부트캠프에서 가르치는 여러 산출물 양식-PRD와 화면설계서, 저니맵, IA, WBS와 백로그, Test Case 등-은 프로덕트 매니저에겐, 적어도 신입 지원자에겐 부차적이라고 주장해 본다. 이렇게 생각하는 데에는 몇 가지 이유가 있다.

   첫째, 본질이 아니다. 제품과 관리 중에 하나를 꼽는다면 제품이거니와, 더 나아가 문서 양식이 관리를 의미하지도 않는다. 관리란 방향을 풀고자 하는 문제를 풀기 위해 이해관계자에게 방향을 설명하고, 이게 왜 하필 지금 이만큼이나 필요한지 설득하고, 그 과정을 예측가능하게 만들고 리스크를 방지하며 이슈를 관리, 대응하며 일이 돌아가게 만드는 행위의 총체다. 문서를 쓰지 않는다고 관리가 되지 않는 게 아니고, 문서가 예쁘고 정확하다고 관리가 성공하는 게 아니다. 이해를 돕고 기억을 돕기 위해 약속한 형태와 약속한 수준으로 기록하고 전달하는 게 문서의 목적이다.

   둘째, 회사마다 다 다르다. 문서란 이처럼 일이 돌아가기 위해 이해관계자 사이에 약속한 형태와 수준으로 기록한 내용일 뿐이므로, 그 여부와 노하우, 이름과 수준이 조직마다, 팀마다, 프로젝트마다 제각각이다. 글 몇 줄로 PM의 기획이 마무리되는가 하면, 애자일 하다면서 기획자가 화면설계서를 일일이 그리는 경우도 있고, 때론 적당히 눙치는 경우도 있다. 그러니 암만 문서 양식을 배우고 이를 잘 만들어 포트폴리오에 넣어둔다 한들, 받아보는 이는 심드렁하다. 잘해야 "오, 노션 잘 쓰나 보네" 정도일까.

   셋째, 금방 배울 수 있다. 규모가 크든 작든, 사수가 있든 없든, 얼마나 디테일하든 혹은 엉성하든, 이미 제품이 있는 곳이라면 이를 관리하기 위한 문서가 이미 존재한다. 신입의 일은 입사와 동시에 전대미문의 완벽한 체계를 만들어내는 게 아니라, 기존의 체계를 파악하고 숙달하는데서 시작한다. 그리고 문서는 양식일 뿐이므로, 양식을 따라 작성하는 건 어렵지 않다. 그 내용의 타당함과 논리 정연함이 어려울 뿐이다.

신입에게 중요한 건 결과물이 아닌 이해력과 잠재력

   신입 PM이라는 게 애당초 가능한가? 채용이 있나? 하는 질문이 있지만, 그럼에도 불구하고 신입 PM을 채용하는 조직에서 신입에게 기대하는 건 어떤 완성된 결과물, 멋진 성공의 경험이 아니다. 실무자도 프로젝트가 어긋나면 결과물조차 나오지 않기도 하고, 성공보단 실패가 잦다. 그보단 얼마나 잘, 빨리 학습할 수 있는지, 얼마나 큰 잠재력을 갖고 있는지를 검증한다.

   그러니 산출물의 디테일함, 정확함 등은 중요치 않다. 부트캠프 또는 개인 프로젝트 과정에서 이 문서의 맥락과 핵심이 무엇인지 이해하고, 일련의 프로세스 내에서 문서를 한 번 작성해 보는 경험 자체를 가져간 뒤에, 정말로 중요한 부분-문제를 발굴하고 정의하여 합리적인 솔루션을 도출해 결과를 확인하고 가설을 검증하여 이를 토대로 다시 새로운 문제나 가설을 도출하는 과정-이 잘 정리되어 있는지를 점검해 보면 좋겠다. 제대로 된 조직이라면 본질이 흔들리는데 문서가 깔끔하고 디테일하다고 채용하는 곳은 없다.