Product Management를 잘하기 위해 필요한 역량
어떤 일이든, 개인이든 조직의 업무든, 육하원칙에 따라서 모든 사태를 정리해 보면 대부분의 일들이 일목요연하게 정리가 된다. 육하원칙으로 정리되지 않는 일이란, 논리적으로 풀 수 없는(혹은 논리가 존재하지 않는!) 누군가의 감정에 호소해야 하는 일들일 확률이 높다.
육하원칙 : 무엇을, 왜 누가, 언제, 어디서, 어떻게
무엇을 해야 하는가, WHAT
소위 대기업이던, 스타트업 이던, 해야 할 ‘무엇’이 정해져 있는 경우는 매우 흔하다. 대기업의 경우, N개년 계획이 보통 세워져 있고, 스타트업의 경우, 보통 다음 성장을 위해 정의된 전사 OKR에 맞춰서, 팀 OKR 이 정해지고, OKR 달성을 위해 액셔너블한 단위의 이니셔티브가 결정된다.
따라서 보통, PM 들이 가장 고민해야 하는 일은 what 은 아니다.
왜 해야 하는가, WHY
무엇이 정해졌다면, 그 일에 대한 당위는 이미 선행되어야(만) 한다. 보통의 (다음 투자를 끌어내는) 회사의 성장을 위해 정의된 what 일 것이기 때문이다. 만약 PM이 수행하는 액션의 당위성을 스스로 이해하지 못하고 있다면, 아래 두 가지 경우일 가능성이 크다.
- PM 스스로 KR을 만들기 위해 정의한 액션 아이템인데 스스로 설득되지 않았거나
- 다른 사람 (보통 대표 혹은 팀 리드)이 하자고 했는데 PM 스스로 설득되지 않았거나
두 가지 모두 결과는 마찬가지다. PM은 꾸역꾸역 팀을 이끌고 가지만, 스스로 이해하지 못한 프로젝트를 PM 보다 더 많이 이해하고 있는 프로젝트 멤버들은 존재하지 않는다.
다시 말해, PM 스스로가 그 당위를 이해하지 못했다면,
- 본인이 시작한 일이라면, 스스로 멈춰야 하고
- 남이 시작한 프로젝트라면, 그 일을 제안한 사람에게 추가 설명을 요청하거나, 프로젝트를 멈추자는 콜아웃을 해야 한다.
프로젝트에서 PM은 불확실성을 제거하는 사람이다. PM이 프로젝트의 존재 이유를 이해하지 못한다면, 그 프로젝트에서 당도해야 하는 끝 그림은 존재하지 않는 것이다. 그러니 시간 낭비하지 말고 팀을 해체해라.
누구와 혹은 누구를 위해 해야 하는가, WHO
- 누구와 해야 하는가
PM 은 보통 프로젝트를 위한 팀 구성에 대한 선택권을 온전히 갖고 있지 못하다. 보통의 스타트업은 한정된 리소스 안에서 움직이기 때문이다. 비단 PM뿐만 아니라, 팀 리드도 마찬가지 이므로, 이 부분에 대해선 크게 아쉬움을 갖지 말자.
- 누구를 위해 해야 하는가
스타트업의 서비스/제품팀은 무조건, 고객을 위해 일을 해야 한다.
언제 해야 하는가, WHEN
개인적으로 PM이 육하원칙 중에서 가장 중요하게 생각해야 하는 일은 언제라고 생각한다. 같은 액션이라 하더라도, 언제 진행하는 가에 따라 그 행동의 임팩트와 가치가 달라지기 때문이다. 하지만 생각보다 많은 PM들이 WHAT 에 신경을 쓰느라 WHEN을 간과하는 경우가 많다. WHEN 에 맞춰서 WHAT 을 스코핑 하는 훈련을 하는 것이 좋다.
기획이 늦어져서, 디자인 이터레이션이 예상보다 한번 더 돌아서, 개발 킥오프 이후, 미처 발굴하지 못한, 레거시가 있어서, 개발 리소스에 이슈가 생겨서 등은 대부분의 프로젝트에서 빈번히 발생하고, 이 모든 일들의 발생 자체를 PM이 컨트롤 할 수는 없다. PM이 할수 있는 유일한 일은, 이런 일들을 핑계로, right timing 을 놓치지 않기 위한 매 순간 빠른 의사결정을 하는 것이다.
순간 순간 의사결정을 하려면 해당 프로젝트 내에서 의사결정의 기준을 갖고 있어야 한다. 딜리버리를 하지 못하는 PM 은 대학교 랩실에서 있는 것과 다를바가 없다. 만약 당신이 기한에 못 맞춰서 딜리버리 타이밍이 계속 늦다면, 그 프로젝트의 목표를 온전하게 이해하고 있는지 스스로 물어보라.
어떻게 해야 하는가, HOW
프로젝트를 풀어나가는 방법에 대해선 PM이 스테이크홀더들을 믿고 맡기는 것이 좋다. PM은 가고자 하는 end goal 에 대해서 설득하고 얼라인먼트를 맞추는 것에 집중하고, 그 엔드골에 가기 위한 최선의 방법은, 사용성은 디자이너에게, 개발 구현 방법은 테크팀에게 넘기는 것이 최선의 결과를 만들어 내는 단 하나의 방법이다.
어디서 해야 하는가, WHERE
어디서는 서비스/제품 개발 단계에서 보통 생략한다. 보통 물리적 공간을 일컫는데, 피엠에 물리적 공간이 변수가 되는 경우는 크게 없을 것 같다.