[경영] 개발 함정을 탈출하라 - 2부 프로덕트 매니저의 역할과 커리어

이전 글

2023.03.20 - [IT 말고/책] - [경영] 개발 함정을 탈출하라 - 1부 개발함정과 프로덕트 매니지먼트의 개념

[경영] 개발 함정을 탈출하라 - 1부 개발함정과 프로덕트 매니지먼트의 개념

2부 프로덕트 매니저의 역할

 
2부에서는 프로덕트 매니저가 구체적으로 어떤 일을 하고, 프로덕트 매니저의 커리어를 어떻게 구성해야 하는지에 대해 정리하고 있습니다. 

프로덕트 매니지먼트는 회사 내의 직무 중 하나를 넘어선 커리어이다. 프로덕트 매니저는 기업과 소비자 양쪽을 깊이 이해해 가치를 창출할 적절한 기회를 알아본다. 사용자 분석, 소비자 반응, 시장조사, 주주 의견 등 여러 자료를 종합한 후 팀이 나아갈 방향을 결정할 책임이 있다. 프로덕트 매니저는 팀이 '왜'에 집중하게 해야 한다.

프로덕트 매니지먼트를 배울 수 있는 곳은 많지 않다. 대학에는 그런 교육과정이 없다. 기업에서의 직무훈련은 부실하기 마련이다. 프로덕트 매니저가 신입으로 경력을 쌓을 수 있는 대기업은 마이크로소프트와 구글이 전부다. 인턴십은 보기 드물고 우리가 만나는 프로덕트 매니저의 대부분은 사내에서 수평이동했거나 소프트웨어 개발직에서 '승진'한 사람들이다.

많은 회사들이 애자일을 채택해 왔지만 돌아오는 것은 실망뿐이었다. 왜 그랬을까? 애자일이 협력 방식을 개선하고 소프트웨어 개발 속도를 높여주는 것은 맞지만 프로덕트 매니지먼트를 효과적으로 진행하는 면은 대체로 무시되었기 때문이다. 애자일은 누군가가 깔때기 앞단에서 아이디어를 도출, 검증하고 있다는 가정하에 소프트웨어 제작과적을 최적화했지만 그 부분들은 개발과정에서 사라졌다. 그래서 애자일 조직의 수많은 프로덕트 매니저가 여전히 폭포수형 방식으로 일한다. 

현실적으로 프로덕트 매니저는 전문성을 인정받기보다는 generalist 취급을 받는 경우가 많은데요. "회사 내의 직무 중 하나를 넘어서 커리어"라는 말이 좀 위로가 되는군요. 도메인 지식을 넘어서 데이터를 종합하고, 팀이 나아갈 전략 방향을 정하는 것도 프로젝트 관리 기법처럼 전문성이 인정되어야 하는 분야라고 생각합니다.

올바른 프로덕트 매니지먼트란?

나쁜 프로덕트 매니저의 전형

미니 CEO:CEO는 많은 사안에서 독점적 권한을 가진다. 반면 프로덕트 매니저는 조직 안에서 CEO처럼 많은 것을 바꿀 수 없다. 다만, 팀원들이 특정 방향으로 나아가도록 방향을 제시할 뿐이다.

웨이터: 이해관계자, 고객, 매니저에게 다가가 무엇을 원하는지 물어보고 그들의 요구를 정리해 개발할 사항을 나열한다. 목표, 비전, 의사결정 과정도 없다. 이런 유형의 프로덕트 매니저들이 가장 많이 한 질문은 우선순위를 정하는 방법이었다. 목표가 없으니 우선순위 설정이 요청하는 사람들 사이에서 인기투표로 전락하고 말았다. 가장 중요한  사람이 원하는 기능이 우선시되는 경우가 많았다. 보통 이런 태도는 학습된 무력감에 크게 기인한다. 하지만 프로덕트를 성공으로 이끌려면 남의 말을 거부하는 과정은 필수다. 그것도 일의 일부다.

