개발 함정을 탈출하라 by 멜리사 페리

 

[ 밑줄/연결 ]

 

특정 인물이나 부서의 잘못이 아니라 조직 자체가 성공할 수 없는 구조였기 때문이다.

 

개발 부서는 기능을 잔뜩 만들어 게시하면 보상을 받는다. 이 해로운 사고방식이 조직에 만연해 있다.

 

결과가 아닌 산출에 최적화된 회사의 전형적인 예다. 산출은 우리가 제작해 쉽게 정량화할 수 있는 것들이다.

프로덕트나 기능의 개수, 출시 횟수, 개발부서의 속도 등이 그 예다.

 

 

프로덕트를 중심에 두지 않는 기업의 중심에는 무엇이 있을까? 

영업, 비전, 기술이 중심인 기업들이 많은데 이런 식으로 조직을 구성하면 개발 함정에 빠지고 만다.

 

 

프로젝트 매니저형..

그들은 "왜" 보다는 "언제"에 집중하곤 하기 때문이다.

프로젝트 매니저가 프로덕트 매니저의 직무를 맡으면 일정표를 가지고 다니는 웨이터가 되기 쉽다.

웨이터는 문제를 발견하지 않고 묻기만 한다. "무엇을 원하세요?"

 

프로덕트 매니저는 "왜"를 책임진다.

이것을 왜 개발할까? 우리 고객에게 가치를 어떻게 전달할까? 이것이 사업목표 달성에 어떻게 기여할까? 

 

프로덕트 매너저는 기술 전문가나 시장 전문가가 아니다. 

프로덕트 매니저는 프로덕트 매니지먼트 분야의 전문가다. 

 

개발자와 함께 일하고 사용자의 필요와 문제들을 개별적으로 분류하고 데이터를 측정하는 기반은 직급을 불문하고 프로덕트 매니저에게 중요한 역량이다. 

 

계획을 세세하게 짜놓는 것이 아니라 의사결정을 도와주는 체계를 제시하는 것이 훌륭한 전략이다.

 

프로덕트를 중심에 두지 않는 기업의 중심에는 무엇이 있을까? 영업, 비전, 기술이 중심인 기업들이 많은데 이런 식으로 조직을 구성하면 개발 함정에 빠지고 만다. 

 

(영업 중심)

ㅇ 전략을 전체적으로 정렬하지 않고 고객사에게 해준 약속에 따라 프로덕트 로드맵과 방향을 결정한다.

 

(비전 중심)

ㅇ 비전이 사라지면 프로덕트는 방향을 잃고 무너지기 십상이다. 

 

(기술 중심)

ㅇ기술은 SW 기업 성공의 중요한 열쇠이지만 프로덕트 전략까지 기술에 좌우되게 놔둘 수는 없다. 

ㅇ 기술은 무척 멋있지만 정작 아무도 안 사는 프로덕트를 열심히 생각한다.

 

(프로덕트 중심)

ㅇ 사업 결과를 최적화하고 그 목표에 맞게 프로덕트 전략을 통일하고 그 프로덕트를 지속가능한 성장동력을 개발하는 데 가장 효과적인 프로젝트들을 최우선적으로 진행한다. 

 

프로덕트 매니저가 신입으로 경력을 쌓을 수 있는 대기업은 마이크로소프트와 구글이 전부다.

 

프로덕트 매니저는 프로젝트 매니저가 아니다. 프로젝트 매니저는 "언제'를 책임진다. 프로젝트를 언제 완성할까? 모두 일정을 잘 따라오고 있나? 마감일을 맞출 수 있을까?

프로덕트 매니저는 '왜'를 책임진다. 이것을 왜 개발할까? 우리 고객에게 가치를 어떻게 전달할까? 이것이 사업목표 달성에 어떻게 기여할까? '왜'라는 질문은 '언제'를 챙기는 것보다 어려운 문제이며 자신의 역할을 제대로 이해하지 못하고 프로젝트 다루듯 일을 진행하는 프로덕트 매니저가 무척 많다.

 

프로덕트 매니저는 점들을 연결한다. 고객 연구, 전문가의 정보, 시장조사, 사업 방향, 실험 결과, 데이터 분석 자료를 면밀히 뜯어보고 분석한 후 이것을 활용해 회사를 발전시키고 고객의 필요성을 채우는 데 기여할 프로덕트 비전을 그린다.

 

프로덕트 매니저먼트는 시스템 전체를 돌보는 활동이다. 요구사항, 기능 요소, 가치 제안, 사용자 경험, 기저에 깔린 사업 모델, 가격전략과 결합 상태를 모두 살펴보면서 그것으로 회사에 수익을 안겨줄 방법을 구상해야 한다. 

스티브 번게이(Stephen Bungay)는 여러 조직에서 전략을 연구하면서 전략을 계획처럼 다루는 기업은 기대한 바를 이루지 못하는 경우가 많다는 것을 알게 됐다. 결과, 계획, 행동 사이의 간극을 메우지 못한 것이 실패의 원인이었다. 이 간극은 결국 조직 내에서 마칠을 일으킨다.

 

(전략의 간극)

전략을 계획처럼 다루는 기업은 기대한 바를 이루지 못하는 경우가 많다는 것을 알게 됐다.

결과, 계획, 행동 사이의 간극을 메우지 못한 것이 실패의 원인이었다.

 

