도대체 프로덕트 매니저는 무슨 일을 하는가? 그리고 엔지니어들이 이를 알아야 하는 이유

지난 기사에서 Ian Vanagas는 엔지니어링이 어떻게 코드베이스를 벗어나고 있는지를 다뤘다. 엔지니어링 툴과 마인드셋, 그리고 그들의 정체성이 특히 스타트업에서 어떻게 작동하는지에 대해서 말이다.

우리는 PostHog에서 이를 직접 경험했고, 이는 더 이상 우리만의 사례가 아니다. 프로덕트 매니지먼트와 엔지니어링의 경계 역시 점점 흐려지고 있다.

LLM(거대 언어 모델)으로 인해, "어떻게 개발할 것인가"보다 "무엇을 개발해야 하는가"가 훨씬 더 많은 시간과 연구를 요구하는 문제가 되었다. 따라서 개발자들이 프로덕트 매니저들의 방식으로 생각하는 것도 중요한 덕목이 되었다.

이 아티클에서는 프로덕트 매니저들의 매뉴얼에 나오는 가장 중요한 세 가지 스킬을 다룬다. 이 스킬들이 개발자인 당신에게도 도움이 되기를 바란다.

1. 올바른 컨텍스트를 수집하라

잘 설계된 컨텍스트를 제공하는 것은 프로덕트 매니저에게 가장 중요한 일이다.

그렇다면 '컨텍스트'란 무엇을 의미할까? 과거에 뱃사람들이 별을 보고 망망대해를 항해해 나갔던 것처럼, 엔지니어들도 올바른 프로덕트 결정을 내리기 위해 컨텍스트를 나침반 삼아 방향을 잡아야 한다.

좋은 컨텍스트가 팀에게 올바른 방향을 제시해 준다면, 잘 설계된 컨텍스트는 한 회사의 경로를 완전히 바꿀 수 있다.

듀오링고를 예로 들어보자.

듀오링고의 프로덕트 총괄 책임자인 Jorge Mazal이 Lenny's Newsletter에 쓴 아티클에 따르면, 듀오링고는 정체된 성장률 문제를 해결해야 했다. 처음에는 친구 추천, 프리미엄 체험, 인게임 방식을 시도했지만 효과가 없었고 DAU(일간 사용자)는 계속 줄어들었다.

그러나 Mazal과 데이터 사이언스 팀은 다른 어떤 지표보다 CURR(현재 사용자 유지율)이 DAU에 5배나 더 큰 영향을 미친다는 사실을 발견했다. 그리고 이런 섬세한 컨텍스트 해석은 제품 로드맵을 완전히 바꿔놓았다.

그의 팀은 더 많은 신규 유저를 확보하는 대신 리더보드와 연속 달성 일수를 이용해 기존 유저들의 이탈을 막았다. 물론 점점 일그러지는 듀오링고의 시그니처 부엉이 캐릭터 표정과 알림도 유저들이 이 앱을 절대 무시할 수 없게 만들었다.

4년 후 듀오링고의 DAU는 4.5배 증가했다.

듀오링고의 CURR과 DAU 같은 제품 지표는 컨텍스트의 일부이다. 이 외에도 훨씬 더 많은 컨텍스트가 존재한다.

• 경쟁 환경: 우리의 경쟁사는 무엇을 하는가? 그리고 우리는 무엇을 해야 하는가? TechCrunch와의 인터뷰에 따르면 인스타그램의 CEO는 2016년에 Snapchat Stories를 어떻게 카피하고 결국 능가했는지를 설명했다.

• 사용자 조사: 우리의 잠재 고객들은 무엇을 원하는가? Buffer는 크리에이티브 AI 어시스턴트 툴을 사용하는 사람들이 실제로 원하는 것을 발견하기 위해 30명이 넘는 콘텐츠 크리에이터들을 인터뷰했다.

• 산업 동향: 우리가 주시해야 할 산업에서는 현재 어떤 일이 일어나고 있는가? 2023년에 생성형 AI가 급부상한 후 Canva는 이를 핵심 기능으로 전환했고 2년 만에 매출을 두 배 가까이 늘렸다. (17억 달러, 한화 약 2조 2,000억 원 → 33억 달러, 한화 약 4조 2,900억 원)

• 고객 피드백: 현재 고객들은 무엇을 요구하며, 그것은 그들이 실제로 원하는 것인가? (표면적 요구 vs 실제 니즈) Linear의 고객들이 "커스텀 필드"를 요구했을 때, Linear는 단순히 거기에서 그치지 않고 더 깊게 파고들었다. 그리고 고객 지원 게시판의 문의, Slack 메시지, 통화 등을 추적할 수 있는 Customer Requests 기능을 개발했다.

컨텍스트를 수집하는 것은 당연히 어렵다. 시간이 흐름에 따라 특정 영역에서 어떤 정보가 유용한지 명확하지 않을 수 있기 때문이다. 사용자의 기능 사용을 늘리기 위해 버그 리포트 작성에 몇 주를 허비했지만, 유저 인터뷰를 통해 해답은 기능 발견성 문제에 있었다는 걸 깨닫기도 한다.

