제품 관리자 역할이 실수임

• 소프트웨어 제품 회사가 product-led를 “PM이 모든 결정을 내리는 구조”로 오해하면, 예외적 창업자형 리더에게나 맞는 모델을 평범한 커리어 PM에게 적용하게 됨
• 단일 리더에게 제품 통제권을 주는 방식은 그 자체보다 누구에게 맡기느냐가 핵심이며, 비전·카리스마·기술력·강한 신념을 가진 드문 인물을 전제로 함
• 평범한 PM에게 과도한 권한이 주어지면 데이터, 프레임워크, 승인 절차, 회의, 역할 체계가 판단 도구가 아니라 책임 회피와 정치의 방어막이 됨
• 이런 흐름은 뛰어난 사람을 떠나게 만들고, 회사는 낮은 위험의 과제와 내부 프로세스에 갇혀 비전과 재능을 잃어감
• 대안은 PM 직함 중심 구조가 아니라, 각 영역에서 기술과 품질에 집착하는 사람들을 한 팀으로 묶어 제품 발견·관찰성·엔지니어링·디자인·비즈니스·도메인 지식을 함께 다루게 하는 방식임

---

product-led를 PM 독점 구조로 오해하는 문제

• 많은 소프트웨어 제품 회사는 소프트웨어 제품 제작 경험이 강한 사람보다 자금 조달과 대상 산업 이해에 능한 사람이 창업하는 경우가 많음
• 이런 창업자는 산업 경험과 관계를 바탕으로 회사를 시작하지만, 직접 모든 의사결정을 이끌면 도메인 전문가의 확신이 회사에 해가 될 수 있음
• 일부 창업자는 자신이 위험할 수 있음을 인정하고 의사결정을 맡길 사람을 채용함
  • 이때 “서비스 조직이 아니라 제품 회사가 되어야 하고, 제품 회사는 product-led이므로 PM이 책임져야 한다”는 식의 오해가 생김
  • 여기서 product-led는 PM이 모든 결정을 내린다는 뜻이 아님
• 반대 의견이 나오면 Amazon, Apple, Tesla 같은 훌륭한 회사도 한 사람에게 통제권을 위임한다는 반박이 자주 등장함
• 훌륭한 회사 중 다수가 단일 인물에게 통제권을 맡기지만, 모든 훌륭한 회사가 같은 모델을 쓰는 것은 아님

단일 의사결정자 모델의 전제

• 회사 통제권을 한 사람에게 주는 모델은 틀린 방식이라기보다, 누구에게 주느냐에 성패가 달려 있음
• Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo 같은 인물은 비전, 카리스마, 자신감, 회복력, 탁월함으로 대중의 숭배를 받음
• 이들은 대체 현실을 상상하고, 자신의 일에 완전히 몰입하며, 의지로 큰 변화를 만들어내는 유형임
• 이런 인물이 실제로 있다면 단일 통제권 모델은 강력하게 작동할 수 있음

예외적 인물은 일반적인 PM이 아님

• 위대한 인물들은 제품 관리자가 아니었음
  • 예술가, 수학자, 발명가, 과학자, CEO였고, 여러 역할을 동시에 가진 경우도 있었음
• 이들은 OKR, KPI, 데이터, 타인의 의견보다 자신의 비전과 기술에 집착했음
• 예외적 인물은 강한 의견, 큰 자아, 자신만의 방식, 거친 면, 평범함에 대한 경멸을 가질 수 있음
  • 이런 특성 때문에 일반 회사에서는 고용하기 어렵고, 본인도 대부분의 회사에서 일하고 싶어 하지 않을 가능성이 큼
• 위대한 사람을 찾고, 방해하지 않고, 그 강도를 견딜 수 있다면 제품과 회사 통제권을 맡길 수 있음
• 현실적으로는 그런 사람을 찾기 어렵고, 그들이 함께 일하려 하지 않거나, 회사가 그들의 자아와 강도를 견디지 못할 가능성이 큼

평범한 PM에게 위대한 인물용 구조를 적용할 때

• 가장 큰 실수는 예외적 인물이 필요한 운영 모델을 예외적 인물 없이 도입하는 것임
• 회사가 편하게 채용할 수 있는 커리어 PM은 대개 그런 수준의 인물이 아니라고 비판함
  • 비즈니스 하수인, 프레임워크 광신자, 주제 전문가, 기업 사다리를 오른 전직 제작자, 지표 중독자, MBA 출신 등으로 표현됨
