이 글은 Omoqo의 CEO인 David Pereira가 쓴 ‘Product Managers Aren’t Backlog Managers!‘를 바탕으로 필자의 주관적 견해를 덕지덕지 붙여서 쓴 글이다. 원문에 논리의 양강 구도가 너무 뚜렷해서 인용할까 말까를 꽤 오래 고민했지만, 필자 또한 어느 부분에서 깊게 공감하기 때문에 여러분들께도 공유하고자 한다. 조금 불편할 수도 있지만, 그럼에도 마땅히 지적해야 할 문제라는 점에서 유의하여 봐주기를 바란다.
Product Manager의 업무 Role에 상당 부분의 비중을 차지하는 업무가 ‘백로그 관리’ 다. 나는 업무 중에는 항상 지라 백로그 관리 페이지를 켜두고, 진척 상황을 바로바로 업데이트해서 이해관계자들에게 공유한다. 새로운 가치 창출 기회를 모색하거나, 사용자의 목소리를 듣는데 소비하는 시간보다 백로그 관리에 소요하는 시간이 더 많은 것 같다고 느낄 때가 더러 있다.
우리의 역할은 제품과 사용자의 가치를 극대화하는 것이고, 그 과정에서 백로그 관리는 필수불가결한 업무다. 그렇지만, 백로그 관리만 잘하면 제품과 사용자 가치가 알아서 극대화되는 것은 아니다. 올바른 가설과 성공 지표를 세우고, 반복 실험을 통해 가치 창출을 하는 것이 주요 미션이자 가장 오랜 시간 공을 들여야 하는 업무다.
여러분들은 위에서 말한 ‘올바른 가설과 성공 지표를 세우고, 반복 실험을 통해 가치 창출을 하는 것’을 주요 미션으로 수행하고 있는가? 아니면 접수되는 일들을 백로그에 집어넣고 최대한 빠른 시간 내에 구현하는데 집중하는 것이 주요 미션인가? Product Manager와 Backlog Manager의 차이를 알아보자.
David Pereira가 말하는 프로덕트 매니저와 백로그 매니저의 차이점은 다음과 같다.
프로덕트 매니저 Vs. 백로그 매니저
- ✅ 프로덕트 매니저는 (비즈니스적) 가치 창출 기회를 찾는데 중점을 둔다.
- ❌ 백로그 매니저는 특정 백로그 항목을 작성하는데 중점을 둔다.
- ✅ 프로덕트 매니저는 지속적으로 결과를 측정하고 증거를 바탕으로 다음에 무엇을 할지 결정한다.
- ❌ 백로그 매니저는 속도를 높이는데 에너지를 쏟는다. 그들은 빠르게 기능을 구현하는데 주력한다.
- ✅ 프로덕트 매니저는 이해관계자들과의 파트너십을 위해 노력하며, 갈등을 피하지 않는다.
- ❌ 백로그 매니저는 갈등이 야기되는 상황을 회피하며, 이해관계자들을 기쁘게 하는데 최선을 다한다.
- ✅ 프로덕트 매니저는 제품팀에 영감을 주고, 의미 있는 문제를 해결할 수 있도록 역량을 강화한다.
- ❌ 백로그 매니저는 팀을 세세하게 관리하며, 전체적인 비전을 제공하지 않는다.
- ✅ 제품팀은 프로덕트 매니저와 가치를 창출한다.
- ❌ 제품팀은 백로그 관리자를 통해 기능을 만들어 낸다.
다소 강경한 표현이 있기는 하지만, 우리 대부분은 백로그 매니저처럼 행동하고 있다. 잠깐 짚고 넘어가자면, 나는 프로덕트 매니저의 본분 중 하나가 백로그 관리이며, 그것만으로는 큰 문제라고 생각하지는 않는다. 백로그에 대한 이해도 없이 제품팀을 매니지먼트한다는 말은 컴퓨터의 하드웨어도 모르는 사람이 컴퓨터 전문 수리점을 차리는 것과 다를 바 없기 때문이다.
문제는 백로그 매니저 그 자체가 되어버리는 것이다. 조금 불편한 질문을 던져보겠다. 마지막으로 실험주도적인 프로덕트 성장을 경험해 본 것이 언제인가? 중장기적 프로덕트 비전을 수립하고, 여러 이해관계자들을 설득해 본 경험은? ‘진짜 문제’를 찾기 위해서 다양한 리서치를 염두에 두고 고객과 맞닿아 해결해 본 경험은 또 언제였는가. 우리는 ‘프로덕트 매니저’라는 그럴싸한 포장지에 싸인 백로그 매니저가 아니었을까?
올바른 프로덕트 매니저의 역할
필자의 생각은 이렇다.
제품 백로그는 하나의 목표에서 출발해야 한다.
제품 백로그는 ‘구현해야 할 모든 문제들’이 아니다. 소기의 목표 달성을 위한 문제 덩어리다. 맥락 없는 백로그는 제품팀이 스스로 무엇을 만들고 있는지 망각하게 만든다. 백로그를 ‘구현해야 하는 기능 A to Z’처럼 작성하지 말고, 목표 단위로 세분화해서 작성해 보자. 예를 들어, ‘회원가입 전환율을 10% 증가시킨다’는 좋은 목표가 된다. 그럼 ‘회원가입 페이지를 개선한다’던가 ‘비회원 상태로 N분 이상 서비스를 탐색하는 유저에게 가입 유도 메일을 보낸다’와 같은 맥락에 맞는 백로그들이 정리된다.
백로그는 요구사항 정의서가 아니다.
‘작동하는 기능’이 아닌 ‘해결하려는 문제’가 중심이 되어 팀과 논의하고 백로그를 작성해야 한다. 이해관계자의 요구사항이 문제 해결이나 가치 창출 어느 쪽에도 도움이 되지 않는다면 백로그에 작성하지 못하는 이유를 설명해야 한다. 그리고 백로그는 와인이 아니다. 숙성시키지 말고 오래된 항목은 제거하자. 몇 달이 지났는데도 진척이 없다면 가치 창출에 중대한 이슈가 아닐 확률이 높다.
측정할 수 없다면 다시 한번 생각해 보자.
프로덕트 매니저는 제품팀의 책임자로서 무엇을 우선 구현할 것인지를 결정하는 권한을 가진다. 유관부서로부터 ‘이런 기능이 필요해요’나 ‘이게 이렇게 개선되어야 해요’라는 요청을 받았을 때, 그 요청이 타당한지 검토하고 백로그에 옮기는 것은 프로덕트 매니저의 몫이다. 이때 좋은 협업자처럼 보이고 싶어 모든 요구사항을 다 들어주는 사람이 되어서는 안 된다. AS-IS와 TO-BE가 측정할 수 없다면 다른 매력적인 업무들을 다 제쳐두고서라도 이걸 해야 하는 이유가 분명해야 한다. ‘인간 SI’가 되지 말라고 당부하고 싶다.
결정에 영향을 미치는 건 조직도가 아닌 사용자여야 한다.
가장 어려우면서도 모순적인 점은 위 내용을 우리도 알고 있지만 현실적으로 실현하기 어렵다는 것이다. 고위 결정권자들이 전사적 목표 & 전략이라고 내세우는 업무들 모두가 사용자 중심적 해결 방법은 아니다. 1차적으로 우리는 ‘아닌 것은 아니라고 말할 수 있는 용기’가 필요하다. 이상적인 경우라면 말이다. (스타트업이나 사일로 조직에서는 가능할지도?) 큰 규모의 조직에서는 안타깝지만, 까라면 까야한다. 그렇다면 최소한 ‘위에서 만들라고 시켜서’가 결정 요인이 아닌 ‘고객의 어떤 니즈를 충족하면서 어떤 가치를 창출하기 위함’이라고 해석해 보자. 의외로 문제 해결에 큰 도움이 된다.
내 성과 지표는 사용자를 위한 것인가? 기능 구현을 위한 것인가?
올 한 해 동안 내 성과를 돌아보는 연말 성과 정리 시즌이 돌아왔다. 필자는 예전에 ‘얼마나 어려운 업무를 수행했는가’ 혹은 ‘얼마나 짧은 시간 동안 많은 기능을 만들어 냈는가’를 중요한 핵심 성과 지표로 삼았다. 그러나 지금 되돌아보면, 그 업무들 대부분은 내가 맡은 프로덕트에 비약적인 성장을 가져오지는 않았다. 오히려 일주일 정도면 기획부터 개발까지 모두 구현할 수 있는 간단한 업무에 사용자들이 더 환호하기도 했다. 난이도 높은 업무, 많은 기능들이 성과 지표가 되어서는 안 된다. 물론 남들과 똑같은 시간 동안 더 많은 기능을 구현했다면 겉으론 일을 더 열심히 한 사람처럼 보일 수는 있다. 그게 비록 프로덕트에 진짜 도움이 되었는지는 몰라도 말이다.
다시 정리하자면, 나는 ‘백로그 관리’를 프로덕트 매니저의 Role이라는 것을 부정하는 것이 아니다. 또한, 이해관계자나 임원의 지시에 불복하라(그것이 사용자 가치 창출에 큰 도움이 되지 않더라도)는 말은 더더욱 아니다. 현실적으로 우리 대부분은 백로그 매니저를 자처하며 중요한 문제를 해결하는 미션을 두고 덜 중요한 미션을 수행하는데 최선을 다하고 있다.
그렇다면 우리는 무엇을 해야 할까. 올바른 프로덕트 매니저로 성장할 수 있는 환경을 찾는 게 우선이다. 물론, 본인 재량으로 환경을 변화시킬 수 있다면 그렇게 만들어야 한다. 당장 옮길 수 없거나, 그럼에도 자기 자리에서 최선을 다하고 싶다면 프로덕트 매니저만이 갖는 역량과 권한을 썩히지 않도록 당장 달라져야 한다. 여러분들이 이해관계자의 꼭두각시가 아닌 자기주도적인 성장을 이룩하기를 바란다.
채드윅 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
