https://www.youtube.com/watch?v=WVvFRh1vGv8
PM 업계에서 가장 유명한 영상이 아닐까 싶을 정도로 정보도 많고 내용도 하나하나 버릴 것 없는 이 영상. 드디어 봤다.
설명을 굉장히 맛깔나게 잘해주시고, 또 인사이트만 욱여넣은 듯한 밀도라서 시간 가는 줄 모르고 봤는데,
꼼꼼히 요약해보고 인사이트를 정리해보고자 한다. 👨🏫
[요약]
핵심 주제
핵심 메시지: 성공하는 프로젝트, 계속 다니고 싶은 회사에는 항상 '좋은 PM'이 있었다. 개발자 관점에서 좋은 PM의 특징은 딱 3가지다.
동기를 유발하는 PM
정책을 깊이 있게 이해하는 PM
대충이라도 개발(시스템)을 이해하는 PM
동기 유발을 기가 막히게 하는 PM
PM은 본질적으로 개발자에게 '업무를 요청'하는 자리다. 따라서 개발자의 능력을 100%, 200% 끌어내는 동기 유발 역량이 PM의 가장 중요한 무기다. 핵심은 이 일을 '나의 일(OWN)'로 느끼게 만드는 것이다.
나쁜 PM의 업무 방식 (남의 일이 되는 과정)
-
PM 본인이 기획을 엄청나게 고민하고 정리한다. (여기까진 PM 입장에서 '나의 일'이 됨)
-
다 정리된 기획서를 개발자에게 "이렇게 해주세요" 하고 툭 던진다.
-> 개발자 입장에선 이게 단순한 '작업 지시'가 되어버린다.
비유: 위에서 대표님이 대충 다 정리해서 "그냥 해"라고 하면 재미없는 것과 똑같다.
좋은 PM의 업무 방식 (우리의 일이 되는 과정)
-
치열하게 고민하는 건 똑같지만, 개발자에게 줄 때 "이걸 왜 해야 하는지" 집요하게 설명한다. 데이터, 고객 관점, 회사 가치를 들어 납득시킨다.
-
피드백 창구 오픈: 기획서 리뷰를 하면서, 묘하게 개발자가 피드백을 해야 할 것 같은, 프로젝트에 '참여'하고 있는 느낌을 짜낸다.
-> 결과적으로 개발자가 "어? 이거 내 일인데?" 하고 몰입하게 만든다.
디테일한 예시들
"이거 왜 하는데요?"
나쁜 PM: "실장님이 다음 주까지 하래요." (설명 끝)
좋은 PM: "사용자 관점에서 이게 좋아지고, 비즈니스 가치가 이렇게 증가해요."
팁: 개발자에게 접근할 때는 '문제 상황'부터 얘기하는 게 좋다. 개발자는 태생적으로 '문제'라는 단어를 들으면 본능적으로 풀어야 할 것 같은 자극을 받는다.
"나의 일로 만드는 법 (피드백 유도)"
PM이 가져온 기획이 개발적으로 되게 구현하기 어려울 때가 있다.
이때 개발자가 "기획서 요 부분만 살짝 틀면, 개발 리소스 확 줄일 수 있는데요?"라고 제안하게 만든다.
PM이 이 제안을 수용하면, 개발자는 자기가 이 프로젝트를 개선했다는 효능감을 느끼고 완전히 '본인 일'로 받아들인다.
🔥 개발자를 움직이는 마법의 단어: "고민이 있어요"
컴퓨터 공학의 기본은 '문제를 푸는 것'이고, 프로그래머는 훈련받은 '문제 해결사'다.
프로그래머의 핵심 욕망 2가지
1) 문제를 무조건 풀어야 함
2) 내 문제 해결 능력을 인정받고 싶음.
PM이 "고민이 있어요"라고 다가가는 순간, 이 2가지 욕망이 완벽하게 충족된다.
(나에게 풀 문제가 생겼고, PM이 나를 해결사로 인정해 줬다!)
이 마법에 걸리면 개발자는 평소 사이가 안 좋았던 기획자라도 다 용서하고, 심지어 꿈속에서도 코딩을 하며 문제를 해결해 온다 (ㅋㅋ
답정너의 기술
나쁜 PM: 일정, 우선순위, 대안을 자기 혼자 싹 다 정리해서 통보한다. (이러면 개발자는 지식 근로자로서 재미를 못 느낌)
좋은 PM: 사실 속으로는 대안과 일정을 다 정해놨음에도 불구하고, 굳이 개발자에게 가서 "이거 어떻게 해결해야 할까요? (고민이 있어요)" 하고 물어본다.
같이 만들어간다는 '느낌'을 주는 것이 핵심.
(김영한 이사님 피셜, 우아한형제들 대표님이 이 스킬의 만렙이라고 함)
정책을 깊이 있게 이해하는 PM
기획서 화면(UI)만 그리는 게 아니라, 그 밑바닥에 있는 비즈니스 정책과 도메인을 완벽하게 꿰고 있어야 한다.
나쁜 PM: 개발자가 예외 케이스나 정책을 물어보면 "몰라요, 코드 봐야 아는 거 아니에요?"라고 한다. UI만 껍데기처럼 그려온다. (김영한 이사님은 이걸 직무 유기라고 표현함)
좋은 PM: 찔러보면 정책이 자판기처럼 줄줄 나온다. 자기 서비스와 프로덕트에 대한 애정이 깊다. 업무 프로세스와 데이터 흐름을 머릿속에 다 넣고 있다. 이런 PM이어야 서비스에 사이드 이펙트 없는 진짜 '깊이 있는 개선'을 할 수 있다.
시야의 깊이와 넓이: 주니어 기획자는 자기 화면만 본다. 하지만 예를 들어 배민 앱에 가게가 노출되려면 사장님 시스템, 메뉴 시스템, 광고 시스템 3박자가 맞아야 한다.
좋은 PM은 내가 담당하지 않는 시스템이라도 전체적인 얼개를 다 파악하고 있어 큰 변화를 이끌어낸다.
대충이라도 개발 시스템을 이해하는 PM
"PM이 개발을 어디까지 알아야 하나?"에 대한 명쾌한 답변.
PM이 코딩을 다 알 필요는 없다. 하지만 "전 시스템 몰라요, 기획서만 쓸게요" 하는 건 좋은 기획자가 아니다.
- '네모 박스' 그리기: 전체 조직의 역할(R&R), 시스템 관점의 프로세스, 데이터의 흐름 딱 이 정도만 이해하면 된다. 복잡한 시스템들을 '네모 박스'들로 치환해서 머릿속에 매핑해라. 어떤 네모 박스에서 어떤 네모 박스로 데이터가 흐르는지만 알면 된다.
팁
처음엔 당연히 파악하기 어렵다. 이때 개발자한테 가서 "고민이 있습니다. 전체 시스템 네모 박스를 같이 한번 그려보고 싶어요."라고 해봐라. 개발자들이 신나서 시스템 아키텍처 다 그려주고 설명해 줄 거다.
[인사이트]
괜히 PM의 교과서라고 불리는 영상이 아니다. PM이 본질적으로 갖춰야하는 태도에 대한 영상이라는 생각이 듦. 기획자라고 혼자 일을 하는 것이 절대 아니다. 설령 혼자 머릿 속에 대략적인 내용을 상상해뒀다 할지라도, 함께 참여하는 팀 플레이어에게 같이 한다는 느낌을 줄 수 있는 것이 핵심. 그 느낌, 바이브가 정말로 중요하다는 ....
다행인 건 난 물어보는 걸 참 잘하는 사람이라는거다. 그래서 초반에 들을 땐 그럼 잘 물어보고 같이 하면 되겠지 ! 라고 생각했는데 그냥 모르는 상태에서 물어보는 게 아니라 그래도 내 머릿속에 어느정도는 그림이 그려져 있는 상태로 넌지시 물어봐 참여를 이끌어내는 최고급의 소프트스킬을 쓰라는 의미를 깨닫고 (...) 쉽지 않구나 ~ 했다.
여러 사람을 만나고 또 많은 일을 같이 해보다보면 이상하게 사람이 주변에 많은 타입이 있다. 왠지 챙겨줘야 할 것만 같고. (그렇다고 그 사람이 부실해 보인다는 뜻은 아님) 이 영상을 보니 그런 사람들이 왜 그렇게 보이고, 사람이 모이는 지에 대한 이유를 알 것 같다.
곁의 공간을 내어주는 사람
왠지 이 사람 옆에 있으면 내가 1인분, 나아가서 2인분을 해내는 것 같고, 인정 받는 것 같고, 같이 뭔가를 잘 해나간다는 느낌이 들게 만드는 것.
역할의 분배와 신뢰의 형성이 물 흐르듯 자연스럽게 이루어지는 사람.
늘 그런 사람들이 부럽고 나도 그런 사람이 되고 싶어서 애썼는데, 되어야 하는 이유도 될 수 있는 방법도 찾은 것 같아 기쁘다. 강력하고 카리스마 있는 리더십도 중요하지만, 그 끝이 고독함과 독선이라면, 모두가 내 말에 동의하기만 한다면 그건 정답도 아니고 일에 있어서도 틀린 방향임을 ...
철저하고 짜임새 있게 일을 하되, 약간 헐랭하게 (그러니까 주변 사람들이 내 곁에 있을 수 있게) 구는 태도를 꼭 기억해야겠다.
사람이 여럿 모이면 무조건 혼자보다 나아야한다. 그리고 그렇게 만드는 것은 리더의 태도다. 기억 또 기억 !
