Product Management (career)

Publy -제품 업데이트 하기 전 PM이 반드시 체크해야 하는 것들

정말 오랜만에 (social media 포스팅이 아닌) 글을 썼습니다.  Publy에 “제품 업데이트 하기 전 PM이 반드시 체크해야 하는 것들”라는 제목으로 글을 썼습니다. 제 지인들 중 Publy 유료 회원이신 분이 얼마나 계실지 모르겠지만, 혹시 access 가능하시면 보시고 피드백 주시면 고맙겠습니다. Publy에 관심이 있으시면 이 기회에 회원 가입을 하시면 되고(유료입니다), Publy 회원이 아니시라면 아래 커리어리 글을 읽어도 좋아요. 짧은 버전이라 보시면 됩니다. 왜 대규모 업데이트는 항상 욕을 먹는지, 그것을 극복하려면 어떻게 해야 하는지에 대한 내용입니다. 재작년 말에 둘째를 출산하고 작년 초에 이직을 한…

Keep reading

첫 출판 – 집필과 출판 관련한 FAQ 및 깨달음

2020년 10월, 내 인생의 첫 책을 출판했다. 2019년 여름부터 출판사와 얘기를 시작했으니 출판 계약서를 쓴 시점부터 따지자면 1년이 넘었지만, 실제로 본격적으로 집필을 시작한 시점부터 따지면 1년 혹은 그보다 조금 짧은 기간 안에 집필 및 출판을 마친 것이다. ‘책을 출판하는 것’은 내 인생의 버킷리스트 중 하나였다. 나 뿐 아니라 본인 이름으로 된 책을 집필하고자 하는 분들이 꽤 될 것이라는 생각이 들었다. 그래서 오랜만에 내 업무(해외에서 product management 업무) 관련된 얘기가 아닌 집필과 출판 관련된 얘기를 해보려 한다. 다만 아래 내용은 나…

Keep reading

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

