product management

프로덕트 리더가 되기 위해 필요한 스킬들

Inyong SuhLeave a comment

Cracking the PM Interview라는 책을 공저한 Jackie Bavaro의 미디움 글입니다. 본인과 본인 팀원들의 경험을 통해 배운 경력 개발을 위한 중요한 스킬을 정리했습니다. 사실 논리정연한 글이라기보다는 본인이 생각한 중요한 스킬을 쭈욱 나열한 글입니다. 제가 봤을 때 이 글을 한 문장으로 요약하자면 다음과 같습니다.

다른 직무로 전환하는 경우가 아닌 이상 직무 내에서의 경력 개발은 담당 업무의 범위를 넓히고(increasing scope), 더 복잡한 문제(complexity)를 해결하고, 더 자율적(autonomy)으로 일하고, 더 큰 임팩트(impact)를 내는 방향으로 발전해야 합니다. (“Career growth within a role is usually about increasing scope, complexity, autonomy, and impact”)

제가 Booking.com에서 일하면서 배운 것도 위와 동일합니다. 한 제품, 한 문제에만 포커스를 하며 일하다가 스킬이 늘고 좀 더 넓게 볼 줄 아는 시야가 생기면, 자연스럽게 당신의 매니저도 당신의 실력을 믿고 더 많은 수의/더 복잡한 문제를 맡기게 됩니다. 그럴수록 더 큰 비즈니스 성과를 낼 수 있게 되구요. 조직 내에서 자연스럽게 시니어/리더가 되어가는 과정입니다.

성과를 내기 위한 더 많은 기회를 얻기 위해서는 매니저와 수시로 본인의 경력에 대한 논의를 해야 합니다. Career goal에 대한 논의를 말이죠. 매니저는 당신이 더 많은 성과를 내어 경력상의 목표를 달성하기 위해 돕는 역할을 합니다. 그러기 위해선 다시 한 번 말하지만 매니저가 내가 이루고자 하는 목표를 알아야겠죠. 한국의 조직 문화에서는 좀 어색할 수도 있는 대화일 수도 있습니다.

또한, 매니저가 내 목표를 알고 있다고 하더라도, ‘신뢰‘를 주지 못하면 새로운 기회를 얻기 힘들겠죠. 자율적으로 복잡한 문제를 해결하는 모습을 지속적으로 보여줘야 합니다. 문제를 제대로 해결하기 위해서는 각 회사 고유의 업무 문화/프로세스를 잘 알고 이를 토대로 실행 계획을 세워야 하기도 하구요.

‘임팩트’를 증명하기 위해서는 본인의 제품/업무가 회사의 전략/비전과 어떻게 연결되어 있는지 우선 파악을 해야 합니다. 아무리 열심히 일해봤자 회사의 리더들이 ‘중요하지 않다’고 생각하는 일일 경우 그 성과를 인정받을 수 없으며 오히려 리소스를 낭비했다고 생각할 수도 있습니다.

이외에 채용을 더 경험하고 배우라는 것, 사이드 프로젝트를 잘 선정해서 실행하라는 것 등 몇 가지의 조언들이 더 있습니다. 완전 짧은 글은 아니기에 5분 정도는 시간을 두고 읽어보셔야 할 것입니다.

Buffer Analyze, 고객 0명에서 1천명까지의 여정

Inyong SuhLeave a comment
  • 이 글은 제가 커리어리(퍼블리 뉴스, careerly.co.kr)에 큐레이션하여 올린 리뷰 글입니다.

예전에 제목(“Two Years Ago, We Started Building a Product that Now Earns Over $500,000. Here’s How We Did it“)을 보고 저장해놓았던 글을 꺼내 읽었습니다. Buffer라는 Product(소셜 미디어 퍼블리싱 툴)에서 ‘페이스북, 인스타그램 분석’ 부분만 떨어져 나와 standalone 서비스(Buffer Analyze)로 시작하여 유료 고객 1천명까지 성장하기까지의 스토리가 재미있습니다. (저자는 Buffer Analyze의 Product manager이며 총 5명 – 1 PM, 1 디자이너, 3 개발자 – 으로 팀을 꾸렸습니다)

