업계 최고의 IT 기업에서 배운 교훈
기획자/PM 노가리클럽과 함께 읽는 임파워드(1)
마티 케이건의 인스파이어드가 IT 제품팀이 '최신 제품 발굴 기법'을 통해 고객이 좋아하면서도 비즈니스에도 유효한 방식으로 어떻게 어려운 문제들을 해결하고 놀라운 성과를 낼 수 있는지에 대한 내용이라면 임파워드는 경쟁력 있는 제품 조직을 만들고 싶어하는 리더 레벨을 위한 책이라고 할 수 있다.
이 글은 임파워드 책을 요약하고 기획자/PM 노가리 클럽에서 같이 나누었던 이야기를 정리하는 목적으로 한다. 책의 내용을 중심으로 나왔던 의견이나 사례들은 별도 점선 사이에 기록하여 구분할 수 있게 하였다. 임파워드 책의 목차에 따라 내용이 구성하고, 10여편의 글로 정리할 예정이다.
기획자/PM 노가리 클럽의 2022년 첫번째 컨텐츠는 인스파이어드로 유명한 마티 케이건의 2021년 신작 세계 최고의 기업에서 배우는 제품팀의 리더십 "임파워드" 리뷰였다. 밤 10시에 시작해서 많은 분들이 스피커로 참여해주셔서 3시간 30분을 진행하고 마무리가 되었고, 책의 절반 정도를 이야기 할 수 있었다. 다음주 1월 10일에 나머지 반 정도를 리뷰하는 세션이 열린다.
1부. 업계 최고의 IT 기업에서 배운 교훈
최고의 제품을 만들지 못하는 기업의 특징
IT 기술을 단순한 필요 비용으로 여김, IT팀원을 비즈니스를 지원하는 역할이라고 여김
IT팀에 능동적인 코칭이 이루어지지 않음
회사에서 문제를 어떻게 풀어야할지 모르기 때문에 어떤 제품팀원들을 채용해야하는지 모름
비전이 없음
IT팀 스스로 책임감과 오너쉽을 갖기에는 팀 구조가 너무 세분화 되어있어서 다른 팀 의존 없이는 할 수 있는 일이 없음
제품 자체의 전략없이 그저 최대한 많은 이해관계자들을 만족시키는데 역량을 사용함
기업의 기존 제품 로드맵이나 문화를 고려하지 않고 OKR만 적용해, 의미없는 OKR 계획을 세우는데 시간을 소비함
IT팀과 사업팀과의 관계가 좋지 않음
고객을 만족할 수 있는 제품을 만들기 위해 IT팀에 권한이 없고, 로드맵 상의 기능들만 구현함
이렇게 되면 의미 있는 비즈니스 결과를 얻기 매우 힘들고, 사용자가 원하는 것을 너무 잘 만드는 경쟁 업체에 고객을 뺏기고,고용된 직원들의 재능과 능력을 낭비하고, 핵심인재는 높은 확률로 떠난다.
클러방너ㅏㅇㄴ가래아앙ㅇㅇㅇ
"리더십은 모든 사람의 내면에 위대함이 있음을 알아봐 주는 것이고, 리더의 입무는 그 위대함을 펼칠 수 있는 환경을 만들어 주는 것이다." 빌 캠벨
최고의 제품을 만드는 기업과 그러지 못한 기업의 차이임파워드 제품팀에서의 각자의 역할
프로덕트 매니저 : 가치valuable (고객 만족)와 실용viable (비즈니스적인 니즈 만족)
프로덕트 디자이너 : 제품의 사용성 usable
기술 리더 : 제품 구현 가능 feasible
비즈니스 오너와 이해관계자가 로드맵을 결정하고 기능 개발팀이 구현만 하는 것이 무엇이 나쁜걸까?
비즈니스 오너와 이해관계자는 "무엇"을 구현해야하는지 알려줄 수 없다. 그 이유는 기술에 대한 이해가 없기 때문에 문제를 해결 하는 가장 좋은 "방법"을 모른다. 또한 그 "방법"이 해답일지 예측하기 어려우므로 그 "그 방법"을 찾는 것는 단한번이 아니라 반복적인 과정이기 때문이다.
이 책의 핵심은 ⭐강력한 제품 리더십의 중요성⭐이다.
이 책에서는 논의를 위하여 리더와 관리자를 구별했다. 리더가 관리자이기도 하고 관리자가 리더이기도 하지만 리더와 관리자의 역할과 책임은 다르다.
팀의 업무에 대한 영감inspiration은 리더십으로부터 부여받고, 업무의 실행execution은 관리자로부터 부여받는다.
리더십의 역할은 영감/열의inspiration 부여
임파워드팀을 만들기 위해서는(=제품팀이 권한을 부여받아 올바른 결정을 내릴 수 있으려면) 이런 결정을 내리기 위한 전략적 콘텍스트가 필요하고 제품팀을 움직이는 전반적인 전략적 콘텍스트를 제공하기 위해서는 아래 4가지 주요 책임이 있다.
1. 제품비전(aka. 북극성)과 원칙
정의 : 우리가 만들고 싶어하는 미래와 더불어 어떻게 이 제품을 통해 고객의 삶을 개선할지를 설명함
어떤 제품팀에 속해 있고 어떤 문제가 주어졌든지 간에 '북극성'을 향해야 함
직원이 매일 일하는 데 동기 부여가 되고 흥분하게 하는 원동력이 됨
2. 팀 구조
최상의 결과를 낼 수 있도록 여러 제품팀을 적절하게 배치하고 팀간 업무 범위를 나누는 것으로 이는 팀의 구성과 업무 범위, 팀 간의 관계를 포함함
3. 제품 전략
사업적 필요를 충족시키면서 제품 비전을 달성할 수 있는 방법
전략은 선택과 집중을 통해 도출된 다음 통찰력을 거쳐 만들어짐
이러한 통찰력을 실행으로 옮긴 후 마지막으로 일이 완성되도록 관리manage 한다.
4. 제품 에반젤리즘
제품 비전과 원칙, 제품 전략을 내부 조직뿐만 아니라 기업 전체에서 광범위하게 커뮤니케이션 하는 것
미션팀을 원한다면 조직의 모든 구성원이 기업의 비전과 전략을 이해하며 확신을 가지고 조직을 전적으로 신뢰하게 만들어야 함
즉, 제품 비전을 달성하기 위한 방법이 제품 전략이고, 제품 전략은 사업적 필요도 충족되어야 한다. 또한 정의된 제품 비전과 전략에 대해 모든 구성원이 이해를 바탕으로 확신을 가져야 임파워드팀이 만들어 질 수 있다.
관리자의 역할 - 실행execution
제품 비전과 원칙, 제품 전략을 이해하고 효과적으로 전달 하고 아래 3가지에 대한 책임이 있다.
1. 팀원 구성
제품팀 구성staffing에 책임이있다. 즉, 인력 소싱, 모집, 인터뷰, 신입 직원 교육, 평가, 승진, 교체까지
기업의 HR 부서가 있어도 지원을 할뿐이지, 책임은 매니저의 몫이다.
2. 코칭
가장 중요하지만 가장 많이 간과되는 관리의 요소임
관리하고 있는 팀원의 성장을 할 수 있게 도와 주는 것이 가장 중요한 책임
세부적인 관리micromanaging하라는 뜻이 아니라, 팀의 약점을 이해하고 개선하도록 도우며 배운 것에 대한 지침을 제공하고 성장을 가로막는 장애물을 제거해주는 것connecting the dots.
3. 팀 목표
각각의 제품팀에 풀어야 할 문제를 내포하고 있는 한두가지 명확한 목표(일반적으로 분기별로)를 부여하는 것, 해당 목표는 제품 전략에서 직접 도출되어야 하며, 이 단계에서 통찰이 실행으로 바뀐다.
팀은 문제에 대해 생각한 뒤 명확한 성공 방법(핵심 결과key results)를 제안하고 관리자와 논의함
임파워드가 그저 듣기 좋은 단어가 아니라 현실이 되는 부분, 권한을 부여받았는지 확인할 수 있는 명확한 기준은 팀이 문제(목표)를 해결하는 방법을 스스로 결정할 수 있는지를 보면 된다.
요약하자면, 이런 느낌적 느낌이 책은 핵심인 강력한 제품리더십을 만드는 요소들을 한 챕터씩 설명하는 것으로 구성되어있다.
3부 : 제품팀의 인력을 구성하는 방법
4부 : 우리가 만들려는 미래를 정의하는 제품 비전과 원칙
5부 : 제품팀을 회사의 요구에 가장 잘 어울리는 팀구성으로 배치하는 방법
6부 : 제품팀이 해결해야 할 가장 중요한 문제를 결정하는 제품 전략
7부 : 팀 목표(해결해야 할 문제)를 통해 제품 전략을 실행에 옮기기
사례연구(8부), 협업을 진행하는 법(9부), 조직을 변화시킬 계획(10부)로 구성되어있다.
<1부 끝>
�기획자/PM 노가리클럽 대화(긴 대화 주의)
- 비즈니스 오너나 스테이크 홀더들이 로드맵을 정하고 제품팀이 기능만 구현다는 이야기로만 한시간 넘게 이야기할 수 있겠다. ㅋㅋㅋ
- 매니지먼트 입장에서 이 책을 읽고 머리로는 이해해도 어떻게 해야하는지 알기가 어려웠다.
시니어 PM 입장에서 이야기 드리면, 어떤 일들을 요청할때 왜 필요한지 어떤게 문제인지를 설명하지 않고 수단으로 설명하는 경우가 대부분이다. 예를 들어, 어떤 수치의 결과가 있는 대쉬보드라고 할때 무작정 "이화면의 내용을 복사하는 기능을 만들어라"라고 요청이 온다. 듣고 보면 틀린 말도 아니어서 그 기능을 만들어서 배포한다. 그럼 그 뒤에 와서 아니 복사하고 엑셀에 붙여넣었는데 왜 제대로 안되는거야? 라고 와서 화를 낸다. 그럼 만든 입장에서는 아니 복사하는 기능만 만들라고 했자나? 라는 반응을 할 수 밖에 없다. 사실 그 사람의 기저에는 누군가에게 보고 하기 위해서 이 대쉬보드를 보는 사람들의 보고 과정을 쉽게 해주기 위함이었다. 애초에 요청사항을 "이 화면의 정보를 통해 보고하는데 불편함을 해결해라"라고 했다면 복사&붙여넣기 기능이 아니라, 엑셀 다운로드 기능을 넣거나, 아예 리포팅 파일을 만들어서 주기적으로 전달해주던가 하는 등의 다양한 솔루션들을 고민하고 가장 빠르게 적용할 수 있거나 가장 임팩트 있는 방법을 찾을 수 있을 것이다. 수단으로 설명하더라도 "왜? 그것들을 해야하냐"라는 반복질문을 통해서 해결해야 하는 문제를 찾을 수도 있지만, 가끔은 본인이 어떤 문제를 해결해야하는지도 모르는 경우도 있다.
얼마전에 저도 비슷한 일이 있었다. 비주얼화 하는 것이 매우 중요한 프로덕트였는데, 비즈니스팀에서 갑자기 맥락없이 비주얼의 배경을 호텔로 하자고 했다. 대화를 거듭한 결과 "화려한 비주얼"을 위해 호텔이라는 "아이디어 중 (비즈니스팀이 생각하기에) 가장 좋은 것"을 요청한 것이었다. "화려한 비주얼"을 만들어야 한다면 "궁전"이 어떻냐고 제안했지만, 이미 비즈니스팀은 본인들의 아이디어 대신 다른 의견을 받아드리는 것에 대해서 불편해 했다.
- 어디까지 권한을 줘야 하는지 모르겠다. 권한을 주다보면 그 사람이 CEO가 되어야 한다. 그리고 그 원칙을 수행하는데 있어서는 자산이 많이 필요한 것 같다.
이 책을 읽다보면 진짜 리드에서 이런 역할들을 다 수행하면 CEO는 뭐하지? 이런 생각이 들긴 들었다.
진짜 이상적인 이야기인데 정말 임파워드팀이 있으면 성공하는 제품을 만들 수 있는걸까?
일을 할때 너무 이상적인것까지는 바라는 건 아닌데 최소한 문제를 해결하기 위한 방안을 결정하는 것은 제품팀에서 가져가면 일하기 행복할 것 같다.
사소한것까지 다 결정이 되어있으면 자연스럽게 제품팀은 사고를 멈춘다.
- 권한을 한팀이 다 가져가기 어려운 경우나 조직이 커져서 분업이 되어있는 경우는 어떻게 해야하나?
그렇기 때문에 팀 구조가 목적조직으로 이루어져있는 것 같다.
팀 구조 없이 임파워드팀을 만들기 어려운 것 같음
- 혹시 SI 하시는 분들에게 위임을 하고 임파워드팀이 되면 그 팀이 진짜 문제를 잘 해결할 수 있을까요?
요즘 어떤 에이전시들이 그렇게 가는 구조가 있다. 어떤 마케팅 에이전시는 권한과 위임을 받아서 전적으로 운영하고 앞으로 발생할 수익율을 어느정도 쉐어한다. 그리고 그런 케이스가 잘되었다는 사례가 있음
저도 위와 같은 비슷한 제안을 받아서 진행한 적이 있었는데 솔직히 잘되지 않았음. SI업체들이 개발인력을 가지고 다양한 분야를 커버하시다 보니까 협업이랑 일하면서 삐걱거리는 경우가 생기는 것을 보았음
그게 잘 안되는 이유가 욕심 같음. 맡기는 입장에서는 "내가" 맡겼으니까 내꺼야 하는 입장과 만드는 입장은 "직접" 만들었으니까 내꺼야하는 이해관계에서 오는 갈등이 있는 거 같음.
마티가 말하는 임파워드팀을 만드는 것이 이상적인 방법이면 그 관계의 형태가 외주여도 성공했어야 할테지만 저자의 경험이 대부분 컨설팅에서 온 것이기때문에 외주는 빠져있는 것이 아닐까 함. 그리고 2부에서 코칭과 인사까지 긴호흡으로 설명하고 있는데 그것을 봐서는 마티는 임파워드팀을 내부팀이라고 전제한 것 같음
책 읽다보니까, 역시 결론은 "사람"이다. 결국 사람이 잘 코칭하는 것.
