제품은 늘고 제품 관리자는 줄어드는 추세

 (kitemaker.co)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 제품팀에서 PM을 얼마나 둬야 하는지에 대한 논의가 Airbnb의 제품 관리 조직 재편과 PM 없이 성장하는 스타트업 사례 이후 더 커짐
  • PM이 많아질수록 제품의 사업 성과보다 프로젝트 관리와 로드맵 업데이트에 시간을 쓰는 구조가 생길 수 있음
  • 숙련된 디자이너와 엔지니어가 있는 팀에서는 PM 업무가 반드시 풀타임일 필요가 없으며, 팀당 PM 1명 모델도 상황에 따라 재검토해야 함
  • 첫 PM 채용은 창업자가 모든 주요 제품 결정에 관여하기 어려워지는 시점, 대체로 50~100명 규모와 제품팀 3~5개 수준에서 고려됨
  • PM 수를 늘리는 것만으로 제품 중심 조직이 되지는 않으며, 오히려 디자이너와 엔지니어가 가져야 할 제품 책임감을 약화시킬 수 있음

PM을 줄이고 제품 책임을 넓히는 구조

  • PM 필요 인원 논의는 Airbnb의 제품 관리 조직 재편과, PM 없이도 성장하는 스타트업 사례를 다룬 글들 이후 더 활발해짐
  • 많은 회사에서 PM은 제품을 비즈니스에 맞게 최적화하기보다 프로젝트 관리, 로드맵 업데이트 같은 업무로 하루를 채우는 경우가 많음
  • 일반적으로 제품팀 수보다 PM 수가 더 적어야 하며, 모든 팀에 PM을 1명씩 두는 구조는 제품과 팀 상황에 따라 다시 봐야 함
    • 제품 일이 많고 팀이 주니어라면 한 팀에 전담 PM이 필요할 수 있음
    • 경험 많은 엔지니어와 디자이너가 있는 팀에서는 PM 역할이 풀타임일 필요가 없거나, 그래서는 안 될 수 있음
  • 스타트업에서 첫 PM을 채용할 적절한 시점은 창업자가 모든 중요한 제품 결정에 관여하기 어려워지는 때임
    • 대체로 조직 규모가 50~100명, 제품팀이 3~5개일 때가 기준임
    • 전체 제품 전략이 이미 명확해야 하며, PM은 그 전략을 바탕으로 더 낮은 수준의 방향과 의사결정에 참여해야 함
    • 첫 PM은 주니어 PM이나 CPO보다 시니어 PM이 적합함
    • 후보자가 조직 성장에 따라 CPO 역할을 맡을 수는 있지만, 창업자가 사실상 제품 책임자 역할을 계속 해야 함

