강한 제품팀의 원칙

제품 관리자가 일하는 방법

제품 관리자의 책임

어떤 사람이 뛰어난 제품 관리자가 될 수 있는가

제품 관리자

마티 케이건

저자

제이펍

콘텐츠 제공

이승국

큐레이터

서동환

김정원

편집

<q>이 챕터는 다음 독자를 대상으로 합니다. 1. 제품팀에 속해 있지 않지만 제품에 깊이 관여하는 주요 이해관계자 2. 제품팀에 속해서 일하는 사람들 3. 제품 관리자 커리어에 관심이 있는 사람들 4. 제품팀 외부에 있지만 제품팀과 긴밀하게 일해야 하는 실무자</q>이번 장에서 강한 제품팀의 원칙들을 설명한다. 그리고 이어지는 장에서는 팀을 구성하는 각 핵심적인 역할에 관해 자세히 알아볼 것이다.&nbsp;제품팀이 하나의 프로젝트나 기능을 만들어 내는 것이 아니라는 점을 강조하기 위해 때로는 제품 전담팀(Dedicated Product Team) 또는 지속 제품팀(Durable Product Team)이라고도 부른다. 혹은 스쿼드(Squad)라고 하는데, 이는 군사적인 개념에서 유래한 것으로, 제품팀이 다기능 팀이라는 의미를 강조하기 위해 사용된다.&nbsp;제품팀은 각기 다른 전문적인 능력과 책임을 진 사람들의 집단이며, 단일 제품 또는 큰 제품의 주요 영역에 대한 실질적인 주인 의식을 느낀다. 제품팀을 구성하는 데는 다양한 방법이 있다. 하지만 회사별로 제품이나 환경의 고유한 특성이 있음에도 불구하고 뛰어난 제품 회사에서 발견되는 몇 가지 중요한 유사점들이 있다.&nbsp;<h3 dir="ltr">미션팀</h3>실리콘밸리의 유명한 벤처 캐피털리스트인 존 도어(John Doerr)의 말은&nbsp;제품팀의 목표를 가장 잘 표현한다.<blockquote>우리가 원하는 것은 용병팀(Team of Mercenary)이 아닌 미션팀(Team of Missionary)이다.</blockquote>용병팀은 지시한 것만을 만든다. 미션팀은 진심으로 비전을 믿고 그들의 고객 문제 해결을 위해 최선을 다한다. 훌륭한 제품팀은 마치 사내 스타트업처럼 행동하고 느낀다. 그것이 제품팀에 바라는 모습이다.&nbsp;<h3 dir="ltr">팀의 구성</h3>일반적인 제품팀은 한 명의 제품 관리자, 한 명의 디자이너, 그리고 두 명에서&nbsp;최대 12명까지의 엔지니어로 구성된다.&nbsp;