전직 프로젝트 매니저: 프로젝트 매니저는 '언제'를 책임진다. 프로젝트를 언제 완성할까? 모두 일정을 잘 따라오고 있나? 마감일을 맞출 수 있을까? 프로덕트 매니저는 '왜'를 책임진다. 이것을 왜 개발할까? 우리 고객에게 가치를 어떻게 전달할까? 이것이 사업목표 달성에 어떻게 기여할까? '왜'라는 질문은 '언제'를 챙기는 것보다 어려운 문제이며 자신의 역할을 제대로 이해하지 못하고 프로젝트 다루듯 일을 진행하는 프로덕트 매니저가 무척 많다...(중략).. 우리에게는 고객, 사업, 시장, 조직을 이해하는 전략적 태도가 필요하다. 이것은 훌륭한 프로덕트 매니저가 되는 데 필요한 결정적인 역량이다.

미니 CEO 같은 유형은 회사에서 본 적이 없습니다만, 웨이터 같은 유형은 흔히 볼 수 있습니다. 그러나 그것을 비난할 수가 없는 것은 거부를 거부당해 본 경험 때문에 더 이상 거부를 하지 않게 된 것이기 때문입니다. 개인적인 판단으로 개발을 거부해도 저기 어디 윗분들을 통해서 요청하면 "야 그냥 해줘"라는 지시를 들었기 때문이죠. 우선순위 이야기를 보니 더 그렇네요. 우선순위가 높은 개발 건은 절대 거부할 수 없거든요. 우리가 거부할 수 있는 것은 우선순위가 낮은 개발 건뿐인데, 우선순위가 낮다고 꼭 가치가 낮은 것도 아니니까요. 

훌륭한 프로덕트 매니저

기업이 프로덕트 매니저를 고용할 때 저지르는 가장 큰 실수 중 하나는 기술 전문가나 시장 전문가를 찾으려는 것이다. 프로덕트 매니저는 둘 중 아무 영역의 전문가도 아니다. 프로덕트 매니저는 프로덕트 매니지먼트 분야의 전문가다. 그렇다고 기술이나 시장에 대한 지식이 필요 없다는 뜻은 아니다. 엔지니어나 사업부서 사람들과 대화를 나누고 충분한 정보를 바탕으로 의사결정을 내릴 수 있는 정도의 지식이면 충분하다.

프로덕트 매니저는 수반되는 위험을 철저히 따져보지도 않은 채 해결 방안 모색 단계로 뛰어드는 경우가 많다...(중략) 모든 문제 해결 방안은 개인이나 조직의 편견에 좌우된다. 모든 편견을 물리치려면 사용자로부터 배우고 실험할 수밖에 없다.  

성공적인 프로덕트를 만드는 데 중요한 질문들
- 가치를 어떻게 결정할까?
- 시장에서는 프로덕트의 성공 여부를 어떻게 측정할까?
- 우리가 올바른 프로덕트를 개발하고 있다는 것을 어떻게 알 수 있을까?
- 우리 프로덕트의 가격 책정과 포장은 어떻게 할까?
- 우리 프로덕트를 시장에 어떻게 내놓을까?
- 프로덕트 개발과 구매 중 어느 것이 나을까?
- 신규 시장에 진입할 때 제3의 소프트웨어를 어떻게 통합해야 할까?

여기에서 문제 해결 방안이 개인이나 조직의 편견에 좌우된다는 것은 프로덕트 매니저가 사용자로부터 배우고 실험하기 전에 상사나, 조직이 무엇을 개발할지 미리 정해서 프로덕트 매니저에게 지시를 하게 되면 편견이 동작한다는 뜻입니다.
어떤 영화를 보기 전에 "범인은 절름발이다"라고 스포를 하지 않아도 "이 영화 반전이 죽여줘~"라는 말만 들어도 영화의 반전이 무엇인지를 찾아내기 위해 생각을 하게 되고, 영화 보는 재미가 반감되는 경우처럼 아무리 사소한 것도 편견을 만들기에 부족하지 않은 것 같습니다. 하지만 현실적으로 "왜"를 고민할 시간이 많지 않은 것이 문제입니다.

