제품관리

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

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’에 대한 글을 찾아보고 독자분들과 공유하는 이유입니다.

Change aversion : “내가 맨날 쓰는 거 그냥 좀 놔둬!”

Inyong SuhLeave a comment

사람은 대개 변화를 두려워하죠. 익숙한 것을 좋아하고 편안해하구요. 어느날 아침 출근하니 매일 사용하던 업무용 툴의 디자인이 하루 아침에 확 바뀌어 있다고 상상해 보세요. “와 엄청 예뻐졌네. 엄청 사용하기 편해졌겠어!”라는 생각보다는 “아 이제서야 좀 익숙해졌는데 또 바뀌었어? 아 그 XX메뉴는 어딨는거야? 바빠죽겠는데 하나씩 다 눌러봐야 하나?”와 같은 반응일 거에요.

얼마 전에 저도 업무 중에 같은 경험을 했습니다. 이번엔 제가 ‘사용자’가 아닌 그 변화를 주도한 ‘제품팀’이었다는 점이 다르지만요. 모든 맥락을 설명하자면 엄청 길기에 간단히 요약하자면 : “사용자들의 불편한 점을 개선하고자 새로 디자인한 제품을 프로토타입 테스트, 알파테스트, 베타테스트를 거치며 신중하게 테스트했고 마지막에는 78%의 만족도(기준선은 65%였음)를 확인하였기에 ‘성공’을 확신했던 제품 업데이트였습니다. 하지만 큰 규모의 사용자에게 릴리즈를 하기 시작하면서 이 만족도는 급감하였습니다. 처음엔 25% 수준까지 떨어졌죠. PM으로서 실망이 컸습니다. 하지만 이 만족도를 매일 측정하다보니 조금씩 높아지는 게 보였습니다. 2주가 지난 지금은 50% 이상까지 올라왔죠. 사용자들의 피드백을 확인해보면 ‘이전께 더 좋다’, ‘왜 바꿨냐’, ‘불편하다’ 와 같은 피드백이 다수였습니다. 구체적으로 무엇이 불편하다 라는 내용보다는 그냥 불편하다, 이전 것이 더 편하다 라는 의견들이 많았죠.”

사용자들은 갑작스런 변화를 불편하게 느낍니다. 익숙한 것이 편하고 안전하다고 느끼죠. 사실 이번엔 고객 만족도가 초기에 떨어질 것이라는 것은 예상하던 일이었습니다. 이전에 어느 정도 유사한 경험을 한 적이 있었고, 첨부한 링크와 같은 자료를 읽으면서 이것이 자연스러운 일임을 미리 알고 있었기 때문입니다. 첨부된 링크에서는 이러한 현상을 ‘change aversion(변화를 싫어하는 것)’이라는 용어로 사용하고 있습니다.

작은 변화를 적용하는 A/B 테스트라면 굳이 이런 걱정은 하지 않아도 될 것입니다. 하지만 어느 정도 큰 규모의 변화를 적용하는 케이스이고, 정량적인 데이터 뿐 아니라 정성적인 데이터(사용성, 만족도 등)의 중요성도 큰 변화/실험을 계획하고 있다면 첨부한 링크를 한 번쯤 꼭 읽어보시길 바랍니다. 변화의 레벨에는 어떤 것이 있고, 어떤 경우에 큰 change aversion을 예상할 수 있고, 패턴(사용자의 반응)에 따라 어떻게 대응을 해야 할지도 알려줍니다. Change aversion을 줄이기 위한 여러가지 방법도 설명해주고 있구요.

Change aversion은 인간으로서 자연스러운 일입니다. 그렇기에 완전히 피할 순 없어도 최소화 할 수는 있습니다. 첨부된 링크 한 번 읽어보세요. 나중에 피가 되고 살이 될 내용이라 생각합니다. 저만해도 당장 ‘지금’ 경험하고 있는 것이니까요.

* 궁금해 하실까봐 첨언하자면, 베타 테스트 시 change aversion을 확인하지 못했던 이유는 사용자들이 이미변화가 올 것을 알고 있었기 때문이죠. 테스트를 자발적으로 신청한 것이니까요. 그리고 일단 새 디자인의 제품을 사용해보고 원하지 않으면 베타 테스트에서 나갈(opt-out) 수 있도록 구성을 해놓았었습니다. 지금 진행하고 있는 ‘릴리즈’는 opt-out이 불가능한 일괄 변경이기 때문에 저항이 더 큰 것이라고 보구요.

** 이 글은 Publy News에 올린 글입니다.

RICE – 일에 우선순위를 매기는 방법

Inyong SuhLeave a comment

퍼블리 뉴스에 큐레이션해서 올린 글입니다.

원문 : RICE, simple prioritization for product managers

<RICE – Simple prioritization for PMs>

Product Manager의 중요한 역할 중 하나가 바로 어떤 프로젝트나 태스크의 우선순위를 결정하는 일이라 볼 수 있습니다. 이게 쉬운 일은 아니죠. 같은 프로젝트라도 상황에 따라(예, 코로나 전/후), 회사의 전략 방향에 따라, 조직의 목표에 따라, 주요 고객이 누구냐에 따라, 개발팀의 리소스나 디펜던시(다른 팀과 일이 엮여있는 정도) 등에 따라 그 중요성이 달라질 수 있습니다.

그렇기에 ‘이것만 따르면 돼’라고 할 수 있는 방법은 없습니다만 그래도 일반적으로 사용될 수 있는 프레임워크가 여러 가지 있습니다. 이번에 소개할 글은 그 중 RICE framework에 대한 설명입니다. 우선순위를 매기는데 있어 중요한 4개의 단어의 앞글자를 따서 RICE라고 이름 붙였으며 각 단어의 의미는 아래와 같습니다.

  • Reach : 얼마나 많은 수의 사용자에게 영향이 미치는지
  • Impact : 그 임팩트의 크기는 어떠할지
  • Effort : 이를 수행하는데 있어 드는 노력이 얼마나 클지 (시간, 인력)
  • Confidence : 내가 측정한 위 R, I, E의 값에 얼마나 자신이 있는지(예, 구체적인 증거가 있다면 자신감이 높음)

그리고 최종적으로 RICE 점수는 = R * I * C / E 로 계산을 합니다. 이 결과가 큰 순서대로 더 중요한 일이라고 보는 거죠.

사실 모든 일을 이렇게 계산할 수 있다면 좋겠지만 각자의 상황에 따라 이런 프레임워크가 유용할 수도 있고 아닐 수도 있습니다. 저의 경우는 우선순위를 계산할 때 위와 같이 점수를 매기는 방식을 활용하는 경우도 있지만 아닌 경우가 더 많습니다. 여러분들도 일단 이와 같이 우선순위를 계산할 수 있는 프레임워크가 있다는 것만 알아두고 본인의 상황에 맞게 적절히 활용하셨으면 좋겠습니다.

  • 저의 경우는 위의 값과 데이터를 쭉 늘어놓고 디펜던시, 리소스 상황, 현재 회사의 방향, 앞으로 몇 개월 동안 예상할 수 있는 장애물/난관 등 여러가지를 고려해서 우선순위를 결정합니다. 그리고 이렇게 결정한 로직을 제 매니저 그리고 제 개발팀, 디자이너, 마케팅 담당자에게 잘 설명하여 이해를 얻어내려 합니다. (물론 더 복잡한 경우도 많지만 지면상 생략합니다)