계획된 연산을 수행하는 API(Application Programming Interface)의 조합으로만 구성된 프로그램과&nbsp;같이 제품이 사용자 접점의 경험을 다루는 것이 아니라면 아마 제품 디자이너는 필요 없을 수도 있다. 하지만 그 외 많은 제품팀은 제품 디자이너가 꼭 필요하다. 이 책 전반에서 당신의 팀도 그러할 것으로 가정하겠다.&nbsp;팀은 상황에 따라 제품 마케팅 매니저, 테스트 자동화 엔지니어, 사용자 경험 연구원, 데이터 분석가와 같은 다른 멤버들도 포함될 수 있다. 큰 제품 조직에서는 별도의 제품 실행 관리자가 존재하기도 한다. 일부 역할을 아직 잘 모른다고 걱정하지는 말자. 각 역할에 대해 차근차근 알아볼 것이다.&nbsp;<h3 dir="ltr">팀의 권한과 책임</h3>제품팀의 컨셉에서 이야기하는 중요한 사실은, 그들이 비즈니스의 매우 어려운 문제를 해결한다는 것이다. 그들은 분명한 목표를 가지고 그 목표에 맞추어 실행한다. 목표 달성을 위한 제일 나은 방법을 찾아내는 권한이 있으며, 그 결과에 대한 책임도 동시에 가진다.&nbsp;<h3 dir="ltr">팀의 크기</h3>회사의 모든 제품팀이 같은 크기여야 한다고 말하는 규칙 같은 것은 없다. 다만 제품팀을 구성하는 최소 조건은 있다. 보통 한 명의 제품 관리자, 한 명의 디자이너, 두 명의 엔지니어다. 하지만 어떤 팀들은 다섯 명의 엔지니어와 두 명 혹은 그 이상의 테스트 자동화 엔지니어로만 구성되어 있다.&nbsp;실질적으로 팀의 규모는 대개 8명에서 12명의 엔지니어까지 가능하다. 아마 당신은 피자 두 판의 법칙(Two-Pizza Rule)을 들어 본 적이 있을 것이다. 팀의 규모를 두 개의 피자를 먹을 만한 사람 수 이내로 유지하라는 것을 의도하는 표현이다. 팀의 절대적인 규모보다 더 중요한 것은, 팀이 올바른 제품을 올바르게 만드는 데 필요한 고른 역량을 갖추고 있느냐는 것이다.&nbsp;<h3 dir="ltr">팀의 보고 체계</h3>나는 누가 누구를 위해 일하는지 아직 한마디도 한 적이 없다. 제품팀은 보고 관계가 아니다. 의도적으로 수평 구조를 지향한다. 많은 경우 제품팀의 각 구성원은 독립적이며, 관리자가 별도로 존재하지 않는다.&nbsp;팀의 구성원들은 보통 그들의 직무 관리자와 지속적으로 상황을 공유한다. 예를 들어, 엔지니어는 엔지니어 매니저와 공유한다. 마찬가지로, 디자이너는 디자인 총괄 책임자에게, 제품 관리자는 제품 총괄 책임자에게 보고한다. 그래서 제품팀은 보고하는 관계가 아니다. 분명히 말하지만, 제품 관리자는 제품팀 구성원의 상사가 아니다.&nbsp;<h3 dir="ltr">팀 협업</h3>제품팀은 어려운 비즈니스 문제를 해결하기 위해 장기간 함께 일하는 숙련된 기술을 가진 구성원들의 조합이다. 이들 관계의 본질은 진정한 협업에 관한 것이다. 여기서 &#39;협업(Collaboration)&#39;은&nbsp;단순히 함께 일한다는 것만을 의미하지는 않는다.&nbsp;내 말은 제품 관리, 디자인, 기술 구현이 솔루션을 만드는 데 함께 집중한다는 뜻이다. 협업에 관해 더 많은 내용을 이후에 알아볼 것이다. 지금은 제품팀이 계층 구조가 아니라는 것을 이해하는 것이 중요하다.&nbsp;<h3 dir="ltr">팀의 위치</h3>아직 제품팀 구성원들이 물리적으로 어디에 위치하는지에 대해 언급한 적이 없다. 늘 가능하지는 않겠지만, 제품팀은 가능하면 같은 장소에서 함께하기 위해 최선을 다해야 한다. 같은 장소에 있다는 것은 팀 구성원들이 바로 옆에 붙어 앉아서 일한다는 것이다. 같은 건물, 심지어 같은 층에 근무하는 것으로도 부족하다. 서로의 컴퓨터 화면을 쉽게 볼 수 있을 정도로 가까운 거리여야 한다.&nbsp;원격 협업이 더 확산되고 있는 상황에서 갑자기 구태의연한 방식을 이야기하는 것처럼 들릴지도 모르겠다. 그렇지만 최고의 기업들은 팀으로서 같이 앉아서 일하는 것의 가치를 절실히 느끼고 있다. 같은 장소에서 근무하는 제품팀 경험이 있다면 내가 무슨 말을 하는지 이미 잘 알고 있을 것이다. 같이 앉아 일하고, 함께 점심을 먹고, 서로 개인적인 신뢰를 쌓아가는 과정에서 발생하는 특별한 역동성이 있다. 당신은 제품팀의 일하는 방식에서 이것을 볼 수 있을 것이다.&nbsp;다소 감정적인 주제가 될 수도 있겠다. 개인적인 이유로 상당수의 사람들은 근무지가 아닌 곳에서 살고 있으며, 원격에서 효과적으로 일하는 것에 의존하고 있다. 나는 이것을 이분법적으로 판단하고 싶지 않으며, 오해를 만들고 싶지도 않다. 다른 모든 조건이 같다면 같은 장소에서 근무하는 팀이 흩어져 있는 팀보다 훨씬 더 높은 성과를 낸다. 사실이 그렇다는 이야기다.&nbsp;이러한 이유로 계약직이나 외주 업체보다는 정규 직원으로 제품팀을 구성하는 것을 훨씬 더 선호한다. 정규 직원이라야만 같은 장소에서 근무하며 안정적인 팀의 멤버로 함께할 수 있다. 여러 근무 장소를 활용하는 회사가 잘못되었다는 이야기는 아니다. 각 근무지에서 함께 근무하는 팀을 구성하기 위해 노력하면 되는 일이다.&nbsp;<h3 dir="ltr">팀의 업무 범위</h3>자, 이제 제품팀의 기본이 갖춰졌다. 그렇다면 그다음 나올 법한 중요한 질문이 있다. 각 제품팀의 업무 범위와 권한은 무엇인가? 각 팀의 책임은 무엇인가?&nbsp;여기에서 한 가지 축은 해야 할 일의 유형(Type of Work)이다. 팀은 제품과 관련된 그 어떤 일에도 모든 책임이 있다고 보면 된다. 프로젝트, 기능 구현, 오류 수정, 성능 관리, 최적화, 콘텐츠 수정 등을 모두 포함한다.&nbsp;다른 축은 해야 할 일의 범위(Scope of Work)다. 어떤 회사는 제품팀이 단일 제품 전체를 다룬다. 하지만 대개는 하나의 제품이 모든 고객 경험을 포함하고 있고(페이스북이나 페이팔을 떠올려 보라), 각 팀은 부분이지만 유의미한 단위의 사용자 경험을 담당한다.&nbsp;예를 들어, 이베이(eBay)의 제품팀을 생각해 보자. 팀은 사기 행동을 감지하고 방어하는 기술을 책임지는 업무를 할 수도 있고, 대량 판매자를 위한 도구와 서비스 제공을 책임질 수도 있다. 페이스북을 예로 들면 뉴스피드(Newsfeed) 메뉴를 담당하는 제품팀이 될 수 있다. 또는 iOS 모바일 애플리케이션을 맡을 수 있으며, 특정 시장에 필요한 기능들을 담당할 수도 있다.&nbsp;이것은 한 개 또는 소수의 팀으로 구성된 작은 스타트업에게는 무언가를 분리하면 해결되는 비교적 쉬운 주제일지 모른다. 하지만 회사가 성장하면서 몇 개 안 되는 팀에서 20개, 50개 팀으로 구성된 큰 제품 회사로 확대된다. 업무 조정은 갈수록 어려워지지만, 분리하는 것은 빠르게 확장할 수 있다. 사실 분리가 확장성의 핵심이다.&nbsp;파이(Pie)를 쪼개는 데는 다양한 방법이 있다. 다른 유형의 사용자나 고객을 기준으로 각 팀의 업무를 나눌 수 있다. 때로는 단말을 기준으로 나눈다. 어떤 경우에는 업무 단계나 고객 여정(Customer Journey)*을 기준으로 나누기도 한다.&nbsp;실제로 많은 경우에 우리는 주로 아키텍처를 기준으로 팀을 정의한다. 일반적으로 아키텍처가 기술 스택(Stack)을 결정하는데, 이 기술 스택별로 전문적인 인력이 필요하기 때문이다.* 옮긴이: 고객 여정은 고객이 제품 또는 서비스와 상호작용하는 모든 과정에 관한 전체 경험을 말한다. 흔히 고객 여정 지도(Customer Journey Map)로 시각화하여 표현한다.&nbsp;어떤 경우라도 제품 관리와 기술 구현이 잘 어우러져야 한다는 점이 핵심이다. 이러한 이유로 보통은 제품 총괄과 기술 총괄이 팀의 크기와 범위를 정하기 위해 함께 협력한다. 파이를 나누는 완벽한 방법은 없다. 하나의 최적화를 선택하면 또 다른 비용이 발생할 수밖에 없다. 그렇기 때문에 무엇이 가장 중요한지를 먼저 결정한 다음에 실행하기&nbsp;바란다.&nbsp;<h3 dir="ltr">팀의 지속성</h3>제품팀이 오래 지속해야 할 필요가 있음을 몇 차례 언급했었다. 다만 이것이 몇 개월일지 몇 년일지에 대해서는 이야기하지 않았다. 핵심은 제품팀이 함께 안정적으로 유지될 수 있도록 최선을 다해야 한다는 것이다.&nbsp;처음에 업무와 조직이 바뀐 사람들이 모여 팀이 구성된다. 서로에 대해 점점 이해하게 되면서 효과적으로 함께 일하는 법을 배운다. 이것은 정말 아름답고 멋진 일이다. 우리는 이 역동성을 망치지 않도록 최선을 다해야 한다.&nbsp;한 분야에서 혁신이 일어나기 위해서는 충분한 전문성을 확보할 시간이 필요하다. 지속성이 중요한 또 다른 이유다. 항상 이 팀 저 팀 이동하게 되면 충분한 전문성을 가지기 어렵게 된다. 그리고 미션에 대한 열정과 제품에 대한 주인 의식을 느끼기 쉽지 않다.&nbsp;제품팀은 특정&nbsp;프로젝트를 수행하기 위해 형성된 조직이 아님을 분명히 하고자 한다. 특정 프로젝트를 위해 몇 달간 모여서&nbsp;나중에 해체될 거라 생각하는 사람들이 미션을 지향하는 팀이 되는 것은 불가능에 가깝다.&nbsp;<h3 dir="ltr">팀의 자율성</h3>충분한 권한을 가졌다고 느끼면서 고객 문제를 해결하기 위한 열정으로 뭉친 팀을 원한다면 그들에게 높은 수준의 자율성을 제공해야 한다. 딴짓을 할 수 있다거나 재미있어 보이는 일만 한다는 뜻이 아니다. 팀이 판단하기에 주어진 문제를 해결하는 데 가장 적절하다고 생각하는&nbsp;최고의 방법을 시도해 볼 수 있다는 의미다.&nbsp;또한, 자율성은 팀 간의 의존성을 최소화할 수 있다. &#39;최소화&#39;할 수 있다는 것이지 &#39;완전히 제거&#39;하는 것은 아니다. 확장하는 상황에서 모든 의존성을 단순히 제거하는 것은 불가능하며, 지속적으로 최소화하기 위해 노력해야 한다.&nbsp;<h3 dir="ltr">제품팀이 왜 효과적인가</h3>제품 기업들은 몇 년 전부터 이 모델을 적용하기 시작했고, 이제는 뛰어난 제품 조직의 든든한 기둥이 되었다. 이러한 제품팀 모델이 왜 그토록 효과가 있는지에 대한 몇 가지 이유가 있다.<ul dir="ltr">	<li>협업에서는 관계가 중요한 역할을 하는데, 제품팀은(특히 같은 장소에서 일하는 경우) 이러한 관계를 잘 살리는 형태다.</li>	<li>전문성이 필요한 혁신을 하는 경우 오래 지속되는 제품팀은 구성원들이 전문성을 충분히 확보할 수 있을 만큼 깊이 업무를 수행한다.</li>	<li>제품팀은 다른 사람들이 가치 있을 것으로 예상해서 결정한 것을 만드는 것이 아니다. 제품팀 구성원&nbsp;전체가 비즈니스 목표와 상황을 잘 이해하고 있다.</li></ul><big>가장 중요한 점은 팀 전체가 성과에 대해 책임감을 느낀다는 것이다</big>프로젝트 중심의 전통적인 모델은 프로세스에 따라 할당된 업무를 수행하고 나면 끝이다. 반면에 전담팀 모델은 출시가 되었다고 문제가 다 해결된 것이 아니다. 사용자와 비즈니스 입장에서 원하는 결과가 나올 때까지 끈을 놓지 않는다.&nbsp;여러분은 탄탄한 제품 전담팀에 이미 속해 있고, 이제 이 모델의 목적에 더 잘 공감할 수 있기를 바란다. 만약 당신의 회사가 아직 제품 전담팀을 구성하지 않았다면 당신이 해야 할 가장 중요한 일은 제품 전담팀으로 변화하는 일이며, 이는 다른 모든 것에 영향을 준다.&nbsp;한 번에 전체 조직을 바꿔야 할 필요는 없다. 하나의 팀을 대상으로 먼저 작게 시작해 보자. 어떻게 해서든, 지속해서 유지되는 제품팀을 만들거나 그 팀에 들어가야 한다.&nbsp;<h3 dir="ltr">원칙과 기법</h3>왜 이렇게 많은 원칙(Principle)을 강조하는지에 대해 따로 설명하고 싶었다. 나는 제품 관리자들을 코치할 때 우리가 일하는 방식을 개선해야 하는 이유의 근본적인 원칙들을 설명하기 위해 항상 노력한다.&nbsp;한 사람이 원칙에 대해 깊은 이해를 하는 수준에 이르게 되면 각 기법(Technique)이 어떨 때 적절하고 유용한지와 그렇지 않은지에 대한 현명한 판단을 할 수 있는 좋은 심성 모형(Mental Model)을 가지게 된다. 나아가 새로운 기법이 나왔을 때 그들은 빠르게 그 기법의 잠재적인 가치를 평가한다. 그리고 언제, 어디에서 가장 유용하게 쓰일지 판단한다.&nbsp;내가 지난 몇 년간 관찰한 결과, 기법은 꾸준하게 변화하지만&nbsp;근본적인 원칙은 변하지 않는다. 기법에 대해 바로 소개하는 것이 더 솔깃하게 느껴지겠지만, 먼저 원칙을 충분히 살펴봤으면 한다. 그러고 나면 훌륭한 제품을 만드는 방법에 대한 보다 깊은 이해를 만들어 나갈 수 있다.