기업과 고객에게 가치를 선사하는 프로덕트를 개발하고 싶다면 회사 안에 서 바람직한 프로덕트 매니지먼트 기반을 다져야 한다. 이 기반이 다져져 야 직원들이 상위 역할로 성장하면서 커리어를 발전시킬 수 있으니 직원들이 프로덕트 매니저처럼 생각하게 하자. 그들은 대부분 스크럼 팀에서 프로덕트 오너 역할을 맡고 있을지도 모르지만 그들이 프로덕트 매니저처럼 생각해야 기업이 올바른 프로덕트를 개발하고 있는지 검증할 수 있다.

  프로덕트 매니지먼트를 하려면 회사에 프로덕트 매니지먼트 기반이 있어야 합니다. 회사차원에서 프로덕트 매니지먼트에 대해 아무 관심이 없는 상황이라면 프로덕트 매니저는 프로덕트 오너의 역할밖에 할 수 없습니다.

프로덕트 매니저의 업무 유형

프로덕트 매니저의 전술 업무는 기능을 구축해 출시하는 단기활동 위주다. 개발자와 디자이너의 업무를 분류하고 살펴보는 일상업무, 다음 업무를 결 정하기 위해 데이터를 처리하는 업무가 여기에 해당한다.
전략 업무는 프로덕트와 회사가 시장에서 성공하고 목표를 달성하게 만들어 줄 위치선정 작업이다. 제품과 회사가 미래에 어떤 모습이어야 할지, 그 모습이 되기 위해 무엇을 해야 할지 구상한다. 운영 업무는 전략을 전술 업무와 결합시키는 것이다. 이 지점에서 프로덕트 매니저는 프로덕트가 현 상태에서 미래 상태로 나아가고 팀원들의 업무
를 정렬하기 위한 로드맵을 만든다.

기업의 규모가 클수록 프로덕트 팀의 규모도 커지고 그에 따라 프로덕트 매니지먼트 조직도 체계를 갖추어 커리어를 개발해 나갈 수 있도록 해야 한다고 합니다. 그래야 프로덕트 매니저들이 상위 역할로 성장하면서 커리어를 발전시킬 수 있다고 하네요. 프로덕트 매니저의 커리어 단계를 설명하기 위해 프로덕트 매니저의 업무를 크게 전술업무, 전략업무, 운영업무로 나누었습니다. 직급이 낮을 때는 전술업무 비중이 크고, 직급이 올라갈수록 전략업무 비중이 높아져야 한다고 설명하고 있습니다. 아래는 커리어 단계별 상세 내용입니다.

프로덕트 매니저의 커리어 패스

1. 보조 프로덕트 매니저

보조 프로덕트 매니저는 프로덕트 매니저 입문 단계다.  훌륭한 프로덕트 매니저를 원하는 기업은 그런 인재를 
직접 길러내기 시작해야 한다...(중략)

프로덕트 매니지먼트 업무는 이틀 만에 배워서 정복할 수 없다. 타 전문 분야와 마찬가지로 경험과 실습을 통해 역량을 갈고닦아야 한다.

후배들에게 사수가 되어 줄 경력 있는 프로덕트 매니저가 있어야 한다.

회사에서는 사원급에 해당하는 것 같습니다. 그런데, 구글과 마이크로소프트를 제외하면 보조 프로덕트 매니저로 시작할 수 있는 기업은 없다고 합니다. 음.. 저는 입사 때부터 프로덕트 매니저와 비슷한 일을 해왔기 때문에 어쩌면 우리 회사야 말로 구글과 마이크로소프트에 견줄만하지 않나라는 생각이 드네요ㅋ
프로덕트 매니지먼트를 이틀 만에 배워서 정복할 수 없다는 것은 동의하는 부분입니다. 프로덕트 매니저는 경험과 실습으로 기를 수 있습니다. 아무리 역량 교육을 해도 실제 부딪혀보지 않으면 알 수 없는 것들이 있으니까요.

2. 프로덕트 매니저