• “product-led”를 PM이 모든 결정을 내리는 것으로 이해하고 커리어 PM을 고용하면 치명적일 수 있음
• 이 PM들은 비전, 카리스마, 전문성, 강한 신념, 기술 역량이 부족하기 때문에 안전하게 움직이고 정치적으로 행동함
• 자신의 부족함을 알기 때문에 성과는 차지하고 책임은 피하려는 행동이 반복됨

데이터와 프로세스가 방어 수단이 되는 과정

• 첫 단계는 데이터 기반 의사결정의 무기화임
  • 어떤 주장에도 뒷받침 데이터를 찾을 수 있다는 점을 인정하지 않고, 데이터상 자신의 결정만 합리적이라고 포장함
  • 일이 잘못되면 시장, 데이터 품질, 회사의 불운을 탓하고 자신의 책임은 아니라고 주장함
• 다음 단계는 모든 것에 프레임워크와 역할을 도입하는 것임
  • 18단계 커리어 프레임워크, 분기별 성과 평가, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe 등이 등장함
  • 프로세스를 따르지 않음, 데이터 기반이 아님, 문서가 부족함, 문서가 최신이 아님 등이 비난의 이유가 됨
• 조직에는 Director of KPIs, Deputy Director of Product Operations, Global Head of Digital Whiteboard Solutions 같은 역할이 생김
• 모든 것에 승인이 필요해지고, 어떤 프로세스나 영역도 한 사람이 완전히 통제하지 못함
  • 큰 위원회에서는 누구나 “no”를 말할 수 있지만, 아무도 완전히 “yes”를 말하지 못함
• 회의도 폭증함
  • 상태 보고, 정렬 회의, 1:1, 스태프 회의, 전략 논의, 맥락 설정, 릴리스 go/no-go, 프로젝트 보고 등이 늘어남
• 마지막 단계는 나쁜 사람을 많이 채용하는 것임
  • 위협이 되지 않는지를 기준으로 채용하고, 탁월함의 흔적은 거절 사유가 됨
  • 이상적인 채용자는 반대 의견이나 품질에 대한 관심 없이 지시받은 일을 그럭저럭 해내는 만능형 인물이 됨
  • PM 수가 급증하고, 팀과 영역마다 PM 계층이 생겨 같은 행동을 반복함

조직이 잃는 것

• 평범한 사람이 권한을 잡는 흐름이 시작되면, 탁월한 사람은 결국 떠남
  • 평범한 독재자에게 밀려나거나, 환경을 견디기 어려워 스스로 떠남
• 일의 속도는 멈춰 서고, 무언가를 실행하는 일이 고통스럽고 큰 약속이자 위험한 시도가 됨
• 거대한 비전은 비현실적인 것으로 취급되어 빠르게 버려짐
• 회사가 하는 일은 낮은 곳의 열매와 안전한 선택으로 제한됨
• 자신의 기술에 열정이 크지 않은 사람도 고통을 느끼고 떠나며, 남을 만큼 무감각한 사람들은 문제를 더 악화시킴
• 회사는 최고의 인재를 잃고, 비전을 잊고, 내부 지향적으로 변하며, 무의미해짐
  • 최선의 경우 어느 시점에 죽고, 최악의 경우 열정적인 사람을 자기 일을 싫어하는 좀비로 만드는 반쪽짜리 생존 상태가 됨

대안은 일상적으로 뛰어난 사람들의 팀

• 예외적 인물을 찾아 고용하고 통제권을 맡기며 그 강도를 견디는 것 말고도 성공적인 제품 회사를 만들 수 있음
• 대안은 일상적으로 뛰어난 사람들을 고용하는 것임
  • 각자는 어떤 영역에서 뛰어나야 함
  • 자신의 기술에 집착하고 품질에 의해 움직여야 함
  • 서로의 탁월한 영역이 최소한으로 겹치도록 팀을 구성함
• 개인별 책임을 잘게 나누기보다, 이들이 좋아하는 일을 즐겁게 하도록 두고 시간과 기술을 회사에 쓰게 함
• 이런 사람들도 도전적이고, 고집 세고, 자아가 강하고, 특이하고, 변덕스러울 수 있음
• 좋은 문제를 주고 훌륭한 일을 할 수 있게 하면 회사 성공에 완전히 헌신함

리더와 PM이 있어야 할 자리

• 리더를 완전히 포기할 필요는 없고, 팀 리드를 없애고 영역 리드를 외부-내부 조정자로 둘 수도 있음
• 각 영역에 책임 리더를 둔다면, 그 역할에는 위대한 사람에 가까운 인물을 배치해야 함
  • 비전, 카리스마, 강도, 열정, 극단적인 행동 면에서 Jobs, Musk, Bezos에 가까운 사람이 해당함
