해법보다 먼저 문제를 써라
구체적인 기능을 제안하기 전에 고객의 문제와 그것이 왜 중요한지를 평이한 언어로 먼저 밝혀라. 팀이 문제 자체에 먼저 동의하게 만들면, 누구도 코드를 쓰기 전에 잘못된 해법을 걸러낼 수 있다.
화이트보드에 대담한 비전을 그리는 프로덕트 매니저라는 이미지는 대체로 틀렸다. 이 일의 대부분은 화려하지 않은 종합 작업이다. 설문과 분석 데이터를 읽고, 엔지니어가 오해할 수 없을 만큼 정확한 문서를 쓰고, 서로 의견이 다른 여러 사람을 하나의 계획에 동의하게 만드는 것이 진짜 일인 회의에 앉아 있는 것이다.
이 분야 안에서 전수되는 노하우는 어떤 특정 도구보다는 습관에 가깝다. 지금 당장은 틀린 아이디어이기 때문에 좋은 아이디어를 거절하는 법, 실제 엔지니어와 부딪혀도 살아남는 명세서를 쓰는 법, 고객이 선호한다고 말하는 것보다 실제로 하는 행동을 신뢰해야 할 때가 언제인지 아는 것이다.
이 일이 요구하는 역량
우선순위 결정90
글쓰기 소통 능력82
이해관계자 설득력78
데이터 분석75
사용자 조사68
기술적 유창함58
우선순위 결정
무엇을 만들지 않을지 결정하는 것이 매일 내리는 결정 중 가장 중대하다. 로드맵이란 대개 프로덕트 매니저가 거절하기로 한 좋은 아이디어들의 긴 목록이다.
글쓰기 소통 능력
명세서, 로드맵 업데이트, 사후 분석 보고서는 그 자리에 없었던 사람도 정확하게 행동할 수 있을 만큼 정밀해야 한다.
이해관계자 설득력
엔지니어링, 디자인, 영업, 경영진에게 거의 공식적인 권한 없이 같은 계획에 동의하게 만드는 능력. 흔히 '권력 없이 이끌기'로 요약된다.
데이터 분석
사용 데이터와 실험 결과를 읽고 진짜 신호와 잡음을 구분하며, 지표가 진짜로 개선된 것인지 아니면 조작된 것인지 알아채는 능력.
사용자 조사
설문이나 영업팀의 전언에만 의존하지 않고, 고객과 직접 이야기하고 제품을 사용하는 모습을 직접 관찰하는 것.
기술적 유창함
직접 만들 수는 없더라도, 밑바탕 시스템이 작동하는 방식을 충분히 이해해 엔지니어와 실질적인 트레이드오프 대화를 나눌 수 있는 능력.
하루의 풍경
- 8–9
받은편지함, 슬랙, 밤새 쌓인 지표
그날의 회의가 시작되기 전, 메시지를 확인하고 밤사이 대시보드에 뭔가 고장났거나 예상치 못하게 움직인 것이 없는지 살핀다.
- 9–11
스탠드업과 팀 간 동기화 회의
직속 제품팀과의 일일 스탠드업, 그리고 디자인·엔지니어링 리드나 의존 관계에 있는 팀과 정기적으로 만나 막힌 일을 풀고 이견을 해소한다.
- 11–13
몰입 업무: 명세서와 분석
하루 중 가장 잘 보호되는 시간대로, 명세서를 쓰거나 고치고, 실험 결과를 분석하거나, 다가올 의사결정을 위한 문서를 준비하는 데 쓴다.
- 13–14
점심
운이 좋은 날에는 진짜 쉬는 시간이지만, 안 좋은 날에는 늘어진 회의들 사이로 사라져버린다.
- 14–18
이해관계자 회의와 리뷰
하루 중 회의가 가장 몰린 시간대다. 로드맵 리뷰, 디자인 크리틱, 영업이나 고객 통화, 그리고 다음 분기에 실제로 무엇이 출시될지를 정하는 협상들이 이어진다.
- 18–8
퇴근 시간(대체로)
개인 시간이지만, 출시 주간이나 급한 고객 이슈는 공식 퇴근 시간이 한참 지난 뒤에도 슬랙을 통해 프로덕트 매니저를 다시 끌어들이곤 한다.
노하우
현장에서 실제로 전수되는 기술 지식 — 동기부여 문구가 아니다.
설문만 하지 말고 사용자와 대화하라
설문은 사람들이 원한다고 '말하는' 것을 알려주지만, 직접 만나거나 화면 공유를 통해 누군가 실제로 제품을 써보려는 모습을 지켜보면 그들이 언급조차 하지 않았던 마찰을 드러낸다.
진짜 위험을 검증하는 가장 작은 것을 출시하라
완전한 기능을 만들기 전에, 가장 틀릴 가능성이 높은 가정을 검증하는 가장 작은 버전으로 줄여라. 때로는 그 뒤에 아무것도 없이 클릭 수만 측정하는 버튼 하나면 충분하다.
직함이 주지 않는 권한은 스스로 얻어내라
사람들의 의견이 엇갈릴 때 방향을 정하고 최종 결정을 내리되, 그 권한이 직함에 딸려 온다고 여기지 말고 준비와 판단력으로 얻어내라. 조직 내 권력이 없는 프로덕트 매니저는 그저 명령만 내리면 되는 매니저보다 더 자주 옳아야 한다.
거절은 글로, 이유와 함께
기능 요청을 조용히 거절하면 앙금만 쌓인다. '왜 저것이 아니라 이것을, 이번 분기에'라는 트레이드오프를 한 문장으로 써주면, 거절이 사람들이 실제로 반박하거나 받아들일 수 있는 결정으로 바뀐다.
아무도 움직일 수 없는 지표는 의심하라
제안된 성공 지표가 과거 여러 차례의 시도에도 눈에 띄게 움직인 적이 없다면, 그것을 움직이는 데 한 분기의 로드맵을 걸기 전에 정말 그것이 맞는 척도인지 의문을 품어라.
일의 도구들
분석 플랫폼
앰플리튜드, 믹스패널이나 사내 대시보드 같은 도구는 원시 사용 로그를 프로덕트 매니저가 실제로 추론할 수 있는 퍼널과 코호트로 바꿔준다.
이슈 및 로드맵 트래커
지라, 리니어 같은 도구는 아이디어 목록을 엔지니어링, 디자인, 리더십이 모두 동시에 볼 수 있는 우선순위 매겨진 백로그로 바꿔준다.
명세서/PRD 템플릿
문제, 목표, 요구사항, 예외 상황, 성공 지표로 구성된 구조화된 문서 양식으로, 엔지니어가 추측 없이 그대로 만들 수 있을 만큼 명세서를 명료하게 유지해준다.
A/B 테스트 플랫폼
옵티마이즐리 같은 도구나 사내 실험 프레임워크를 이용하면 팀이 서로 다른 사용자에게 두 버전의 기능을 내보내 실제로 어느 쪽 성과가 더 좋은지 측정할 수 있다.
AI 초안 작성 보조 도구
ChatGPT나 Claude 같은 도구는 점점 더 명세서 초안을 작성하고 사용자 인터뷰를 요약하며 설문 응답을 종합해준다. 이 일의 무게중심을 백지에서 타이핑하는 것에서 편집과 판단으로 옮기고 있다.
실패하는 이유
기능 공장 증후군
실제로 문제를 해결했는지가 아니라 얼마나 많은 기능을 출시했는지로 성공을 측정하는 것. 바쁜 로드맵은 만들어내지만 실제로 나아지지 않는 제품을 낳는다.
가장 목소리 큰 고객이 요청한 것을 만들기
그것이 상당수 사용자가 공유하는 문제를 반영하는지 확인하지 않고, 목소리 큰 한 고객의 구체적인 기능 요청을 대표적인 니즈로 취급하는 것.
명세서에서 '왜'를 생략하기
밑바탕이 되는 문제나 목표를 설명하지 않고 요구사항 목록만 상세하게 적으면, 현실이 계획과 필연적으로 어긋났을 때 엔지니어가 좋은 판단을 내리지 못하게 된다.
계속 탐색하기
비즈니스·금융 분야의 다른 직업
🚀
기업가
회사를 세우는 사람 — 틈새를 발견하고 위험을 감수하며 급여 지급까지 책임지는 존재로, 아시리아의 대상 금융업자에서 벤처 투자를 받는 창업자까지 이어진다.
AI 내성 88 💹투자은행가
기업의 가치를 매기고 자본을 움직이는 딜메이커 — 메디치가의 피렌체에서 오늘날의 피치북까지 이어지는 거래로, 수십억 달러가 오갈 때 신뢰의 대가로 보수를 받는다.
AI 내성 42 🧾회계사
장부의 수호자: 문자 자체를 만들어낸 오래된 기술의 계승자이자, 이제는 자신을 자동화하려는 소프트웨어와 협상 중이다.
AI 내성 35 📣마케터
수요를 만들어내는 전문가. 폼페이의 벽화 광고와 P&G의 1931년 브랜드맨 메모에서 경매 기반의 디지털 피드 시대까지.
AI 내성 38 💱경제학자
희소성을 다루는 학자 — 애덤 스미스의 핀 공장에서 중앙은행 결정실까지, 어떤 모형도 완전히 담아내지 못하는 것을 예측하라는 요구를 여전히 받는다.
AI 내성 62