Cracking the PM Interview라는 책을 공저한 Jackie Bavaro의 미디움 글입니다. 본인과 본인 팀원들의 경험을 통해 배운 경력 개발을 위한 중요한 스킬을 정리했습니다. 사실 논리정연한 글이라기보다는 본인이 생각한 중요한 스킬을 쭈욱 나열한 글입니다. 제가 봤을 때 이 글을 한 문장으로 요약하자면 다음과 같습니다. 다른 직무로 전환하는 경우가 아닌 이상 직무 내에서의 경력 개발은 담당 업무의 범위를 넓히고(increasing scope), 더 복잡한 문제(complexity)를 해결하고, 더 자율적(autonomy)으로 일하고, 더 큰 임팩트(impact)를 내는 방향으로 발전해야 합니다. (“Career growth within a role is usually about increasing…

Keep reading

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

이 글은 제가 커리어리(퍼블리 뉴스, 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 개발자 – 으로 팀을 꾸렸습니다) 짧게 요약하자면 아래와 같습니다. 본문 자체도 그리…

Keep reading

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

‘PM의 정의, PM이 해야 할 일’등에 대해서 늘 논쟁이 많죠? 함께 일하는 디자이너, 데이터 과학자, 개발자 등에 비해 역할과 책임을 한 마디로 정의하기 어려운 직무입니다. 정답도 없구요. 그러면 이런 PM들을 ‘매니징’한다는 것은 어떨까요? 링크된 글의 저자에 따르면 이는 ‘모호함’의 제곱(ambiguity² ; 직역은 늘 어색합니다..)입니다. 😂 이번 글은 현재 Shopify의 VP of Product인 Brandon Chu의 글입니다. 여러 명의 PM을 매니징해 본 경험이 있는 그가 밝히는 ‘효과적으로 PM을 매니징하기 위한 프레임워크’를 소개합니다. 1. The mental model for managing PMs — 그들은 사업가이고 당신은…

Keep reading

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

개인적으로 PO/PM 직군으로 이직은 딱 두 번 해봤다. 처음은 삼성전자(상품 기획 및 해외 마케팅)에서 쿠팡으로 Product owner라는 직무로 이직했을 때, 두번째는 암스테르담에 있는 Booking.com으로 Product owner라는 같은 직무로 옮겼을 때다. 쿠팡으로의 이직의 경우 S/W Product management에 대한 경험이 전무한 상황에서의 이직이었고 생애 첫 이직이었기 때문에(삼성전자가 첫 직장) 적응을 위한 전략이고 뭐고 없었다. 모든 걸 맨땅에 헤딩하면서 배웠다. Web/인터넷이 어떻게 동작하는지부터 시작해서 인터넷 업계, 개발, 디지털 마케팅 관련한 용어과 개념을 배우면서 동시에 Product management도 사수나 주위 사람들을 통해 배웠다. 당시 Stakeholder였던…

Keep reading

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

최근에 이직을 위해 10개 이상 회사와 연락을 주고 받았고 그 중 몇 군데와는 실제 내 매니저가 될 사람(보통 hiring manager)을 포함한 다른 Product manager(PM)들과 여러 차례 인터뷰도 진행하였다. 결과를 떠나 3~4년만에 하는 인터뷰는 스트레스이기도 했지만 지루했던 일상에 refresh가 되는 요소이기도 했다. 모든 회사는 다른 문제를 풀기 위해 노력을 하고 있기 때문에 다양한 회사와 인터뷰를 한다는 것은 다양한 고객의 문제에 대해 내 나름의 기준에서 고민해 볼 수 있는 기회이기도 하기 때문이다. 인터뷰어와의 대화도 즐거웠다. 인터뷰를 하다보면 나와 맞을 것 같은 회사와…

Keep reading

Product manager와 Product owner (3편)

* 이 글은 ‘Product owner, Product manager’의 세 번째 글로 아래의 두 글을 먼저 읽는 게 좋습니다. Product owner? Product manager? Product manager와 Product owner (2) 위 두 글을 짧게 요약하자면, 첫번째 글에서는 PO(Product Owner)와 PM(Product Manager)이 거의 동일한 일을 한다고 주장했으나, 두번째 글에서는 Tomtom과 같은 회사의 예에서 볼 수 있듯이 PM과 PO이 서로 다른 역할로 함께 일하는 케이스도 있다고 했다. 이번 3편(아마 마지막 편이 될 것 같아요)에서는 최근에 여러 회사와 인터뷰를 하면서 발견한 또 다른 조직 구조들을 포함하여 정리해…

Keep reading

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

사람은 대개 변화를 두려워하죠. 익숙한 것을 좋아하고 편안해하구요. 어느날 아침 출근하니 매일 사용하던 업무용 툴의 디자인이 하루 아침에 확 바뀌어 있다고 상상해 보세요. “와 엄청 예뻐졌네. 엄청 사용하기 편해졌겠어!”라는 생각보다는 “아 이제서야 좀 익숙해졌는데 또 바뀌었어? 아 그 XX메뉴는 어딨는거야? 바빠죽겠는데 하나씩 다 눌러봐야 하나?”와 같은 반응일 거에요. 얼마 전에 저도 업무 중에 같은 경험을 했습니다. 이번엔 제가 ‘사용자’가 아닌 그 변화를 주도한 ‘제품팀’이었다는 점이 다르지만요. 모든 맥락을 설명하자면 엄청 길기에 간단히 요약하자면 : “사용자들의 불편한 점을 개선하고자 새로 디자인한…

Keep reading

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

퍼블리 뉴스에 큐레이션해서 올린 글입니다. 원문 : RICE, simple prioritization for product managers <RICE – Simple prioritization for PMs> Product Manager의 중요한 역할 중 하나가 바로 어떤 프로젝트나 태스크의 우선순위를 결정하는 일이라 볼 수 있습니다. 이게 쉬운 일은 아니죠. 같은 프로젝트라도 상황에 따라(예, 코로나 전/후), 회사의 전략 방향에 따라, 조직의 목표에 따라, 주요 고객이 누구냐에 따라, 개발팀의 리소스나 디펜던시(다른 팀과 일이 엮여있는 정도) 등에 따라 그 중요성이 달라질 수 있습니다. 그렇기에 ‘이것만 따르면 돼’라고 할 수 있는 방법은 없습니다만 그래도…

Keep reading

Something went wrong. Please refresh the page and/or try again.