• 단기적으로 편하고, 지시를 잘 따르고, 관심을 덜 요구하는 사람을 책임자로 세우면 앞서 말한 상황에 빠질 위험이 있음
• 전통적 의미의 PM 역할은 잘 작동하는 회사에서 자리가 없다고 봄
• 다만 제품 발견, 제품 관찰성 등 전통적으로 PM에게 맡겨진 영역에 집착하는 사람은 필요함
  • 이런 사람들은 PM 직함을 가진 적이 있을 수 있고, 그 자체는 문제가 아님
  • 채용 이유는 직함이 아니라 집착과 강점임
  • 이들을 별도 PM 역할에 두기보다 엔지니어링, 디자인, 성능, 비즈니스, 도메인 지식에 집착하는 사람들과 한 팀에 배치함

PM만의 문제가 아님

• 비전, 카리스마, 열정, 기술 역량, 의지력이 없는 사람이 책임자가 되면 같은 문제가 생김
• PM에 초점을 맞춘 이유는 소프트웨어 제품 개발에서 product manager 직함을 가진 사람을 책임자로 세우려는 경향 때문임
• 일부 PM은 정말 예외적이며, 두 모델 모두에서 매우 잘할 수 있음
• 그러나 그런 PM이 배경이 다른 훌륭한 사람보다 반드시 더 잘하는 것은 아님
• 그런 PM은 아주 작은 소수이고, 대부분의 커리어 PM은 탁월함으로 리드할 능력에 근접하지 못한다고 봄

[GN⁺]

Hacker News 의견들

• 지금 회사에는 똑똑한 사람이 많지만 여러 이유로 제품 관리자가 없고, 그 결과 제품 관리자가 해야 할 일이 그냥 안 됨
  고객 관계 유지, 사용자 인터뷰, 잠재 기능 발굴, 리더십 설득, 리소스 배분을 위한 정치 같은 일을 하고 싶어 하는 엔지니어는 거의 없음
  이전 회사에서는 제품 관리자 3명 중 2명은 무능해서 해고됐지만, 1명은 정말 뛰어났고 그 사람의 일부 시간만으로도 지금 회사가 2년 넘게 한 것보다 더 많은 일을 1년 안에 해냈음
  좋은 제품 관리자가 충분하지 않다는 점에는 동의함. 좋은 제품 관리자가 될 사람 수는 인구에 선형으로 비례하지만, 소프트웨어 산업은 지수적으로 폭발해서 실제 훌륭한 PM보다 100배 많은 PM 역할이 필요해졌다고 봄

  • 아, 그게 제품 관리자가 해야 하는 일이었군요. 예전 회사에 제품 관리자가 도입됐을 때는 그런 일을 거의 안 했고, 고객과 이야기하지도 않았음
    기술적이지도 않아서 Jira 티켓을 관리하지 않았고, 리더십 관리는 대체로 매니저들이 맡았음
    그 제품 관리자들은 주로 회의하고, 리더십과 이야기하고, 엔지니어와 이야기하고, 문서 쓰고, 길어진 스프린트 계획 회의를 주재했던 것 같음
    고객·사용자·리소스 문제를 다루는 제품 관리자라면 훨씬 가치 있을 수 있겠다고 봄
  • 전부 맞는 말처럼 들림. 20년 엔지니어로 일하다가 엔지니어링 매니저가 됐고, 작년에 첫 PM 역할을 맡았는데, 20년 된 소프트웨어 회사가 좋은 제품 관리를 한 번도 해본 적이 없어 상태가 끔찍함
    “우리는 엔지니어링 우선 회사”라는 말을 계속 들었지만, 실제로는 엔지니어링 팀들이 마음대로 최신 기술만 좇았다는 뜻이었음
    주요 제품이 3.5개, 사실상 4.5개인데 각각 다른 기술 스택으로 만들어졌고, 레거시 요구 때문에 지원해야 하는 제품도 8개쯤 더 있음. 제품 간 표준화나 상호운용성이 없고 지식 이전도 안 돼 개발 비용이 천정부지임
    올해 두 번이나, 20년 근속 엔지니어들에게 어떤 API는 TLS 1.3만 쓰고, 다른 건 1.x고, 또 다른 건 TLS조차 요구하지 않는 게 왜 나쁜지 설명해야 했음
    고객들은 우리를 싫어함. 내 제품은 마케팅 자료를 먼저 써놓고 엔지니어들이 알아서 만들게 했음. Oracle 데이터를 parquet로 옮기는 단계 하나를 세 가지 언어와 중간 DB 두 개(MySQL과 PG)로 만들었고, Redis까지 넣으려던 걸 겨우 막았음
    다행히 2년 전 사모펀드가 인수했고 이제 돈을 벌지 못하면 끝이라는 최후통첩을 받음. 20년 된 회사가 한 번도 돈을 번 적 없는 비용 센터였고, 목표를 못 맞춰도 우리가 만든 소프트웨어 설계 참사가 사라지면 우주가 더 나아질 것 같음
  • 제품 관리는 어려운 일임. 무슨 일이 벌어지는지 이해하고 헛소리를 감지할 만큼 기술적이어야 하면서, 사람과 대화할 만큼 높은 감성 지능도 필요함
    멍청한 제품 관리자는 또 다른 업무 장부를 추적하는 유사 프로젝트 관리자가 되고, 똑똑한 사람은 비즈니스를 깊게 이해해서 승진하거나 떠남
    이 역할은 다스리기도 어려움. 때로는 남의 일로 큰 공을 가져가고, 때로는 아무 공도 인정받지 못해 커리어가 정체됨
    이 역할을 엔지니어링, 엔지니어링 관리, 일반 관리에 떠넘기면 엔지니어링 역량이 약해짐. 엔지니어를 뽑아야 한다면 그 능력을 기준으로 선발하고 외부 사람들로부터 보호해야 하는데, 팀이 상호작용까지 처리해야 하면 혼합 역량을 가진 사람을 뽑게 되고 결국 엔지니어링 면이 희석됨
  • 좋은 제품 관리자의 일부 시간만으로도 제품 관리자가 전혀 없는 회사보다 더 많이 해냈다는 건 좋은 증언임
    제품 관리자의 여력을 일부러 빠듯하게 두면 높은 수준과 비전에 집중하게 되고, 너무 깊게 들어가 쓸모없는 프로세스를 만들거나 기능을 과하게 정의하는 일을 피하게 하는 강제 장치가 될 수 있음
  • 그런 것들을 무시한다면 정말 그렇게 똑똑한 사람들일까? 사용자와 이야기하는 건 늘 엔지니어에게 필요한 일 목록에 들어 있었음
    10년 넘게 저금리 성장으로 부풀었던 기술 업계에서는 많은 사람이 그냥 출근만 해도 성공할 수 있었던 셈임

