문제를 어떻게든 해결하는 사람
뭣이 중헌데
최근에 약 3개월 간 진행했던 장기 프로젝트가 끝났고 이에 대한 TF 회고까지 마쳤다. 작은 티켓을 진행할 때와는 확연히 다른 난이도에 정신없이 시간을 보내고 나니 어느새 6월이 다 지나가 있었다. 배포 후 모니터링 기간에도 별다른 이슈가 없어서 잘 끝난 줄 알았더니, 딱 모니터링이 끝나는 날에 마케팅 성과 집계와 연관된 이슈가 터져서 '2차 회고를 준비해야 하나..' 하며 이마를 짚었다.
마침 그런 시기에 기획자의 직업윤리를 정리한 좋은 글을 읽게 되었다. 기획자의 커리어 방향성부터 글쓴이가 정의한 PM의 의미까지, 소화시키면 도움이 될 내용이 많아 북마크를 해두었다.
문제를 잘 정의한다는 건 뭘까
문제를 정의한다는 것은 현 상황을 개선하고 타개할 방법을 찾기 이전에, 현상에 대한 본질적인 원인이 무엇인지 파악하는 행위에 가깝다. 문제는 정의되기 이전에 현상으로 인식되고, 인식된 후에는 정말로 해결이 필요한 사안인지 분석하는 과정을 거친 뒤 비로소 정의된다. 제품의 문제 해결 방법에 대해 배울 당시에는 유저 인터뷰와 설문 조사를 진행하고, 페르소나를 구축하고, 유저 저니 맵을 그려 페인 포인트를 찾아내고, 그 페인 포인트를 해결해주는 방향으로 문제를 정의하는 것이 정론이었다.
다만, 이 문제 정의라는 것이 서비스의 단계에 따라 천차만별로 달라진다는 것을 너무 늦게 알았다. 이제 시작하는 단계의 제품과 이미 성숙기에 접어든 제품은 해결해야 할 문제의 방향성이 크게 달라진다. 문제를 바라보는 시각도 크게 두 가지 관점으로 나뉘었다.
서비스(비즈니스) 관점에서 해결해야 할 문제
고객 관점에서 해결이 필요한 문제
두 가지가 연결되어 있는 경우도 많으므로 굳이 이분법으로 나눌 필요는 없지만, 장기적인 관점에서는 위와 같이 연결 지어 볼 수도 있다고 생각된다. 팀의 리소스는 언제나 한정적이기 때문에, 두 가지 문제가 놓인 상황이라면 해결했을 때 더 큰 임팩트가 예상되는 문제에 집중하는 전략적인 의사결정이 선행된다. 그리고 이 임팩트의 기준은 대개 매출과 밀접한 관련이 있을 수밖에 없다.
https://www.productboard.com/blog/product-management-memes/문제라는 것이 말처럼 단순하게 정의된다면 정말 좋을 것 같은데, 최근 일을 하며 배우고 느끼는 점은 이게 참 말처럼 쉽지 않다는 점이다. 유저가 느끼는 불편과 실제 문제는 전혀 다를 수 있어서, 그 불편함 속의 본질을 꿰뚫는 게 기획자의 몫인 듯한데 그게 말처럼 쉽지가 않다는 거다. VOC로 인입된 문제를 어떠한 해석도 없이 그 문자 그대로 받아들여 서비스에 반영하면 제품의 중요 지표나 매출에 악영향을 끼칠 가능성이 높다. 또 문제를 좁혀 나가는 과정에서 기술적으로 풀어야 할 문제인지, 운영상으로 풀어야 할 문제인지 판단해야 하고 그 이후에는 문제를 기술적으로 해결할 수 있는 단위로 빠개야 하고.. 어허허. GG..
https://www.productboard.com/blog/product-management-memes/문제의 복잡도를 떠나 어떻게든 풀어낼 수 있는 사람
작은 티켓을 진행할 때야 어떻게든 문제를 단순화, 구체화하고 적은 리소스를 들여 해결 방안을 떠올릴 자신이 있었다. 다만, 그보다 큰 규모의 장기 프로젝트를 진행하다 보니 예상치 못한 이슈들이 곳곳에서 발생하면서 자신감은 무슨.. 그랜절 하기 바빴다. 기술적인 문제(기술 부채로 인한 제약), 법적으로 검토가 필요한 문제, 타협이 불가능한 문제.. 정해진 데드라인이 있는 프로젝트의 경우, 돌릴 수 있는 스프린트의 수가 정해져 있기 때문에 산정된 범주 내의 작업은 최대한 지양하는 방향으로 일이 진행된다.
그럼에도 불구하고 항상 돌발적인 문제는 생기기 마련인데, 이때 PO는 정해진 시간 내에서 최대한 효율적인 의사결정을 내려야 한다. 돌이켜보면 나는 이러한 돌발 상황이 터졌을 때, 예정에 없었던 작업(기능)은 덜어내거나 대응하지 않는 방향으로 1차원적인 의사결정을 내렸다. 더 심각한 것은, 당시의 나는 스스로 태스크 매니지먼트를 하고 있다고 오인했다는 점이다. 문제의 원인이 되는 사안을 단편적인 수치로 판단하고 스프린트 목표 달성에 악영향이 있을까 봐 과감하게 스펙 아웃하기로 결정한 것인데, 그러다 이후 논의 과정에서 설득의 논거가 부족해 앞서 내린 의사결정을 뒤엎는 상황도 있었다. 문제 현상에 대한 충분한 고민을 하지 못한 탓에 정말 단편적인 숫자에 불과한 데이터를 참고했고, 그 데이터가 가진 세부 속성을 무시한 채 결정을 내린 탓이었다.
외에도 legal risk와 연관된 문제들이 있을 수 있다. 예를 들어, 정부의 법적 규제에 서비스를 중단했던 타다가 해결 방안을 찾지 못하고 그대로 멈추었다면 지금의 타다가 될 수 있었을까? 토스가 금융 업계의 규제를 넘어 간편 송금 서비스를 런칭하지 못했더라면 당시 투자금을 유치할 수 있었을까? 서비스 운영을 위해 현행 법과 제도를 무시해야 한다는 뜻이 아니다. 법적 테두리 내에서 어떻게든 일이 되게 하는 방안을 찾아내는 것 역시 문제 해결 능력이라는 점이다.
이처럼 여러 복합적인 문제가 연이어 발생했을 때 나는 PO로서 어떤 스탠스를 취해야 할까? 문제를 좁히고 좁혀서 작은 문제로 만들고 이를 간단하게 해결할 것인가 아니면 된다/안 된다의 이분법적인 시야로 바라봐야 할까? 이렇게 적어놓고 보니 당연히 전자여야 하는데, 실제 상황에서는 그렇게 행동하지 못했다.
출처 - nintendo Super Mario Bros. | NINTENDO 뼈 아프지만, 무지는 목표 달성에 리스크가 된다
상당히 조심스러운 표현인데, 위 문장은 직군과는 무관하게 내가 주니어라서 읊조릴 수 있는 자조인 듯싶다. 주니어이든, 시니어이든 본인이 의도하는 바와 무관하게 레거시를 생산해 내는 것은 똑같다. 물론, 경험치 측면에서 앞선 시니어라면 주니어보다 치명적인 레거시를 남길 가능성은 현저하게 적다는 것이 차이일지도 모른다. 하지만 주니어이건, 시니어이건 기획자라면 그 제품에 대한 오너십을 가지게 되므로 결과에 대한 책임감도 동반될 수밖에 없다.
주니어가 시니어가 되기까지 실수를 통한 배움이 필요한 것은 사실이나, 샌드박스가 아닌 실제 라이브 환경에서 실수를 통해 얻은 교훈은 꽤나 뼈 아프기 마련이다. (.. 사실 그 이상이다ㅠㅠ)
데이터 정합성이 어긋난 수치를 보고 섣부른 판단을 내리거나, 스킬 셋 또는 도메인에 대한 경험이 부족해 맥락을 빠르게 쫓아가지 못한다거나.. Early stage에 있는 기획자는 슈퍼마리오처럼 물음표 박스를 들이받아 경험치를 부지런히 먹는 수밖에 없는 듯싶다. 그 물음표 박스는 개인적인 공부가 될 수도 있고, 동료가 될 수도 있고, 기록이 될 수도 있고, 말 그대로 물음표(어느 것에서나 얻을 수) 일 수도 있다.
잘 하자. 오늘의 회고 끝.