그러나 그런 상황을 위해 성과 책임 피드백 루프가 존재한다. 이를 이용하면 어떤 종류의 컨텍스트가 좋은 성과로 이어지는지 파악하고, 자신의 직관을 발전시킬 수 있다. 이에 관해서는 다음 섹션에서 더 자세하게 다루겠다.

[엔지니어를 위한 실천 포인트]

누군가가 당신의 프로덕트를 위한 컨텍스트를 제시해 주기를 기다리지 마라. 대신 당신만의 시스템을 직접 만들어서 컨텍스트를 파악하라.

이는 제품 출시 단계의 속도를 높일 뿐만 아니라 당신에게 더 생생한 데이터를 제공한다. 예를 들어 유저와의 직접적인 소통은 단순히 PM이 남긴 메모를 통해서는 얻을 수 없는 더 명확한 인사이트를 선사한다. 정보는 여러 다리를 거치면 거칠수록 의미가 희석되기 마련이니까.

당신이 직접 뛰어들어서 컨텍스트를 파악해야 하는 또 다른 이유는, 팀원들이 기술적인 옵션과 제약을 제대로 이해하지 못할 수 있기 때문이다. 완전한 컨텍스트를 가진 사람만이 제대로 된 질문을 할 수 있다.

실천 방법: 일주일에 한 번씩 유저 인터뷰를 실시하라. 프로덕트에 관한 피드백 설문조사를 실시하고 매 스프린트마다 결과를 검토하라. 유저들이 어떤 부분에서 어려움을 겪고 있는지 LLM 평가를 설정해서 파악하라. 일주일마다 경쟁사 블로그를 요약해서 팀원들에게 이메일로 공유하라.

Subscribe to our newsletter

Product for Engineers

Read by 100,000+ founders and builders

Subscribe

We'll share your email with Substack

2. 피드백 루프를 활용해서 성과를 추적하라

만약 당신의 팀이 성과를 제대로 파악하지 못한다면 이 모든 컨텍스트는 무의미하다.

PostHog의 프로덕트 매니저는 매달 성장 리뷰를 통해 성과를 점검한다. 제품을 개발하는 엔지니어들이 직접 참여하는 월간 미팅을 열어서 매출, 유저 피드백, 사용 지표, 분기별 목표 등을 검토한다.

만약 지표가 우리의 목표대로 나아가지 않는다면, 프로덕트 매니저는 결과를 기반으로 설명하고 팀원들이 가설과 해결책을 제시할 수 있도록 돕는다.

그리고 다음 달에 무엇이 효과가 있었고, 무엇이 효과가 없었는지를 다시 검토한다. 이러한 반복 과정이 프로덕트와 프로덕트에 대한 이해를 발전시킨다.

PostHog의 오류 추적 팀이 직접 경험한 예시를 들자면 다음과 같다.

1. 문제: 프로덕트 매니저는 신규 고객 유입률은 좋은데 이탈률이 높다는 문제를 확인했다.

2. 컨텍스트: 사용자 인터뷰 결과 모두 한 가지 문제를 지적했다. 프로덕트의 "신뢰성"에 문제가 있었다. 유저들은 레코드 누락, 스택 트레이스에서 일부 예외 상황이 제대로 처리되지 않는 문제 같은 프로덕트의 미흡한 완성도 때문에 떠나갔다.

3. 가설: "이는 전반적인 프로덕트 완성도의 문제이지 어떤 기능이 부족해서 발생한 문제는 아니다. 자잘한 불편함, 인터페이스 사용성, 안전성을 개선한다면 이탈률을 낮출 수 있을 것이다."

4. 해결책: 유저 피드백을 통해 신뢰성과 관련한 모든 문제를 구조적으로 분류했고 수십 개의 해결책을 적용했다. 유저 이탈률은 그다음 분기에 21%에서 10%로 감소했다.

프로덕트 매니저의 분석이 없었더라면 해당 팀은 완성도를 가다듬는 근본적인 문제를 해결하는 대신 엉뚱하게 새로운 기능을 개발하느라 몇 개월을 허비했을 것이다.

이처럼 피드백을 통한 반복 개선 작업은 책임감을 형성하고, 그 결과 개발자들에게 더 많은 자율성을 줄 수 있다. 피드백 루프가 개발자들이 회사의 실질적인 성과(수익)에 기여하고 있음을 보장하기 때문에, 그들은 더 자유로운 프로덕트 결정을 내릴 수 있다. PM이 프로덕트 로드맵을 일일이 통제할 필요 없이 말이다.

[엔지니어를 위한 실천 포인트]

각 세션마다 다르게 성공을 정의하고 평가해서 모든 스프린트를 미니 성장 리뷰로 만들어라.

PostHog에서는 각각의 마일스톤을 다음과 같이 분류한다.

• 성공: 우리가 해냄!

• 재정비: 목표에 거의 도달했음, 그러나 몇 가지 개선 필요.

• 실패: 목표 달성에 실패했지만 개선점 파악. 여기서부터 다시 시작.