프로덕트 매니저는 개발팀, UX 디자인팀과 협력해 고객에게 적합한 해결 방안을 구상하고 구축한다. 그들은 프로덕트 개발 단계부터 참여해 사용자와 대화하고 데이터를 종합하고 기능에 대한 결정을 내린다. 
프로덕트 매니저는 보통 하나 또는 한 묶음의 기능을 책임지며, 이러한 기능은 프로덕트라는 더 큰 결과물의 일부분이다.

프로덕트 매니저는 어려운 자리다. 전략적으로 생각해 기능의 비전을 만들고 프로덕트 전체와 어우러지게 해야 한다.  그러면서도 전술적으로 생각해 해결 방안을 원활하게 수행할 전술을 생각해야 한다. 이 단계에서는 단기적인 영향을 받는 책임을 수행하고 로드맵에 제시된 기능들을 출시하므로 전략 관련 업무보다 운영 관련 업무가 많다.

프로덕트 매니저가 운영 업무만 도맡아 프로덕트를 출시하는 과정만 관리하고, 전체적인 관점에서 기능을 최적화하는 데 집중하지 않으면 위험하다. 팀의 하루하루 업무 처리를 최적화하는 데만 급급해지면 기능을 성공으로 이끌기 위해 필요한 전략을 세우고 비전을 제시하는 일이 뒤로 밀리기 때문이다. 그래서 프로젝트 매니지먼트 활동을 팀원들에게 최대한 맡기고 출시 업무를 위임해야 한다.

프로덕트 매니저는 더 큰 프로덕트 팀의 일원으로서 프로덕트와 포트폴리오 단계에서 프로덕트 담당자들에게 기능의 성과 관련 데이터를 공급한다. 이 데이터는 프로덕트 포트폴리오와 조직의 전략 방향성을 보여준다. 프로덕트 매니저는 보통 프로덕트 디렉터, 소기업에서는 프로덕트 부사장에 게 보고한다.

많은 기업이 프로덕트 오너 직책을 프로덕트 매니저가 되기 전에 거치는 입문 단계로 간주한다. 앞에서 설명했듯이 프로덕트 매니저가 전략만 담당하고 프로덕트 오너가 전술만 담당한다고 생각하면 비전과 일상 업무를 잇는 연결고리가 끊어진다. 그러면 앞에서 설명했듯이 프로덕트 오너가 전술에만 치중할 때 생기는 위험이 닥친다. 
커리어를 개발하고 위로 올라가려는 프로덕트 책임자에게 실전에 필요한 전략업무 경험이 없는 것이다.
 업계 차원에서 프로덕트 오너라는 직책을 없애고 이 직무를 맡은 사람을 모두 프로덕트 매니저라고 불러 일관되고 의미 있는 커리어 경로를 만드는 것이 가장 바람직하다고 본다
.

회사에서는 대리, 과장급인 것 같습니다. 프로덕트 매니저의 역할에 대해 설명하고 있는데, 보조 프로덕트 매니저는 아무것도 모른다고 치면 사실상 가장 하위에 있다고 보면 될 것 같습니다. 그럼에도 불구하고 하나 또는 한 묶음의 기능을 책임져야 하기 때문에 책임이 작지는 않습니다. 회사마다 차이는 있겠으나, 이 책의 PM 직급 체계를 따르지 않는 회사는 대부분 팀장이하 모두가 프로덕트 매니저인 것 같습니다. 프로덕트 매니저는 단기적인 업무를 주로 하므로 전략과 비전에 소홀해지기 쉽습니다. 전략과 비전을 세우고 그에 따라 프로덕트를 관리해야 개발함정에 빠지지 않을 것이므로 항상 높은 수준에서 생각하는 습관이 필요합니다. (보통은 전략적으로 생각합니다. 하지만, 앞서 본 것처럼 학습된 좌절감으로 인해 전략적으로 사고하지 않는 것이라고 생각합니다.)
제가 PM업무를 하면서 하지 않았던 것 중의 하나가 "기능의 성과 관련 데이터"를 공급하는 것이었습니다. 아무도 요구하지 않았고, 측정할 방법도 마땅치 않으니, 속으로만 생각하는 경우가 많았습니다. 
그리고 가장 안타까운 것은 "프로덕트 매니저가 전략만 담당하고 프로덕트 오너가 전술만 담당한다고 생각하면 비전과 일상 업무를 잇는 연결 고리가 끊어진다"는 부분입니다. 여기서는 프로덕트 오너가 전략경험이 없이 프로덕트 매니저가 되는 경우를 말하고 있지만, 이것은 프로덕트 매니저입장에서도 일상업무에 대한 감이 떨어지면서 전략에 대한 현실성이 떨어지는 문제가 생길 것이라고 생각합니다.  

