두 역할 모두 "PM"으로 줄여 쓰지만, 서로 다른 질문에 답합니다. 프로덕트 관리는 무엇을 왜 만들 것인가를 책임집니다. 프로젝트 관리는 그것을 어떻게, 언제 전달할 것인가를 책임집니다. 하나는 올바른 목적지를 고르는 것이고, 다른 하나는 그곳에 효율적으로 도달하는 것입니다.
두 역할 모두 "PM"으로 줄여 쓰지만, 서로 다른 질문에 답합니다. 프로덕트 관리는 무엇을 왜 만들 것인가를 책임집니다. 프로젝트 관리는 그것을 어떻게, 언제 전달할 것인가를 책임집니다. 하나는 올바른 목적지를 고르는 것이고, 다른 하나는 그곳에 효율적으로 도달하는 것입니다.
| 측면 | 프로덕트 관리 | 프로젝트 관리 |
|---|
| 핵심 질문 | 무엇과 왜 | 어떻게와 언제 |
| 초점 | 사용자 가치, 비즈니스 성과 | 전달, 일정, 범위 |
| 시간 지평 | 지속적(프로덕트 라이프사이클) | 한정적(프로젝트는 끝이 있음) |
| 성공 척도 | 성과(도입률, 매출) | 정해진 기한, 범위, 예산 준수 |
| 책임 영역 | roadmap, 우선순위, 비전 | 계획, 일정, 리스크, 상태 |
| 마인드셋 | "올바른 것을 만들고 있는가?" | "올바르게 만들고 있는가?" |
추천 프로그램(referral program)을 출시하는 경우: 프로덕트 매니저는 (다른 아이디어 대신) 추천 기능이 만들 가치가 있다고 결정하고 성공이 어떤 모습인지 정의합니다. 프로젝트 매니저는 이를 엔지니어링, 법무, 마케팅에 걸친 날짜가 명시된 계획으로 바꾸고 출시까지 끌고 갑니다.
작은 팀에서는 한 사람이 둘 다 합니다. 큰 이니셔티브에서는 둘이 구별되며 짝을 이루어 일합니다. 프로덕트가 방향을 정하고, 프로젝트가 실행을 끌고 갑니다. 갈등은 보통 우선순위와 일정에 대한 책임이 모호할 때 생깁니다.
둘을 혼동하면 빈틈이 생깁니다. 팀이 잘못된 기능을 흠잡을 데 없이 전달하거나(훌륭한 프로젝트 관리, 부실한 프로덕트 관리), 뛰어난 아이디어를 골라놓고 제때 출시하지 못할 수 있습니다.
그 구별을 아는 것은 질문을 올바른 사람에게 보내고 누가 어떤 결정을 책임지는지 이해하는 데 도움이 됩니다.