좋은 PO(Product Owner)
좋은 PO는 도대체 어떤 사람인지 궁금했던 과거의 나에게.
이전 회사에서 저는 PO나 PM이라고 부르기에는 애매한, 서비스 기획에 피드백을 하는 전략기획실장 정도의 자리에 있었습니다.
프로덕트의 가치를 극대화하기 위해 백로그를 수집하고, 경험을 설계하고 개선하는 관점보다 사업 전략을 기획하고, 전략의 실행을 위한 기능 추가나 수정하는 사람에 가까웠습니다. 큰 차이가 없어 보이지만, 그 오묘한 차이가 자꾸만 저를 괴롭혔습니다.
그래서 이직의 과정 가운데서도 도대체 PO나 PM이 하는 일은 무엇인지, 그리고 어떻게 하는 것이 잘하는 것인지 큰 고민이 있었습니다.
없는 경험에 운이 좋게도 지금의 회사로 이직하게 되었고, 이직한 후 가장 먼저 했던 것 중 하나가 조직에서 PO의 역할들을 정리해 보는 것이었습니다. 단순 R&R의 관점에서 정리해 보니 역할과 해야 할 일이 정말 많았습니다.
대충 R&R은 이 정도로 정리가 되었습니다.
스프린트의 각 단계에서의 역할과 단계와 상관없이 상시로 해야 하는 일들. 커뮤니케이터로서 해야 하는 일들. 그리고 당연히 프로덕트에 가치를 더하는, 다시 말해 성과 책임자로서 해야 하는 일들까지...
PO가 해야 할 일은 정말 많았습니다. 그렇다면 이 일들을 다 잘 해내면 좋은 PO일까요?
R&R을 한참 뚫어져라 쳐다보다가, 문득 한 질문이 떠올랐습니다.
‘주어진 R&R은 시간이 지나면 익숙해지고, 익숙해지면 잘하겠지만, 진짜 좋은 PO는 이 R&R을 잘하는 것으로 증명이 될까?’
결국 PO는 어떤 일을 잘하는가 보다, 어떤 마음가짐을 가지고 있는지가 더 중요한 것 같다는 생각을 했습니다.
그래서 더욱 좋은 PO를 만드는 마음가짐에 대해 아래에 제 나름의 결론을 내려 보았습니다.
1. 무엇이든 유저스토리(유저 관점)로 변환하는 습관
이직 초기에 마케팅팀과 협업을 해야 하는 프로젝트가 있었습니다. 저희 팀은 이전까지 마케팅팀과 협업을 해본 적이 없었기 때문에, 프로세스나 시스템도 없었습니다. 그래서 마케팅팀의 프로모션 내용만 전달받은 후, 개발팀과 소통해서 스프린트와 별도가 가능한 리소스를 확인하고 진행하면 되겠다고 생각했습니다.
처음 소통은 잘 이루어진 듯했지만, 프로모션이 정상적으로 진행되기 위해서 빠질 수 없는 유저 요구사항이 숨겨져 있는 것을 발견했고, 결국 프로모션 시작 전 날까지 개발팀과 고생하며 앱스토어에 심사 제출을 했던 기억이 납니다. 이때 마케팅팀의 프로모션 내용을 유저 스토리로 변환했다면 개발팀도 공수 산정을 더 정확하게 할 수 있었을 텐데, 간단한 프로모션이라고 생각했었기 때문에 가장 중요한 유저가 보게 될 관점을 놓치게 되었습니다.
그래서 이때부터 사소한 백로그 아이템이라도 유저스토리로 변환하려고 노력합니다. 사실 꼭 유저스토리일 필요는 없습니다. 핵심은 유저의 관점과 나의 관점을 일치시키는 과정입니다.
유저스토리만으로 부족한 점을 채우기 위해 유저 시나리오와 수락 기준도 함께 써줍니다.유저스토리는 사용자 중심으로 관점을 전환하기 가장 간단하지만, 좋은 방법이기 때문에 습관으로 형성하면 도움이 되는 것이지, 사용자의 관점으로 나의 관점을 맞출 수 있는 다른 방법이 있다면, 그 방법을 습관으로 형성하면 됩니다.
사실 줄글로 구구절절 케이스들을 써 내려가는 것이 불편하고, 불필요하다고 느껴질 수 있습니다. 저도 지금껏 여러 기획자들과 함께했던 일해본 경험에 의하면, 기획자들은 머릿속에 기능들의 a to z를 이미 다 그려내고 있습니다. 하지만 그렇기 때문에 사용자의 경험과 관계없이 자신의 경험을 그려나가는 오류를 범하기 쉽다는 점도 경험했습니다.
이런 오류들이 쌓이고 쌓이면 결과물을 측정하기 어려운 가설을 세우게 되는 경우도 많습니다. 가설을 세우고 검증해 나가는 사이클을 통해 Product Market Fit (프로덕트 마켓 핏)이나 유저 페르소나를 점점 명확하게 맞추어가야 하는데, 계속 주변만 빙빙 돌게 되는 것이죠.
2. 공감대가 형성된 목표와 핵심 지표
PO 포지션에 있다 보면 자주 듣게 되는 질문들이 있습니다.
경영진에게는 ‘핵심 지표가 무엇인지’ 그리고 ‘지표의 달성률’과 ‘달성 전략’은 무엇인지 가장 많이 질문받습니다. 팀원들에게는 ‘프로덕트의 목표가 무엇인지’ 그리고 ‘프로덕트의 비전’과 ‘프로덕트의 로드맵’이 무엇인지 모르겠다는 취지의 질문을 많이 받습니다.
이 질문들 사이에는 당장의 성과와 장기적인 전략이라는 좁혀질 수 없는 간극이 항상 존재한다고 생각합니다. 조금만 고민해 보면 양쪽의 질문 모두 이해가 됩니다.
경영진의 입장에서는 프로덕트의 성과가 기업을 운영하고 성장시키는 것에 아주 중요할 겁니다. 팀원들은 내가 오늘 이 일을 왜 해야 하고, 프로덕트가 나아가는 방향에 내가 오늘 짠 코드가 어떤 영향이 있는지 알고 싶을 겁니다.
그래서 경영진과 팀원들 모두가 공감하는 목표가 중요합니다. 사실 이 부분은 어떤 전략이나 방법이 있는 것 같지는 않습니다. 항상 너무 어렵습니다.
프레임워크는 중요하지 않습니다. 공감대 형성이 더욱 중요합니다.다만 프로덕트의 로드맵과 단기적인 비전에 대해서 공감대가 형성된다면 벌어진 관점의 간극 사이에 징검다리 하나정도 놓는 것은 되는 것 같습니다.
제 개인적으로는 프로덕트의 미래의 모습에 대해서는 양쪽과 의논해 보고, 실제로는 핵심 지표의 선정에 신경을 더 많이 썼습니다. 목표를 달성하기 위해 관리해야 하는 핵심 지표를 설정이 적절하면 양쪽을 설득하기 훨씬 수월하기 때문입니다. 이후부터는 PO가 양쪽에 소통하기 비교적 편해집니다 (절대적으로 편해지는 것은 아닙니다).
3. 완벽한 기획은 없다. 완전한 소통은 있다.
이전 회사에서도 기획을 완벽하게 해야 한다는 압박은 있었습니다. 그래야 개발자와 디자이너들의 짐을 덜어줄 수 있을 것이라고 생각했기 때문입니다. 항상 데드라인에 쫓기는 입장에 있는 개발자와 디자이너에게 숨 쉴 공간을 주고 싶었습니다. 하지만, 기획이 항상 수정되는 것은 피할 수 없었습니다. (또르륵…)
그때마다 생각한 것은 기획보다 소통에 집중하는 것이었습니다.
완벽하게 기획해서 전달하는 것은 사실상 불가능한 일입니다. 사람인지라 어쩔 수 없습니다.
기획이 완벽한 것보다 중요한 것은 어떤 방향으로 기획이 되고 있고, 그 맥락과 근거는 무엇인지 팀원들과 빠르게 소통하는 것이었습니다. 이렇게 빠르게 소통했을 때 디자이너와 개발자들은 자신의 생각과 관점을 더할 수 있었고, 결과적으로, 자신의 의견이 반영된 결과물을 마주했을 때, 모든 팀원의 몰입도가 더 높아졌습니다.
따로 퍼실리테이팅하지 않아도 리뷰 때는 각자가 생각하는 프로덕트 개선 방향을 내놓았고, PO로서 저는 기꺼이 그 모든 아이디어들을 백로그에 수집했습니다.
결국 결과물을 내기 위해 PO가 개발자와 디자이너를 쥐어짜는 것이 아니라, 한 팀으로 목표를 향해 협력하는 PO, 개발자, 디자이너가 될 수 있었습니다.
과하게 해서 해가 될 게 없는 게 소통이라고 생각합니다.
오히려 과하게 할수록 함께하는 과정에 시너지가 난 경우가 더 많습니다.
써놓고 보니 참 별거 없어 보이는 글이네요
경험이 없다는 것이 그대로 적나라하게 드러나는 글인 것 같기도 해서 부끄럽습니다.
하지만, 제목처럼, 오늘보다도 더 경험도 아는 것도 없던 과거의 제가 미리 이런 것들을 알았더라면 이전 회사에서도 어떻게든 다양한 방법들을 동원해 Product Led Growth (제품주도성장)을 이끌 수 있지 않았을까 하는 아쉬움도 생겨, 이참에 정리를 해놓고자 합니다.
경험과 경력이 쌓여가며, 더 깊이 있는 PO가 된다면 또 다른 생각들을 남겨주고 싶어지지 않을까 생각해 봅니다.
일단 오늘의 깊이에서는 여기까지.
어떤 피드백이든 얼마든지 환영합니다