3. 선임 프로덕트 매니저
선임 프로덕트 매니저는 프로덕트 매니저와 같은 책임을 맡지만 더 광범위하고 복잡한 프로덕트를 감독한다.
 프로덕트 매니지먼트 부문에서 개인적인 기여자로서 올라갈 수 있는 높은 자리다. 즉, 선임 프로덕트 매니저는 인력 관리에 관여하지 않는다. 팀을 성장시키기보다 프로덕트를 만드는 데 집중한다. 운영 업무를 맡길 사람이 없으므로 보고를 직접 하지 않으면 매우 어려운 자리다. 전략 업무와 운영 업무를 모두 높은 수준에서 수행하면서 둘 사이의 균형을 잡아야 한다.

우리 회사는 선임 프로덕트 매니저가 딱히 구분되어있지는 않지만, 프로덕트 매니저 중에서 차장이나 부장급 시니어가 이에 해당되는 것으로 보입니다. 

4. 프로덕트 디렉터

기업이 성장하면...(중략) 
프로덕트 부서에 프로덕트나 포트폴리오 비전을 주지시켜 그들이 전략을 일관되게 적용하고 운영업무를 효율적으로 진행하도록 도와줄 프로덕트 디렉터가 필요하다.
프로덕트 디렉터 직급은 인력관리의 첫 단계다. 프로덕트 매니저들은 포트폴리오나 프로덕트 라인에 속한 프로덕트 하나를 중심으로 일하며 프로덕트 디렉터가 이 매니저들을 감독한다. 프로덕트 디렉터는 보통 향후 1년 앞을 내다보며 프로덕트의 전략적 로드맵을 책임진다. 모든 프로덕트 매니저가 한 방향을 바라보면서 적절한 목표를 가지고 프로덕트 발전을 위해 가장 중요한 일을 하고 있는지 확인해 팀을 효과적으로 운영하는 것도 프로덕트 디렉터의 몫이다.

팀장급을 의미하는 것 같습니다. 이 단계부터 인력관리를 한다고 하니까요. 

5. 프로덕트 부사장

프로덕트 부사장은 프로덕트 라인 전체의 전략과 운영을 감독한다...(중략)
대기업의 프로덕트 부사장은 프로덕트 기능 출시뿐만 아니라 프로덕트 라인의 재무적 성공도 직접 책임진다. 대기업에서 프로덕트 부사장은 프로덕트 포트폴리오를 성공적으로 구축하기 위해 통일된 전략과 목적을 가져야 한다. 
중소기업에는 프로덕트가 하나뿐이고 프로덕트 라인이 여러 개 있지 않으므로 보통 프로덕트 부사장이 가장 높은 직급이다.

실무에서 프로덕트 부사장은 전략, 전술 중 한쪽에 더 치중한다...(중략) 프로덕트 부사장으로 성공하려면 무엇보다 전략적이어야 하고 조직 규모를 키우려면 전술업무와 운영업무를 넘겨받을 사람들을 뽑아야 한다는 사실을 알아야 한다. 부사장 자리에서 전략에 가장 주력하는 최고 프로덕트 책임자 자리로 올라가기 위해서도 이 과정이 필요하다.

상무급으로 보이는데요. 하나의 프로덕트 전체를 책임집니다. 이 단계부터는 사실상 전술업무는 거의 하지 않으며 운영과 전략에 집중하게 됩니다. 재미있는 부분은 전술업무와 운영업무를 넘겨받을 사람들을 뽑아야 한다는 것이네요. 

