훌륭한 PM은 팀이나 로드맵을 통제하지 않고, 훌륭한 엔지니어는 지시가 필요 없다

PM과 엔지니어 관계를 어떻게 재정의했는지​

2020년 Tim과 PostHog를 처음 시작할 때, 나는 절대 제품 관리자(PM)를 뽑지 않겠다고 완강히 주장했다. 엔지니어들이 어려운 제품 문제를 직접 고민하고 풀어내길 바랐다. PM들은 오히려 방해만 될 거라 믿었기 때문이다.​

4년이 지난 지금, (부분적으로) 내가 틀렸음을 인정한다. PM이 필요하다. 실제로 그들 없이는 8개 이상의 제품을 출시하거나 수익 목표를 달성할 수 없었을 것이다.​

하지만 한 가지는 맞았다. 더 나은 방법이 존재한다. 지난 2년간 우리는 PM과 엔지니어가 함께 일하는 방식을 완전히 재정의했고, 모든 프로세스를 속도와 자율성에 최적화했다. 바로 우리 실전 플레이북이다.

1. PM은 엔지니어를 통제하지 않는다

많은 회사에서 제품 관리는 이런 식으로 운영된다:창업자나 영업팀이 원하는 기능 목록을 받아 엔지니어링 팀에게 최소한의 정보만 전달하고 가능한 한 많은 기능을 짜내게 하는 거다. 당연히 이상적인 방식은 아니지만, 다들 이런 장면 본 적 있지 않나?

너무 자주 PM들은 엔지니어를 통제하거나 조직의 혼란에서 그들을 보호하는 역할로 전락한다. 이건 관련된 모두에게 고통스럽고 제품 품질에도 치명적이다. 결과적으로 반쯤 구워진 기능들의 미로가 생기고 속도도 느려진다. PM이 모든 결정의 병목이자 관문이 되면서 엔지니어들은 좌절감을 느낀다.

명확히 하자면, 이건 PM들의 잘못이 아니다. 리더들은 “엔지니어들에게 코딩 시간 더 주려면 다른 일로 방해 안 하면 된다”고 생각해 PM이 관리할 온갖 프로세스를 만든다. 하지만 이 때문에 엔지니어들은 정제된 진실만 접해 최선의 결정을 내릴 제대로 된 정보를 갖지 못한다.

대신 우리는 다른 대안을 제시한다.

2. 엔지니어가 제품 결정을 내린다

PostHog에서 만든 가장 중요한 기능은 엔지니어가 직접 ‘무엇을 만들까’를 결정한 결과물이다. 초기 PostHog가 product analytics(제품 분석)만 제공하던 시절, Karl이라는 엔지니어가 많은 고객들이 session replays(세션 재생)를 요청한다는 걸 알아챘다.

그는 이를 만들고 싶어 했지만, 나는 최악의 아이디어라 여겼다. 시간이 너무 오래 걸릴 테고 회사 초점을 여러 제품으로 분산시키고 싶지 않았다. Karl은 내 의견을 따르지 않고 독자적으로 개발했고, 결과는 고객들 사이에서 폭발적인 인기를 끌며 회사 전체 전략을 바꿔놓았다!

이 성공으로 PostHog가 단순 제품 분석을 넘어설 수 있음을 깨달았다. 그래서 feature flags(기능 플래그), experiments(실험), surveys(설문조사)를 만들었고, 지금도 web analytics(웹 분석), data warehouse(데이터 웨어하우스), error monitoring(에러 모니터링, 현재 알파 버전)으로 확장 중이다. 모든 게 단 한 명의 엔지니어가 CEO와 의견 충돌한 데서 시작됐다.

Karl이 옳았던 이유, 그리고 엔지니어들이 대체로 옳은 이유는 그들이 만들 수 있는 것에 대한 가장 깊은 이해를 갖고 있기 때문이다. 기술적 제약을 알며 기능 간 패턴을 파악하고 문제를 정확히 해결하는 법을 안다.

그래서 우리는 이 점을 적극 활용하기로 했다. PostHog에서 PM들은 더 이상 로드맵을 소유하거나 제품 결정을 내리지 않고, 사용자나 비즈니스 목표로부터 엔지니어를 보호하지도 않는다. 대신 엔지니어들이 주도권을 쥔다. 그들은 제품 팀을 관리하며 완전한 자율성을 가지고 제품을 앞당긴다. 심지어 사용자와 직접 대화하기까지 한다.