(지식 간극)

ㅇ 경영진이 알고 싶어 하는 것과 기업이 실제로 아는 것 사이의 간극

ㅇ 경영자는 소통에 집중하고 의사결정에 필요한 만큼만의 정보를 요구해야 한다.

ㅇ 상급 경영자는 더 자세한 정보를 갈구하는 대신 전략적 의도나 사업 목표를 정의하고 전달하는 선까지만 정보를 탐색해야 한다. 

(정렬 간극)

ㅇ 직원들이 하는 일과 경영진이 사업목표 달성을 위해 직원들로부터 바라는 것의 차이를  뜻함

ㅇ 세세한 지시를 내리기 보다 상부조직이 원하는 목표를 사내 각 층위가 달성할 방안을 직접 정의하도록 해야 함

ㅇ 회사의 전략적 의도와 비전에서 벗어나지 않는 한, 경영진은 실무진에게 필요한 자율성을 기꺼이 내 줄 수 있어야 함

(효과 간극)

ㅇ우리가 특정 행동으로부터 기대하는 결과와 실제 결과의 차이

ㅇ개인과 팀이 목표를 달성할 수 있도록 각자의 행동을 조정할 재량을 주는 것이 그들이 원하는 결과를 이루게 해주는 길이다. 

프로덕트 조직 대부분의 전략 배치는 크게 4단계로 구성되어야 한다.

ㅇ 비전

ㅇ 전략적 의도

ㅇ 프로덕트 계획

ㅇ 옵션

(프로덕트 카타)

개발해야 할 솔루션을 알아내는 과정이며 프로덕트 매니저가 문제 해결 과정에서 프로덕트 개발에 접근하도록 가르쳐주는 체계적인 방식

 

엉뚱한 요소들을 측정하는 데 시간을 허비하기 쉽다. 소위 '허영 지표'를 측정하는 경우가 많다. 

 

학습은 위험을 줄어준다. 해결 방안 탐구의 목표는 의견을 신속히 얻는 것이다

 

실무진이 개발 중인 제품을 책임지면서도 "왜" 개발하는지 모른다면 상황이 심각하다.

 

 

(조직을 이루는 4가지 구성 요소)

ㅇ 올바른 책임과 구조를 갖춘 프로덕트 매너저 직무를 만든다.

ㅇ 바람직한 의사결정을 끌어낼 전략을 갖춘 프로덕트 매니저를 선발한다.

ㅇ 실험과 최적화를 통해 무슨 프로덕트를 개발할지 결정하는 과정을 이해한다.

ㅇ 모든 구성원을 지원해주는 올바른 조직 정책, 문화, 보상을 통해 프로덕트 매너지먼트를 순항시킨다.

성과물이 아닌 산출물을 성공 기준으로 삼다가 올짝달싹 못하게 됐을 때 SW에 들어가는 기능의 실제 가치는 확인하지 않고 기능을 개발해서 출시하기에만 급급할 때 기업은 개발 함정에 덫에 빠진다.

 

"영업부는 기업 고객들에게 다양한 기능을 출시겠다고 약속해 놓았어요. 그쪽 시장에서 서비스를 제공해 본 적도 없는데 처음부터 전부 새로 만들어야 할 판이에요."

 

"로드맵이 있어야 하는데 고객에게 설득할 거리를 주는 사람이 아무도 없어요. 저는 그냥 나가서 고객들에게 공수표나 날리며 실적을 올리고 있어요. 프로덕트 팀이 아무 것도 주지 않으니까요."

 

특정 인물이나 부서의 잘못이 아니라 조직 자체가 성공할 수 없는 구조였기 때문이다. 

 

사업으로 가치를 창출하는 방안을 탐구할 수 있는 프로덕트 매니지먼트 조직을 제대로 갖추어야 합니다. 전문가가 필요한 영역이에요...프로덕트가 중심이 되어야 합니다. 그러려면 산출물만 내놓기보다 성과를 내는 것을 더 중시하도록 조직 전체의 사고방식을 바꿔야 합니다. 조직구조, 전략, 업무 방식, 그것을 지배하는 정책과 보상 방식까지 다 바꾸셔야 해요.

 

사업적 관점에서 가치의 의미는 간단하다. 돈, 데이터, 지식자산, 홍보 등 사업에 연료를 공급해주는 것이 가치다. 기업은 어떤 기능을 개발하거나 계획을 실행함으로써 이런 사업적 가치가 담긴 결과를 내야 한다.

 

특정 고객사 한 곳만을 위한 단발성 기능이 잔뜩 쌓였다. 많은 고객에게 유용한 프로덕트를 개발하는 방향으로 전략적 선택을 하지 않았다.

 

 

(올바른 해결 방안 선택하기)

 

 

[ 자평 ]  처한 현실이 답답하여, 3번 정도 읽으면서 업데이트를 하고 있다. 

 

최고의 경영자는 구체적인 히트 제품에 몰입한다고 생각한 지 오래 되었기 때문에 책의 내용에 동의한다.

그들의 손에 무엇을 들려 있는가?에 따라 성장하는 회사와 사라지는 회사가 결정된다고 믿었다.

전반적으로는 마티 케이건 (Marty Cagan)이 책이 더 나은 것 같다. 2018년에 새로운 번역판이 나왔다.