언제 프로덕트 매니저를 채용해야 할까?
When to hire a product manager
처음 스타트업을 시작할 때 PM이 없었던 팀은 성장하면서 PM을 언제 채용해야 할지 항상 고민이 됩니다. 현재 Dark의 CEO인 Ellen Chisa의 관련 글을 번역해보았습니다. 그녀는 Lola에서 VP of Product이었으며, Kickstarter와 Microsoft에서 PM을 해본 경험이 있습니다. 이 글은 20명 규모의 스타트업이고 PM이 없거나 주니어 PM만 있는 조직에서 읽으면 도움이 될 것 같습니다.
원문: https://medium.com/once-upon-a-team/when-should-you-a-hire-a-product-manager-91e393862150 By Ellen Chisa
최근 몇 년 동안 창업한 많은 친구들이 나에게 “PM을 고용해야 해?” 또는 “만약 한다면 언제 첫 PM을 고용해야 할까?”라고 물었다.
나는 Lola(역자 추가: 글쓴이가 다녔던 회사로 기업용 비즈니스 출장 매니지먼트 서비스를 제공)에서 PM으로 첫 직원이었으며, 창업자들 중에 한 명도 Product 쪽 업무를 하는 사람이 없었다. 그 덕분에 나는 시작부터 Lola가 Product 조직을 어떻게 확장하는지 볼 수 있었다. 조직 규모를 확장한다는 건 건 때로는 채용을 의미하기도 했지만, 때로는 내부에서 적합한 사람을 찾는 일이거나 여러 사람들이 같이 가지고 있는 책임을 나누는 작업일 때도 있었다.
필요하기 전까지는 채용하지 마라
사람들이 Product Management에 대해 떠올리는 큰 불만 중 하나는 팀을 느리게 만든다는 것이다. 그리고 다른 하나는 PM들이 하루 종일 미팅에 참석하느라 실제로 팀이 업무를 실행하는 데에는 도움이 되지 않는다는 것이다. PM이 너무 많거나 하나의 책임을 여러 사람들이 가지면 문제가 발생한다.
의사 결정을 내릴 수 있는 명확한 오너가 없어 의사 결정 상황에서 교착 상태에 빠진다.
명확한 오너가 없으면 사람들은 자신들이 만든 결과물이 인정받을지에 대해서 걱정하게 되고, 앞으로 나가려고 하기보다는 현재에 안주하려고 한다.
위의 문제들을 피하기 위한 몇 가지 좋은 방법이 있다.
견디기 힘들 정도가 아니라면 PM을 뽑지 말자
혹자는 PM이 계획을 세워 미래에 생길지도 모르는 제품 부채를 미리 방지하도록, PM을 일찍 채용해야 한다고 말한다. 나는 반대 의견이다. 만약 당신과 팀이 생각하기에 현재가 괜찮다면, 추가로 고용할 필요는 없다. 현재 PM 없이도 적절한 Product를 늦지 않게 릴리즈하고 있는 상황에서, PM을 새로 채용하면 이들은 팀을 돕는 대신 자신들이 왜 존재해야 하는지를 ‘증명’ 해야 하는 상태가 된다.
PM을 채용해야 할 만한 문제점들은 다음과 같다. 대부분의 성장하는 스타트업들은 이 문제들을 경험한다:
다음번에 뭘 만들지에 대해서 놓친다 (할 일에 대한 우선순위가 정리되어 있지 않음).
아무도 신경 쓸 시간이 없어서 동작하지 않는 솔루션을 만든다 (꼭 캐치했어야 했던 그것).
팀 간에 우선 순위를 다르게 생각하고, 커뮤니케이션이 제대로 되지 않아 Product를 유저에게 전달하는 것이 늦어진다.
현재 만들고 있는 것에 대해서 “이걸 왜 만들고 있는지”에 대해서 감이 없다.
문제를 풀 수 있는 다른 방법이 있으면 PM을 뽑지 말아라
문제를 해결하기 위해서 꼭 새로운 사람이 필요하지는 않다. 초기에 내 고민 중 하나는 디자인에서 요구한 픽셀 정렬과 각종 항목에 대한 모든 범위 테스트 등에 대한 충분한 QA 시간을 갖는 것이었다. 이때 나에겐 일이 많아 정신이 없었고, 작은 스펙에 대한 Product Management을 돕거나 QA 업무를 할 주니어 PM을 뽑고 싶었다.
결론적으로 그렇게 하지 않았다. 대신 같이 일하는 여행 컨설턴트에게 파트타임으로 QA 업무를 맡겼다. 이건 생각하지 못한 효과가 있었는데, 그는 QA 업무를 하면서 좋은 버그 리포팅 테크닉을 배웠다(게다가 다른 에이전트들에게 버그 리포팅 방법을 가르쳤다). 우리는 꽤 오랫동안 이 방식으로 QA 업무를 처리했다. 최종적으로는 QA 업무를 하던 그에게 Product 업무를 맡겼다 (추가 채용은 필요 없었다).
비슷한 방식으로 여러 번 문제를 해결했다. Lola의 운영 총괄은 여행 컨설팅 툴에 대해 수많은 Product 관련 업무를 했다. 우리 개발팀장은 내가 일했던 다른 회사에서 PM이 주로 했던 “로드맵 진행 상황” 미팅을 주간으로 진행했다. 이렇게 하면 Product와 관련한 많은 문제점들은 회사 내에서 해결하면서 동시에 기존 직원들이 성장할 수 있는 기회를 제공할 수 있다.
그럼 언제 고용하나?
물론 Product팀에 PM을 절대 뽑지 말라는 이야기가 아니다. 우린 최근에 새로운 PM을 팀에 채용했다. 아래 상황을 고려해서 언제 PM을 채용할지 고민해보자.
PM #1 — 창업자가 다른 일에 집중해야 할 때
초기 멤버로 PM을 꼭 채용해야 할 첫 번째 순간은 창업자가 Product팀의 운영을 그만둘 때이다. 이때 창업자는 본인이 가진 Product에 대한 비전을 완벽하게 내부에 전달할 누군가를 찾아야 하고, 그런 의미에서 이 채용은 굉장히 중요하다. 창업자와 Product 사이의 관계는 회사 내에서 가장 어려우면서도 가치 있는 일 중 하나다.
창업자의 이전 경험
첫 PM을 언제, 누구를 고용할지 고민할 때 가장 중요한 것은 창업자의 이전 경험이다. 만약 창업자인 당신이 Product 업무를 계속하고 싶다면 새로운 PM을 채용하는 건 쉽지 않다. 이 경우엔 기존 팀에 PM이 없었던 것이 아니라, 당신이 PM이었던 것이고 그 업무를 좋아했기 때문에 가능했을 것이다. 만약 당신이 다른 곳에서 PM을 했었거나 자연스럽게 현재 PM업무를 하고 싶은 경우 첫 PM을 채용하지 않고 더 큰 팀으로 만들 때까지 계속 당신이 이 업무를 계속할 수 있다. 만약 당신이 Product 리더로서 경험이 있다면, 주니어 PM을 채용해서 직접 팀을 매니징 할 수도 있다. 이런 식으로 팀이 더 커지기 전까지 또 다른 리더의 채용을 잠깐 미룰 수 있다.
반대로 PM 업무와 관련한 경험이 전혀 없다면 (예를 들어, 개발자인데 기술 쪽에만 더 관심이 있었거나, 세일즈 담당인데 Product와 관련한 일을 해본 적이 없을 때), 아마도 조금 더 빨리 경험 있는 사람으로 PM을 채용하고 싶을 것이다. 시니어를 채용하면 그의 이전 경험을 바탕으로 Product에서 일어날 문제를 피하게 해 줄 것이다.
첫 번째 PM을 채용을 하기 전에 해야 할 고민들이 있다. Product 조직을 어떤 성격의 조직으로 발전시키고 싶은지, 그들과 어떻게 상호작용하며 업무를 하길 기대하는지 우선 정의하는 것이 필수적이다. PM들이 Product에 대해서 최종 의사 결정을 할 수 있게 만들 것인가 혹은 당신이 직접 할 것인가? 에 대한 질문도 고민해서 정의해야 한다.
Product의 복잡도
고려해야 할 또 다른 이슈는 Product의 복잡도이다. Product팀 입장에서 가장 나쁜 방식은 “나는 상위 레벨의 전략을 다룰 테니, 당신들은 디테일을 챙겨라.” — 이렇게 하면 디테일을 챙겨야 하는 사람들이 좋은 의사 결정을 하기 어렵다. 또한 의사 결정자들과 팀의 다른 사람들 사이에 좋은 관계를 만들어지기 어렵다.
Lola는 일반 유저 사이드의 앱과 여행 컨설턴트 사이드의 컨설턴트 용 툴, 양쪽을 모두 가지고 있는 장점이 있었다. 또한 일반 유저 사이드와 컨설턴트 사이드 간의 조율이 필요한 인터랙션들이 존재했다. 이 Product 구조는 Product 조직을 어떻게 구성해야 하는지에 대한 좋은 지침이 되었다.
Product가 복잡할수록, 깊게 고민하기 위해서 추가적인 리소스가 필요하다. 그리고 창업자는 그것에 계속 깊게 관여해야 한다. Product가 복잡하고 빠르게 성장할 것이라 예상된다면, 첫 번째 PM은 좀 더 시니어를 채용해야 할 것이다.
다른 팀원들
PM을 채용할 때 세 번째로 고려할 것은 팀이다. 만약 팀에 여러 명의 디자이너와 엔지니어들이 있다면, 팀 내에 PM에 대한 니즈가 이미 많을 것이다. 그러나 팀이 주로 세일즈 인력들로 구성되어 있고, Product가 단순하다면 창업자가 좀 더 오래 직접 PM을 맡아도 된다. 팀의 다른 사람들이 가지고 있는 경험치도 고려해야 한다. 나는 개발팀 매니징뿐만 아니라 주니어 PM까지 쉽게 매니징 할 수 있는 엔지니어링 VP와 일해본 경험이 있다. 이런 경우에는 시니어 PM을 채용할 필요가 없다.
PM #2 & 그 이상의 고민
많은 결과물과 매출을 위해서는 “좋은 엔지니어”와 좋은 세일즈”를 중심으로 채용하는 것이 회사 입장에서 옳은 것인지도 모른다.
그러나 이건 Product 입장은 아니다. Product팀을 생각하면 당신은 역할에 딱 맞는 사람을 찾아야 한다. 팀에 “PM이 없을 때”와 “PM이 있을 때”는 상황이 다르기에 다른 팀원의 채용에도 영향을 준다. 첫 번째 PM을 정하는 것이 가장 어렵다. 첫 번째에 맞는 사람을 찾았다면 이어지는 채용에도 도움이 될 것이다.
한 영역에 대해 전체를 모두 맡길 수 있는 사람을 찾아라
Kickstarter에서 나는 50명 이내의 입사자이자 5번째 PM이었다 (Product 팀장을 포함해서). 이전에 적은 것처럼 Kickstarter에 지원하고 일을 시작할 때까지 6개월이나 걸렸고, 입사 지원부터 일을 시작하기까지의 기간 동안 2명의 다른 사람들이 Product팀에 합류했다. 예를 들면, Daniella는 커뮤니티팀에서 내부 툴 관련 업무 담당으로 팀을 옮겼다. 난 아마 그 업무에 적합한 사람이 아니었을 것이다.
새로운 PM이 업무를 하기 위해서는 명확하게 그의 영역을 구분하는 것이 필요했다. 또한 채용 공고에서도 정확히 역할을 구분해서 적어야 했다. “우린 도움이 필요해요~” 또는 “여기 우리가 할지도 모르는 기능이 있어요~”라는 식이 아니라. 새로운 PM에게는 규모는 작지만 프로젝트의 전체를 맡겼다. 예를 들면 나의 첫 프로젝트는 심비안 OS를 위한 파워포인트 Broadcast 뷰어였다. 이 뷰어는 단순히 서버에 있는 걸 보여주기만 하면 되는 것이었다. 제품은 단순했지만, 내 업무는 전체 영역에 다 걸쳐 있었다. 나는 이 업무 방식을 통해 Kickstarter의 후원자 경험에 대해 6개월 만에 익숙해졌다.
지금까지 해온 것들을 생각해보자
Product팀을 만들 때 당신에게 기준이 있을 것이다. 팀에 있는 모든 사람들이 기술에 밝다는 것을 알게 될 수도 있다. 혹은 아무도 그렇지 않다는 걸 알게 될 수도 있다. 혹은 모든 사람들이 매우 둔감하다는 것을 알게 될 수도 있다. 혹은 이메일로 의사소통하는 걸 선호한다는 것을 알게 될 수도 있다. 창업자들과 초기 Product팀원은 팀의 문화를 만든다.
채용할 때마다 Product팀의 문화를 어떻게 만들고 싶은지 생각해봐야 한다. 모든 PM이 테크에 능했으면 하는지? 그렇지 않다면 PM을 채용할 때 기술적 배경을 고려하지 않아도 된다. 만약 새로 채용할 PM이 이미 만들어져 있는 문화를 번성하게 할 수 있는지도 한 번 생각해보라.
새로 PM을 채용할 때는 즉각적으로 필요한 일을 해결하기 위해서가 아니라 Product팀을 견고하게 만들기 위해서 채용해야 한다. 채용을 통해 팀의 퀄리티와 강점을 높여야 한다. 새 PM을 채용해서 팀의 퀄리티와 강점이 개선되지 않는다면 채용하지 않는 것이 낫다.
그래서 PM은 언제 채용해야 하나요?
PM을 언제 채용해야 하는지는 직원의 수로 이야기하기는 어렵다. 대신 아래 4가지 질문에 대답해보자.
Product팀의 문제점이 무엇인가요?
왜 이 문제를 다른 방식으로 고칠 수 없나요?(지속 가능하게)
새 PM은 Product에 대해 무슨 역할을 하나요?
새 PM은 Product에 대해 창업자와 어떻게 커뮤니케이션하나요? 또한 어떻게 새 PM을 기존의 팀(다른 분야 또는 다른 Product 유관자들)과 융화시킬 것인가요?
(1) 물론 당신들이 원하는 건 숫자인 것을 안다. 나는 첫 PM은 10명 이내로 채용하는 것을 추천하며, 적어도 30명 이내로는 채용해야 한다고 생각한다.
역자 주.
저도 Product Manager, Product Owner 등 기획 업무를 하는 사람을 언제 채용해야 할지에 대한 질문을 많이 받습니다.
Product팀에서 다른 사람들의 의견을 조율하여 로드맵을 만들고, 개발자/디자이너와 일정을 조정하고, 비즈니스 조직이나 운영 조직과 커뮤니케이션해서 Product 전체의 방향과 톤을 맞추는 역할은 반드시 필요합니다. 그러나 그 역할을 하는 사람이 꼭 PM일 필요는 없습니다. 이미 제품을 만들고 팀을 잘 운영하고 있다면 앞에 설명한 그 역할을 누군가가 잘하고 있는 겁니다. 단순히 우리 팀에 PM이 없는데?라는 이유로 PM채용을 고민할 것이 아니라, 팀에 어떤 역할이 비어있는지를 찾아보는 것이 더 중요합니다. 그리고 그 역할은 새로 채용한 PM이 아니라 팀의 다른 누군가가 더 잘할 수도 있습니다.