6. 최고 프로덕트 책임자(CPO)
CPO는 회사의 프로덕트 포트폴리오 전체를 감독한다. 프로덕트 매니저로서 가장 높은 직급이며 기업 임원이 된다는 의미다.
기업은 두 번째 프로덕트를 개발하고 다른 지역에 진출하거나 다른 기업과 합병하기 시작하는 단계에서 CPO 선임을 고려한다. 이 자리는 포트폴리오 전체가 회사 목표 달성을 향해 일사불란하게 전개되도록 하는 중요한 역할을 한다.
모든 프로덕트가 회사의 목표와 전략적 궤를 함께 하도록 각 프로덕트에 목표 달성을 위한 자원과 인력을 배치시킨다.

..(중략) “이사진은 기술과 프로덕트 관련 결정이 미치는 재무적 영향에 신경 씁니다. CPO로 성공하려면 프로덕트 부문에서 이루어지는 활동들을 이사진이 이해하는 언어로 옮길 수 있어야 합니다."
이미 프로덕트, 기술, 재무관리 면에서 모두 뛰어난 사람들이 있다고 할 때 최고 프로덕트 책임자로서 빛을 발하는 사람은 3가지 면에서 두드러진다. 신뢰감을 추고, 공감하며, 굴복하지 않고 끈질기게 버티는 것이다.
...(중략) 상대방에 맞추어 이야기 전개 방식을 조정하고 집단 사이에서 진정성 있는 행동을 해야 한다. 그래야만 직접적인 지시를 내리는 대신 영감을 주는 방식으로 일을 처리할 수 있다.
다른 최고 경영자급 직책과 마찬가지로 CPO는 프로덕트 매니지먼트의 교과서적 원칙만을 바탕으로 결정을 내리는 자리가 아니다. 현재 상태, 재무 적 목표, 조직 증감률과 같은 다른 요소들을 반드시 고려해야 한다. CPO는 다른 임원진, 고객, 팀들과 공감함으로써 모든 목표에 일관성을 부여하 고 앞으로 나아가는 길을 찾는다. 그러면 유사 업계를 면밀히 살피고 고객의 관점을 직접 체험할 수도 있다.
마지막으로 CPO는 절대로 굴복하지 않는 끈기가 있어야 한다. 무엇이 효과적이고 무엇이 그렇지 않은지 파헤치고 알아내려는 열망이 필요하다. 끊임없이 평가, 분석하고 가설을 검증하고 스스로 데이터에 대한 책임을 진다. 뭔가 계획대로 작동하지 않을 때는 문제를 파헤치고 무엇을 해야 할지 파악하는 집요함이 있어야 한다.

전무 혹은 부사장급으로 보입니다. "임원"이라고 명시되어있기도 하고, 그 쯤 되어야 "전략"에 올인할 수 있을 것 같습니다. 인상 깊은 부분은 "상대방에 맞추어 이야기 전개 방식을 조정하고 집단 사이에서 진정성 있는 행동을 해야 한다"는 내용인데요. 높이 올라갈수록 직접 모든 걸 다하려고 하면 안 된다는 뜻입니다. 모든 것에 손대다 보면, 전략을 고민할 시간은 줄어들고, 직원의 사기는 떨어지니까요.
이 부분은 내용이 길지만, 생소하면서도, 관심이 가는 부분이기도 해서 많이 인용했습니다. 

프로덕트 전략 중심 조직

팀 조직하기

특정 기능을 중심으로 팀들을 구성하면..(중략)... 아예 처음부터 개발을 시작하는 경우에는 좋은 방법이지만 이런 방식은 시간이 흐를수록 결과물 중심적인 태도를 야기한다.
한 걸음 물러나 이 팀들의 업무를 프로덕트와 전략의 전체적인 비전에 맞게 조율하면(다음 절에서 다룬다) 그중 우선 다루지 않아도 될 일이 무척 많을 것이다. 기능이 안정되면 모니터링을 지속하면서도 프로덕트 전략을 뒷받침하기 위해 더 중요한 다른 일로 넘어가야 한다.