제품 중심 팀을 만드는 실천 방식

  • 제품 책임은 PM 한 명에게 모이지 않아야 하며, 디자인과 엔지니어링도 사용자와 제품 맥락을 직접 이해해야 함
    • 디자이너와 엔지니어는 제품 형성에 적극 참여하고 세부 제품 논의를 이끌어야 함
    • PM은 UX, 와이어프레임, 진행 추적, 스탠드업 운영, PRD/명세 단독 작성자가 되어서는 안 됨
    • PM의 초점은 제품 비전 표현, 올바른 문제 선택, 제품 방향 유지, 비즈니스 요구와의 정렬임
  • Michael Seibel의 “Guide to product development”는 Social Cam에서 이런 방식을 구현한 사례로 연결됨
    • 팀은 맥락과 판단 근거를 적극 공유해야 함
    • 디자인과 엔지니어링도 사용자 피드백에 접근할 수 있어야 함
    • 문제 해결은 PM 중심이 아니라 제품, 디자인, 엔지니어링의 협업이어야 함
  • 제품 지향 팀을 만들기 위한 실천 방식은 네 가지로 정리할 수 있음
    • 함께 시작하기: 티켓이나 명세를 쓰기 전, 해결책을 정하기 전, 디자인·엔지니어링·제품/창업자가 함께 논의해 진행 방식과 계획을 맞춤
    • 모두를 사용자에게 노출하기: 사용자 리서치와 사용성 테스트에 직접 참여하거나 영상 스트리밍, Lookback 같은 도구로 사용자가 제품을 쓰는 모습을 보게 함
    • 팀 관리 방식 주의하기: 닫은 티켓 수나 스토리 포인트로 성과를 측정하면 팀은 좋은 제품이 아니라 티켓 처리에 맞춰 움직이게 됨
    • PM 도구를 쓰지 않기: 사용자 피드백, 인사이트, 데이터, 명세, 로드맵이 별도 PM 도구에 갇히면 팀 전체가 제품 맥락에 접근하기 어려워짐
  • 제품 개발은 본질적으로 예측하기 어렵고, 배포 자체보다 비즈니스에 영향을 주는 올바른 것을 배포하는 일이 더 중요함
  • 대규모 제품 중심 회사에서 PM은 매우 중요하지만, 필요한 PM 수는 쉽게 과대평가될 수 있으며 PM 수 증가가 곧 제품 집중도 향상으로 이어지지는 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 엔지니어링 매니저나 기능 조직장으로서 제품 관리자들과 꽤 오래 일했고, 중견 기술 회사에서 내부 제품의 임시 PM 역할도 해봤음
    제품 관리는 회사가 하는 일 중 가장 중요한 영역에 속한다고 봄. 하지만 일이 정말 어렵고, 역량이 부족한 PM일수록 거기서 멀어져 엔지니어링 팀을 “주도”한다는 명목의 미세관리나 사내 정치로 흘러가기 쉬움
    엔지니어링과 제품 조직이 별도 지휘 체계로 나뉜 조직에서는 이 문제를 다루기 어렵고, 위로 문제를 올려도 그쪽 대역폭은 자연스럽게 매우 제한적임. EM 입장에서는 이런 PM들이 최고의 엔지니어들을 괴롭게 만들고, 결국 그들이 떠나는 결과가 자주 생김
    지금은 각 팀에 mini-CEO 형태의 PM을 심고, 기술적으로 충분하지 않다면 mini-CTO와 짝을 이루게 하는 방식이 최선이라고 봄. 정치가 끼어들 여지가 훨씬 줄고 팀워크 여지가 훨씬 커짐

    • 제품 관리자나 제품 책임자가 더 나은 제품이나 더 나은 회사를 만드는 데 순효과를 낸다고 믿지 않음
      내가 있었던 가장 성공적인 팀들은 전담 제품 역할이 없었고, 모든 결정은 개발자들이 했음
      지금은 개발자들이 평온하게 만들 수 있도록 비기술 인력이나 어설프게 기술적인 사람들까지도 개발자 앞길에서 치우는 편이 최선이라고 봄
    • 반도체 업계에서 35년 있었지만, 내가 멍청한 건지 정치라는 걸 정말 잘 못 보겠음
      내가 보는 건 사람들이 자기 선택지를 주장하고 지지를 얻으려는 모습임. 사람들이 불평하는 그 정치를 본 적은 없음. 내가 운이 좋은 건지도 모름
      정치라는 게 기술적으로는 틀렸지만 더 설득력 있게 주장하는 사람을 뜻하는 건가? “정치”가 뭔가? 아니면 내가 아직 충분히 높은 직급이 아닌 건가, senior principal인데도
    • 이 자리에서 말하는 mini-CTO는 사실상 아키텍트임

  • 이 글과 이 주제를 분석하려는 많은 사람들이 핵심 요소 하나를 놓치고 있음. 바로 인센티브임
    많은 개발자들은 기술 자체, 즉 코딩, 복잡한 기술 문제 해결, 효율적인 해법 만들기에 더 열정적임. 승진, 보너스, 인정 같은 공식 보상도 기술적 성취와 연결되는 경우가 많음
    개발자가 고객 조사에 40시간을 쓰면, 팀 전체에 도움이 되는 새 인증 솔루션을 개발하는 기술 성과만큼 공식적으로 인정받거나 보상받지 못할 수 있음
    이 동학을 바꾸는 일은 개발자에게 제품 관리 시간을 더 쓰라고 권하는 정도로는 안 됨. 조직이 무엇을 가치 있게 여기고 어떻게 보상하는지에 대한 시스템적 변화가 필요함
    인센티브 구조를 기술 중심에서 사용자 중심으로 바꾸면 중간·상위 관리자의 역할에 큰 영향을 줌. 그런 변화는 그들의 역할과 책임의 기반을 흔들고, 통제력과 영향력 상실로 이어질 수 있음
    그래서 이런 변화는 중간·상위 관리자의 은근하지만 강한 저항을 받을 가능성이 큼. 이들은 조직 안에서 상당한 정치적 힘과 기득권을 가진 경우가 많음

    • 그렇게 어렵지 않음. 개발자들이 자기 소프트웨어로 사람들을 직접 교육하게 하면 됨
      모든 장인 일은 실제로 닿는 순간 배우게 됨. 영화감독은 편집실에서 영화를 천 번 볼 수 있지만, 실제 관객과 처음 같이 보는 한 번이 그 천 시간보다 더 많이 가르쳐 줌
      목수는 일주일 내내 가구를 만들며 만족할 수 있지만, 진짜 순간은 그 가구가 고객 방에 놓일 때 옴. 소프트웨어도 마찬가지임
      소프트웨어 엔지니어가 사용자를 신경 쓰게 하려면 무엇이 잘 되고 무엇이 형편없는지 직접 피드백을 받아야 하고, 가능하면 자기 눈으로 봐야 함
      제대로 된 소프트웨어 엔지니어라면 일을 잘 해내는 데 어느 정도 자부심이 있음. 그 자부심이 코드, 커밋 기록, 다른 추상적 개념에만 연결되고 실제 사용자를 위해 얼마나 잘 쓰이는지는 전혀 닿지 않는다면, 애초에 어떻게 관심을 갖기 시작하겠나
    • 네 결론이 “관리자들이 이걸 싫어한다”인 게 좀 재미있음. 개발자는 코드만 써야 한다고 생각해서 이런 변화를 싫어할 개발자도 많이 알고 있음

  • 글과 거의 관련은 없지만, 블로그 글의 대표 이미지로 AI 이미지를 쓰는 요즘 흐름이 정말 미치게 함
    글을 쓸 때 뚜렷한 대표 이미지가 떠오르지 않았다면, 컴퓨터의 헛꿈을 내려받느라 내 대역폭을 낭비하게 하지 않았으면 함
    AI 이미지는 매우 가치 있는 도구라서 찬성하는 편임. 하지만 페이지의 유일한 이미지로 AI 이미지를 쓴다면 정말 그럴 만한 이유가 있어야지, 단순한 공간 채우기면 안 됨
    특히 생성된 이미지 속 모든 사람의 손가락 수조차 제대로 큐레이션하지 못했다면 더더욱

    • 글에 대해 머릿속에 분명한 이미지가 있는 경우가 많음. 다만 내가 그릴 수 없고, 사람을 고용할 예산도 없음
      이미지는 어떤 느낌을 전달하려는 목적임. 글의 추상적인 개념을 조금 더 만질 수 있는 것으로 만들려는 것임
      예전에는 그 목적에 맞는 이미지를 인터넷에서 찾아 썼음. 이제는 DALL-E로 직접 만들 수 있고, 보통 훨씬 나음
      이 이미지는 글을 보완해야 함. 글의 텍스트가 정보, 느낌, 개념을 전달하려는 것처럼 이미지도 그 일부를 해야 함
    • 동의함. 문제는 AI가 아니라 취향 없음임
      아무도 주요 인종 집단을 다 넣은 사람들이 원형으로 둘러서 서로 이상하게 웃는, 불쾌한 골짜기 느낌의 그림을 보고 싶어 하지 않음
      이런 기묘하고 영혼 없는 기업풍 그림 유행은 AI 생성이 폭발적으로 인기를 얻기 전부터 시작됐음
    • AI 이미지에만 해당하는 문제는 아님. 밈이나 관련 없는 스톡 이미지도 쓰여 왔음
      아마 검색 엔진 최적화에 대한 어떤 믿음 때문일 수 있음
    • 스톡 사진 모델이 촬영 대상에 대해 꾸는 헛꿈보다 더 나쁜가? 스톡 사진 속 사람들은 보통 자신이 대표하는 직업이나 상황에 대해 똑똑해 보이기, 바빠 보이기, 수다스러워 보이기 같은 기본 관념 말고는 거의 모름
      동시에 보기 좋아야 할 뿐임
    • 내 뇌가 스톡 사진을 자동으로 차단하는지, 이 글에 이미지가 있었다는 사실도 못 알아챘음
      그런데 여기에는 좀 웃긴 면이 있음. 블로그 템플릿이 이미지 영역을 요구하니 아무 생각 없이 뭔가 채우는 것임. 그게 너무 어려우면 밋밋한 스톡 사진을 찾고, 그것도 어렵다면 일부러 밋밋한 스톡 사진을 생성함
      영감도 없고 취향도 없는 AI 쓰레기가 곧 모든 걸 덮어버릴 것 같음

  • 대부분의 PM 문제는 현장에서 발로 뛰는 일을 하지 않는다는 데 있음. 좋은 PM은 엔지니어링과 사용자 사이의 간극을 계속 이어야 함

    1. 만들고 있는 제품이나 아이디어를 그것을 쓸 사람들과 연결해야 함. 보여주고, 사용자 느낌을 듣고, 실현 가능하고 필요한지 확인해야 함. 개발 내내 시연, 관찰, 새 피드백 반영을 통해 지속적인 피드백을 모아야 함. 출시를 계획하고 실행하며, 걸림돌을 지켜보고, 사용자에게 지원과 해결책을 제공해야 함
    2. 모은 피드백을 엔지니어링에 전달하되, 프로젝트가 기술적으로 어디쯤 있고 어디로 가며 무엇이 바뀌어야 하는지 이해한 상태로 해야 함. 엔지니어링에 “왜”를 줘야 함. 프로젝트에 필요한 것, 이미 있는 것, 진행 중인 것 사이의 우선순위를 전달해야 함
      이 피드백 루프를 반복해야 함
      하지만 대부분은 문서 세계에서만 일할 수 있다고 생각하며 로드맵 문서를 찍어내고 끝없는 체크인과 잔소리로 이해관계자 정렬을 유지하려 함. 결국 “프로젝트 매니저” 일을 하고 있는 셈임
    • 우리 팀은 배짱 없는 PM에게 제품 관리를 받았는데, 사실상 시니어 개발자와 기술 리드에게 모든 실무를 떠넘겼음
      요구사항 수집, 버그에 화난 사용자 대응, 주간 상태 회의, 우선순위 관련 나쁜 소식 전달까지 전부 시니어 개발자나 기술 리드를 보냈음. 바쁜 사람이라며 애자일 의식 대부분도 건너뜀. JIRA 티켓을 쓰거나 고친 적도 없고, 그건 기술 조직이 관리할 일이라고 했음. 다른 두 기술 팀도 똑같이 PM 했음
      기술 리드와 시니어 개발자들은 첫 주부터 그 PM이 좋지 않다는 걸 알았지만, 그는 우리 모두보다 오래 버티다 4년 뒤에야 인력 감축으로 나갔음
      애자일 숭배에 빠진 관리층은 이런 사람들에게 쉽게 매혹되고, 조직을 몇 년씩 탈선시킬 수 있음. 이론상 PM의 이해관계자는 사용자지만, 실제로는 자신을 고용한 고위 경영진의 자존심을 닦아주는 일이 됨
      고위 경영진, 애자일 컨설턴트, PM 사이에 자기강화 폐루프가 생길 수 있음
    • 여기 인구 구성상 뜨겁고 의미 있는 프로젝트를 하는 사람이 많아 내가 말할 곳을 잘못 찾았을 수도 있지만, 지난 8년 넘게 기업에서 일하며 본 바로는 많은 회사의 제품은 내부 직원이 쓰거나, 다른 기업 고객이 관성 때문에 또는 맞춤형 업무 로직이 너무 많이 들어가 이제 교체 비용이 커져서 계속 돈을 내는 제품임
      두 경우 모두 경쟁력 없는 제품이고, 대개 중단되기 전까지 그대로 남을 가능성이 큼. 그런데도 회사는 PM과 PO를 두고 SCRUM 비슷한 구성을 만들며, 마치 혁명적 제품을 만드는 것처럼 행동함. 긴급 업무와 결과 압박까지 포함해서
      이런 환경에서는 PM과 PO가 좋은 제품이나 쓸 만한 제품에는 별 관심 없이, 사내 승진 사다리를 오르기 위한 정치에 몰두하는 경우가 많았음
      그들은 기능과 개선 측면에서 무작위 보행처럼 보이는 파편화된 제품을 만들더라도, 자신이 경영진이나 고객에게 좋아 보이는 방향으로 프로젝트를 몰고 감
      60·70·80년대에 어떻게 만들었는지는 알 만큼 나이가 많지 않지만, SCRUM/PM/PO가 없었을 것 같음. 과거 수십 년과 비교해 생산성이 크게 둔화됐고 오늘날은 대체로 과거에 만든 것에 기대고 있다는 비관적 담론은 내 인식과 꽤 잘 맞음
    • 나는 PM이고, 지금은 고려하는 역할마다 technical이라는 수식어가 붙는지 먼저 봄. 네가 쓴 내용, 특히 마지막 문단에 전적으로 동의함
      최근에는 다른 PM들을 멘토링하고 있음. 널리 공유되는 로드맵도 있지만, 나 말고는 아무도 다시 보지 않는 문서와 스프레드시트가 정말 많이 만들어짐. 일을 하고 있다는 걸 보여주려고 만든다는 느낌을 받으며, 그런 습관을 깨려 함
      기술 제품 관리를 강하게 옹호하는 이유는 문제를 단순화해 보면 일부 PM들이 높은 추상화 수준에 갇혀 있기 때문이라고 보기 때문임. 매일 팀과 세부 기술 사안을 이야기할 수 없어서 결국 프로젝트 관리와 제품 관리 사이의 이상한 회색지대에 머무르게 됨
    • PM이었다가 지금은 개발자인데, 내가 겪은 문제는 시간의 절반쯤을 관리자들을 위한 문서, 커뮤니케이션, 증거 자료에 써야 했다는 것임
      그 자체는 괜찮지만, 제품 결정을 하고 싶어 하는 HIPPO 증후군이 있으면 대부분의 시간을 뒤를 방어하고 상향 관리하는 데 쓰게 됨
      PM들은 많이 두들겨 맞고, 때로는 정당하지만, 결국 일을 되게 하려고 사내 정치를 해야 하는 경우가 많음
    • 내 경험은 정반대였음. FAANG에서 PM들은 기능을 상상하고 로드맵을 만들면 자기 일이 끝났다고 생각함
      훌륭한 PM은 비전이나 계획을 만들 뿐 아니라 실행과 반복도 이끎. 계획은 전체의 20% 임

  • 함께 일한 최고의 제품 관리자는 그냥 매우 뛰어난 사람이었고, 구현 복잡도를 이해하면서도 필요하면 직접 해낼 가능성까지 있었으며, 동시에 비즈니스 필요도 이해했음
    엔지니어링 매니저가 아니면서도 회사에 가치를 더하는 사람이었음
    안타깝게도 대부분의 제품 관리자는 그 자리에 앉아 있는 사람일 뿐임. 공로든 책임이든 가져가는 문지기이고, 자기 이해관계는 거의 걸려 있지 않은 경우가 많음
    전반적으로 제품 관리 조직이 따로 있다면 잘못하고 있는 것이라고 봄

    • “제품 관리 조직이 있다면 잘못하고 있는 것”이라는 말에 동의함
      내가 참여했던 최고의, 그리고 가장 성공적인 제품들은 모두 실제 구현자들이 제품 소유권을 가졌음. 엔지니어, 디자이너, 고객 성공팀 같은 사람들임
      엔지니어로서 지원 순번에 들어가는 걸 좋아했는데, 내 작업과 그것을 매초 쓰는 실제 사람들 사이의 추상화 간극을 닫아줬기 때문임
      아주 드물게 순가치를 더하는 PM과 일한 적도 있는데, 그런 경우 모두 그 사람들은 괜찮은 엔지니어가 될 수도 있었을 사람들임
    • 내 경력에서는 이 문제의 양쪽에 모두 있어 봤고, 전체 조직 규모가 충분히 크다면 PM 조직이 있는 게 좋다는 쪽으로 결론 내렸음
      주된 이유는 PM 또는 팀에서 그 역할을 맡은 사람이 같은 엔지니어링 관리 체계로 보고하면, 모든 일이 결국 엔지니어링의 필요 쪽으로 기울기 때문임
      비즈니스를 앞으로 나아가게 할 가능성이 높은 꼭 필요한 기능 작업도, 기술 부채나 인프라 작업이 항상 어떤 식으로든 사람들을 막고 있다는 이유로 결국 우선순위에서 밀림. 때로는 그게 실제로 옳은 선택일 수도 있지만, 그런 결정을 하려면 동등한 자리를 가진 두 조직 사이의 긴장이 필요함. 엔지니어링의 일부가 되면 그게 잘 일어나지 않음
      물론 우리 업계의 슬픈 현실은 별도 PM 조직이 “비즈니스에 좋은 것”을 소유한다는 이유로 엔지니어링 조직보다 더 큰 권한을 갖게 된다는 점임. 여기에 절차나 프레임워크는 따를 줄 알지만 자기 제품이나 사용자를 실제로 이해하지 못하는 PM들이 더해지면 악몽이 됨

  • 나는 비율로 생각함
    프론트엔드 엔지니어와 백엔드 엔지니어의 비율은 얼마인가? 엔지니어링 매니저와 개별 기여자의 비율은? 기술 문서 작성자와 전체 엔지니어의 비율은? 제품 관리자와 전체 엔지니어의 비율은?
    그리고 이 비율을 정교하게 조정해 영향은 최대화하고 간섭과 미세관리는 최소화하려 함
    이 비율의 실제 숫자는 조직마다 다르겠지만, 간섭이 감지되거나 “어떻게”가 엔지니어들 자신에게서 충분히 나오지 않는다면 비율을 바꿔야 함
    사람 관리자나 제품 관리자당 엔지니어 수를 늘려 그들이 이런 식으로 끼어들 수 없게 만들고, 관여할 일을 우선순위화하게 하며, 미시적 영역에서 물러나 엔지니어에게 방법의 자율성을 돌려줘야 함

    • 이게 유일하게 제정신인 방향임. PM이 아예 없거나, 반대로 PM이 너무 많은 곳이 얼마나 많은지 놀라움
      QA, 주니어 엔지니어, 시니어 엔지니어, 아키텍트, HR 인력, 부사장, 영업사원도 마찬가지임

  • 20년 넘게 제품 관리를 해왔고, 여기서 말한 대부분에 동의함. 비율은 중요함
    CPO는 PM 군대를 거느리며 제국을 만들기 쉬움. 조직은 PM들이 단일 페이지 같은 고객 경험의 일부 조각을 소유하고, 버튼 클릭률을 최적화하지만 제품 전략이나 비전에 의미 있게 기여하지 않는 상태가 됨
    제품을 소유하지 않으면서 제품 관리자가 되기는 어려움

    • 나도 오래된 PM이고 강하게 동의함. PM은 넓은 책임 범위를 가져야 함. 이상적으로는 제품 전체, 혹은 그 이상을 맡아야 함
      PM은 지금 대부분보다 훨씬 더 비즈니스 목표에 집중해야 함. 사용자 문제를 해결하는 건 필요하지만 충분하지 않음. 그 문제 해결이 회사의 가치로도 이어져야 함
      이를 가능하게 하려면 제품 감각이 강한 엔지니어링·UX 파트너가 필수임
    • 실제로 PM은 스크럼 마스터 수준으로 붙음. 그러면 스크럼 마스터는 “SCRUM MASTERS”이고 개발자가 아니라는 이유로 PM 성격의 일에도 집중함
      더 나쁘게는 “쉽게 교체 가능한” 개발자들이 외주 회사에서 옴. 이제 개발을 고객으로부터 더 많은 관리 계층으로 격리해야 함
      GDP를 늘리는 훌륭한 방법임
    • “제품을 소유하지 않으면서 제품 관리자가 되기는 어렵다”는 말은 제품 규모에 따라 다르다고 봄
      예를 들어 ERP, Oracle Fusion Apps, WorkDay, SAP 같은 걸 다룬다면 PM 한 명이 제품 전체를 소유할 수 없음. 대신 여러 기능을 맡게 되고, 각 기능 자체가 복잡하며 ERP 특성상 여러 다른 제품과의 통합도 보통 포함됨
      그래도 PM이 의미 있는 무언가를 소유해야 한다는 큰 방향에는 동의함

  • 개발자이자 개발 매니저로서 함께 일한 최고의 제품 관리자들은 “어떻게”에는 거의 관여하지 않았음
    물론 백로그에 에픽 수준의 티켓을 만들 수는 있지만, 그보다 아래 단계에서는 당신과 프로젝트 담당자들이 일을 끝낼 수 있다고 신뢰함
    문제는 조직이 그걸 지원해야 한다는 점임. 대부분의 회사에서 가장 많은 관심을 받는 일은 비전이나 성장 중심이 아니라 가장 시끄러운 일임
    그리고 그런 일은 제품 책임자나 관리자가 원하는 방향과 직접 충돌하는 경우가 많음

    • 내 경험은 완전히 반대임
      “어떻게”를 이해하지 못하는 PM, 즉 자기 제품이 어떻게 작동하는지 모르는 PM이 최악임
      함께 일한 최고의 PM들은 기술 배경이 있었음
    • 제품 관리자는 “왜?”와 “무엇?”을 소유함. 프로젝트 관리자는 “언제?”를 소유함. 엔지니어링 매니저는 “누가?”를 소유함. 엔지니어는 “어떻게?”를 소유함
      사람들이 남의 영역을 밟으려 하면 항상 재앙으로 끝남. 양방향 모두 그렇다. 엔지니어는 “어떻게?” 관점으로 너무 많이 생각하기 때문에 “왜?”와 “무엇?”에 서툴고, 제품 관리자도 “무엇?”이나 “왜?”를 명확히 하기 위한 경우가 아니라면 “어떻게?”에서 물러나야 함
    • 반대편에서는 아무것도 모르는 PM/PO와 일한 적도 있음. 개발자들이 “이건 엄청 복잡해서 이해 못 하실 거예요”라거나 “구현에 오래 걸립니다”라고 말하지만 실제로는 작은 기능인 경우임
      균형이 있어야 함. PM/PO에게도 기본적인 이해는 필요함. 컴퓨터도 겨우 쓰는 사람이어서는 안 됨
    • 아니면 코드 수준의 세부사항을 다듬는 데 과도하게 빠져 있음. 이 두 접근 사이의 중간은 거의 없음
      좋은 PM도 주변에 평범한 PM들이 너무 많으면 꽤 묶일 수 있음
    • 그 방식은 아래 사람들이 유능하고, 비즈니스 이해관계가 보상 구조와 어느 정도 맞아떨어질 때만 작동함

  • 여러 Fortune 500 기업과 일하며 망가진 문화를 많이 봤음
    그런 곳에서 PM은 자기에게 있는 유일한 도구인 회의로 대부분의 문제를 해결함. 승진 인센티브는 회의가 클수록 더 중요한 사람처럼 보이게 되어 있음
    수백 시간의 교차기능 팀 회의에 들어가 봤는데, 실제로 일하는 사람은 1~2명이고 보통 PM이 내내 말하며, 10~20명은 음소거 상태로 있다가 마지막에 자신이 존재함을 증명하듯 승인만 함
    결과적으로 엔지니어 팀은 의욕을 잃고 실제 기술 작업을 할 시간이 없어지며, 코드 조사나 이해도 없이 그 자리에서 추정치나 약속을 요구받음
    PM이 기술 설계를 숫자나 “포인트”가 마음에 들지 않는다는 이유로 거절하고, 엔지니어들은 알 수 없는 PM 미학을 만족시키려고 같은 아이디어를 다른 “티켓”으로 재포맷해야 했던 일도 봤음
    이해 부족과 무의미한 상태 과시 의식 때문에 전체 프로젝트가 지연되고 탈선함
    반대로 뛰어난 PM과 일한 적도 있는데, 그런 사람들은 팀을 이런 헛소리에서 보호하고 올바른 목표에 집중하게 해줬음. 그런 사람들은 귀중하고, 앞의 사람들은 그만큼 해로움

  • PM 수와는 별개로, 내가 함께 일하고 싶은 PM의 유형에 관한 이야기임
    업계에서 네 회사에서 일했고, 40명 미만 스타트업부터 JP Morgan Chase까지 경험했음
    “기술적인” 사람이 “비기술적인” 사람보다 똑똑하다는 생각은 거부함. 사실 엔지니어인 나는 세부에 빠져 큰 그림을 놓치는 일이 많고, PM이 나를 끌어내 줄 필요가 자주 있음
    다만 내 경험상 엔지니어로서 가장 함께 일하기 쉬운 PM은 코드에 대해 실제 노출이 조금이라도 있었던 사람임
    대단할 필요는 없음. 오래전에 HTML과 CSS로 웹사이트를 만들어봤거나, 임시 SQL 질의를 써봤거나, 석사 과정 중 Python 수업을 들은 정도면 됨
    PM이 코드 작성이 정확한 과학도 아니고 완전한 마법도 아니라는 걸 이해하게 해주는 무언가가 있으면 됨
    이런 PM들은 함께 일하는 엔지니어들을 옹호하거나, 적어도 비즈니스 요구와 엔지니어링 현실 사이의 균형을 맞추려 함
    기술 노출이 전혀 없이 PM이 된 사람들은 더 “비즈니스 지향”인 경향이 있는데, 특정 시점의 비즈니스에는 바로 그게 필요할 수도 있지만 항상 그런 것은 아님. 엔지니어로서는 내 관점도 더 잘 이해하는 사람과 일하고 싶음

    • JPM처럼 내가 일했던 회사들이 그런 기술 역량을 가진 PM을 실제로 채용하고 뽑기만 한다면 좋겠음. 지금은 어떤 괴상한 기준을 쓰는지 모르겠음
      전혀 서운한 건 아님 :p
답변달기