Field Log · Entry

[책 리뷰] 개발 함정을 탈출하라 — 좋은 PM은 기능이 아니라 문제를 본다

지난 글에서는 『개발 함정을 탈출하라(Escaping the Build Trap)』가 말하는 나쁜 PM 3유형을 정리하고, 고객의 요구사항을 그대로 받아 적어 개발에 반영해온 내가 웨이터형 PM에 가깝다는 자각을 적었다. 그 글이 “어디에 빠지면 안 되는가”에 대한 글이었다면, 이번 글은 그 반대편을 본다. 그렇다면 좋은 PM은 대체 어떻게 일하는가.

책의 좋은 PM 관련 내용을 정리하면 핵심은 이렇다. 좋은 프로덕트 매니저는 기능을 많이 만드는 사람이 아니라, 고객의 문제와 사업 목표를 연결해서 팀이 올바른 제품을 만들도록 이끄는 사람이다. 이 글은 책에 대한 정리이자, 그 정리에 비춰 내 일하는 방식을 다시 들여다본 기록이다.

좋은 PM은 관리자가 아니다

책에서 먼저 강조하는 것은 프로덕트 매니저는 팀원을 관리하는 사람이 아니라는 것이다.

이름에 “매니저”가 들어가 있어서 개발자, 디자이너, 기획자에게 지시하는 사람처럼 보일 수 있지만, 실제 PM은 직접적인 권한이 별로 없다. PM은 사람을 통제하는 사람이 아니라, 팀이 같은 방향을 보도록 설득하고 정렬시키는 사람이다.

즉, 좋은 PM은 “내가 정했으니 이렇게 개발하세요”라고 일하지 않는다. 대신 이렇게 일한다.

“우리가 왜 이 문제를 풀어야 하는지 같이 이해해봅시다.” “이 방향이 고객과 회사 목표에 맞는지 검증해봅시다.”

좋은 PM의 힘은 직급이나 권한이 아니라 문제 이해, 설득, 정렬, 근거에서 나온다. 1편의 미니 CEO형 PM이 권한이 없는데도 권한이 있는 것처럼 행동했다면, 좋은 PM은 권한이 없다는 사실을 인정하고 다른 방식으로 팀을 움직인다.

좋은 PM은 “왜”에서 출발한다

나쁜 PM은 보통 “무엇을 만들까?” 또는 “언제까지 만들까?”에 집중한다. 1편의 표현을 빌리면, 웨이터형 PM은 “고객이 원하는 기능이 뭐지?”를 묻고, 전직 프로젝트 매니저형 PM은 “언제까지 끝낼 수 있지?”를 묻는다.

하지만 좋은 PM은 먼저 “왜 이걸 만들어야 하지?”를 묻는다. 책에서 좋은 PM은 항상 왜에서 출발한다고 설명한다.

좋은 PM이 던지는 질문은 이런 것들이다.

• 왜 이 프로젝트를 하는가?
• 고객은 어떤 문제를 겪고 있는가?
• 이 문제가 정말 중요한 문제인가?
• 이 문제를 해결하면 고객에게 어떤 가치가 생기는가?
• 이 일이 회사의 목표와 어떻게 연결되는가?
• 성공한 상태는 어떤 모습인가?
• 이 방향이 틀릴 위험은 무엇인가?

즉, 좋은 PM은 요구사항을 바로 개발 항목으로 바꾸지 않는다. 먼저 그 요구가 나온 이유와 문제의 본질을 파악한다.

좋은 PM은 고객의 말을 그대로 구현하지 않는다

좋은 PM은 고객의 말을 잘 듣는다. 하지만 고객이 말한 기능을 그대로 만드는 사람은 아니다.

책에서는 고객이 말하는 요구사항이 대개 문제 그 자체가 아니라 고객이 생각한 해결책일 수 있다고 말한다. 1편에서 정리한 웨이터형 PM의 함정이 바로 이 지점에서 갈린다.

예를 들어 고객이 “필터를 하나 더 추가해주세요”라고 말한다고 하자. 웨이터형 PM은 “네, 필터 추가하겠습니다”라고 반응한다. 하지만 좋은 PM은 이렇게 생각한다.

“왜 필터가 필요하다고 느꼈을까?” “원하는 정보를 못 찾는 것이 문제인가?” “검색 결과가 너무 많은가?” “데이터 분류 체계가 사용자의 업무 방식과 맞지 않는가?” “필터 추가가 정말 최선의 해결책인가?”

좋은 PM은 고객의 요구를 무시하지 않는다. 다만 고객의 말을 결론으로 보지 않고, 문제 탐색의 출발점으로 본다.

좋은 PM은 팀과 함께 답을 찾고, 모르는 것을 인정한다

좋은 PM은 혼자서 모든 답을 내는 사람이 아니다. 제품은 PM 혼자 만드는 것이 아니라 개발자, 디자이너, 사업부서, 고객지원, 영업, 마케팅 등 여러 사람이 함께 만든다. 좋은 PM은 각자의 전문성을 활용할 줄 안다.

