좋은 PM은 어떤 능력을 갖춰야 할까?
아직도 많이 부족한 주니어 PM의 회고 노트
목차
1. 무지성 인터뷰 멈춰! Task Observation
2. 고객에게 빙의해봅시다.
3. 조금씩 붙여나가기, Build Up
이런 사람이라면 읽기 추천해요!
1. PM이 얼마 되지 않은 주니어
2. PM, PO가 되고 싶은 사람
한 달 전, '에딧메이트'라는 스타트업의 프로덕트 팀에 합류했다. 에딧메이트는 영상 편집 WaaS (Work as a Service) 서비스로, '영상 편집을 희망하는 사람'과 '검증된 에디터'를 이어준다. 프로덕트 팀은 크게 (1) 고객지향형 프로덕트와 (2) 내부 프로덕트를 만드는 팀으로 구성됐는데, 이 중에서 내부 프로덕트 팀의 PM을 맡게 됐다.
회사 문화 자체가 주체적이라서, 입사하자마자 바로 ERP 프로덕트를 기획할 수 있엇다. ERP 시스템을 공유하고, 저번 주에 프로덕트 팀의 PO와 미팅을 잠시 가졌다. 궁극적 커리어를 PO, PM을 생각하고 있어서, 해당 직무로 오랫동안 경력을 쌓아온 PO에게 많은 부분을 물어봤다. PO는 내가 정말 좋은 PM이 되고 싶다면, 몇 가지 능력을 갖추길 노력하라고 조언해줬다.
좋은 PM은 어떤 능력을 갖춰야 할까?
좋은 PM이 되려면... 어떤 능력이 필요하지??무지성 인터뷰 멈춰! Task Observation
1. 어딘가 묘하게 부족한 리서치
내가 프로덕트를 기획하는 과정은 크게 아래와 같다. 리서치를 통해 데이터를 수집하고, 이 데이터를 해석해 문제를 파악한다. 이 후, 문제와 얼라인되는 목표를 설정하고 기능을 기획 및 개발 작업에 들어간다.
1. 리서치 : 다양한 데이터를 수집
2. 문제 파악 : 수집한 데이터를 해석해서 진짜 문제 찾아내기
3. 목표 설정 : 프로덕트의 전반적 방향을 결정하는 목표를 설정
4. 프로덕트 기획 : 목표 달성을 가능케 하는 기능을 구상
5. 제작 : 개발자에게 프로덕트의 맥락과 방향 등을 공유하고, 제작을 진행
ERP 프로덕트를 기획할 때도 위와 같은 과정을 거쳤는데, PO는 여기서 '리서치' 단계에 아쉬움이 남았다고 말했다. ERP 프로덕트는 팀원이 쓰는 내부 프로덕트이므로, 팀원의 니즈와 페인 포인트를 알아내야 했다. 이를 위해 (1) 조사할 내용을 사전에 정리하고 (2) 인터뷰를 통해 하나하나 파악해 나갔다. 이렇게 보면, 정말 평범하고 대표적인 리서치 방법인 거 같은데, 뭐가 부족했을까?
PO는 문제를 파악하기 위한 방법으로 인터뷰도 좋지만, 가장 먼저 태스크 관찰 방식(Task Observation)을 하라고 추천했다. 즉, 리서치 단계에서 가장 먼저 할 일은 고객에게 물어보는 게 아니라, 고객이 먼저 무엇을 하는지 조용히 지켜봐야 한다는 말이다. 프로덕트를 사용하는 고객이 어떤 것을 하기 위해 무슨 일(Task)을 하는지 지켜보고, 거기서 인사이트를 뽑아내서 인터뷰를 진행하는 게 훨씬 효과적이라고 한다.
다 지켜보자! ( 출처 : <오징어 게임> )2. 인터뷰 Stay...!!
왜 PO는 인터뷰를 가장 먼저 하지 말라고 했을까? 고객을 이해하기 위해 대게 '인터뷰'라는 방법을 사용한다. 인터뷰는 계속 고객에게 "왜?"를 질문함으로써 겉으로 보이지 않는, 숨겨진 니즈와 페인 포인트를 끄집어 낼 수 있다. 하지만, 인터뷰가 항상 100% 성공적인 리서치 방법이 되는 건 아닌데, '인터뷰'는 '나'에게 크게 의존하기 때문이다. 이게 무슨 말일까?
'아는 만큼 보인다!'라는 말이 인터뷰에 그대로 적용된다. 고객을 잘 알수록 인터뷰에서 유효한 인사이트를 얻을 확률이 높아지지만, 반대로 고객을 잘 모른다면 인터뷰에서 얻을 수 있는 겐 별로 없어진다. 애초에, 고객에 대해 잘 모르기 때문에 무엇을 질문할 지도 모르기 때문이다. 고객을 애매하게 안 상태에서 인터뷰를 진행한다면, 어떠한 인사이트도 얻지 못할 수 있고 혹은, 아예 잘못된 인사이트를 얻을 수도 있다.
s...stay! 인터뷰를 당장 멈춰!!! ( 출처 : <인터스텔라> )고객에게 빙의해봅시다.
1. 고객이 하는 일 관찰하기
프로덕트의 기능은 '고객이 겪는 니즈와 페인포인트'와 얼라인되야 한다. 즉, 고객을 더 잘 이해할수록, 더 좋은 프로덕트가 탄생할 수 있으며, 이를 위해 고객에게 빙의되야 한다. 고객에게 빙의되기 위해선, 이들이 평소에 어떤 생각과 감정을 갖고 있는지 알아내야 한다.
그렇다면, 질문을 바꿔서 어떻게 해야지 이들이 어떤 생각과 감정을 갖는지 알 수 있을까? 고객이 평소에 어떤 일(Task)을 하는지 유심히 지켜봄으로써 알 수 있다. 즉, 방금 말한 태스크 관찰(Task Observation)이 필요하다. 고객이 특정 목표를 위해 어떤 일을 하는지 지켜보고, 이걸 '나'가 직접 한다고 가정해보고 고객을 이해해야 한다. 빙의를 통해 고객의 생각과 감정을 알아내고, "고객은 이런 걸 불편해하지 않을까?"라고 생각할 수 있다. 또한, 이런 부분은 다시 인터뷰를 통해 검증할 수도 있다. 결국, "인터뷰에서 무엇을 물어볼까?"를 알아내기 위해 '태스크 관찰'이 먼저 선행되야 한다.
2. 저에게 설명해주세요!
물론 상황에 따라서, 타겟 고객이 어떻게 일하는지 지켜보기 어려울 수도 있다. 내부 프로덕트를 만들기 위해선, 이 프로덕트를 사용하는 팀원의 모습을 봐야 하는데 재택 근무를 하고 있다면? 구성원의 집에 찾아가 지켜볼 수도 없는 노릇이다. 이런 경우엔 "저에게 업무를 한 번 설명해주세요"라고 요청하면 된다. 고객이 업무를 설명하는 걸 듣고, 여기서 불편해보이는 부분을 되물음으로써 알아낼 수 있다.
고객님! 스피드 웨건이 되어주세요! ( 출처 : <조조의 기묘한 모험> )3. 오늘은 내가 고객!
직접 구성원의 업무를 해보는 것도 방법이 될 수 있다. 예를 들어, 휴가를 관리하는 인사담당자를 위한 프로덕트를 만들고 싶다면, 인사담당자가 된 것처럼 실제로 휴가를 관리하는 시나리오를 대입해보면 좋다.
오늘은 내가 고객~ ( 출처 : <짜파게티 CF> )조금씩 붙여나가기, Build Up
PM에게 필요한 또 다른 능력은 프로덕트를 조금씩 개선하게 만들 수 있는 Build Up 능력이다. 어떠한 프로덕트도 처음부터 크게 만들 수도, 100% 완벽하게 만들 수도 없다. 프로덕트는 조금씩 개선되며, 이렇게 완성시킨 작은 기능 하나하나가 모여서 큰 프로덕트를 탄생시킨다. 이 때도 무턱대고 기능을 붙이는 게 아니다. 건물을 공사할 때, 밑에서부터 무지성 마구잡이로 쌓지 않고, 완성된 모습을 계속 그려가며 건설한다. 이처럼, 지금 프로덕트의 기능과 앞으로 구현할 기능 사이의 조화를 생각하고, 미래에 완성된 프로덕트가 어떤 모습일지 생각해가며 Build up을 해야한다.
또한, 단순히 필요한 기능만 스케치하는 게 아니라, 새로운 기능을 고안하면서 다양한 이해관계자에게 어떠한 영향을 줄지도 고려해야 한다. 예를 들어, 새로운 기능을 구현함에 따라 백엔드에서 데이터셋이 어떻게 영향을 주는지 고려해야하고, 프론트에서 어떻게 새로운 기능을 잘 합칠 수 있는지 고민해야 한다.
기능 합체! (출처 : <태양의 용자 파이버드> )