첫 30일 동안 PM이 해야 할 12가지
기억하라, 당신은 일을 하러 온 것이지 만들러 온 것이 아니라는 사실을!
GV(Google Ventures)의 파트너인 Ken Norton이 쓴 글입니다. Google에서 Docs, Calendar, Mobile Maps 프로젝트의 PM을 담당했으며 개인 블로그에 Product Management에 관한 글을 많이 올리고 있습니다. “How to Hire a Product Manager”라는 글로도 유명합니다.
원문: “12 Things Product Managers Should Do in Their First 30 Days at a New Company” by Ken Norton
축하한다! 드디어 프로덕트가 PM을 만났다.
당신은 작은 스타트업에 들어갔거나, 아니면 큰 회사에서 새로운 프로젝트를 담당하게 되었을 것이다. 앞으로 성공 가도를 걷게 될지, 아니면 고생길을 걷게 될지는 당신이 첫 30일을 어떻게 보내는 지에 달려있다고 해도 과언이 아니다.
여기 당신이 첫 달을 어떻게 보내야 할지에 대한 몇 가지 조언을 준비했다. 다음 세 가지 영역을 기억해라. - People(사람), Product(제품), Personal(개인)
People (사람)
1. CEO나 당신의 상사와 기대 수준을 명확히 이야기하라
회사는 빈 부분을 채우기 위해 당신을 고용했을 것이고, 따라서 즉시 성과를 내야 한다는 압박을 느낄지도 모른다. 당신이 할 업무에 대해 CEO가 정확히 파악하고 기대하고 있는지 확인해 보라. 첫 달의 가장 중요한 목표는 효과적으로 팀에 합류하는 것이다.
2. 모든 팀 구성원과 1:1 미팅을 잡아라
이 과정은 회사 규모에 따라 짧으면 몇 시간, 길면 한 달이 통째로 걸릴 수 있다. 모든 사람을 개별적으로 만날 수 있는 시간을 마련하라.
나는 걸으면서 진행하는 대화방법을 선호한다. 앞을 보며 함께 걸으며 얘기하는 것은 회의실에서 마주 보고 얘기하는 것보다 더 집중이 잘되고, 활기찬 면이 있다.
3. 모두에게 이 질문을 하라
당신의 삶을 더 편하게 만들기 위해 제가 무엇을 할 수 있을까요?
당신이 그들에게 명령하기 위해서 온 것이 아니라, 도와주기 위해 왔다는 것을 보여줄 수 있다. 그들이 얘기하는 내용만큼이나, 어떻게 반응하는지도 중요하다. PM 역할을 어떻게 생각하는지, 당신으로부터 무엇을 기대하는지 잘 알게 될 것이다.
4. 그들의 업무를 덜어줘라
미팅을 통해 그들의 생산성을 갉아 먹고 있는 일 중 당신이 덜어줄 수 있는 부분을 알아낼 수 있을 것이다. 엔지니어를 위해 버그 분류 업무를 가져가는 게 그 답이 될 수도 있다. 또는 간식을 사다 줄 수도 있다.
Product (제품)
5. 리드 엔지니어에게 제품의 기술적 아키텍처에 대한 자세한 설명을 들어라
모르는 부분을 물어보거나 이해가 되지 않는 부분을 잡고 늘어지는 것을 부끄러워하지 말아라.
많은 PM이 엔지니어들에게 자신의 기술적 통찰력을 뽐내려 하지만, 내 경험으로 봤을 때 엔지니어들은 “그 부분은 잘 모르겠는데요” 라고 기꺼이 물어보는 PM을 더 좋게 생각한다.
6. 바로 뛰어들어 뭔가를 바꾸고 싶다는 충동을 억제해라
아마도 당신은 제품이나 개발 프로세스를 바꾸는 일을 당장 시작하고 싶다는 생각을 하게 될 것이다. 그 충동을 잠시 눌러두고 있기를 권한다.
당신의 아이디어와 생각들은 당신이 회사에 정착하고, 신뢰를 얻고, 분위기 파악을 할수록 다듬어 지고, 나아질 것이다. 또, 당신이 ‘잘 들어주는 사람'이라는 것을 보여줄 수 있을 것이다.
7. 유저와 대면해라
유저를 만날 수 있는 시간을 초기에 많이 가져라. 영업 전화도 직접 걸어보고, 고객 방문에도 따라가라. 고객 지원업무에도 직접 참여해라. 행사에 참여하고, SNS를 통해서도 유저와 소통하라.
8. 뭔가를 직접 고쳐보라
나는 PM은 기술적인 부분을 잘 알아야 한다고 생각한다. 버그를 고치거나 작은 기능을 만들어 보는 것은 훌륭한 시작이 될 것이다.
개발환경을 세팅하고 당신이 할 수 있는 작은 일을 찾아라. 때로는 도움을 요청하되, 팀원들의 시간을 낭비하지 않아야 한다. 어쨌거나 당신은 PM이지 풀타임 엔지니어가 아니니까.
Personal (개인)
9. 모든 것을 읽어라. 아직 없는 문서는 직접 써라
읽을 수 있는 모든 것을 읽어라 — 예전 OKR 문서, 스펙 문서, 디자인 문서, 위키 페이지 등. 아직 작성되지 않았거나 업데이트가 필요한 문서는 직접 작성하거나 수정해라. 이제까지 배운 것에 관해 써 보고, 다음 채용자를 위해서 어떤 부분을 개선할지에 대해도 적어보라.
10. 개인적인 목표를 세워라
직장을 옮기면서 때로는 자신감이 충만하다가도, 또 금방 스스로가 비참하게 여겨지기도 한다. 이럴 때 개인적인 목표와 동기부여가 필요하다.
당신이 잘하고, 또 계속하고 싶은 일은 무엇인가? 어떻게 그것을 계속할 것인가?
개선해야 할 점은 무엇인가? 더 잘하기 위해 어떤 단계가 필요한가? 나아지고 있는지 어떻게 측정할 것인가?
11. 일하기 위한 기본 설정을 마쳐라
필요한 도구나 장비들을 갖춰라. 소프트웨어를 설치하고, 이메일 필터를 만들어라. 당신의 제품과 경쟁사의 제품 소식을 듣기 위한 Google News Alert 설정을 해라.
12. 즐겨라!
“피할 수 없다면 즐..?!”역자 주.
개인적으로 “다음에 다른 팀에 합류할 때 꼭 실천해보고 싶다”라고 생각하고 저장해 놓았던 글입니다.
여기서 나온 12가지와 반대로 행동하고 있지 않은지 돌아봐야 합니다. 이 중 첫 30일이 아니라 업무를 하는 동안 계속 유념해야 할 항목들도 많이 보입니다.
청개구리(?) 리스트
당신이 할 일에 대해 CEO, 상사, 당신까지 모두 명확한 정의를 내리지 못하고 있다.
모든 팀 구성원을 만나긴 커녕, 한 번 인사만 하고 실무를 진행할 때 까지 아무런 커뮤니케이션을 하지 않았다.
“당신의 삶을 더 편하게 만들기 위해 제가 무엇을 할 수 있을까요?”가 아닌, “당신에게 제가 무슨 일을 주어야 할까요?” 에 대해서만 고민했다.
팀 구성원의 일을 덜어주진 않고 더해주고만 있다.
엔지니어로부터 기술적인 설명을 듣지 못했다.
(충분히 파악이 되지 않은 상황에서) 바로 뛰어들어 뭐라도 보여주기 위해 애쓴다.
유저에 대한 고민 없이, feature list 또는 technical roadmap에 따라서만 업무를 진행하고 있다.
뭔가를 직접 고칠 기회가 없다. 고쳐달라고 건의해도 먹히지 않는다.
기존 문서는 이미 지난 일이니 읽지 않았다. 문서를 써도 아무도 읽지 않을 것 같아서 나도 쓰지 않는다.
그냥 하던대로 하면 되겠지. (지키지도 못할) 개인적인 목표는 세우지 않는다.
소프트웨어 설치는 다른사람에게 맡긴다. 이메일 필터 같은건 따로 설정하지 않는다. 경쟁사 뉴스는 다른 사람이 공유해줄때까지 기다린다.
“즐기긴 뭘.. 일은 일이지..” 라고 생각한다.
적어보니까 끔찍..하네요 ;(
부제목에도 적어봤지만, 저는 이 부분이 중요하다고 생각합니다. “기억하라, 당신은 일을 하러 온 것이지 만들러 온 것이 아니라는 사실을!”
더 많은 글을 만나보시려면 Build Magazine을 구독해보세요.
We Build Product 페이스북 페이지를 통해서도 구독할 수 있습니다.
