출처 : Practical Ways to Earn Respect as a Product Manager
*PM에 대한 다양한 의견이 존재함
“테크 업계에서 반드시 필요하다”
“코드를 짜거나 디자인을 하는 등 실질적인 업무는 하지 않는 overhead에 불과하다”
“(실질적인 업무를 하지 않으므로) 오히려 업무에 악영향을 미칠 수 있다”
=> 늘 존재 증명을 위해 싸워야 하는 프로덕트 매니저
1.극단적인 정직함 - 무언가 모를 때 인정할 것
특히 엔지니어 동료에게 존경받지 못하는 가장 빠른 방법은 모르는 걸 아는 척 하는 것.
자신감은 무언가 알고 있을 때뿐 아니라 모르는 것에 대해 어떻게 표현하느냐에서 빛날 수 있음.
ex) 기술적인 백그라운드가 없는 시니어 제품 디렉터 -> 논의가 기술적인 내용으로 확장됨 -> 논의 마무리 단계에서 (non-technical) 전반적인 내용 요약 및 핵심 챌린지 공유를 솔직하게 요청함 -> 동료들의 리스펙을 얻음
2.도메인 전문성
Q.프로덕트 매니저가 되기 전에 어떤 일을 했나요?
A.고객대응팀 리드, 시인, 중고차 영업맨, 전략 컨설턴트, 하드웨어 엔지니어, 솔루션 설계자 등등
PM의 커리어는 상당히 다양함. 그 어떤 회사도 똑같지 않다는 점이 PM 역할에 역동적으로, 도전적으로 만듦. 기술 자체는 어느 업종에서든 동일할 수 있으나 프로덕트는 같은 업종에서도 서로 다를 가능성이 높음 -> 업계에 대한 이해도가 꼭 필요함.
특정 도메인 경험 없이 PM 역할을 시작하는 게 굉장히 도움이 될 수 있음 (관행이나 관습을 모른다는 걸 전략적인 이점으로 활용할 것)
3.투명성
PM은 이해관계자들과 협의하는 데에 많은 시간을 보냄.
어떤 의사결정이 왜 이뤄졌는지, 혹은 왜 그 의사결정이 우선시 되지 않는지 투명하게 공유할 때 PM으로서 리스펙을 얻을 수 있음.
로드맵과 특정 핵심 지표를 왜 추구하는지 투명하게 공유할 때, 프로덕트 작업에 동의하지 않는 내부 분위기를 뛰어넘을 수 있음. 동의를 얻어야 한다는 뜻이 아님. 의사결정에 대한 이유를 명료화해서 그 결과로 리스펙을 얻는 것.
4.데이터에 대해 ‘생각’할 것
데이터를 참고하는 것과 데이터에 이끌리는 것에는 미묘한 차이가 있음. PM이 무비판적으로 데이터를 따를 경우 프로덕트 전반적인 경험을 해치는 의사결정을 할 수 있음.
ex) 넷플릭스 자동재생 기능
자동재생 기능으로 인해 시청시간이 더 늘어남 -> 시청과 관련된 핵심 지표로 보고 이 숫자를 높이는 데에 몰빵할 수도 있음 but 마니악하게 숫자만 좇을 경우 전반적인 경험에 영향을 끼칠 수 있음.
Q.지나치는 것만으로도 영상이 풀사운드로 자동재생 되는 게 짜증나는 경험을 준다면?
Q.한 영상을 보고 다음 에피소드로 넘어가기 전에 잠시 쉬고 싶어하는 유저가 있다면?
Q.디지털 중독에 대한 리스크는 없을지? 어린 시청자에 대한 책임이 발생하지 않을지?
데이터에 이끌리는 PM : 핵심 지표 달성을 위해 기능을 도입
데이터를 참고하는 PM : 의사결정 이전에 위 질문을 고려할 것
이런 논의 과정을 거치는 것이 어려울 순 있지만, 프로덕트 빌딩에 대해 깊이 고민하는 PM에 대한 리스펙으로 이어질 가능성이 높음.
5.때로는 직관에 기반한 전략을 펼치는 것
데이터를 참고하는 ‘프로덕트 인간들’의 특징 = 직관에 따라 의사결정을 실행에 옮김.
데이터 및 유저 리서치로 무장할 순 있지만, 그게 성공을 보장해주는 건 아님.
ex) New Coke
1985년 4월, 펩시에 대항해 코카콜라에서 내놓은 신제품. 20명 이상의 소비자 조사를 진행함. 이들은 신제품을 기존 코카콜라보다 선호함.
결과는?
-매일 8천통 이상의 항의 전화를 받음.
-부모들이 시위를 벌임. (우리 아이에게 옛 코카콜라 맛을 돌려내라!)
존경받는 PM은 제품 의사결정에서 ‘감각’을 발휘해야 함. 시간을 들여 시장과 제품, 유저에 대한 이해와 경험을 쌓을 때 생기는 감각.
Q.기존 소비자들이 코라콜라 레시피를 중요하게 보는가? 맛을 근본적으로 바꾸면 혐오할까?
Q.제품의 맛을 바꾸지 않으면서도 펩시의 위협을 이겨낼 다른 방법은 없을까?
제품 의사결정 과정에서 이 감각을 동원하고, 내부에 이를 공유하여 존경을 받을 수 있음.
6.흔들리지 말 것.
PM이 인내심을 갖고 반대 의견을 경청해야 하는 타이밍이 있음. (ex: 전략적 의사결정, 제품 구축의 다음 단계)
하지만 PM이 불도저처럼 밀고 나아가야 하는 타이밍도 있음.
무례하게 굴라는 의미가 아님. 모두가 좋아하진 않는 의사결정이라도 그걸 방어하며 밀고 나아가는 자신감이 필요함.
ex1 : 제품 첫 회기에 포함되지 않은 작업을 굉장히 명료하게 제외할 것.
ex2 : 동료나 이해관계자들에게 명료한 피드백을 제공할 것.
ex3 : 무언가 해내기 위해 몰입하고 있는 팀 동료를 지적으로부터 방어할 것.
7.실행할 것.
멋져 보이는 프레임워크나 로드맵 템플릿에 얽매이지 말 것.
ex : 스트라이프 CEO가 말하는 회사의 리듬 = 내달리기(‘run’)
-적절한 사람을 채용하기 기다리지 말고 프로젝트를 진행시킬 것
-분기 계획에 맞추기 위해 기다리는 대신 지금 가치있는 일을 해낼 것
-회의 때마다 자문할 것. “더 민첩할 수 있었을까? 실행에 필요한 최소한의 요건은? 더 빠르게 수행할 수 있을까?”
무언가 제대로 먹힐지 확인하는 최선책은 최대한 빨리 시도해보는 것. PM이 몸소 실천할 때 리스펙을 얻을 수 있음.
8.하겠다고 말한 것을 하는 것.
쇼피파이의 프로덕트 원칙 중 하나는 GSD(Get Shit Done) -> 일단 실행하는 것.
특히 완료하는 것만큼, 하겠다고 말한 것을 하는 습관이 중요함. 한다고 해놓고 하지 않을 시 급격하게 리스펙을 잃게 됨.
당신이 약속을 이행하는 만큼 배터리가 채워지는 것과 같음.
[함께 읽으면 좋은 아티클]
토스 팀이 남들보다 3만 시간 덜 일하고 더 잘 나가는 방법
배달의민족 CEO가 말하는 ‘함께 일하고 싶은 개발자의 기준’
👇매주 나를 돌아보고 용기 충전! 이오레터 구독하기👇