PM, 제품팀, 로드맵
PM이 하는 일이라는 글에서 Product Manager라는 직무에 대해 저의 경험을 담아 이미 한번 정리한 적이 있는데요.
<인스파이어드>라는 책을 최근에 다시 정독하면서 저도 다시 개념적으로 정리가 된 부분이 있어 세 가지 정도의 아티클을 참고해 PM 직무를 설명해보려고 합니다!
Product Management – Start Here
https://www.svpg.com/product-management-start-here/
책 <인스파이어드>의 저자 마티 케이건이 이끄는 실리콘밸리 제품 그룹(SVPG)에 올라온 아티클인데요. PM이 던지는 세 가지의 질문에 대해 답변을 정리해볼께요!
PM의 전문성
https://www.svpg.com/the-product-manager-contribution/
'PM이 전문가인가?'하는 질문을 팀장님께 드린 적이 있었습니다. 디자이너, 엔지니어와 다르게 특별한 전문지식이 있는 건 아니기 때문에 보통은 제너럴리스트로 분류하니까요. 어떤 역량을 강화해서 팀에 기여하는, 소위 '잘하는' PM이 될 수 있을까하는 고민에서 나온 질문이었던 것 같습니다. 혹시 저와 같은 고민을 하셨던 분이라면 마티 케이건이 말하는 PM의 네 가지 전문성을 참고하시면 도움이 될 것 같아요.
PM의 전문성이라고 하면, 데이터에 대한 중요성은 많이 언급이 되고 있는 것 같은데요. 단순히 데이터 분석 역량을 기르는 것을 넘어서 고객/데이터/비즈니스/시장 전반을 이해하는 것이 중요하다는 걸 알 수 있습니다.
저는 신사업 팀에 있을 때는 데이터랄 게 없었기 때문에 정성적인 분석에 많이 의존할 수밖에 없었어요. 그때 팀장님께 '데이터를 쌓으면 이런 게 가능할 것 같다'라는 말씀을 종종 드리곤 했는데, 팀장님이 데이터를 찾기보다 왜 그것이 필요한지, 무엇을 알고 싶은지, 그걸 다른 방법으로 알아내려면 어떻게 해야하는지를 찾으라고 해주셨던 말씀이 다시금 기억이 나네요!
최근 만났던 스타트업 대표님도 데이터보다, 그 데이터나 여러 리서치, 시장 조사를 통해서 쌓은 직감, 통찰력을 강조하셨었는데요. '직감', '통찰력'이라고 하면 일종의 감으로 결정하는 것이니 근거가 없는 것이 아닌가 할 수 있는데, 오히려 많은 정보들을 가지고 더 높은 시각에서 바라보는 힘이라고 보는 것이 더 적절할 것 같다는 생각이 듭니다.
제품팀의 역할
보통 디자이너, 엔지니어라고 하면 각자 디자인, 프로그래밍만 할 것이라는 생각을 하기 쉬운데요. 이렇게 일하는 방식이 바로 '워터폴 방식'입니다. 워낙 워터폴, 애자일 같은 용어들이 익숙하다보니 '실제로 워터폴로 하는 데가 얼마나 많겠어, 다 애자일하게 일하지'라고 생각하는데, 실제로는 아직도 워터폴로 일하는 경우가 허다한 것 같습니다.
애자일이 '빠르게'와 동의어처럼 사용되어서라고 생각하는데요. 워터폴은 뭔가 모르게 구닥다리 방식으로 일하는 것을 칭하는 것 같고, 애자일은 신식이고 빠르게 일하는 것 같은 느낌을 가지고 있는 것 같아요.
마티 케이건의 설명을 읽어보면, 사실 둘의 큰 차이는 속도라기보다는 제품을 발견하고 실행하는 모든 단계에 디자이너와 엔지니어가 참여하느냐 아니냐의 차이라고 보는 것이 더 적합합니다. 그리고 무엇보다 제품팀이 미션팀으로서, 목표 달성을 위한 제일 나은 방법을 찾아내는 권한과, 그 결과에 대한 책임을 갖고 있느냐 아니냐의 차이입니다.
신사업을 진행하면서 디자이너, 엔지니어분들도 모두 제품 발견부터 실행까지 함께 진행했는데요. 이 과정에서 아무래도 디자이너인데 디자인보다 제품 기획 쪽을 더 많이 하는 것 같아서 고민이다, 혹은 엔지니어라서 개발할 시간도 없는데 인터뷰를 꼭 들어가야 하느냐하는 고민을 할 때가 있었습니다.
그런데 정말 신기하기도 인터뷰를 같이 했을 때 디자이너도 고객과 제품을 이해하게 되고, 엔지니어도 제품의 문제를 더 쉽게 발견하는 것에 더불어 해결의지도 확 올라가는 걸 느낄 수 있었어요. 물론 저도 매번 열정을 다시 불태울 수 있는 기회가 되었구요. 고객을 만나지 않는 팀은 점차 불씨가 꺼지게 되고, 반대로 고객을 만나는 팀은 열정의 수준이 올라가는 걸 실제로 체감할 수 있었습니다. 마티 케이건이 책 말미에 정리한 좋은 제품팀 / 나쁜 제품팀에서 나온 내용을 잊지 말아야겠다는 생각이 듭니다.
좋은 제품팀은 최종 사용자 및 고객과 매주 직접 만나고, 최신 아이디어에 대한 고객들의 반응을 확인한다.
나쁜 제품팀은 그들 자신이 고객이라고 생각한다.
로드맵이 망하는 이유
https://www.svpg.com/product-fail/ https://www.svpg.com/product-vs-feature-teams/
저는 애자일하게 일하고 있다고 착각하기 쉬운 이유가 바로 툴 사용에 있다고 생각하는데요. 스프린트로 팀을 운영하고, 백로그를 관리하고, 로드맵을 가지고 있으니 애자일한 것 아닌가로 생각할 수 있는 것 같아요. 저도 그렇게 생각했구요.
하지만 문제는 '이번 분기에 얼마의 성과를 내겠다'라는 OKR을 세워두었음에도 불구하고, 그 OKR과는 별개로 '이번 분기에 이런 프로젝트를 하겠어'라는 백로그가 함께 있기 때문에, 사실상 제품팀은 성과를 내기 위해 일하는 미션팀이 아니라 결과물을 만들기 위한 용병팀으로 일하게 됩니다. 마티 케이건은 이런 방식이 실패하는 이유를 아래 10가지로 설명하는데요.
아이디어 (1) 뛰어난 아이디어를 한번에 정답 풀듯이 가져오기 어려움 (2) 권한 위임이 안되므로 제품팀은 열심히 시킨 걸 실행하는 역할만 하게 됨
비즈니스 케이스 얼마만큼의 수익이 날지, 얼마만큼의 비용이 들지 현재 시점에서 알 방법이 없음. 어떤 솔루션을 만들지 모르는 상태이기 때문에, 그에 해당하는 수익/비용 모두 말그대로 아무것도 모름
로드맵 (1) 아이디어 중 최소 절반 이상은 유효하지 않음 (2) 비즈니스 가치를 만들어 내는 수준으로 만들려면 최소 몇 번의 이터레이션을 반복해야 함 = 돈을 버는 데 필요한 시간이 필요함. 그런데 로드맵 체제로 하면 개선해서 성과를 내도록 시도하는 게 아니라 다음 프로젝트를 시작하는 식으로 넘어가게 됨.
제품 관리자의 역할 제품 관리가 아니라 프로젝트 관리. 엔지니어를 위해 요구사항을 수집하고 문서화하는 역할만 하게 됨
디자이너의 역할 디자인의 진정한 가치를 담기에 너무 늦은 상황에 투입됨
엔지니어의 역할 너무 늦게 참여하게 되면서, 코드를 짜는 역할만 하게 됨
애자일의 원칙과 핵심적인 장점이 늦게 적용됨 제품 구현과 전달에서만 애자일 적용
프로젝트 중심적 프로젝트는 결과물에 대한 것, 제품은 비즈니스 성과에 대한 것
고객 검증이 너무 늦게 일어남
기회비용 그 시간에 조직이 할 수 있었던 혹은 해야만 했던 것에 대한 기회비용
특히 로드맵으로 진행했을 때 문제는 성과를 내기 위해서 달려가는 것이 아니라 내부에서 일종의 SI 업체처럼 일을 쳐내는 식으로 일하게 되는 것이라고 생각합니다. 그런데 더 큰 문제는 이렇게 일하고 있음에도 애자일하게 일하고 있다고 생각하고 있다는 점인거죠.
여기에 대해서 대안으로 성과 중심 로드맵을 제안하는데요. 제품팀에 특정한 비즈니스 문제를 제공하고, 제품팀이 사업적 맥락 안에서 목적을 달성하게끔 하는 방안입니다. 말만 들어도 PM이 느끼는 무게감이 확 달라지는 걸 알 수 있는데요. 여러 사업 성과의 우선순위를 받게된 PM은 문제 해결을 위해 달릴 수밖에 없을 것 같습니다.
Last updated