이게 PostHog 개발자들이 product engineers(제품 엔지니어)로 불리는 이유다. 그들을 의견 강하고 고객 집착적으로 만들려면 진짜 자율성과 제품 결정 책임이 필수다. 다만 엔지니어가 모든 결정을 내리려면 여전히 지원이 필요하다.

3. 제품 관리자는 엔지니어에게 맥락을 제공한다

엔지니어들은 필요한 모든 정보를 직접 수집하고 정리할 여유가 부족한 경우가 많다. 여기서 PM의 역할이 빛난다. PostHog에서는 PM들이 다음 일을 맡는다:

• 제품 분석(product analytics) 데이터 분석
• 기회 탐색
• 경쟁사 연구
• 사용자 연구 수행 (단 엔지니어들도 사용자와 직접 소통해야 함)
• 산업 뉴스 공유
• 팀 작업 결과 추적

이 책임들 어디에도 팀 관리나 로드맵 정의는 없다. PostHog에서 PM은 엔지니어를 통제하는 게 아니라 힘을 실어주는 존재다.​

PM을 팀의 나침반(compass)으로 본다. 목적지를 정하지는 않지만, 팀이 올바른 방향으로 가고 있는지 알려줄 정보를 준다.​

PM들은 팀 결정을 도전하고 의문을 제기할 수 있고 해야 하지만, 최종 결정은 엔지니어 몫이다. 물론 이는 엔지니어의 판단력에 대한 극도의 신뢰가 전제되는데, 다음 포인트로 이어진다.

4. 피드백 루프로 책임감을 확보한다

끝없는 프로세스 체크리스트와 리뷰는 회사가 엔지니어를 신뢰하지 않는다는 명백한 신호다. 이는 전형적인 안티패턴이다. 엔지니어 속도를 극도로 늦추고 팀은 좌절하며 최고 인재들이 떠난다.​

하지만 엔지니어가 항상 옳은 결정을 내릴 거라 맹목적으로 믿는 것도 실수다. 누구도 100% 맞지 않는다. 우리는 더 큰 자율성을 주되 성공에 필요한 맥락과 책임감을 제공하는 간단한 피드백 루프를 만들었다.​

이렇게 접근한다:

a. 제품 엔지니어가 분기 목표를 스스로 세운다

예전엔 OKR과 메트릭 기반 목표를 썼지만 두 문제에 부딪혔다:

1. 팀들이 올바른 메트릭 선정을 위해 너무 많은 시간을 낭비했다.
2. 엔지니어들이 사용자 진짜 요구가 아닌 메트릭 움직임을 위한 작은 단기 승리에 치중했다.

이제 분기 계획 세션 결과물은 팀들이 만들 목록이다. 간단화된 프로세스는 다음과 같다:

1. 경영진이 회사 목표를 고수준으로 공유한다. 예를 들어 “상단 퍼널 채택률을 높여야 한다” 또는 “올인원 툴이 되려면 더 많은 제품을 만들어야 한다”. 이는 제품 팀이 목표를 정하기 전에 이뤄진다.
2. 엔지니어들이 이를 달성할 빌드 항목을 브레인스토밍한다. 필요시 경영진 조언을 구하지만 최종 결정은 엔지니어 몫이다.
3. 제품 팀이 모여 목표를 정한다. 출력은 만들 목록과 담당자다. 제품 분석 팀 Q4 목표 예시처럼.

이 방식이 낫다. 특정 메트릭 달성 스트레스 없이 빌드에 집중할 수 있고 엔지니어들이 직접 작업을 고르니 동기부여가 자연스럽다. CEO로서 팀 아이디어가 맞다고 가정하지만, 그 작업이 의미 있는 임팩트를 내는지 검증해야 한다. 여기서 growth review가 등장한다.

b. 제품 관리자가 월간 growth review를 주도한다

Growth review는 각 팀 작업 임팩트를 평가하기 위한 거고 PM이 주관한다. 먼저 팀 PM이 모든 데이터를 모아 다음 인사이트를 수집한다: – 수익 메트릭: MRR, 월별 성장률, 수익 이탈률, 총 유료 고객 수 등. – 제품 분석: 활성 사용자, 사용자 성장률, 조직 성장률, 사용자 유지율 등. – 사용자 피드백: NPS 점수, 고객 인터뷰, 지원 티켓, 기타 요청 등.

이걸 이해하기 쉬운 형식으로 정리한다 – 복사 가능한 예시 템플릿 여기 있다. 다음으로 깊이 파고들어 논의할 흥미로운 발견을 강조한다.