여기서 이런 질문이 나올 수 있다. 팀들이 모든 기능을 담당해서 기능들을 돌보는 사람이 늘 존재하게 만드는 게 낫지 않을까? 그렇기도 하고 아니기도 하다...(중략)... 각자 주어진 목표를 책임지고 성과를 바탕으로 성공 여부를 평가받는다. 각자 목표를 달성하기 위해 필요한 일이라면 뭐든지 할 수 있도록 모든 프로덕트를 넘나들며 일한다.  이렇게 조직을 구성하면 회사 전반에 여유가 생겨 한 제품에 대한 중요한 정보가 1명의 머릿속에만 머물지 않는다...(중략)... 다만, 기업 규모가 커지고 특히 관리하는 프로덕트가 두 개 이상으로 늘어나면 이 방식은 힘을 잃는다. 팀을 꾸릴 때 다른 요소를 추가해야 하지만 프로덕트 전략과 목표를 중심에 두는 구조는 유지하는 것이 좋다. 이 요소들과 함께 조직의 가치 흐름도 보아야 한다.

프로덕트 매니지먼트의 전제는 프로덕트 전략을 중심으로 팀을 조직하는 것입니다. 이때 기능 중심으로 팀을 구성하는 것은 프로덕트가 처음 개발되는 시점에는 좋은 방법이지만, 프로덕트가 안정화되면 그 후에는 프로덕트의 전략과 목표 그리고, 조직의 가치흐름을 보아야 한다고 합니다.

가치 흐름은 고객에게 가치를 전달하는 데 필요한 모든 행동을 말한다...(중략)... 조직이 고객에게 가치를 전달하는 속도를 높이려면 이 흐름을 최적화하기 위해 노력해야 한다. 그러려면 가치 흐름을 중심으로 팀들을 조직하는 것이 맞다. 

프로덕트는 가치를 전달하는 수단이므로 앱, 인터페이스, 기능이 그 자체로 가치를 더해주지 않는다면 프로덕트 전체 중 일부로 보아야 한다. 

책을 읽는 내내 "그렇다면 우리 회사의 프로덕트는 무엇일까?" 계속 고민하고 있었는데, 여기서 나오네요. 여기서는 보험회사를 예로 들고 있는데요. 자동차보험이 가치이고, 자동차보험을 관리하기 위한 앱은 그 자체로 가치를 전달하지 못하고, 자동차포험이 필요하므로 가치 흐름의 단편에 불과하다고 합니다. 따라서 스마트폰 관리 앱을 프로덕트 매니저 한 명이 담당하더라도 프로덕트 매니저는 자동차보험이라는 프로덕트 관리 부서에 속해 있어야 합니다. 

회사가 프로덕트를 늘리기 위해 규모를 키울수록 매니지먼트 단계를 늘려야 다양한 영역을 효과적으로 감독할 수 있다. 

대신 너무 단계가 늘어나도 문제겠죠.

마케틀리 프로덕트 매니지먼트 조직 차트의 최종 상태

위 그림은 가상회사 마케틀리의 매니지먼트 조직 차트입니다. API와 같은 성분영역을 중간에 두지 않고 가치흐름을 중심으로 구성한 조직 차트입니다. 원래 마케틀리의  프로덕트팀은 총 20개였으나, 줄어든 것입니다. 프로덕트를 가치 흐름에 따라 분류하게 되면 생각보다 많은 사람이 필요하지 않다는 것을 알게 된다고 합니다.

몇 가지 핵심 목표를 중심으로 철저히 우선순위를 정하면서 일관된 프로덕트 전략을 수립하지 않은 조직은 결국 얇고 넓적하게 퍼져버린다. 그러면 프로덕트 전체를 보지 않은 채 구성 성분들을 최적화하려고 노력하는 팀들이 많아진다. 

맞습니다. 기능이 추가되는 대로 그 기능마다 사람을 붙이다 보면 조직이 점점 늘어나고 전체적인 전략과 동떨어지게 되는 것 같습니다.

3부에 계속..

 

2023.03.22 - [IT 말고/책 리뷰] - [경영] 개발 함정을 탈출하라 - 3부 프로덕트 전략을 세우는 방법

[경영] 개발 함정을 탈출하라 - 3부 프로덕트 전략을 세우는 방법