짧게 요약하자면 아래와 같습니다. 본문 자체도 그리 길지 않고 읽기 쉬우니 스크린샷이나 그래프를 보고 싶다면 읽어보셔도 좋습니다.

– 리서치 : 초기에는 리서치에 집중. 잠재 고객 20-30명과 전화 통화를 하고, 이메일로도 대화를 하고, 수백개의 설문조사 결과를 받았다. 10번째 콜부터 어느 정도 패턴이 보였다. (frustration, recurring challenges in workflows, etc)

– 제품 개발 프로세스 : 리서치를 시작한 후 얼마 지나지 않아 바로 제품 디자인을 시작했다. 제품 개발 일정 내내 리서치, 디자인, 개발을 모두 병렬로 동시에 진행했다. 예를 들면, PM이 기능 D를 리서치를 하는 동안 디자이너는 기능 C를 디자인하고 기능 B가 (개발자들에 의해) 만들어지고 있으며 기능 A는 측정(사용)되고 있다. (제 의견을 덧붙이자면, 저는 이런 프로세스가 빠른 릴리즈에는 좋다고 생각하지만 잘못 운영하면 팀원들의 motivation에 해가 되는 프로세스가 될 수도 있다고 생각합니다.)

– 첫 고객 : 처음부터 많은 기능을 넣진 않았다. 시장에 이미 존재하는 툴에 비하면 간소하지만 우선은 소수라도 실제 사용자들을 통해 우리가 맞는 방향으로 가고 있는지 확인하고자 했다. 기존 Buffer의 사용자들에게 개별로 이메일을 보내고 50% early-access 할인을 제공하는 등 어떻게든 진짜 사용자를 획득하고자 했고 그들에게 피드백을 받으려 했다. 개발 시작 후 7개월만에 첫 고객을 얻었고 첫 매출 25불을 올렸다.

– 100명의 고객 : 기존 Buffer의 고객들을 모두 spreadsheet에 넣고 그들이 누구인지 분석했다. 그리고 우선순위별로 그룹을 나누어 이메일을 보내기 시작했다. 첫 그룹은 40%의 회신율을 보였으나 그 다음 그룹은 25%로 떨어졌다. 1천 여통의 이메일을 보냈고 약 10개월 만에 고객수 100명을 찍고 5천불의 MRR(Monthly Recurring Revenue)를 달성했다.

– 첫 500명의 고객 : 이메일 전략은 잘 먹혔으나 스케일업하기 힘들었다. 그래서 self-serve signup 기능의 우선순위를 높여 개발했다.

– 글을 쓰고 있는 현재(2019년 7월), Buffer Analyze는 약 1천명의 고객을 획득했고 매달 4만7천불 정도의 매출을 올린다. 연으로 환산하면 50만불 정도다. (위 100명 달성 후 8개월만의 일임) 하지만 현재 7명의 팀원과 인프라 비용 등을 고려했을 때 1년에 1백만 불 정도는 벌어야 수지타산이 맞다. (더 성장해야 한다는 뜻)

PM을 매니징하고 성장을 도울 수 있는 방법

Inyong SuhLeave a comment

‘PM의 정의, PM이 해야 할 일’등에 대해서 늘 논쟁이 많죠? 함께 일하는 디자이너, 데이터 과학자, 개발자 등에 비해 역할과 책임을 한 마디로 정의하기 어려운 직무입니다. 정답도 없구요. 그러면 이런 PM들을 ‘매니징’한다는 것은 어떨까요? 링크된 글의 저자에 따르면 이는 ‘모호함’의 제곱(ambiguity² ; 직역은 늘 어색합니다..)입니다. 😂

이번 글은 현재 Shopify의 VP of Product인 Brandon Chu의 글입니다. 여러 명의 PM을 매니징해 본 경험이 있는 그가 밝히는 ‘효과적으로 PM을 매니징하기 위한 프레임워크’를 소개합니다.