• 혼란스러운 글임. “PM 역할을 없애야 한다”고 하면서도 “PM이 하던 일을 전담할 사람은 여전히 필요하지만 PM이라고 부르지 말고 그냥 평범하게 뛰어난 사람이라고 하자”고 말함
  글쓴이가 PM과 나쁜 경험을 했고, MBA 얘기를 보면 그 흔적이 보이며, 그래서 아이까지 목욕물과 함께 버리려는 것 같음
  비즈니스 규모가 커지면 역할 전문화가 생기고 필요해짐. 형편없는 PM도 있고 어려운 일이지만, 우리 팀의 PM을 잃는다면 정말 실망스러울 것임

  • 특히 PM에게 회사의 통제권을 넘긴다는 식의 표현을 반복하는 걸 보면, 나쁜 PM 경험에서 나온 글처럼 들림
    내가 PM과 좋은 경험만 해본 걸 수도 있지만, 우리 회사 PM들은 고객이 뭘 원하는지와 제품이 무엇을 제공해야 하는지 파악하고, 엔지니어링 매니저와 함께 기술적으로 가능한지와 구현 여력이 있는지를 균형 있게 맞춤
    엔지니어링 매니저가 “이 일정으로는 절대 안 된다”고 말하면, PM은 제품을 위한 대안 계획을 찾아냄
  • 조직 리더십에서 아주 흔한 실패 모드는 “이 역할/대상은 쓸모없으니 없애자… 어라, 사실 필요했네. 실수를 인정하지 않도록 다른 이름으로 다시 가져오자”임
    이 글은 중간 단계를 건너뛰고 그냥 이유 없이 이름만 바꾸려는 것처럼 보임
  • 모두가 대단한 팀을 만들면 된다고 하는데, 그런 채용 마법부터 성공하기 어렵고, 그다음에는 “좋은 문제를 주면 된다”고 함
    팀이 어떤 문제를 우선순위로 삼아야 하는지는 정확히 누가 결정한다고 보는 걸까? 그게 바로 PM 역할의 핵심 책임임
    결국 그 우선순위 결정을 못 한 PM과 나쁜 경험을 한 듯함
  • 운 좋게도 정말 좋은 제품 관리자들과 계속 일해 왔고, 예외 한 명은 큰 피해를 주기 전에 오래 버티지 못했음
    다만 그 사람 때문에 내가 참석한 회의 중 가장 어색한 회의에 들어가야 했는데, 처음부터 끝까지 한 시간 내내 제품을 전혀 이해하지 못한다는 사실을 상위 관리자 앞에서 드러냈고, 그 상위 관리자는 제품을 이해하고 있었음
    좋은 PM들은 고객이 원하는 것, 우리가 제공할 수 있는 것, 현실적인 일정, 법무와 비즈니스 이해관계자 대응을 이해해서 많이 도와줌. 나는 그들이 기술 측면을 확인해야 할 때 도와줌
    팀에는 만들 아이디어나 제품·운영 경험을 개선할 방법이 부족한 경우가 드묾. 제품 관리자는 올바른 것을 만들게 하려는 사람임
  • MBA 과정에 업계 경험 전제 조건이 있었으면 정말 좋겠음. 일부는 이미 그런 걸 알지만 더 많아져야 함
    나는 IT 경력 20년의 PM이고, 지식과 공식적인 비즈니스 이해를 얻고 앞으로 성장하는 데 도움이 되도록 MBA를 고민 중임
    나와 비슷한 PM들은 MBA를 받자마자 군대식 표현을 빌리면 헛짓거리 게임을 시작하지 않음
    문제는 고등학교, 대학, MBA, 관리직으로 곧장 간 사람들임. 학부 중간의 짧은 인턴십 정도를 빼면 현장 경험이 하루도 없는 경우가 많음

