#5. PM, PO에 관한 9가지 질문들
PM과 PO는 어떻게 다른가요?
시작하며.
스타트업 IT 조직에 속하신 많은 분들과 PM에 대한 이야기를 하면 늘 궁금해하시는 질문들이 있습니다. 9가지 정도를 제 맘대로 간략히 추려서 짧게 설명드리는 글입니다.
01. PM과 PO는 어떻게 다른가요?
A) 간단하게 정리하자면.
Product Manager = Business의 주요 이해관계자와 상호 작용할 책임이 있는 사람 & 전략 수립
Product Owner = 개발팀과 상호 작용하고 Back-log를 관리하는 사람 & 전술적 역할 수행
※ INSPIRED의 저자 'Marty Cagan' 또한 이 두 직군을 거의 동의어로 대하는 것이 그리 이상하지 않았다고 회고합니다. 이 둘의 구분을 명확히 해야 될 필요성이 없는 경우가 대부분 이기도 했구요. 또한 마티 케이건 스스로도 PM 제품 관리자는 동시에 PO 제품 소유자가 되는 것이 필수적이라고 말하기도 합니다. 그러나 조직 내 비즈니스의 단계가 나아가며 조직 전체의 볼륨이 커지는 경우, 첫 번째 PO는 곧 PM의 역할을 수행하며 다수의 PO를 조직화하여야 합니다. 이를 통해 고도화된 제품을 유기적으로 연결시키는 작업을 PM이 전략적으로 만들어 갈 수 있게 됩니다.
02. PO와 PM을 나누는 경계가 있을까요?
A) 생각보다 많은 조직에서 이 직군의 명칭을 두고 혼란스러워합니다.
조직의 규모에 따라 PO와 PM 모두의 역할을 수행할 수 도 있으며, PM과 PO의 역할이 딱 나눠지기도 합니다. 두 직무는 책임을 지는 범위가 다릅니다. 그렇기에 이 둘을 나누는 질문을 한 가지로 압축하자면 아래와 같습니다.
PO와 PM을 나누는 핵심 질문 TIP)
조직에서 개발팀과 함께 back log만 관리하고 있습니까? > PO
아니면, 실제로 고객과 비즈니스의 어려운 문제를 주요 이해관계자와 함께 조율하며 해결 중이십니까? > PM
03. 주요 이해관계자에게 'no'라는 말을 할 수 있을까요?
A) 'no'라고 말을 하는 것은 때때로 큰 용기를 필요로 합니다.
하지만 이 단어는 PM, PO가 되기 위한 필수적인 자격요건입니다.
이 단어를 적시에 사용하지 못할 경우, 팀 전체를 구렁텅이로 몰고 갈 수 있습니다. 잘못된 방향 혹은 의심스러운 접근으로부터 팀을 보호해야 합니다. PM, PO는 목표로 하는 올바른 제품을 조직에 배송해야 하며, 작업량을 최소화하며 더 많은 가치를 창출할 수 있어야 합니다. 그렇기에 조직은 이들로부터 '아니오'를 존중해야 합니다. 권한이 부여된 제품 소유자 없이는 그 어떤 에자일, 스크럼도 진행 불가입니다. 그저 평범한 waterfall 2.0 이 될 것입니다.
04. 다른 팀 구성원과 어떻게 협력해야 할까요?
A) 5가지 원칙을 제시드릴 수 있겠습니다.
1️⃣ 더 빨리 초기에
2️⃣ 더 자주(시간이 지남에 따라, 뜨겁고 무거워지는)
3️⃣ 정중하게
4️⃣ 투명하게
5️⃣ 적절한 속도와 관심
보다 자세한 설명을 보고 싶으신 분들을 위해 최근 개정된 스크럼 가이드 링크를 첨부드립니다.
Link)
Scrum Guide 2020 https://scrumguides.org/scrum-guide.html#scrum-team
05. PO로 성공하려면 제품 비전이 필요한가요?
A) 물론입니다.
'어디로 가는지 모르면 어떤 길로도 갈 수 있습니다' -Lewis Carroll
회사의 비전과 전략에서 제품의 기초 뼈대가 시작됩니다. 정원에서 자라는 모든 식물의 새싹이 비슷할지라도 비전에 따라 전혀 다른 나무로 자라날 수 있습니다. 그렇기에 PO는 제품이 어느 방향으로 진화 발전되어 가는지에 맞춰 전체 제품의 윤곽과 스텍을 잘 파악하고 실행시켜 나아갈 수 있어야 합니다.
06. 좋은 PO라는 것을 어떻게 알 수 있을까요?
A) 좋은 PO의 기준을 정량적인 측면에서 찾아봅시다.
아이디어로부터 출발한 가설의 묶음을 개발 back-log에 라인업 하여 릴리즈 되는 시점까지의 리드타임, NPS 점수 평가 등을 사용해볼 수 있을 것입니다. 또한 이를 위해선 스크럼에서 사용되는 증거기반 관리를 참고해보시기를 권장드립니다. 아래 4가지 평가 항목을 통해 PO의 정량적 평가 기준을 수립할 수 있을 것입니다.
4가지 영역에서 현 비즈니스에 대한 가치 측정 평가 항목.
1️⃣현재가치 - 현재 고객 또는 사용자에게 제공되는 가치 측정
2️⃣미실현 가치 - 고객 또는 사용자의 모든 잠재적 요구 사항을 충족 시의 가치 측정
3️⃣혁신 능력 - 고객 또는 사용자 요구에 더 부합하는 새로운 영역을 제공하는 능력 측정
4️⃣시장 출시 시간 - 새로운 기능, 서비스 또는 제품을 신속하게 제공하는 능력을 측정
Link)
evidence-based-management
https://www.scrum.org/resources/evidence-based-management
07. 좋은 아이디어인지 어떻게 판단할 수 있나요?
A) 숫자로 확인할 수 있는 영역과 가치로 판단할 영역을 구분해 봅시다.
매출 증가. 고객 가입률 증가. NPS 고객 만족도 증가. 내부 프로세스 개선으로 인한 비용절감 혜택. 긍정적 고객 피드백... 등과 같은 숫자로 증명될 영역과 가치판단으로 인식될 결과가 존재합니다. 수많은 아이디어 중에 일정 정도의 베팅을 하게 될 것이며, 베팅의 과정은 논리적으로 혹은 직관적으로 이해관계자를 설득시킬 수 있어야 합니다. PM, PO는 고객을 대신하여 팀의 가치를 극대화하는 데 있어 본인의 역량을 입증해내야 합니다. 그렇기에 수많은 아이디어에서 좋은 베팅을 할 수 있어야 하며, 그 결과를 통해 조직과 팀으로부터 신뢰자본을 쌓아갈 수 있어야 합니다.
08. 아무도 원하지 않는 기능에 리소스를 잘못 할당하지 않으려면 어떻게 해야 할까요?
A) 때로는 모호한 것이 죄(?)가 될 때가 있습니다.
조직과 팀이 실패의 후속타로부터 영향을 받지 않기 위해선 분명히 확고한 태도로 'no'라고 이야기할 수 있어야 합니다. PM, PO의 잘못된 의사결정 방향은 조직 전체의 수동적 행동을 야기하게 됩니다. 그렇기에 주요 목표 KPI 지표 수립을 동반한 정기적 사용자 테스트와 같은 지속 가능한 모니터링 시스템을 세팅해야 합니다. 빌드 > 측정 > 결과 > 학습 주기에서 성공 가능성이 낮다는 증거가 발견되다면 리소스 할당을 바로 중지하여야 합니다.
'매몰 비용'의 오류에 빠지면 안 됩니다.
판단이 흐려지는 것을 허용하면 안 됩니다.
이미 얼마를 지출했더라도 실패로 예상될 작업을 지속하는 것은 조직과 팀을 낭떠러지로 끌고 갈 수 있습니다.
09. 칸반 보드를 써야만 합니까?
A) 아뇨. 도구일 뿐입니다.
절차와 도구보다 '개성과 상호작용' 이 더 우선합니다.
가장 좋은 방법은 face to face라고 생각합니다. 서로의 의사소통이 더 자주 더 긴밀하게 더 밀도 있는 대화가 이뤄지는 것을 권장합니다. 그저 메모장에 task들이 나열되어도 괜찮습니다. '작동하는 소프트웨어'가 가장 중요합니다. Early Stage의 소규모 팀을 벗어나 중규모 이상의 팀으로 나아갈 때, 일정 정도의 생산성 향상을 위한 도구들이 필요할 것입니다. 그때 어떤 도구와 방식들이 우리의 생산성을 높여서 좋은 결과로 이뤄지게 만들지 팀과 함께 논의하시면 됩니다.
목적과 수단이 역전되지 않아야 합니다.
도구는 도구로써 바라봐야 합니다.
Reference Link)
Scrum Guide 2020
https://scrumguides.org/scrum-guide.html#scrum-team
evidence-based-management
https://www.scrum.org/resources/evidence-based-management