PM, 엔지니어, 경영진이 모여 이런 질문을 논의한다: – 우리 10대 고객이 제품을 만족스럽게 쓰고 있나? – 고품질 ICP(ideal customer profile, 이상 고객 프로필)와 비ICP 고객이 제품을 다르게 쓰나? – 지난달 이탈률이 왜 높았나? 이유를 찾을 수 있나? – 장기 제품 사용을 예측하는 선행 지표를 찾을 수 있나? (예: Facebook의 10일 내 7명 친구). – 온보딩 퍼널 어디서 신규 사용자가 어려워하나?

이게 팀과 제품 상태를 완전하게 보여준다. 제품 팀 리드(엔지니어)가 팀이 현재 코스를 유지할지 바꿀지 결정한다. 프로젝트 재우선화, 목표 변경, 완전 신규 프로젝트를 선택할 수 있다. CEO나 고위 리더가 가정을 도전하고 어려운 질문을 던져 최종 책임감을 유지한다.

이 구조가 건강한 긴장감을 만든다. 엔지니어는 결정 자율성을 지키지만 명확한 피드백 루프로 그 결정이 실질 가치를 창출하는지 확인한다. 이 책임감 없인 자율성이 방향성 없게 되고, 있으면 팀이 실시간 피드백으로 실험하고 빠르게 피벗할 수 있다.

5. 속도 최적화로 빠르게 배우기

이 변화들은 엔지니어의 블록을 풀고 PM을 재미없는 관문 역할에서 해방시키지만, 마지막 한 수가 남았다. 대부분의 사람은 Steve Jobs처럼 제품에 마법 같은 직감을 갖지 않는다. 처음부터 ‘무엇을 만들까’를 알거나 거대한 비전을 갖진 않는다.

최고의 제품을 만들려면 다음을 반복해야 한다:

1. 출시하기
2. 사용자 손에 쥐여주기
3. 피드백으로 개선하기
4. 반복.

이 순환이 빠를수록 제품이 좋아진다. 간단한 진리다. 우리 팀에 도움이 된 실행 가능한 팁들을 공유한다.

a. 기본적으로 디자이너가 없다

프로젝트 의존성이 적을수록 빨리 움직인다. 디자인도 예외가 아니다. 그래서 프로젝트가 디자인부터 거치길 기대하지 않는다. 대신 엔지니어들이 프로젝트 목표와 현재 단계를 파악한 뒤 필요한 디자인 도움을 스스로 판단하게 한다. 대략 이런 식이다.

엔지니어들이 디자인 시스템(design system)을 셀프서비스로 써서 더 빨리 나아가도록 돕는다.​

b. 급진적 투명 커뮤니케이션

모든 걸 공개적으로 소통한다. 팀 로드맵, 스프린트 노트, 이사회 회의록, 회사 재무, 펀드레이징 업데이트 등 포함. 정보 사일로의 온상인 1:1 미팅도 대거 없앴다.

이점은 셀 수 없다. 팀 간 맥락 구축에 도움될 뿐 아니라 미팅 줄이고 결정 가속화한다. 정치도 줄어든다 – 모든 게 공개면 몰래 할 수 없으니까! 이를 위해 커뮤니케이션 가이드라인을 정했다: 모든 걸 비동기(asynchronously)로 하고 선호 채널에 명확한 계층을 뒀다.

c. 소규모 팀

팀당 최대 6명. 그 이상이면 지옥문: 미팅·프로세스·병목·헛소리 폭증. 💩

팀을 작고 효과적으로 유지하는 법:

1. 명확한 미션 부여 – 예: “PostHog를 엔지니어를 위한 최고 실험 플랫폼으로 만들기”
2. 엔지니어를 책임자로 세우기
3. 원하는 대로 일하게 하기
4. 6명 되면 무조건 분리.

효과있다는 증거? PostHog 엔지니어의 전형적 주간 스케줄이다.

소규모 팀 마법은 속도뿐 아니라 소유권에 있다. 6명 이하가 문제 소유하면 숨을 곳도 책임 떠넘길 곳도 없다. 모두 무게를 져야 하고 모든 기여가 중요하다.

요약

이게 우리 플레이북의 가장 간단한 핵심이다:

• 훌륭한 PM은 팀이나 로드맵을 통제하지 않는다. 팀 임팩트를 증폭하는 인사이트를 발굴하고 방향 이탈을 막는다.
• 훌륭한 제품 엔지니어는 지시가 필요 없다. PM이 주는 맥락과 가능성에 대한 지식을 활용해 제품 결정을 주도한다.

---

원문: Product management is broken. Engineers can fix it