이 글은 국내에서도 잘 알려진 제품 관리자를 위한 서적 인스파이어드의 저자 마티 케이건이 SVPG 웹사이트에 게재한 글 Product Team VS Feture Team을 번역한 글입니다.
이 글은 분명 많은 사람들을 불편하게 만들 것 같다.
그렇다면 미안한 일이지만, 최근 테크 기업에서 제품 관련 역할에 대한 수많은 노이즈가 점점 더 심해지고 있고 소위 '프로덕트 피플'을 위한 회의, 트레이닝 프로그램 등 각종 자격증이 만들어 내는 여러 문제들이 심심치 않게 눈에 띄고 있어 답답하다.
나는 예전부터 미션팀(Empowered Product Teams)에 대해 다루는 여러 기사나 글을 통해 이러한 문제들에 대해 여러 번 목소리를 내곤 했다. 하지만 대개 자신이 원하는 것만 듣고 취하는 모습을 보이는 관계로 좀 더 분명하게 의견을 낼 필요가 있다는 생각이 들었다.
이 글은 어쩌면 듣기 싫은 잔소리처럼 여겨질 수도 있지만, 만약 당신이 이 업계 사람들의 모순되고 요란스러운 프로파간다에 지친 데다 내가 내뱉는 (일종의) 잔소리를 짜증 내지 않고 새겨들을 수 있다면 아마도, 당신이 기대하는 명확한 관점을 얻을 수 있을 것으로 생각한다.
테크 업계에는, '제품팀'으로 불리는 세 종류의 팀이 존재한다.
실제로 가장 많이 보이는 것은 '개발팀', '스크럼 팀' 혹은 '엔지니어링 팀'으로 불리는 일종의 '배달팀'이다. 만약 당신의 회사가 SAFe (대기업을 위해 고안된 애자일 프로세스 프레임워크) 같은 것을 운영하고 있다면 불행하게도 여기에 해당한다. 이 유형의 팀에는 개발자 다수와 프로덕트 오너 한 명이 존재한다. 여기서 프로덕트 오너는 내가 '백로그 관리자'라고 부르는 역할을 한다. 대개 제품을 배포하는데 필요한 행정적인 업무를 처리할 뿐 고객을 위한 진실하고 일관된 혁신을 추구하는 것과는 큰 관계가 없는 일들을 수행한다. 나는 이 모델(SAFe)이 그저 폭포수 프로세스를 그럴싸하게 포장한 것일 뿐 진짜 제품팀과는 다른 방식으로 일한다는 내용의 글을 종종 써왔다. 그러니 오늘의 논의에선 살짝 제외해두자.
오늘은 나머지 두 가지 팀 유형의 차이점에 대해 얘기하려 한다.
재미난 건 이 두 가지 팀 모두 '제품팀' 또는 '스쿼드'라는 명칭을 동일하게 사용하고 있다는 것이다. 얼핏 보면 이 두 유형의 팀은 돌아가는 방식까지도 꽤 비슷한 듯 보이는데 막상 제품 관리자가 수행하는 역할을 중심으로 살펴보다 보면 아주 극명하게 그 차이가 드러난다.
나는 뛰어난 제품팀이 갖춰야 할 미덕에 대한 글을 적을 때 이들은 '제품팀'으로 불리며 교차 기능 팀(제품 관리자, 디자이너, 엔지니어가 함께 일하는)의 구성을 갖추고 있고 제품의 완성이 아닌 성과에 초첨을 맞추고 끊임없이 측정하며 고객들이 맞닥뜨린 문제를 해결하기 위해 최선의 방법을 알아내는데 집중한다고 말했다.
이런 관점에서 제품팀의 목적은 사업적 성과를 그들의 고객이 사랑하는 방식으로 달성하는 것에 있다. 하지만 나의 기대와는 별개로 '제품팀'으로 불리는 곳들 중 매우 적은 수 만이 이러한 목적을 중심으로 일하고 있다. 그렇지 않은 대부분의 '제품팀'들은 아무런 권한도 없이 그저 사업의 과제들을 해결하기 위한 일들을 수행하고는 한다.
지금부터 나는 이 후자에 속하는 팀을 '기능팀'이라 부를 것이다. 이 명칭에 대한 정의가 적절한지는 모르겠지만 '출시'에 집중한다는 측면을 강조하기에는 도움이 될 것 같아 이렇게 불러 보려고 한다.
기능, 때로는 프로젝트라고 부르는 것은 대부분 로드맵이라고 불리는 방식으로 정리된 우선순위 목록을 가지고 있다.
자 이쯤에서 제품이 다뤄야 하는 중요한 네 가지 리스크를 살펴보자.
- 가치 리스크 (사람들이 살까? 사용할까? 선택할까?)
- 사용성 리스크 (사용자들이 어떻게 쓰는지 알까?)
- 구현 리스크 (제시간에 완성할 수 있을까? 이걸 위한 기술이나 역량이 갖춰져 있나?)
- 비즈니스 생존 리스크 (이 결과물이 여러 관점에서 우리 비즈니스와 핏이 맞을까?)
충분한 권한을 가진 '제품팀'에서는 제품 관리자가 가치와 생존 가능성에 대한 책임이 있으며, 기술 책임자는 구현 가능성에 대한 책임이 있다. 그래서 이 팀은 효과적인 해결책을 위해 매우 열심히 협력하여 최선의 결과를 도출하는데 힘쓸 수밖에 없다.
이 책임이라는 것의 무게가 매우 크기 때문에 좋은 제품팀의 좋은 제품 관리자가 되는 것이 어렵고도 가치 있는 일인 것이다.
물론 '기능팀'에도 사용성이 좋은 제품을 설계할 수 있는 디자이너가 있고, 그것을 적절히 구현해 낼 엔지니어가 있겠지만 정작 '책임'이 기능과 로드맵을 전달한 경영진 혹은 이해관계자에게 있기 때문에 이 팀은 로드맵에서 x를 말하면 x를 구현하는 데에만 집중하게 된다.
진짜 문제는 x로 기대하던 결과를 만들어내지 못할 때 발생한다. 경영진 혹은 이해관계자가 실제 결과에 책임이 있는 사람이지만 결국 다양한 방법으로 팀을 비난할 구실을 찾아낸다. 너무 오래 걸렸고, 디자인이 구리고, 주문을 제대로 이해하지 못했고.. 등등
실제로 두 유형의 팀에 매우 뛰어난 역량을 갖춘 구성원이 모여있다 하여도 만들어내는 결과의 차이는 매우 크다.
우선 제품 관리자가 하는 일을 살펴보자. '제품팀'에서는 제품을 성공시키기 위해 필요한 다방면(데이터, 도메인, 판매, 마케팅, 금융, 운영, 법무 등)의 지식을 갖추는 것이 필수 불가결한 조건이다.
그러나 '기능팀'에서는 검증된 지식을 가진 (책임을 떠넘길) 사람들과 미팅을 잡는데 시간을 쓰게 된다.
둘이 수행하는 일과 그 결과는 매우 다를 것이 분명하다.
기능팀에서 제품 관리자의 일은 흔히 '고양이를 한 곳에 모은다(고양이는 말을 안 듣는다)'는 말로 표현하는 퍼실리테이터(진행자) 즉 의견 조율의 역할이나 특정한 책임 없이 업무 문서를 정리하는 교차 기능 리더로 설명할 수 있다. 그들은 제품 발견을 하고 있다고 생각하겠지만 실제로는 그저 설계업무를 담당하거나 사용성을 테스트하는 수준의 일일 뿐이다.
또 '기능팀'의 제품 관리자로 일하게 된다면 좋은 제품 디자이너와 일하기 어렵다는 문제도 있다. 좋은 제품 디자이너는 서비스의 구조와 인터랙션, 시각적 효과와 사용성을 종합적으로 다룰 수 있는 역량을 갖춘 사람을 말하는데 '기능팀'에서는 제품 관리자가 수행하는 일이 겹치는 바람에 대개 자신의 바람을 화면으로 그려줄 수 있는 그래픽 디자이너와 일하게 된다. 물론 시각적 산출물의 중요성을 깎아 내리는 게 아니다.
다만 팀의 누군가는 인터랙션 설계와 사용자 연구의 전문적인 역량을 갖춰야 하는데 제품 관리자가 그리 어렵지 않게 디자인 툴을 배웠다 한들 좋은 디자인은 단순히 지식을 습득하는 것과는 다른 문제이기 때문이다. 더 큰 문제는 좋은 제품 디자이너와 일해본 경험이 없다 보니 뭘 놓치고 있는지 조차 알 수 없다.
만약 이 제품 관리자가 운 좋게도 좋은 제품 디자이너와 일하게 될 기회를 갖는다면(적어도 디자이너가 자신의 역량을 충분히 발휘할 회사로 이직하기 전까지), 디자이너들은 보통(너무 당연히도) 제품 관리자의 필요성에 대한 의문을 제시한다. 어차피 대부분의 일을 자기가 하기 때문이다.
결국 그들이 떠나고 '기능팀'에 남은 제품 관리자는 프로젝트 매니저 업무와 더불어 실력 없는 디자이너 역할을 수행하게 된다.
종종 엔지니어와도 위와 유사한 '실망스러운 상황'이 연출된다. 제품 관리자(사실은 프로젝트 매니저)가 엔지니어가 제시한 방법을 신뢰하지 않고 일을 밀어붙이는 상황이다 (흔히 그건 일정 때문에 안돼요 패턴). 당연히 엔지니어들은 자신이 그저 시키는 대로 구현하고 있다는 것에 스트레스를 받을뿐더러 그들이 제공할 수 있는 가치의 절반도 활용하지 못하는 방식이다(그리고 결국 이들도 자신의 역량을 십분 발휘할 수 있는 회사를 찾아 떠난다.)
요점을 정리하자면 내가 과거 글에서 '제품 관리자는 회사에서 가장 강력한 인재 중 한 명이 맡아야 한다.', '제품 관리자는 잠재적 리더 후보이다.', '제품 관리자는 제품의 CEO라고 볼 수 있다.'라고 적을 때 말한 '제품 관리자'는 '기능팀'에 일하는 그들을 뜻한 게 아니다.
이쯤에서 이 글을 읽고 있는 많은 사람들이 자신이 기능팀에서 일하고 있음을 깨닫길 바라긴 하지만 경험상 스스로 그 사실을 알고 있는 경우는 꽤나 드물었던 것 같다.
그러니 한번 아래의 질문에 답하며 내가 어떤 팀의 제품 관리자로 일하고 있는지 확인해보자.
- 일정과 우선순위가 정리된 로드맵을 전달받았나요? 아니면 해결이 필요한 비즈니스 목표를 전달받았나요?
- 당신과 팀의 디자이너 사이에 역할 혼란이 있나요?
- 하루의 대부분을 프로젝트 관리하는데 쓰고 있나요?
- 갖가지 KPI로 범벅된 일들과 거절, 배포 계획으로 뒤덮인 일과를 보내나요?
- 당신의 팀이 지향하는 미션을 가지고 있나요?
- 당신이 맡은 책임의 수준은 어떤가요?
기능팀과 제품팀은 겉보기엔 매우 유사하지만, 운영 방식, 권한 및 책임의 범위(특히 제품 관리자의 책임)에서 매우 큰 차이를 가지고 있다.
몇 가지 예외를 제외하면 대부분의 성공한 팀들은 충분한 권한을 갖고 있다. 하지만 솔직히 말해서 내가 생각하기에 무척 뛰어난 팀이라고 해서 모든 권한을 가지고 있는 것은 아니다. 기능팀으로도 뛰어난 결과를 만들어 낸 이후에서야 경영진의 신뢰를 얻어 권한을 획득하기도 한다. 결국 방향의 키를 잡는 것은 기업의 리더이다.
그동안 충분한 권한을 가진 '제품팀'에 대한 애정을 숨긴 적이 없다. 하지만 단지 그들을 옹호하는 것 이상으로 '기능팀'이 야기하는 문제에 대해서 언급해야 한다는 생각을 갖게 되었다.
오늘날 수많은 기업들이 배달팀(분리된 팀으로 폭포수 프로세스를 수행하는)을 탈피하고 진정한 기술 기업으로 도약해야 할 필요성을 느끼고는 있지만 콘셉트의 핵심이 빠진 피상적인 변화로 인해 기능팀에 머무르는 것을 수도 없이 목격하고 있다.
글을 마무리하며 나는 다시 한번 권한과 책임을 부여받은 제품 팀이 만들어내는 차이점을 강조하고 싶다. 기능팀과는 완전히 다른 방식으로 동작하고 이 둘을 같은 명칭으로 부르면서 빚어지는 노이즈를 간과하면 안 된다.
아주 많은 디자이너와 엔지니어는 진정한 의미의 제품 관리자를 만날 기회를 잃었고, 진정한 의미의 제품팀에서 일할 기회를 얻지 못했다는 게 나는 슬프다. 이것이 역량을 발휘할 충분히 맞이 하지 못한 인재들이 넘쳐난다고 믿는 이유이며, 매일같이 기업과 사람들을 설득하기 위해 노력하는 이유이다.
요즘 들어 더더욱 많은 고민을 하게 만드는 '제품팀' 콘셉트에 대한 좋은 가이드가 되어준 글이라 이미 널리 알려진 글임에도 번역하여 공유합니다. 결국 진정한 의미의 '제품팀'이 만들어지는데 가장 필요한 것은 기업 리더들의 신뢰와 확신이라는 생각을 하는 요즘입니다.
잘 읽으셨나요? 혹시 이 글이 도움이 되셨다면 아래 버튼을 눌러 커피 한 잔 어떠세요? 여러분의 작은 후원이 창작자에게 큰 힘이 됩니다! 😁