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