1. The mental model for managing PMs — 그들은 사업가이고 당신은 그들의 투자자라고 생각하라 (they’re entrepreneurs, you’re the investor)

  • PM은 기업가의 기질을 가지고 있는 경우가 많다. 이들을 사업가로 생각하고 당신은 그들의 비전을 산 투자자로 생각해보라. 각 PM의 오퍼레이션에 깊이 관여하지 말되 적절한 피드백을 주고 그들이 보지 못한 부분(blind spot)을 볼 수 있도록 도와줘라.
  • 당신도 그들로부터 배울 수 있다는 것을 잊지 말라. 다양한 백그라운드(실제 스타트업 창업을 몇 번 해본 PM, FANG 등에서 일했던 PM 등)에서 온 직원들의 다양한 관점/능력을 통해 당신도 그들로부터 배울 점을 찾을 수 있다.
  • 그들이 당신보다 뛰어날 수 있다. 그들이 가능성을 펼치고 빛날 수 있도록 도와줘라.

2. Developing PMs — 적절한 업무 범위를 어떻게 설정할까?

  • Whole customer experience를 출시해 보는 경험은 PM의 성장에 가장 좋은 방법이다. PM은 그의 팀이 제공하는 end-to-end 고객 경험을 통해 가치를 만든다.
  • 당신의 임무는 해당 PM이 매니징 가능한 최대 범위의 업무를 맡겨 그들이 최대한의 성과를 내게 하는 것이다. 여기서 ‘업무 범위를 정해준다’라는 것은 ‘어떤 제품을 만들어라’라는 지시의 개념이 아닌 어떠한 크기의 ‘목표(goal)’가 적절한 지 PM과 함께 조절하는 개념이라 보면 좋겠다. 능력이 뛰어나고 야심이 있고 잠재력이 큰 PM의 경우는 더 큰 목표를 맡기면 될 것이다.
  • 그럼 어떻게 그 ‘적절한 범위’를 알 수 있을까? 우선 제품/프로젝트(의 복잡도)를 6가지 관점(이 6가지에 대해서는 첨부된 링크 확인바람)에서 분석을 한 후, 해당 PM이 이 제품/프로젝트를 맡아서 성공적으로 임무를 수행할 수 있을지 생각해 본다. 함께 오래 일한 PM이라면 가능성/잠재력에 대한 판단이 상대적으로 쉽겠지만, 새로 입사한 PM이라면 좀 어려울 수 있다. 이럴 경우 처음엔 좀 난이도가 낮은 제품을 맡기고 적응과 성과의 속도에 따라 업무 범위를 조정해 주면 된다.

3. Assessing PMs for performance — PM의 성과는 어떻게 측정할까?

  • PM은 특정 몇 개의 ‘스킬’만으로 일하는 직무가 아니기 때문에 성과를 평가하기 굉장히 어렵다. 아래의 4가지 관점에서 PM의 성과를 평가해 보자.
    1. 제품 성과(Product performance) : 이론적으로 가장 적합한 방법이다. 하지만 이것만으로 PM의 평가를 순전히 평가하는 것은 현실적으로 어렵다. 왜냐하면 : 1) 어떤 제품은 그 성공여부의 판단이 오래 걸리기도 하고, 2) 모든 제품의 성과를 직접적으로 측정하기 어려울 때도 많고, 3) 어떤 제품을 맡느냐에 따라 성과의 크기가 다를 수 있고, 4) PM은 팀의 일원으로 디자이너나 개발자의 역량에 따라서도 제품의 성과는 달라질 수 밖에 없기 때문이다.
    2. 다른 직원들과 얼마나 소통을 잘 하고 효과적으로 일하는가? : Product management는 직무적으로 리더일 수 밖에 없고 그들의 잠재적인 성과는 얼마나 다른 이들로부터 ‘신뢰’를 얻는가에 따라 달라진다. 함께 일하는 팀원, 동료 PM, 유관 부서 등으로부터 피드백을 받아보자.
    3. 의사 결정 능력 : 모든 의사결정은 기회 비용이 수반된다. PM이 내린 결정을 깊이 분석해보고 왜 그런 결정을 내렸는지 논의를 해보라. 이는 좋은 코칭 기회가 되기도 한다.
    4. 전략적인 사고 능력 : 디테일에 함몰되지 않고 큰 그림에서 제품을 바라볼 수 있는 능력.