• 이상한 글임. 많은 말을 동원했지만 결국 “성과 낮은 사람을 뽑으면 회사에 해롭다”는 말 아닌가 싶음
  대안도 “좋은 사람을 뽑되 PM 역할로는 뽑지 말라”는 식임
  스스로를 Steve Jobs라고 생각하는 PM과 나쁜 경험을 한 사람이 쓴 글처럼 읽힘. PM도 그냥 보통 사람인데, 그 직함을 가진 사람이 전부 특권의식 있는 인간이라고 가정하는 이유를 모르겠음
  조직에는 수천 명의 PM이 있을 수도 있고 각자 상사가 있음. 그냥 이상한 글임

  • 그 부분은 오히려 반대로 이해했음. Steve Jobs는 엄청난 의지력으로 좋은 제품을 만든 비범한 리더였고, 그런 사람을 보통 사람 제품 관리자로 대체하려 하면 평범한 제품이 나온다는 뜻으로 읽힘
  • 나도 거의 같은 말을 하려 했음
    “제품 관리자를 뽑지 말라, 그들은 훌륭한 사람이 아닐 테니까. 대신 훌륭한 사람을 뽑아라, 그것도 한 명이 아니라 팀 전체로!”라는 식임
  • 사람을 뽑는 사람들은 낮은 성과자를 뽑는 걸 도무지 멈추지 못하는 것 같음. 특히 이런 일이 생기지 않도록 프로세스가 필요하다고 많이 말하는 사람들이 그렇음
    매일같이 낮은 성과자를 뽑는데 왜 그런지 모르겠음. 이력서 더미를 든 훈련 안 된 침팬지가 더 나은 적중률을 보일 것 같음