이런 분류는 개발자들이 대충 수정 배포하는 게 아니라 각각의 사이클을 통해 새롭게 학습하고 개선할 수 있도록 돕는다. 프로젝트가 끝났다고 해서 단순히 "완료"라고 표시하는 것보다 훨씬 의미 있는 작업이다.

실천 방법: 각각의 작업마다 성공에 대한 기준을 정의하고 이를 평가하는 피드백 루프 세션을 가져라. 그리고 다음 스프린트에서 목표 달성에 성공했다면 이를 리뷰하는 시간을 가져라. 목표 달성에 실패했다면 문제점을 파악하고 어떻게 개선할지 정하라.

또한 그룹 간 행동을 비교하기 위해 A/B 테스트를 실시할 수 있고, 초기 프로토타입을 테스트해서 사용자 피드백을 얻을 수도 있으며, 제품을 직접 사용해서 실제 내부 데이터를 확보할 수 있고, 고객에게 직접 메시지를 보내 그들의 문제가 실제로 해결되었는지 확인할 수도 있다.

3. 행동 지향의 커뮤니케이션을 하라

위의 모든 사항들을 효과적으로 만들기 위해선, 결국 바로 행동으로 옮길 수 있는 커뮤니케이션을 해야 한다. 아마 PM들이 항상 입에 달고 사는 말처럼 들리겠지만, 구체적으로 설명해 보자.

사실 누구나 이런 식으로 문제를 제시할 수는 있다.

"우리의 기능 부족 때문에 경쟁자들한테 기업 고객을 뺐기고 있다."

그러나 이런 식의 커뮤니케이션은 개발자들이 무엇을 개발해야 하고, 왜 그것을 개발해야 하는지를 설명해 주지 못한다.

행동으로 옮길 수 있는 커뮤니케이션은 다음과 같다

"지난 3개월 동안 SSO, 감사 로그, 역할 기반 권한 관리 기능 부족 때문에 20만 달러 규모의 계약 5건을 놓쳤습니다. 핵심 사용자군에서는 이미 높은 유지율을 보이고 있기 때문에, MCP v2를 출시하는 것보다 이 기능들의 개선을 우선순위로 두는 것이 좋습니다. 또한 기업 고객의 요구가 2분기 회사 전체 목표와도 더 잘 맞습니다."

이 편이 훨씬 낫다. 그렇다면 왜? 처음부터 가장 중요한 문제를 파고들었기 때문에 다른 불필요한 방해 요소를 줄였기 때문이다.

• 결과를 설명하라. "거래를 놓친다" 대신 "5개의 기업 고객 거래를 놓쳤다"

• 구체적으로 설명하라: 단순히 기능 부족이라는 말 대신 어떤 세 가지 기능이 개선되어야 하는지 언급했다. (SSO, 감사 로그, 역할 기반 권한 관리)

• 관련 컨텍스트를 공유하라: 이익 감소(문제), 이미 핵심 사용자군의 높은 유지율에 대한 언급(상황), 그리고 2분기 전사 목표(목표)는 모두 의사결정에 도움을 준다.

• 트레이드오프를 명확히 드러내라: 앞의 표현은 무엇을 우선순위로 둬야 하는지 언급하지 않지만, 뒤의 표현은 정확히 무엇을 선택해야 하는지를 보여준다.

• 의견을 제시한다: 막연하게 "어떻게 생각하세요"라고 묻는 대신 어떤 옵션이 더 나은지, 왜 그렇게 생각하는지를 제시하라. (세 가지 기능 개선에 집중하는 편이 더 낫다)

앞에 언급한 세 가지 중요한 스킬은 함께 활용할 수 있다. 프로덕트 매니저들은 자신이 이해한 컨텍스트와 실시했던 피드백 루프를 통해 어떤 정보를 제공할 것인지 파악하고, 행동으로 옮길 수 있는 커뮤니케이션을 통해 이를 전달한다. 이 세 가지가 합쳐지면 더 효과적이다.

[엔지니어를 위한 실천 포인트]

바로 실행할 수 있다면 그렇게 하라. 직접 코드로 보여주는 편이 낫다. 그래서 PostHog에서는 풀 리퀘스트(PR)를 가장 좋은 커뮤니케이션으로 여긴다. (이메일은 당연히 최하위이다)

그러나 다음 단계가 불분명해서 논의할 필요가 있을 때는 거꾸로 생각해야 한다. 정보를 최대한 실행 가능하게 만들기 위해 PM이라면 어떤 컨텍스트와 성공 기준을 제시할지 생각해보라.

실천 방법: "~이거 할까요?"라고 묻기 전에, 다음과 같은 정보를 제시하고 바로 실행 가능한 형태로 만들어라.

1. 문제와 그 결과를 구체화하기
2. 이미 어떤 부분까지 조사했는지
3. 최소한 하나의 대안과 그에 따른 트레이드오프
4. 본인이 선택할 옵션과 그 이유

Subscribe to our newsletter

Product for Engineers

Read by 100,000+ founders and builders

Subscribe

We'll share your email with Substack