저는 아직 PM을 매니징해 본 경험이 없습니다. 하지만 매니저의 관점에서 상황을 볼 수 있는 능력은 다음 세 가지의 장점이 있다고 생각합니다. (1) 어떻게 해야 성과를 낼 수 있는지를 명확히 알 수 있다, (2) 매니저와의 대화를 내가 능동적으로 이끌 수 있다, (3) 매니저도 사람이다. 매니저의 고충을 이해하고 그의 시선에서 상황을 바라보고 대화를 할 수 있다(인간적인 bonding에 좋음). 그것이 제가 종종 ‘Product leadership’에 대한 글을 찾아보고 독자분들과 공유하는 이유입니다.

내가 이직했을 때 알았으면 좋았을 것들 (이직 후 PM이 처음 해야 할 것)

Inyong Suh1 Comment

개인적으로 PO/PM 직군으로 이직은 딱 두 번 해봤다. 처음은 삼성전자(상품 기획 및 해외 마케팅)에서 쿠팡으로 Product owner라는 직무로 이직했을 때, 두번째는 암스테르담에 있는 Booking.com으로 Product owner라는 같은 직무로 옮겼을 때다.

쿠팡으로의 이직의 경우 S/W Product management에 대한 경험이 전무한 상황에서의 이직이었고 생애 첫 이직이었기 때문에(삼성전자가 첫 직장) 적응을 위한 전략이고 뭐고 없었다. 모든 걸 맨땅에 헤딩하면서 배웠다. Web/인터넷이 어떻게 동작하는지부터 시작해서 인터넷 업계, 개발, 디지털 마케팅 관련한 용어과 개념을 배우면서 동시에 Product management도 사수나 주위 사람들을 통해 배웠다. 당시 Stakeholder였던 마케팅 팀장에게 가서 까놓고 “나 이런 거 하나도 모르니까 좀 알려달라”면서 광고 채널, user acquisition cost, LTV 등에 대해 A4 용지에 적어가면서 배웠던 기억이 아직도 생생하다. 이렇게 배움에 정진(?)을 했지만 Booking.com에 와서도 또 한차례 폭풍 학습을 했다. Booking.com은 PO/PM의 역할이 쿠팡보다는 좀 더 명확히 정리가 되어 있었다. (4~5년 전 얘기다) 물론 쿠팡과 Booking.com의 조직 구조나 문화 자체가 많이 달랐기 때문에 완전히 같은 기준으로 비교를 할 순 없지만, 최소한 Booking.com은 애자일 개발에 대한 경험이 쿠팡보다는 길었으며, 미국, 유럽 및 인도의 메이저 인터넷 업체에서 온 동료들로부터 좋은 practice를 배울 수 있었고, A/B 테스팅의 수준도 높았다. 이 과정에서 많이 질문하고, 싸우고(?), 피드백을 받고, 다양한 고민을 하고, 시행착오도 (또) 많이 겼었다.