제품 디자이너

엔지니어

제품 마케팅 매니저

제품 디자이너/엔지니어/제품 마케터

디폴트 하단 배너 타이틀

디폴트 타이틀

이런 분들에게 권합니다

제품팀 만들기: 이승국 큐레이터의 말(1)

기술 중심 제품에 대한 오해: 이승국 큐레이터의 말(2)

서비스 기획 직무에 대한 오해: 서동환 큐레이터의 말

큐레이터의 말: 제품 기획? 제품 관리!

제품의 핵심 개념

핵심 개념

좋은 제품팀 Vs. 나쁜 제품팀

혁신을 잃는 10가지 이유

속도를 잃는 10가지 이유

강력한 제품 문화 구축하기

제품 문화

훌륭한 제품을 이끄는 사람

실패한 제품의 근본 원인

보편적인 업무 방식이 갖는 문제 10가지

린과 애자일을 넘어

최고의 기술 기업에서 배운 것

리더십의 역할

제품 총괄의 역할

기술 총괄의 역할

리더십

제품 로드맵 개요

제품 로드맵의 문제

제품 로드맵의 대안

제품 로드맵

제품 비전과 제품 전략

제품 비전의 원칙

제품 전략의 원칙

OKR 기법

제품팀의 목표

확장 단계에서의 제품 목표

목표

제품 발견

제품 발견의 원칙

가치 테스트

사업 유효성 테스트

가치 테스트 및 사업 유효성 테스트

이해 관계자 관리하기

혁신을 잃게 되는 상황

이해관계자 관리하기

당신에게 '인스파이어드'는 어떤 콘텐츠였나요?

큐레이션이 어땠나요?

인스파이어드: 감동을 전하는 IT 제품은 어떻게 만들어지는가?