• PM은 아주 구체적인 필요를 충족함. 그 필요는 정량화하기 어렵지만, 좋은 PM이 없으면 모든 게 무너진다고 말할 수 있음
  보통 사용자에게 무엇이 되고 안 되는지 정보를 모으고, 임원에게 회사 운영에 필요한 일을 듣고, 업계 리더에게 산업이 어디로 가는지 파악하고, 디자인과 일하고, 이 모든 것을 실제로 만들어야 할 기능으로 정제함
  또 엔지니어링과 함께 무엇이 실용적인지, 대략 얼마나 걸릴지 판단하고, 시간이 많이 들지만 가치가 낮은 기능을 제거하며, 추정과 팀 속도가 어느 정도 예측 가능하도록 돕음
  이미 1.5명분 일을 설명한 셈임. 제품 조직을 없애면 이 모든 일이 엔지니어링 팀에 분산되는데, 팀원 모두가 그 일을 잘하지는 못함
  설령 균형을 잡더라도 한 사람이 떠나면, 채용에서 찾지도 않던 보이지 않는 공백이 생김

  • 정말 동의함. 기능하는 제품 조직 없이 일하고 싶지 않음
    많은 팀이 기능장애가 있는 제품 조직에 데인 것 같음. 그런 조직은 고객·산업·조직 측면과 단절되거나 관심이 없어 보이면서, 대신 목업을 반복하는 회의에 엄청난 시간을 태우고, 디자이너를 마이크로매니징해서 좋은 사람을 떠나게 만들고, 필요 없는 제품 회의에 엔지니어를 묶어둠
  • 프로젝트 예산 확보를 주장하고 이해관계자를 참여시키려는 일도 포함됨
  • 최근 내가 함께 일한 PM들은 주로 임원들의 욕구에만 신경 썼음. 위에서 말한 나머지 책임은 말 그대로 전부 다른 사람들이 처리했음
  • PM으로서 이 설명은 정확함. PM은 글에서 말하는 것처럼 팀에게 무엇을 만들라고 지시하는 권위주의적 의사결정자가 아니라, 팀의 가까운 동맹이어야 함
    PM은 팀과 밀접하게 일하면서 로드맵을 정의하고 고객과 비즈니스에 가장 큰 영향을 줄 일을 우선순위화함
    PM이 일을 잘하면 엔지니어들은 다음에 어떤 문제를 풀어야 하는지와 왜 풀어야 하는지를 아주 명확하게 이해하게 됨
  • 뛰어난 제품 관리가 정량화하기 어렵다는 말에는 동의하기 어려움. 창의적인 측면은 있지만, 쉽게 볼 수 있는 지표 중 하나는 단순한 기능 빙고가 아니라 전략적 경쟁 분석을 이해하는지임
    둘째로, 프로젝트에 대해 고위 경영진과 소통할 조직 내 위상이 있는지도 중요함. 두 속성을 모두 갖췄다면 좋은 상태임

• 기술 업계에서 12년 넘게 일하며 배운 건, 역할이란 조직의 바람을 표현하는 방식일 뿐이라는 것임
  누군가가 제품으로 생각하길 원하면 PM 포지션을 열고, 팀 리드를 원하면 엔지니어링 매니저 포지션을 만듦
  직함은 우리가 일이라는 RPG를 여러 각도에서 플레이하게 해주는 허구의 요소임. 결국 일터에 가져가는 것은 각자의 재능과 경험의 고유한 조합임
  어떤 사람들은 종종 이런 역할의 경계를 넘고, 그래도 괜찮음. 그들은 아이디어가 있고 자기만의 직함까지 만들어낼 수 있음
  조직은 그런 사람들이 성장하고 번창하도록 둘 만큼 영리해야 함. PM으로 성공하거나 훌륭한 일을 할 수 없다는 뜻은 아니고, 보통 조직이 합류시키는 사람을 깊이 알아볼 시간을 충분히 투자하지 못하니 미리 조리된 역할을 제공한다는 뜻임

  • 맞음. 최근 이 생각을 정말 받아들이게 됨. 역할은 누군가가 항상 특정 관점에서 생각하도록 고용하는 것임
    엔지니어도 PM 역할을 할 수 있지만, 모든 것을 PM 관점에서 생각하지는 않음. 주된 정체성이 PM이 아니라 엔지니어이기 때문임
    역할의 경계를 넘는다는 맥락에서 또 깨달은 건, 대개 한 사람의 역할에서 가장 가치 있는 부분은 명시적으로 정의되지 않은 책임이라는 것임
    설명하기 어렵지만, 사람들은 묘사하거나 정량화하기 어려운 방식으로 가치를 제공하는 경우가 많음
  • 조직은 사람들이 성장하고 번창하게 할 만큼 영리해야 한다는 데 100% 동의함. 하지만 특히 큰 조직에서는 바로 그 지점에서 많이 실패하는 걸 봄

