사람

결국 좋은 제품은 좋은 사람에서 나와. 어떤 역할이 필요하고, 각 역할이 어떤 책임을 져야 하고, 좋은 팀은 어떻게 구성되는지가 핵심이야.

강한 제품 팀은 미션을 가진 자율적인 팀이야. PM, 제품 디자이너, 엔지니어 몇 명이 한 팀을 이루고, 해결해야 할 문제를 부여받지. 기능 목록이 아니라 문제를 받는다는 게 핵심이거든. 이 팀은 **선교사 팀(missionaries)**이지 **용병 팀(mercenaries)**이 아니야. 용병은 시킨 걸 만들고, 선교사는 문제를 해결해. 선교사 팀은 자신이 만드는 제품에 진심으로 주인의식을 느끼고, 결과에 책임을 져. 이 차이는 미묘해 보이지만 결과에서 엄청난 차이를 만들거든. 시킨 걸 만드는 팀은 "출시했으니 끝"이라고 생각하지만, 문제를 해결하는 팀은 "고객이 실제로 가치를 느꼈는가"까지 추적하지.

케이건은 PM을 제품의 CEO라고 부르지만, 동시에 그 말이 오해되는 방식을 경고해. PM은 아무도 관리하지 않거든. 대신 PM의 핵심 책임은 가치 있고, 사용 가능하고, 실현 가능하고, 사업적으로 유효한 솔루션을 발견하는 것이야. PM은 네 가지를 깊이 알아야 해: 고객, 데이터, 비즈니스, 시장과 산업. 이 네 가지 지식을 바탕으로 팀이 올바른 문제를 올바른 방식으로 풀도록 이끌지. PM이 이 역할을 제대로 못하면 팀 전체가 방향을 잃어. PM은 단순히 요구사항을 정리하는 사람이 아니라, 제품의 방향을 결정하는 핵심 의사결정자야.

케이건이 말하는 제품 디자이너는 단순히 예쁜 UI를 만드는 사람이 아니야. 제품 디자이너는 PM과 함께 제품 발견의 파트너거든. 사용성 문제를 해결하고, 사용자의 실제 행동을 이해하고, 프로토타입을 빠르게 만들어 아이디어를 검증하지. 좋은 제품 디자이너는 요구사항을 받아서 화면을 그리는 게 아니라, 문제 정의 단계부터 참여해서 솔루션을 함께 만들어. PM이 "이걸 만들어줘"라고 하면 안 되고, "이 문제를 같이 풀자"라고 해야 해. 디자이너가 일찍 참여하면 사용자 관점의 통찰이 솔루션에 자연스럽게 녹아들거든.

케이건의 핵심 메시지는 명확해. 엔지니어를 코더로만 쓰면 팀 역량의 절반을 버리는 것이야. 최고의 제품 아이디어 중 상당수는 엔지니어에게서 나오거든. 왜냐하면 기술이 무엇을 가능하게 하는지 가장 잘 아는 사람이 엔지니어니까. 그래서 엔지니어는 제품 발견에 반드시 참여해야 해. 매일의 발견 활동에 직접 참여하기 어렵더라도, 최소한 프로토타입 리뷰와 기술적 실현 가능성 평가에는 깊이 관여해야 하지. 엔지니어가 "이건 기술적으로 이렇게 하면 훨씬 나은 경험을 만들 수 있어요"라고 말할 수 있는 환경이 되어야 해.

PMM은 제품 팀의 핵심 멤버는 아니지만 중요한 파트너야. PMM의 역할은 시장을 이해하고, 포지셔닝과 메시징을 만들고, 고투마켓 전략을 수립하는 것이거든. PM이 제품의 "무엇을"을 결정한다면, PMM은 어떻게 시장에 전달할 것인가를 담당해. 특히 B2B 제품에서 PMM의 역할이 크지. 아무리 좋은 제품을 만들어도 시장에 제대로 전달되지 않으면 소용없잖아.

제품 팀의 핵심 삼인방(PM, 디자이너, 엔지니어) 외에도 중요한 지원 역할들이 있어. 사용자 리서처는 고객을 깊이 이해하는 전문가이고, 데이터 분석가는 제품 데이터에서 인사이트를 뽑아내지. 테스트 자동화 엔지니어는 품질을 보장하고. 이 역할들이 전담으로 있으면 좋지만, 작은 팀에서는 PM이나 디자이너가 겸하기도 해. 중요한 건 이 기능들이 수행되느냐이지, 별도의 사람이 있느냐가 아니야. 리서치 없이 제품을 만드는 건 위험하고, 데이터 분석 없이 결정하는 건 추측에 불과하거든.

