선언적으로 일하는 PM
프로덕트 매니저의 수습 회고 (1)
지난 5월, 패션 커머스 회사의 CDP PM으로 이직하고 정신없이 바쁜 3개월을 보냈습니다. 일이 많아 그만큼 체력적으로나 정신적으로 많은 도전을 마주했던 시기였습니다. 수습을 마무리하며 지난 3개월 동안 제가 겪었던 경험과 그 안에서 배운 점들을 나누고자 합니다.
내가 다니엘을 이해하지 못했던 이유
결국 나도 기획자의 마인드였더라
음원 스트리밍 서비스 스포티파이의 탄생 스토리를 담은 넷플릭스 드라마 <The Playlist>에는 인상적인 장면이 나옵니다. 이 중 4화 '코딩의 문제'편을 보면, CEO 다니엘과 CTO 안드레아스의 갈등과 그의 고민을 매우 흥미롭게 묘사합니다.
넷플릭스 <The Playlist>스포티파이는 '접근성'과 '속도'를 핵심 목표로 삼고 개발을 시작했습니다. 특시, 사용자 경험 측면에서, 당시 유사 서비스에서 가장 큰 불편함으로 꼽던 '속도'를 개선하려고 했습니다. 개발팀은 엄청난 노력 끝에, P2P 방식을 활용해 음원 로딩 속도를 0.5초로 단축하는데 성공합니다. 0.5초도 당시 다른 서비스들과 비교할 때, 엄청나게 빠른 속도였습니다.
하지만 다니엘은 "음악 듣자고 누가 0.5초를 기다리냐"며 로딩 시간을 '0초'로 만들 것을 지시합니다. 콘텐츠 크기나 네트워크 부하 등 다양한 영향 때문에 0.5초 또한 대단한 성과라고 생각했던 안드레아스는 그런 CEO의 요구에 난색을 표합니다. 결국 0.25초까지 줄였음에도 다니엘이 만족하지 못하자, 둘은 크게 갈등합니다. 하지만 안드레아스는 결국 새로운 프로토콜 방식을 개발하고, 사람이 차이를 인지할 수 없다는 0.2초 이하 수준으로 로딩 시간을 낮추는데 성공합니다. 그리고 다니엘에게 결국 인정받게 됩니다.
이 드라마를 처음 봤을 때, 저는 다니엘의 업무 방식에 강한 의문을 품었습니다. 이미 다른 서비스보다 훨씬 빠른 0.5초를 0.2초로 줄이기 위해 막대한 리소스를 쏟는 것이 과연 옳은 일인가? 성공했더라도 이런 식으로 개발팀을 압박하는 것이 좋은 방식인가? 저건 '괴짜 CEO라 저렇게 하는 거다, PM이 개발자와 일하는 일반적인 상황에서는 저렇게 일하면 안 된다'고 생각했습니다.
선언적으로 일하기
PM은 고객과 비즈니스의 대변자다
지금의 회사에서, 저는 이전과는 다른 방식으로 일하는 법을 배우고 있습니다. 여기 계신 훌륭한 시니어 IC(Individual Contributor)와 TPM(Technical Program Manager)분들을 보면서 제가 가진 사고방식이 얼마나 제한적이었는지 깨닫습니다. 이분들은 조직의 목표 달성뿐만 아니라 우리가 일하는 방식 자체를 끊임없이 개선하려 노력하고 있습니다. 저 역시 프로그램 리뷰나 개별적인 만남을 통해 그분들의 깊이 있는 경험과 사고방식을 배우려 노력하고 있습니다.
그러던 중, 최근 TPM님과 점심을 먹다가 머리를 한 대 맞은 듯한 깨달음을 얻었습니다. 점심 전날, 한 시니어 IC분의 세미나에서 '절차적 방식보다 선언적 방식으로 일하자'는 주제를 다뤘는데, TPM님은 그 내용이 특히 PM들의 업무 방식을 개선하라는 메시지였다고 말해주셨습니다.
절차적 방식과 선언적 방식은 프로그래밍 방법론에서 나온 개념이라고 합니다. 절차적 업무 방식이 주어진 지시를 순서대로 실행하는 '어떻게'에 집중한다면, 선언적 방식은 '무엇을 달성할 것인가'와 '왜 그것이 중요한가'라는 목표와 가치를 제시하는 데 중점을 둡니다.
이전의 저는 2-Pager나 PRD(Product Requirement Document)를 작성할 때, 개발 범위를 효율적으로 잡는 데 많은 리소스를 쏟았습니다. 개발 스콥이 지나치게 커지는 것을 막고 '내 기준'의 적절한 작업량을 제안하며, 그 안에서 리소스와 우선순위를 잘 조율하는 것이 제 역할 중 큰 비중을 차지한다고 생각했습니다.
하지만 이런 방식은 결국 조직의 성장 한계를 낮추는 결과를 초래합니다. 예를 들어, 개발팀이 충분히 A, B, C, D를 해낼 수 있는 역량이 있는데도, 제가 개발을 잘 모른다는 이유로 A, B, C까지만 제안한다면 이는 팀의 잠재력을 스스로 제한하는 것이나 다름없습니다. 결과적으로 조직 전체의 기준(Bar)을 낮추게 됩니다.
따라서 PM/PO는 조금 더 '선언적'으로 일을 해야합니다. 고객의 관점에서 충분히 비즈니스 요구사항을 수렴하고, 그중 가장 임팩트가 크다고 예상되는 목표를 제시해야 합니다. 물론 이는 무작정 과도한 업무를 던지는 것과는 다릅니다. 상호 신뢰와 존중을 바탕으로 비즈니스 요구사항과 기술적 구현 가능성에 대해 치열하게 논의하는 과정이 반드시 필요합니다.
그 과정에서 개발팀은 그들이 할 수 있는 최선의 결과를 제시할 것입니다. PM은 '0초 로딩'처럼 과감한 목표를 설정하고, 이 목표를 달성했을 때 얻을 수 있는 가설(예: 사용자 경험 극대화, 리텐션 증가)을 수립해야 합니다. 그리고 개발팀은 그 가설을 기술적으로 검증하고 실현하는 역할을 맡습니다. 이처럼 두 역할이 명확히 분리되면서도 긴밀하게 연결되어야 비로소 최고의 결과물을 만들어낼 수 있습니다.
끝으로
CDP PM으로서 초반에는 고객보다 제품 자체의 구현에 초점을 맞췄던 것 같습니다. 물론, 구현 과정에서도 비즈니스 임팩트나 정량적인 기대효과를 충분히 고민했습니다. 하지만 과연 제가 고객의 입장을 온전히 대변했는가, 내가 스스로 프로덕트의 한계를 만들지는 않았었나 반성하게 됩니다.
그래서 입사 초기에는 CDP의 인프라 구축, 데이터 파이프라인과 같은 기술적인 내용에 집중했다면, 요즘은 마케팅팀을 포함해 고객 접점에서 일하는 다양한 조직과 소통하며 관련 도메인에 대한 이해도를 높여가고 있습니다. 내부 고객의 숨겨진 니즈를 찾아내고, 이를 기반으로 제품의 가치를 높이는 것이 제 역할이기 때문입니다.
이렇게 계속 노력하다 보면, 언젠가는 스스로를 '기획자'가 아닌 진정한 'PM'이라고 자신 있게 말할 수 있지 않을까 생각해 봅니다.
재미있게 읽으셨다면 좋아요 부탁드립니다.