• 전체적으로 꽤 harsh한 관점이지만, 분명 맞는 부분도 있음. 회사 안에 제품 조직이 생기면 글쓴이가 묘사한 것처럼 위원회, OKR, 검토 주기, 계획, 많은 관료주의로 흘러가는 경향이 있음
  예전에 고객 대면 세일즈 엔지니어링 역할에서 영향력으로 제품을 매우 성공적으로 이끌고 있었고, 정식 통제권을 갖게 될 거라 생각해 순진하게 제품 관리자 일을 맡았음
  막상 앉아 보니 극도로 제약된 사무직이었고 나와 전혀 맞지 않았음. 티켓과 백로그 관리, 결정을 내리는 대신 조율하기, 끝없는 PowerPoint 보고서 작성이 대부분이었고, 가장 창의적인 일은 회사가 제품 로드맵을 공식화할 프로세스를 만드는 것이었음. 6개월 만에 도망쳤음
  이 기능은 무엇이 만들어지는지 가시성을 주고 성장하는 제품의 충돌하는 우선순위를 관리하는 데 꽤 유용함. 하지만 제품의 진화 방향을 형성하거나 통제하는 일은 아님
  정렬, 필터링, 운이 좋으면 데이터 수집 기능이고, 감사 가능한 의사결정 흔적과 성숙한 의사결정의 인상을 만들어 위쪽 MBA들이 조금 더 편히 잠들게 해주는 역할임

  • 다른 관점을 보태자면, 내가 PM으로 일한 모든 B2C 회사 세 곳, 두 산업에서는 제품의 진화 방향을 만들고 통제하는 데 밀접하게 관여했음
    보통 한 달에 새 기능 제안서(PRD)를 4~12개 만들었고, 회사 규모와 필요한 프로세스 양에 따라 숫자는 달랐음
    형태는 늘 “사용자에게 현재 X 문제가 있고, 이를 해결하기 위해 Y를 만들어야 한다. Y는 이런 모습이다…”였음
    물론 조율과 커뮤니케이션의 어려움은 있지만, 언제나 다음에 무엇을 만들지 알아내기 위한 것이었음
    모든 PM 역할이 이렇지 않다는 건 이해하지만, PM이 “정렬/필터링/의사결정 성숙도 연극” 이상으로 좋아질 수 없다는 말에는 동의하지 않음
    단순히 기존 백로그의 순서를 정하는 역할이었다면, 백로그에 새로 넣을 항목은 누가 정의했는지 궁금함
  • 결국 문제는 PM 역할의 명확한 역할·책임 정의가 부족하고 책임성이 부족한 데 있음
    제품 조직이 지원자가 아니라 정치적·관료적 실체가 될 수 있다는 데 동의함
    개인적으로는 제품 역할이 엔지니어링 팀 안에 내장되고 같은 리더에게 보고해야 한다고 봄. 레벨은 논쟁 가능하지만, 그래야 나쁜 PM도 나쁜 엔지니어처럼 처리할 수 있음
    물론 회사가 나쁜 엔지니어도 내보내지 못한다면 다른 문제가 있는 것임
  • 동의함. 그래서 질문은 제품 문제에 대한 스튜어드십과 책임성을 전담 조직 없이 어떻게 효과적으로 구현하느냐임
    글쓴이는 여기에 대한 프레임워크를 별로 제시하지 않음

• 글의 해결책은 위인 이론 냄새가 남
  “엄청난 사람들은 대안적 현실을 상상하고, 일에 완전히 헌신하며, 의지력으로 산을 옮긴다”는 마지막 부분은 너무 환원적임
  산을 옮기는 건 의지력이 아니라 실제로 비전을 구현하는 아래 사람들임. 기껏해야 그 “위대한 사람”은 실제 실행자와 전문가를 움직이도록 인센티브를 정렬하는 정도임

  • MBA를 향한 전형적인 한 방도 들어 있음
  • 맞음. “기껏해야” Maxwell의 악마처럼 행동하는 셈이니 쓸모없다는 말이 됨