책에서는 좋은 PM이 다음 사람들과 협력해야 한다고 말한다.

• 개발자와 기술적 가능성, 복잡도, 구현 방식 논의
• UX 디자이너와 사용자 경험, 주요 작업 흐름 파악
• 사업부서와 회사 목표, 수익 구조, 시장 방향 확인
• 고객과 실제 문제, 사용 맥락, 불편함 탐색
• 데이터와 실험 결과를 통해 가설 검증

좋은 PM은 “내 아이디어가 맞다”고 주장하는 사람이 아니라, 팀이 함께 올바른 문제를 풀도록 만드는 사람이다.

여기서 책이 강조하는 또 하나의 메시지가 이어진다. 좋은 PM은 자신이 모른다는 사실을 인정한다. 제품 개발 초기에 우리는 많은 것을 모른다. 고객이 정말 무엇을 원하는지, 어떤 문제가 가장 중요한지, 어떤 해결책이 효과적인지, 시장에서 성공할지, 사용자가 실제로 쓸지 — 대부분 모른다.

나쁜 PM은 모르는 상태에서 바로 해결책을 정하고 개발을 시작한다. 좋은 PM은 모르는 것을 인정하고, 실험과 학습을 통해 위험을 줄인다. 책에서 좋은 PM의 목표는 단순히 기능을 완성하는 것이 아니라 학습을 통해 위험을 줄이는 것에 가깝다.

좋은 PM은 실험으로 검증한다

좋은 PM은 아이디어를 바로 대규모 개발로 연결하지 않는다. 먼저 작은 실험을 통해 방향이 맞는지 확인한다. 책에 나오는 담보대출 서비스 사례가 그 예시다.

처음 목표는 “담보대출 신청 과정을 디지털화하자”였다. 하지만 좋은 PM인 메건은 바로 전체 온라인 시스템을 만들지 않았다. 먼저 사용자를 관찰하고, 대화하고, 문제를 파악했다.

사용자들은 대출 신청 과정에서 이런 불편을 겪고 있었다.

• 은행 지점을 여러 번 방문해야 했다.
• 서류를 다시 작성해야 했다.
• 필요한 서류가 무엇인지 몰랐다.
• 절차가 복잡해서 중간에 포기했다.

메건은 문제를 파악한 뒤, 작은 실험을 했다. 일부 신청자에게 서류를 이메일로 보내게 하고, 은행 직원이 그것을 검토하게 했다. 그 결과 은행을 직접 방문해야 했던 사람들보다 대출 신청 완료 가능성이 크게 높아졌다.

이 실험을 통해 팀은 “온라인 서류 제출”이 실제 문제를 줄일 수 있다는 것을 배웠다. 그 후에야 제품 방향을 확장했다. 즉, 좋은 PM은 이렇게 움직인다.

문제를 이해한다. 가설을 세운다. 작게 실험한다. 결과를 본다. 효과가 있으면 제품화한다.

좋은 PM은 사업 목표와 고객 목표를 연결한다

좋은 PM은 고객만 보는 사람도 아니고, 회사만 보는 사람도 아니다. 둘을 연결해야 한다.

고객에게 좋은 기능이라도 회사의 전략과 맞지 않으면 지속 가능하지 않다. 반대로 회사가 원하는 기능이라도 고객 문제가 해결되지 않으면 제품은 사용되지 않는다. 좋은 PM은 항상 이 두 가지를 함께 본다. 고객에게 어떤 가치가 있는가, 그리고 회사의 목표에는 어떻게 기여하는가.

책에서 말하는 좋은 PM은 사업 목표와 고객 목표를 결합해 가치를 창출하는 사람이다. 예를 들어 회사의 목표가 “대출 신청 완료율 증가”라면, PM은 단순히 온라인 기능을 많이 만드는 것이 아니라 고객이 어디에서 포기하는지를 찾아야 한다. 그리고 그 문제를 해결함으로써 고객에게는 편리함을 주고, 회사에는 신청 완료율 증가라는 사업 성과를 만들어야 한다.

좋은 PM은 산출물이 아니라 결과를 본다

나쁜 PM은 “기능을 만들었다”, “요구사항을 반영했다”, “백로그를 처리했다”, “일정을 맞췄다”고 생각한다. 모두 산출물(output)에 대한 문장이다.

하지만 좋은 PM은 이렇게 생각한다.

“이 기능이 실제 문제를 해결했는가?” “사용자가 더 잘 사용하게 되었는가?” “고객의 행동이 바뀌었는가?” “사업 지표가 개선되었는가?” “우리가 세운 가설이 맞았는가?”

즉, 좋은 PM은 산출물(output)이 아니라 결과(outcome)를 본다. 기능을 출시하는 것은 끝이 아니다. 출시 후 사용자가 실제로 쓰는지, 문제 해결에 도움이 되는지, 회사 목표에 기여하는지 확인해야 한다.