이번 글은 ‘내가 이직할 때 알았으면 좋았을 것들‘이다. ‘PM으로 이직 초기에 해야 할 것‘이라 할 수도 있겠다. 지난 번 글 ‘스타트업의 첫 PM이 해야 할 일’에서 언급했듯이 조만간 경력상의 변화가 또 있을 것 같다. 이에 다른 회사로 옮기는 상황을 가정하면서 내가 쿠팡에서 Booking으로 이직했을 때 경험했던 실수와 아쉬웠던 점에 대한 회고를 해보았다.

  1. 해당 산업(Industry)과 주체들에 대해 충분히 공부하자.
    • 필요한 것
      • 해당 비즈니스를 만드는 주체들은 누구인지, 어떻게 거래가 이루어지고, 언제 어떻게 돈이 오고 가는지에 대한 이해
      • 우리 회사는 그 과정에서 어떤 부분을 맡고 있고, 누구와 거래하고 있고, 어떤 문제를 해결하려 하는지에 대한 이해
    • 내가 못했던 것
      • 파트너(호텔리어 측)가 사용할 제품 담당이라고 해서 초반에는 파트너에 대한 공부만 많이 했던 것 같다. 하지만 Marketplace 비즈니스 구조에서 공급(부킹 가능한 호텔 룸) 측면만 공부하는 건 반쪽짜리도 안된다. 결국 파트너도 수요(부킹을 할 게스트)의 트렌드에 따라 대응을 해야 하기 때문에, 수요와 공급 양쪽 주체의 니즈에 대한 철저한 파악이 필요하다.
  2. 매니저에게 ‘이 회사에서 개인의 성장을 위해서는 어떻게 해야 하는지’를 확인하자.
    • 필요한 것
      • 승진 싫어할 사람 많진 않다. 하고 싶다면 ‘어떻게 승진 대상자를 뽑고 어떻게 평가하는지’ 확실히 알아두자. 그리고 좋은 고과를 받기 위해서는 어떤 요건을 충족시켜야 하는지도 대놓고 물어보자. 새로운 회사에서는 어떤 사람이 일을 잘 하는 것인지 명확히 알면 개인의 경력 관리도 일찍부터 할 수 있다.
    • 내가 못했던 것
      • 한국은 좀 다를 수 있어도 유럽과 미국(풍문으로만 들었소)에서는 ‘열심히 한다고’ 승진을 챙겨주지 않는다. 내가 무엇을 원하는지 확실히 얘기해야 한다. 나는 이것을 늦게 깨달았다.
  3. 조직이, 팀이 어떻게 의사결정을 하는지 빨리 파악하자.
    • 필요한 것
      • 팀이 어떤 식으로 의사결정을 하는지 파악을 빨리 해서 나중을 대비하자. 상사와, 팀원들과 논쟁을 벌일 날이 멀지 않았다.
    • 내가 못했던 것
      • 지금도 그렇지만 내가 입사했던 3년 전에 부킹닷컴은 모든 소프트웨어(작던 크던) 릴리즈를 A/B 테스트를 통해 했고 자체 개발한 A/B 테스트 툴을 통해 결과를 분석하고 의사결정을 한다. 나도 쿠팡에서 A/B 테스트를 했었지만 부킹닷컴은 훨씬 더 상세히 가설을 잡고 지표를 선정하며 통계적으로 유효한 결과를 얻기 위한 여러가지 고민을 한다. 처음 몇 번은 이런 문화 및 ‘통계’에 대한 깊은 이해없이 팀의 중요한 의사결정을 하려고 했다가 역풍을 맞고 설전을 벌인 적이 있었다. (물론 졌다…여담이지만 이런 논쟁을 영어로 하는 것도 처음에는 굉장히 힘든 일이었다.)
  4. 당신 제품이 회사의 비즈니스 모델 그리고 사용자 여정(user journey) 등에서 어떤 역할을 맡고 있는지 파악하자.
    • 필요한 것
      • 당신이 맡을 제품이 회사의 전략 그리고 사용자의 삶/업무(B2B인 경우)에서 어떤 역할을 하고 있는지 좀 더 넓은 시야에서 자신의 제품을 바라보자. 당신 제품이 사용자와 회사에 어떤 영향을 미치는지, 어떤 문제를 해결하려고 하는지 확인하자는 말이다. (이런 넓은 시야는 본인 팀의 현재 성과 뿐 아니라 나중에 시니어나 리더가 되기 위해서도 필요하다)
    • 내가 못했던 것
      • 나의 경우 당시 신설됐던 팀을 맡게 되었다. 단기간에 이해하기 어려운 제품이었으며(주위 많은 동료들의 평이다), 나도 숙박(hospitality) 산업과 주체들에 대한 이해가 깊지 않은 상황에서 팀을 맡게 되어서 시야가 좁았다. 우리 제품이 사용자의 삶(업무)에서 어떻게 사용되는지, 그것이 (파트너 및 Booking의) 비즈니스에 어떤 영향을 미치는지에 대한 이해가 얕았다. 결과적으로 우리가 풀어보고자 했던 문제를 깊게 분석해 보지 못했고 초기 성과도 미미하였다.
  5. 상위 부서 및 자기 제품의 주요 지표를 확인하고 회사 전체 지표와의 연결을 파악하자.
    • 필요한 것
      • 위 4번과 사실 유사한 개념이라 볼 수 있다. 상위 부서 및 자기 제품의 주요 지표에 대해 알아보고 그 주요 지표가 회사 전체의 지표와 어떻게 연결되어 있는지 확인하자. 내 제품이 회사 전체의 비즈니스에 어떤 기여를 하는지 확인 할 수 있으며, 앞으로 어떤 부분을 중점으로 발전시켜야 할 지 파악할 수 있다. 대쉬보드를 확인하고 없다면 만들자.
      • 100% 확실한 지표를 찾기 힘들어도 최대한 ‘내가(우리 팀이) 한 일이 회사의 비즈니스 혹은 사용자에게 어떤 영향을 미쳤는지’에 대해 가늠해 볼 수 있는 지표를 찾아 팀원들 뿐 아니라 매니저, 상위 조직장들과 align을 하자.
    • 내가 못했던 것
      • 사실 제품의 특성에 따라 제품의 주요 지표와 회사의 주요 지표와의 연결점을 찾기 쉬울 수도 있고 아닐 수도 있다. 나는 어려운 편에 속했다. 이 연결점을 찾지 못하면 본인 뿐 아니라 팀원들도 ‘그래서 내가 한 일이 회사에 어떤 도움이 되지?’라는 의구심을 계속 갖게 된다. 이는 장기적으로 봤을 때 팀의 성과 평가 뿐 아니라 사기에도 영향을 준다.
  6. 모르는 건 모른다고 하고 질문을 하고 도움을 요청하자.
    • 내가 못했던 것
      • 처음에는 혼자 끙끙 싸매고 혼자 집에서 야근도 종종했다.(이 동네에선 야근은 거의 안한다고 본다) 하지만 모두가 모든 것을 알 수도 없고 시간이 지나면 당신도 자연스럽게 전문가가 된다. 첫 한 두 달은 무조건 질문을 빨리 많이 하자. ‘내가 바보같아 보이면 어쩌지?’라는 고민하지 말자. 질문을 짊어지고 있다가 너무 늦게 하는 것보다 빨리 물어보는 게 낫다. 다음 주 목요일에 있을 매니저와의 1:1까지 기다리지 말고 바로 물어보자. 아무도 뭐라고 하지 않는다.

