출시한 기능을 아무도 쓰지 않는다면
주니어 PM 성장기 #12
프로덕트 매니저로 일하면서 누구나 한 번쯤 내가 제시한 프로덕트 방향이 올바른지 고민해 보았을 것이다.
성공 가능성을 높이기 위해 수많은 데이터와 사용자 조사 결과를 종합하여 나름의 가설을 세우고 실행하지만,
모든 시도가 성공적 일리 없다.
오히려 실패할 확률이 훨씬 더 높다.
실패는 성공의 어머니라는 말이 있다.
실패를 어머니라고 부를 수 있으려면, 거기서 뭔가를 얻어야 한다.
아무것도 얻지 못한 실패는 어머니가 아니고 그냥 실패다.
실패가 클수록, 그 안에서 얻을 수 있는 배움도 깊어진다.
작은 실패는 시행착오를 덜어주고, 큰 실패는 방향 자체를 바꾸게 만든다.
최근 내가 경험한 실패와 그 과정에서 배웠던 점을 회고하고자 한다.
어느 때와 마찬가지로 목표를 달성하기 위해 무엇을 해야 하는지 고민하고 있었다.
지금 와서 생각해 보면 고민하는 척했던 것이 아닌가 싶다.
내가 담당한 프로덕트에는 사용자들이 겪는 고질적인 문제가 있었고 그 문제는 분명하고 당연해 보였다.
나는 그 문제를 해결하지 못한 이유가 그 방법이 너무 복잡해서라고 믿고 있었다.
그러니까, '무엇을', '왜' 해야 하는지 고민하기보다는 '어떻게' 해야 하는지만 고민하고 있었다.
나름대로 열심히 하긴 했다. (심지어 뿌듯하기까지 했다.)
벡터, 삼각함수 등 문과로 살아온 내 인생에 없을 것만 같았던 수학 개념까지 공부하면서 문제를 어떻게 해결해야 하는지 아이디어를 제시했다.
덕분에 나중에 나온 해결책의 퀄리티는 그다지 나쁘지 않았던 것 같다.
문제는, 너무 어려웠다는 것이다.
기능 구현까지 석 달이 걸릴 정도였다.
시간이 길어질수록 점점 초조해져만 갔다.
언젠가부터 ‘일을 하고 있다’기보단, 어디에도 닿지 않는 연구실에 갇힌 기분이었다.
스스로를 지팡이 깎는 노인이라고 칭하며 조소 섞인 농담을 하기도 했다.
아마 그때부터 마음 한구석에서 잘못하고 있다는 것을 알았던 것 같다.
기나긴 터널을 지나 기능을 출시했지만, 결과는 처참했다.
사용자 만족도 점수는 0점에 가까웠고, 심지어 이게 무슨 기능인지 이해하지 못하는 사용자도 있었다.
사용량도 형편없었다. 성공 지표는 개선되긴 커녕 뭔가를 바꿨다는 흔적조차 없었다.
심지어 내부 직원들에게도 대체 이게 뭘 한 거냐는 혹평도 받았다.
고생한 팀원들에게 뭐라 말해야 할지 모르겠고, 스스로에게 할 변명조차 떠오르지 않았다.
'PM은 항상 사용자와 가까이 있어야 한다.'
'가설 검증을 위한 기능 구현이 오래 걸리면 틀린 것이다.'
이런 내용이 담긴 책을 읽으며, 항상 PM 책은 비슷한 소리를 한다며 우매함의 봉우리에 있었던 내가 부끄러웠다.
마치 PM으로서 커리어가 모두 부정당하고 앞으로 무엇을 어떻게 해야 하는지 막막했다.
하지만, 이렇게 무너져있을 수만은 없었다.
같이 고생한 팀원들을 위해서라도 문제를 빠르게 해결해야 했다.
우선, 출시했던 기능을 롤백했다.
쓸데없는 기능은 필요 없다는 핑계를 댔지만 사실 내 실수를 눈앞에서 치워야 집중할 수 있을 것 같았다.
다음으로, 팀원과 함께 회고했다.
기능이 왜 이런 평가를 받았는지, 왜 실패한 것인지 같이 얘기를 나눴다.
그러자 애써 외면하고 있었던 문제를 직면할 수 있었다.
사용자가 진짜 겪는 문제는 무엇인지, 그것이 왜 문제인지 제대로 정의한 적이 없다는 게 가장 큰 문제였다.
돌이켜보면 처음부터 삐끗하니, 모든 게 삐걱였던 것 같다.
이를 해결하기 위해 사용자를 중심으로 문제를 재정의했다.
1. 유저 인터뷰를 통해 실제 불편한 점은 무엇인지 직접 듣고
2. 유저 테스트를 통해 우리가 놓친 행동 패턴이 무엇인지 찾고
3. 프리토타입을 제시하면서 궁극적으로 원하는 것이 무엇인지 정의해 나갔다.
이 과정에서 사용자에게 실패했던 해결책을 다시 보여주기도 했었는데, 이런 기능을 절대 쓰지 않을 것 같다는 쓰라린 피드백을 듣기도 했다.
좋았던 점은 왜 기능을 쓰지 않을 것 같은지 물어볼 수 있었고 그 과정에서 많은 힌트를 얻을 수 있었다.
문제를 재정의하자 당연하다고 생각했던 문제보다 한 단계 더 깊은 진짜 문제를 찾을 수 있었다.
심지어 그 문제를 해결하는 방법은 이전 해결책보다 훨씬 간단했다.
문제를 재정의하고 2주 만에 새로운 가설을 기반으로 한 기능을 출시했다.
새로 출시한 기능에 대한 사용자 반응은 분명히 달랐다.
만족도 점수는 80점 초반을 기록했고, 피드백도 긍정적이었다.
더불어 꾸준하고 높은 사용량을 얻을 수 있었다.
'이 기능 정말 좋네요. 저에게 정말 필요한 기능이었어요.'라는 피드백을 받고 찡한 감동을 받기도 했다.
실패하고, 고치며, 다시 시도한 경험을 통해 배운 것이 있다.
머리로는 알고 있었으니 배운 게 아니라, 체득이라는 말이 더 정확하다.
1. 당연한 건 없다. 항상 한번 더 왜를 묻고 '구체적인' 답변을 얻어야 한다.
2. 해결책은 항상 단순해야 한다. 구현이 오래 걸리면 그만큼 파급력이 크다.
요약하자면...
뻔한 소리지만, 문제를 해결하는 것보다 '진짜 문제'를 찾는 것이 훨씬 중요하다.
PM으로서 실패를 피할 수는 없다고 생각한다.
하지만 이번 경험을 통해 실패하는 방향을 한 가지 알게 되었다.
앞으로 이 방향은 내 선택지 중에 반드시 소거될 방향이 되었다.