좋은 PM은 단계마다 역할이 다르다

책에서는 PM의 역할이 항상 같지 않다고 말한다. 제품의 단계와 팀의 상황에 따라 PM이 집중해야 할 일이 달라진다.

초기 단계에서는 고객 문제 탐색, 시장 조사, 제품 방향 검증, 작은 실험 설계, 핵심 가설 확인 같은 일을 많이 해야 한다. 반면 제품 방향이 어느 정도 검증된 이후에는 우선순위 조정, 팀 규모 확장, 백로그 관리, 실행 조율, 출시 전략, 성과 측정이 중요해진다. 즉, 좋은 PM은 상황에 따라 전략가, 탐색자, 조율자, 실행 리더 역할을 유연하게 수행한다.

책에서는 프로덕트 오너와 프로덕트 매니저도 구분한다. 프로덕트 오너는 보통 스크럼 팀 안에서 백로그 정의, 사용자 스토리 작성, 우선순위 정리, 완료된 작업 검수를 한다. 하지만 책에서는 이것만으로는 충분하지 않다고 말한다. 좋은 PM은 더 큰 질문을 다뤄야 한다.

• 제품의 가치를 어떻게 정의할 것인가?
• 시장 성공 여부를 어떻게 측정할 것인가?
• 가격과 패키징은 어떻게 할 것인가?
• 제품을 시장에 어떻게 출시할 것인가?
• 개발할 것인가, 구매할 것인가?
• 외부 소프트웨어와 어떻게 통합할 것인가?
• 우리가 올바른 제품을 만들고 있는지 어떻게 확인할 것인가?

즉, 프로덕트 오너는 스크럼 안의 역할에 가깝고, 프로덕트 매니저는 제품 전체의 성공을 책임지는 더 넓은 역할이다.

나쁜 PM과 좋은 PM을 한눈에 비교하면

1편에서 정리한 나쁜 PM과 이번 글에서 본 좋은 PM을 나란히 놓으면 이렇게 정리된다.

구분	나쁜 PM	좋은 PM
출발점	요구사항	문제
질문	무엇을 만들까?	왜 만들어야 할까?
고객 의견	그대로 구현	문제 탐색의 단서로 사용
팀과의 관계	지시하거나 전달	함께 답을 찾음
기준	기능 출시	고객 가치와 사업 성과
방식	바로 개발	가설, 실험, 검증
역할	관리자, 웨이터, 일정 담당자	문제 정의자, 조율자, 검증자
성공 판단	개발 완료	실제 문제 해결

책에서 말하는 좋은 PM을 한 문장으로 정리하면 이렇다.

좋은 PM은 고객의 문제를 깊이 이해하고, 회사의 목표와 연결하며, 팀의 전문성을 활용해, 실험과 데이터로 위험을 줄이고, 실제 가치가 있는 제품을 만들도록 이끄는 사람이다.

더 짧게 말하면, 좋은 PM은 기능을 관리하는 사람이 아니라 제품이 올바른 문제를 풀고 있는지 책임지는 사람이다.

마무리: 나의 상황에 연결하면

1편에서 나는 고객의 요구사항을 듣고 기능으로 반영하는 일을 하면서 웨이터형 PM에 가까웠다고 적었다. 이번 글의 좋은 PM 관점에 비춰보면, 내가 일하는 방식은 이렇게 바뀌어야 한다.

기존 방식은 이랬다.

고객이 요구한다 → 요구사항을 정리한다 → 기능으로 만든다 → 개발한다 → 반영한다.

좋은 PM 방식은 이렇게 된다.

고객이 요구한다 → 왜 그 요구가 나왔는지 묻는다 → 실제 업무 문제가 무엇인지 파악한다 → 그 문제가 반복적이고 중요한 문제인지 확인한다 → 우리 제품의 목표와 연결되는지 본다 → 작은 방식으로 검증한다 → 효과가 확인된 해결책을 제품화한다.

이 책을 읽고 내가 가져가는 것은 세 가지다.

1. 출발점이 다르다. 좋은 PM은 요구사항이 아니라 문제에서 출발한다. 고객의 말은 정답이 아니라 단서다.
2. 혼자 판단하지 않는다. 좋은 PM은 모른다는 사실을 인정하고, 팀의 전문성과 작은 실험으로 위험을 줄인다.
3. 결과로 판단한다. 기능을 출시한 것은 끝이 아니다. 사용자가 실제로 쓰고 문제가 해결됐는지가 기준이다.

즉, 고객의 말을 듣는 것은 맞다. 하지만 고객의 말을 그대로 개발하는 것은 부족하다. 좋은 PM은 그 단서를 가지고 진짜 문제를 찾아내고, 팀과 함께 검증 가능한 해결책을 만든다.

다음 챕터에서는 이 “좋은 PM”이 실제 조직과 전략 안에서 어떻게 작동하는지를 읽고, 또 정리해볼 생각이다.