• 현재 PM 역할을 거의 두지 않는 대형 기술 회사에서 일하고 있어서 직접적인 느낌을 말할 수 있음
  지금까지는 복합적임. PM이 많은 조직에서도 일해 봤고 그런 조직이 별로라는 데 동의함. 하지만 결국 PM이 할 일이 여전히 필요함
  우리 조직에서는 그 책임이 공식적으로 소프트웨어 매니저와 시니어 이상 개발자에게 떨어짐
  예를 들어 시니어 엔지니어로 팀의 이니셔티브를 이끌면, PM이 하던 모든 활동을 책임져야 함. 다른 활동은 매니저나 시니어 매니저가 맡음
  개발자 입장에서는 꽤 힘듦. 개인 기여자로서 자기 일도 해내야 하는데, 다른 사람을 조율하고 일이 끝나도록 보장해야 함
  추가 업무일 뿐 아니라, 솔직히 많은 개발자는 효과적인 PM이 될 기술을 갖고 있지 않음. 보고 체계가 다른 사람들을 조율해야 하므로 팀 간 협업도 어려워짐
  이 방식은 자주 소유권 부족, 책임성 부족, 중복 노력, 틈새로 빠지는 일, 전반적 무질서로 이어짐
  다만 몇 명이 참여하는 작은 팀 내부 이니셔티브에는 잘 작동함. PM 오버헤드를 없애고 만드는 사람들에게 통제권을 주기 때문임. 하지만 더 큰 이니셔티브에도 맞는지는 확신이 안 듦

  • 다른 관점에서 보면, 개인 기여자로 자기 일도 하면서 다른 사람을 조율하고 일이 끝나게 만드는 것이 내게는 시니어/리드 엔지니어의 정의임
    많은 개발자에게 효과적인 PM 기술이 없다는 말은 맞지만, 공정하게 말하면 많은 PM도 효과적인 PM 기술이 없음
    보고 체계가 다른 사람들과 조율해야 하는 어려움은 PM에게도 마찬가지임
    핵심 차이는 “이 일을 전담 역할로 떼어낼 가치가 있는가”에 대한 판단인 듯함. 나는 엔지니어에게는 거의 항상 그럴 가치가 없다고 보는 편임

• 제목만 보고는 싫어할 준비를 했음. 전형적인 “PM은 멍청하고 회사에는 세상을 지배하는 똑똑한 엔지니어만 있으면 된다”는 글일 줄 알았음
  하지만 그런 글은 아니었고, 문제 자체는 거의 완벽하게 짚었다고 봄
  다만 해결책은 손을 휘젓듯 사라짐. “각자 뭔가에 뛰어나고, 자기 기술에 집착하며, 품질에 의해 움직이는 평범하게 위대한 사람들을 고용해 팀으로 묶고 개인 책임 없이 일하게 하라”는 식임
  듣기에는 좋지만, 실제로 100명 이상 회사에서 이 방식이 성공한 사례를 누가 댈 수 있을까? 현실에서 어떻게 작동할 수 있을지 모르겠음

  • 우리는 그렇게 하고 있지만 15명이라 해당이 안 됨
    Valve가 아주 비슷한 방식을 하거나 적어도 했던 것 같음. 직원 핸드북[0]은 예전 HN 단골이었는데 요즘은 별로 안 보임. 그들에게 잘 작동하고 있는지 궁금함
    [0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
  • 그 “해결책”은 직원 10명 미만 회사에서도 보편적으로 작동하지 않음

• 글쓴이는 정말 평범한 제품 관리자들과 일해 본 것 같음. 나는 독학 엔지니어링 배경의 PM이고, 여러 분야에서 평범한 사람들을 많이 봤음
  내 일을 주로 위험 관리로 봄. 훌륭한 엔지니어와 디자이너 팀도 좋은 제품을 출시하는 과정에서 많은 위험을 마주함
  비전을 설명해 다른 사람을 설득할 기술이 없을 수도 있고, 법무팀이 할 수 있는 것과 없는 것에 요구사항이나 제한을 걸 수도 있음
  내 일은 그런 것을 관리해 팀의 장점을 끌어내고, 팀이 정말 중요한 일인 좋은 제품을 만들고 출시하는 데 집중하도록 돕는 것임
  성공은 내가 얼마나 불필요해졌는지로 판단함. 목표는 내가 필요 없게 되는 것, 팀이 나 없이도 좋은 결정을 할 맥락·자신감·지원을 갖추는 것임
  엔지니어들이 그런 능력을 키우도록 함께 일하는 걸 좋아하고, 엔지니어링 매니저 파트너들과 각 엔지니어의 강점·약점·목표를 이해해 성장할 방법을 찾음
  이상적인 유토피아에서는 내가 필요 없을 수도 있다는 주장도 이해함. 하지만 대부분의 경우 정말 훌륭한 일을 하려면 도전과 위험에 부딪히며, 좋은 PM은 팀과 협력해 그것을 넘어서게 해주는 순가치 추가자임

  • 나도 PM이고 동의함. 내가 일을 잘하고 있는지는 팀을 위해 모든 것이 얼마나 매끄럽게 돌아가는지로 판단함
    팀이 최고의 일을 하는 데 필요한 맥락, 요구사항, 통찰, 지표, 목표 등을 갖추고, 어떤 문제를 누구를 위해 왜 풀어야 하는지 이해하게 만드는 것임
    좋은 PM은 엔지니어가 “PM은 아무것도 안 하니 필요 없다”고 생각할 만큼 환경을 잘 만들어냄. 그런 판단은 근시안적이고 솔직히 모욕적임