<참고>

  1. 사실 써놓고 보니 지난 번에 쓴 ‘스타트업의 첫 PM‘ 글과 겹치는 부분이 꽤 많다. 흥미로웠던 부분이다.
  2. 인터넷 검색을 해보면 ‘First 30 days as a product manager(PM으로 이직 후 첫 30일 동안 해야 할 일)’와 같은 글이 많다. 그만큼 여러 사람들이 고민하는 질문인 것이다. 나도 예전에 그런 글들을 읽어보고 해당 에버노트 링크와 같이 정리해 본 적 있으나, 이번 글은 순전히 내 경험을 회고한 내용이다. 물론 예전에 읽었던 글이니 영향을 받았을 수도 있겠다.

스타트업의 첫 Product manager가 해야 할 일

Inyong Suh1 Comment

최근에 이직을 위해 10개 이상 회사와 연락을 주고 받았고 그 중 몇 군데와는 실제 내 매니저가 될 사람(보통 hiring manager)을 포함한 다른 Product manager(PM)들과 여러 차례 인터뷰도 진행하였다. 결과를 떠나 3~4년만에 하는 인터뷰는 스트레스이기도 했지만 지루했던 일상에 refresh가 되는 요소이기도 했다. 모든 회사는 다른 문제를 풀기 위해 노력을 하고 있기 때문에 다양한 회사와 인터뷰를 한다는 것은 다양한 고객의 문제에 대해 내 나름의 기준에서 고민해 볼 수 있는 기회이기도 하기 때문이다. 인터뷰어와의 대화도 즐거웠다. 인터뷰를 하다보면 나와 맞을 것 같은 회사와 사람이 보이고, 이런 인터뷰는 내가 ‘인터뷰를 당한다’라는 생각보단 ‘즐거운 대화를 나눴다’라는 느낌이 든다. 좋은 질문(내가 대답을 하기 쉽진 않지만 핵심을 짚는 질문들)을 하는 인터뷰어가 있을 경우 그 회사에 대한 매력도가 올라가기도 한다. (*참고로 PM 인터뷰는 어떻게 준비해야 하고 주로 어떤 질문을 하는지에 대해서는 나중에 포스팅할 생각이다.)