제품 리더의 핵심 역할은 두 가지야. 첫째, 제품 비전과 전략을 수립하는 것. 둘째, 강한 제품 팀을 구축하고 코칭하는 것. 특히 PM들을 코칭하고 성장시키는 게 제품 리더의 가장 중요한 업무지. 나쁜 제품 리더는 모든 결정을 직접 내려. 좋은 제품 리더는 팀이 스스로 좋은 결정을 내릴 수 있도록 맥락과 전략을 제공하고, 필요한 역량을 키워주지. 리더가 병목이 되면 팀의 속도가 리더 한 명의 속도로 제한돼.

CTO의 역할은 회사 규모에 따라 크게 달라져. 스타트업에서는 직접 코딩하는 사람이지만, 성장하면서 기술 비전과 아키텍처를 책임지는 리더로 변해야 하거든. VP of Engineering은 엔지니어링 조직의 관리와 전달을 책임지고. 핵심은 CTO든 VP든, 기술 리더가 제품 발견에 적극적으로 참여해야 한다는 거야. 기술이 무엇을 가능하게 하는지 아는 사람이 제품 전략에 관여해야 기술 기반 혁신이 일어나거든.

전달 관리자는 팀이 제품을 실제로 출시하는 데 필요한 장애물을 제거하는 역할이야. 스크럼 마스터와 비슷하지만, 범위가 더 넓지. 의존성 관리, 릴리스 조율, 팀 간 협업 촉진 등을 담당해. 좋은 전달 관리자가 있으면 PM과 엔지니어가 본업 -- 발견과 개발 -- 에 집중할 수 있어. 눈에 잘 안 띄는 역할이지만, 이 역할이 없으면 팀이 온갖 조율 업무에 시간을 뺏기거든.

팀 구조를 결정할 때 케이건이 제시하는 핵심 원칙들이 있어. 자율성을 극대화해야 해 -- 팀 간 의존성이 최소화되어야 하지. 미션 중심으로 팀을 나눠야 해 -- 기술 컴포넌트가 아니라 고객 문제나 비즈니스 목표 기준으로 나누는 거야. 적절한 크기를 유지해야 해 -- 보통 5-10명이 적당하고. 잘못된 팀 구조는 아무리 뛰어난 사람들이 있어도 제품을 망칠 수 있어. 팀 구조가 제품 아키텍처를 결정한다는 콘웨이의 법칙을 항상 염두에 둬야 하지. 프런트엔드 팀, 백엔드 팀, QA 팀으로 나누면 그 경계에서 책임이 흐려지고 협업 비용이 폭발하거든.

케이건은 Adobe가 어떻게 패키지 소프트웨어 회사에서 클라우드 기반 구독 모델로 성공적으로 전환했는지를 보여줘. 이 전환은 단순한 비즈니스 모델 변경이 아니라, 제품을 만드는 방식 자체를 바꾸는 것이었지. 핵심은 Adobe가 강한 제품 팀을 구축하고, 그 팀들에게 자율성을 부여하면서도 명확한 비전과 전략으로 방향을 정렬한 거야.

많은 회사에서 PM이 실질적으로는 프로젝트 매니저, 요구사항 정리자, 백로그 관리자로 전락해 있어. 이해관계자의 요구를 모아서 정리하고, 우선순위 매기고, 엔지니어에게 전달하는 역할만 하는 거야. 케이건은 이걸 기능 공장의 PM이라고 부르지. 진짜 PM은 요구사항을 모아 전달하는 사람이 아니라, 제품의 가치와 사업 유효성에 대한 답을 찾는 사람이야. 이 차이를 이해하지 못하면 PM이라는 직함은 있지만 실제로는 제품 관리가 부재한 상태가 돼. "기능 공장의 PM"은 바쁘지만 팀에 방향을 제시하지 못하거든.

케이건이 말하는 좋은 PM의 핵심 자질은 이래. 똑똑하고 창의적이고 끈기 있어야 해. 고객에 대한 깊은 지식, 데이터에 대한 유창함, 비즈니스에 대한 이해, 시장에 대한 통찰이 있어야 하지. 하지만 가장 중요한 건 팀원들의 존경을 받는 것이야. PM은 누구에게도 명령할 수 없거든. 오직 자신의 지식과 판단력으로 팀을 설득해야 해. 그래서 PM은 팀에서 가장 열심히 일하고, 가장 많이 아는 사람이어야 하지. 권한이 아니라 전문성과 헌신으로 리드하는 사람, 그게 좋은 PM이야.

---

정리

2장 읽고 기억할 거 세 가지:

1. 강한 제품 팀은 기능이 아니라 문제를 부여받는 자율적인 선교사 팀이야. PM, 디자이너, 엔지니어 모두가 제품 발견의 핵심 파트너지.
2. PM은 백로그 관리자가 아니라 가치와 사업 유효성의 답을 찾는 사람이야. 권한이 아니라 전문성과 헌신으로 팀을 이끌어야 하고.
3. 팀은 기술 컴포넌트가 아니라 고객 문제 기준으로 나눠야 해. 좋은 리더는 직접 결정하지 않고, 팀이 좋은 결정을 내릴 수 있게 만들지.