실리콘밸리의 PM은 어떻게 일할까?
1편) 실리콘밸리 PM의 기술 강의를 완강하고
탈잉에서 괜찮다는 강의로 '실리콘 밸리 PM의 기술'을 들었었는데, 올해 드디어 완강을 하게됐다.
설연휴 중 하루의 반나절 정도를 투자하니 다 들을 수 있는 정도의 분량이었다.
PM/PO 직군에서 일하면서 가장 궁금한 건 '다른 PM/PO들은 어떻게 일하고 있는걸까? 내가 지금 잘하고 있는 걸까?'에 대한 물음이다. 스터디나 주변 동료들을 통해 국내 PM/PO들이 어떻게 일하고 있는지는 어느정도 잘 알고있지만 실리콘밸리에서 일하는 PM/PO들은 어떻게 일하는지 궁금했었다.
기획자가 다 똑같이, 똑같은 프로세스로 일하는게 아니라 기업에 따라 모두 각자의 스타일대로 일하고 있는데 가장 헷갈리는 부분이 PM/PO의 역할과 책임 범위였다. 이 강의에서는 PM/PO의 역할, 실제 어떤 프로세스로 어떻게 일하고 있는지, 어디까지가 PM/PO의 책임 범위인지 모두 포함된 강의로 PM/PO로서 방향성을 잡고 싶다면 들어보는 것을 추천한다.
이제 이야기 할 내용에는 실리콘 밸리 PM의 기술 강의를 듣고 요약한 부분이 포함되어 있고, 이를 통해 느낀 나의 인사이트 위주로 설명될 예정이다.
실리콘밸리의 PM은 다양한 전문가(디자이너, 데이터 사이언티스트, 마케터, UX리서처, QA, 개발자)로 이루어진 팀을 끌며 제품을 출시, 유지, 보완해 최고의 성과를 만들 수 있도록 하는 직책이라고 정의했다.
PM은 다양한 정보에 기반해 판단을 내리고 책임을 져야하는데, 권한은 없어서 끊임없이 주변을 설득해야한다고 했는데 이 부분이 공감됐다. 특히 부하직원은 없는데 책임은 있어 끊임없는 설득과 협력이 필요한데 이 부분에서 가장 중요한게 '커뮤니케이션'인 것 같다고 생각되는 부분이었다.
또, 많은 사람들이 기획자가 왜 필요하냐, PM/PO가 왜 필요하냐 라고 묻는데 그 이유를 명확히 설명해준다. PM/PO가 없다면 서비스의 end-to-end를 보고 일관성을 유지할 수 없고, 사용자 니즈를 최우선시 할 수 없으며, 전체를 보고 방향을 제시하는 책임자가 없으므로 결단력 부족으로 인한 자원낭비가 심하다. Makers들의 우선순위를 정할 수 없고 중요한일보단 시급한 일 위주로 처리하게 되어 자원을 낭비할 수 있다.
만약, PM/PO없이 CEO가 PM의 역할을 하게 될 경우 회사의 존폐가 걸린 일을 CEO가 처리할 수 있는 시간이 줄어들어 CEO의 효율이 감소하는 등의 부작용이 발생할 수 있다.
사실 나 조차도 기술직무가 아닌 PM/PO는 누구나 대체할 수 있고, 서비스를 만드는게 꼭 필요한 직무는 아니라고 생각했는데 이 강의를 통해 PM/PO가 없을때의 부작용을 알 수 있어 좋았다. 앞으로 프로젝트를 진행하거나 주변 동료가 '서비스에 굳이 PM/PO가 필요한가?'라고 묻는다면 위 강의에서 배웠던 부작용을 말해줘야 겠다.
PM/PO의 책임은'전략, 실행, 책임' 3가지가 존재하고 각각의 책임은 아래와 같은 질문으로 확인할 수 있다.
1. 전략 : 옳은 방향으로 가는가?
2. 실행 : 정해진 시간 내 약속한 최고의 성과를 냈는가?
3. 책임 : 팀의 역량이 커져가는가?
PM/PO은 옳은 방향으로 가도록 리드하기 위해 전략을 세우고, 목표를 수립하고 로드맵을 작성하고 우선순위를 설정한다. 또 Makers와 Stackholders와의 커뮤니케이션을 진행하며 로드맵대로 과제를 진행할 수 있도록 이끄는 역할을 해야한다. 과제가 끝나면 Makers, Stackholders에게 성과를 투명하게 공유하고 팀 내 개개인이 가진 역량을 최대치로 끌어낼 수 있도록 독려하고 적합한 일을 부여해 역량을 키우는 데 도움을 줘야한다. (왜 미니 CEO라고 불리는지 알겠다.)
PM/PO의 업무 범위에 대한 부분을 어떻게 구분하는지가 사실 제일 궁금했는데, 강의에선 아래와 같이 업무의 바운더리 원칙을 설명한다.
1. PM만이 할수 있거나, 전적으로 책임져야 하는일
2. PM이 할 수 있고, 다른 팀원도 할 수 있는일
3. PM이 할 수 있지만, 다른 팀원은 할 수 없거나 할 시간이 없는 일
1번은 전략, 우선순위, 로드맵, 목표수립, 팀 내부/외부의 커뮤니케이션이 있고, 2번은 개발, 디자인, 리서치, 회의록 작성, 데이터 분석이 있고, 3번은 디자이너가 없는 디자인. 데이터 분석가가 없는 데이터 분석이 있다.
특정 업무가 들어오면 1,2,3 중 무엇에 해당하는 업무인지 파악하고 2,3에 해당된다면 1번 업무 중 우선순위가 밀리는 일이 무엇이 있는지 파악 후 진행한다. 특히 3번의 경우 짧은 시간 동안만 진행하며 1번 업무가 장시간 미뤄지지 않도록 조율하여 진행하는 것이 중요하다.
다음은, PM/PO가 자주 하는 실수인데 많은 PM/PO들이 본인은 '최종 결정자'라고 생각한다고 하는데, 실제로 우린 최종 결정자가 아닌 '책임자'로 불리는 게 맞다. 모든 결정을 PM/PO가 내리려고 하면 속도가 느려지고 팀원의 주체성을 줄이는 악영향을 미칠 수 있으므로 팀원 스스로가 방향성에 맞는 결정을 내릴 수 있도록 해야한다. 그 전에 PM/PO는 팀원에게 우선순위, goal, 중요정보를 확실히 전달해놓는게 필요하고 팀원이 의사결정을 한 경우 문서화가 되어있는게 중요하다.
사실 나도 내가 최종 결정자라고 생각하고 있었고, 모든 결정을 내가 지려고 하니 매일 시간이 없었던 경험이 많다. Makers들은 모두 나를 보고 있고 결정을 기다리고 있었다. 심지어 어떻게 개발해야 레이턴시(*지연 시간)를 줄일 수 있는지 묻기도 했는데 기술적인 이해도가 개발자보다 떨어져 이러한 의사결정을 하기는 어려움이 있었다. 이런 상황에서 나는 디자인과 개발에 대한 공부를 더 해야하나라는 생각도 하고 실제로 개발책을 사서 공부한 적도 있지만 강의를 듣고 생각해보니 그동안 내가 잘 못 생각하고 판단했구나 라는 생각이 들었다. 만약 이 강의를 듣고난 후 현재 시점에 개발자가 이렇게 묻는다면 '어떤 방향으로 개발해야 개발 레이턴시를 줄일 수 있을까요? A로 할까요 B로할까요?' 나는 이렇게 대답할 것 같다. '우리가 이 과제를 진행하는 목적은 X이고, 바라는 기대효과는 X-1입니다. 이러한 기대효과를 줄이기 위해서는 A로 하는게 좋을까요? B로 하는게 좋을까요?'
또, 가끔 판단을 내리기 헷갈릴 때 PM/PO는 '다수결로 또는 만장일치'로 결정을 내리려고 하는데, 이 또한 문제가 될 수 있다고 한다. PM/PO가 자신만의 의견을 내놓지 않고 팀원들의 의견을 모으기만 하면 PM/PO 본인만의 역할인 장기를 쓰지 않아 팀원들의 존중을 받지 못할 수 있다고 한다.
PM/PO는 정보를 투명하게 팀에 전달하는 게 중요한데, 회사 내에서 일어나는 모든 일을 투명하게 전달하려고 하면 모두가 스트레스 받는 상황이 될 수 있으니 상부에서 내려오는 스트레스는 본인이 우산이 되어 막어주고 팀원을 보호하며 감정적으로 안정을 유지시켜줘야한다.
결정을 내리기 힘들 때 다수결 만큼 좋은 의사결정 방법은 없다고 생각했다. A와 B중 결정을 해야한다면 보통 Makers나 Stackholders의 의견을 물어 더 많은 투표를 받은 쪽으로 의사결정을 했다. 이유는 나혼자 결정하면 독재자처럼 보일까봐 걱정되는 것도 있었고, 한편으론 내 주장이 틀렸을지 모른다는 불안감도 있었기 때문에 '이 결정은 우리 모두 같이 한거야.' 라고 공동의 책임을 지기위한 것도 있었던 것 같다. 근데 강의에서 다수결로 의사결정하는 것도 문제가 될 수 있다고 했는데 한마디로 요약하면 '스스로 판단을 못 내리는 PM/PO라는 인식이 생길 수 있다.' 로 이해했다. 물론 모든 의사결정을 다수결로 의견을 모아 결정하면 이러한 문제가 발생할 수 있겠지만, 특정 이슈에 대해 모든 이들의 의견이 필요한 때가 있을 수 있을 것 같다. 이 부분은 '정성적인 의사결정'이 필요할 때 종종 쓰고 평상시엔 '다양한 정보를 통해 스스로 판단을 내리는' PM/PO가 되기 위해 조금 더 신경써야 겠다.
강의가 길어서 하나의 글에 다 담기가 어려워 이번편엔 PM의 정의, PM이 필요한 이유, PM의 책임, 업무범위, 자주하는 실수에 대해서만 담아보았다. 다음편에선 Great PM과 Good PM은 어떻게 다른지, Great PM의 조건은 무엇인지에 대해 자세히 다뤄보려고 한다.
2편> 당신은 Great PM인가요, Good PM인가요?
부제 : 실리콘밸리 PM의 기술에서 말하는 Great PM의 정의와 나의 회고)