그 중에서 총 직원수가 10명이 넘지 않는 스타트업의 첫 PM으로 합류하는 케이스도 있었다. 이를 위해 ‘회사의 첫 Product manager로서 내가 해야 할 가장 중요한 일이 뭘까?‘에 대해 혼자 고민해보면서 인터넷 검색도 함께 해봤다. 이번 글에서는 그 (검색) 결과들을 간단히 요약해보고 나의 의견도 덧붙여보려 한다. 다만 아래의 내용은 ‘일반화’를 하긴 힘들 수도 있다는 것을 먼저 얘기해두고 싶다. 창업멤버들의 Product management 경험 여부, 어떤 유형의 제품을 만드는지, 제품의 life cycle 중 어디에 있는지(product-market-fit은 찾았는지, 찾는 중인지 등), 조직이 어떻게 구성되어 있는지, 개발자와 디자이너는 어디에 몇 명이 있는지 등 많은 변수에 따라 회사가 나에게 거는 기대와 내가 할 수 있는 일들, 내가 꼭 해야 할 일들이 달라질 수 있기 때문이다. 이에 아래 정리한 내용은 ‘참고 사항’일 뿐 꼭 따라야 할 ‘Bible’은 아니라는 점 염두에 두길 바란다.

살펴본 의견들을 6가지 카테고리로 나눠보았다.

  1. 기대 수준을 확인하고 조절하기 (set the expectation)
    • 우선 왜 PM을 채용하려는지, 나에게 어떤 기대를 거는지 확인해야 한다. 초기 단계에서는 보통 창업자와 인터뷰를 하고 창업자와 이 대화를 할 것이다. 보통은 창업자가 PM의 일을 겸임하다가 회사/조직의 성장과 함께 업무량이 많아지면서 자기 일을 대신해 줄 사람을 찾게 된다. 새로 채용할 PM이 주로 operational/tactical한 일을 하길 바라는지(자기의 비전을 실현시켜 줄 사람을 찾는 경우), 아니면 제품의 비전과 전략적인 부분까지 맡아주길 원하는지 확실히 확인해야 한다.
    • 함께 일할 다른 직무의 동료들(stakeholder)이 Product management를 어떻게 이해하고 있고, 내가 어떤 역할을 할 것이라 기대하는지 확인도 필요하다. 또한 제품의 의사결정에 입김이 센 동료가 누구인지 파악하고 권한에 대한 대화와 조율도 필요하다. (물론 창업자가 가장 큰 영향력이 있겠다)
    • 초기 스타트업은 인력이 모자라기 때문에 업무의 범위를 정확히 자르기 어려우며 ‘니 일, 내 일’ 딱 자르기 힘든 환경이다. 이에 내 책임과 역할의 범위도 유연하게 가져가야 한다. 필요한 경우 다른 직무의 업무도 어느 정도 대신해야 할 경우도 생기기 때문이다. (wearing multiple hats)
  2. 팀원들과 1:1 미팅하기
    • 함께 일 할 개발자, 디자이너 등 팀원들과 1:1 미팅을 하면서 개개인의 성향도 파악하고, 그들이 PM에게 기대하는 것이 무엇인지 확인하며, 그 동안 제품 개발을 하면서 어려웠던 점/어떤 문제점이 있었는지 확인한다. 이후 실제 업무를 시작했을 때 참고해야 할 중요한 사항들이 될 것이다.
    • 개발팀 리더나 시니어 개발자에게 제품의 기술적인 부분(아키텍처, 테크 스택 등)에 대해 배우고, 현재의 제약 사항 및 최근 이슈 등에 대해서도 브리핑을 받는다. 영업 및 마케팅 담당자와도 비슷한 대화가 필요하다.
  3. 해당 산업과 제품에 대해 이해하기
    • 많은 답변 중 하나가 “푹 쉬면서 산업 전반적인(macro) 부분에 대해 공부해라.”였다. 실제 실무에 들어가게 될 경우 큰 그림에서 상황을 바라보기 쉽지 않다. 이에 내가 일하게 될 산업의 전반적인 지식, 기술의 흐름, 전반적인 기회와 제약사항 등을 알아두자.
    • 경쟁사들이 누구이며 경쟁사의 제품의 강점과 약점이 무엇인지 확인한다.
  4. 고객에 대해 이해하기
    • 가장 좋은 것은 고객들을 직접 만나서 인터뷰를 하고 얘기를 들어보는 것이다. 시장에서 우리 제품을 대신할 만한 제품은 무엇인지, 어떤 제품을 선택했는지(+ 왜?), 사용하고 있는 제품의 pain point는 무엇이며, 고객이 (해당 제품군을 통해) 수행하려고 하는 일이 정확히 무엇이고, 수행하는데 있어 (특정 제품을 떠나) 불편한 점은 무엇인지 등 고객과의 대화를 통해 얻는 정보는 무엇보다 중요하다.
    • 블로그, 트위터, 커뮤니티 등에서 사용자들이 우리 제품을 어떻게 평가하는지 확인한다. 만약 고객의 피드백을 직접 듣는 채널이 있다면 그 피드백 내용들을 확인한다.
  5. 데이터를 정확하게 측정하고 확인하기
    • 회사의 핵심 지표 뿐 아니라 사용자가 제품을 어떻게 사용하는지, 사용에 만족하는지 등에 대한 지표를 확인하고, 그 지표들이 제대로 트래킹되고 있는지 확인한다. 단순히 ‘트래킹하고 있어요’라는 말만 믿지 말고 실제 데이터를 확인하고 검증한다. 관련된 데이터베이스 및 대쉬보드(있다면…) 등에 대한 접근을 요청하고, 이 지표들이 주기적으로 측정이 되고 있는지 확인한다.
  6. 제품 직접 사용해보고 리뷰하기
    • 이 부분은 사실 위 3번과 4번과 어느 정도 겹친다고 볼 수 있다. 경쟁사 제품을 써보기 전에 내가 담당할 제품을 써볼테니까. 내가 담당할 제품을 제대로 사용해보고 이해가 안되는 부분은 동료에게 물어보고, 개선의 여지가 있는 부분은 따로 정리해 두었다가 나중에 활용한다. B2B 제품의 경우 테스트가 쉽지 않은 경우가 있으므로 테스트 방법을 동료들을 통해 미리 확인하고 테스트한다.

사실 회사의 첫 PM이 해야 할 일의 범위는 정말 넓고 많겠지만 위 6가지는 회사에 막 입사했을 때 해야 할 일이다. PM도 업무를 파악하고 제대로 수행하려면 최소 몇 주 이상 걸릴 수 밖에 없다. 특히 완전히 새로운 제품군/산업을 경험하고 있다면 말이다. 너무 조급하게 생각해서 처음부터 디테일의 함정에 빠지지 말고, 넓은 시야에서 산업과 사용자와 제품을 이해하는 시간을 가져야 한다.

여기까지가 인터넷 검색을 통해 알아본 ‘스타트업의 첫 Product manager로서 해야 할 일’이며, 내 의견 또한 어느 정도 추가했다. 내가 참고한 글의 링크, 발췌한 내용 등은 다음의 노트(링크)에 있으니, 혹시 더 자세한 내용을 확인하고 싶다면 위 링크를 확인하기 바란다.

  • ‘스타트업의 첫 PM’ 혹은 유사한 경험이 있으시다면 댓글이나 이메일 등을 통해 인사이트를 나눠주시면 고맙겠습니다. 제가 곧 그 경험을 하게 될 것 같아서요. 🤞 😅