PO는 무엇을 기준으로 프로젝트를 선정할까?
문제를 문제라고 정의하는 것
이 글이 이런 분들께 도움이 되기를 바랍니다.
- 프로젝트/백로그의 우선순위 선정에 어려움을 겪고 있는 분
- 새로운 프로젝트를 시작하고자 이에 대한 실마리를 찾고 있는 분
- 제품팀의 프로젝트의 선정 기준에 대해 궁금하신 분
들어가며
Product Owner의 역할에서 가장 중요한 것은 제품을 만드는 이들과 협업하여 서비스를 만들고, 이를 고객에게 전달하여 성과를 도출해 내는 것일 것이다.
그렇기에 우리는 프로젝트의 실패 확률을 줄이고 성과를 견인해 내기 위해 끊임없이 고민한다. 그렇다면 무엇을 기준으로 프로젝트를 선택해야 뒤따라올 성과를 최대한 보장해 낼 수 있을 것인가?
고객의 문제를 해결하는 제품을 만드는 것이 정답이겠지만, 너무나 두루뭉술하다. 고객은 단 하나로 정의되기 어려운 정말 수많은 문제들을 가지고 있다. 이 중에서 어떤 문제가 진짜 우리가 해결해야 하는 문제인지를 잘 골라내야 한다.
1. 백로그/아이디어의 수집
1) 유저 인터뷰
- 유저와의 직접적으로 인터뷰를 통해 의견, 사용 행태를 수집하는 방법. '포커스 그룹 인터뷰' 방식으로 특정 페르소나를 지정하고, 이에 부합하는 대표 유저들을 뽑아 진행하는 것이 대표적이다.
- 회사 밖 일반 유저를 대상으로 하는 것이 정석적이나, 간단하게는 진행하기 위해서는 업무 관련도가 낮은 타 부서의 도움을 구하기도 한다.
- 통계적 유의미성을 확보하기까지에는 많은 물리적 시간을 투입해야 하는 단점이 있으나 데이터 너머의 유저의 진짜 사용 패턴과 생각을 알 수 있다는 장점이 있다. 그리고 유저가 기대하는 수준과 현재의 우리 제품 사이에 어떤 Gap이 있는지도 알 수 있다.
2) 유관 부서
- 마케팅/운영/CS 담당부서 등과 대화하거나 해당 부서에서 발행하는 리포트(주간회의록, 월간 리포트 등)를 주기적으로 확인한다.
- 이러한 과정을 통해 해당 부서의 담당자와의 1:1 소통에서는 PO에게 직접적으로 인입되지 않았던 부서 내 새로운 아이디어나 유저의 문제를 발견할 수 있다.
- 목적 조직을 운영하는 경우 이러한 부서들은 하나의 스쿼드를 담당하기보다는 여러 스쿼드를 동시에 담당하고 있는 경우가 많다. 가령 한 개의 마케팅팀이 A, B, C 스쿼드 제품의 마케팅을 지원하는 식이다. 해당 팀이 여러 스쿼드를 조망하는 과정에서 도출되는 거시적 관점의 해석이나 의견을 스쿼드로 역수입(?)해서 활용할 수 있다. 종종 하나의 조직과 문제에 매몰되다 보면 새로운 생각을 떠올리기 어려워질 때가 있기 때문이다.
3) 과거의 프로젝트
- 기존 배포한 제품들은 모두 실패 혹은 성공이라는 결과를 낸다. 하지만 설령 기대 수준을 초과한 성공을 하더라도 영원히 그 성장세가 지속적으로 유지되기 어렵다. 시간이 지나면 성장곡선이 완만해지는 것이 일반적인 패턴이다.
- 성장세가 꺾인 기능에 다시 J커브를 만들기 위해서 기존 성공 요인은 무엇이었고 앞으로 어떤 변화를 주어야 하는지, 혹은 실패한 기능은 왜 그렇게 되었는지 원인을 분석하고 아이디어를 덧붙여 새로운 가설을 만들 수 있다.
4) 타사 사례
- 대부분의 서비스는 '유저의 행동을 불러일으키기 위해' 애쓰고 있다. 이 측면에서 바라본다면 같은 도메인의 제품이 아니더라도 수많은 서비스들 속에서 레퍼런스로 삼을만한 점들을 우리는 찾아낼 수 있다.
- 바이럴을 일으킨 타사의 전략, 혹은 제품이 나왔을 때 우리 제품에는 어떻게 적용할지 생각하는 것은 많은 PO들이 습관적으로 하는 고민의 방법 중 하나이다.
2. 이 중 무엇을 할 것인가?
1) 목표를 잊지 말자
- 가끔 아이디어 자체의 구현에 집중하다 보면 이를 통해 달성하고자 하는 '목표'가 무엇인지 길을 잃게 되는 경우가 생기기도 한다. 비즈니스/제품의 성장이 이루어졌음을 알 수 있는 지표가 무엇인가? 그리고 이 문제를 해결하는 것이 이 지표를 변화시키는데 영향을 주는 것이 맞는가? 이 질문에 대한 답을 먼저 내려보자.
- 명확하게 달성해야 할 비즈니스 목표가 있다면 해결할 문제의 결과로 '사용자 경험을 좋게 만든다' 정도로는 충분하지 않다. 더 좋아졌다는 것을 어떻게 증명할 것인가? 또한, 이 '좋아짐'이 우리의 제품 성장에 어떻게 기여했음을 알 수 있는가?
- 가령 이전에 '필터가 사용하기 어렵다'는 고객 의견이 다수 접수 된 적 있었다. 이 불편이 지금 우리가 의도하는 '최종 목표 전환'에 어려움을 주고 있는 것이 맞는지 우선 확인했다. 실제로 최종 전환행동 전에 대다수의 유저가 필터를 이용했으나 필터 이용~최종 전환까지 이르는 과정에서 많은 이탈이 발생하는 것을 확인할 수 있었다. 필터의 재정비와 개인화를 작업을 진행했고, 변경된 필터를 이용한 최종 전환율을 향상한 적이 있었다.
2) 양, 효율 그리고 치명성
- 앞 단계를 거친 후에도 많은 문제들이 여전히 해결해야 할 백로그로 남아있을 것이다. 왜냐하면 대부분의 문제들은 발제자들이 이 이슈가 중요하고, 또 목표와 어떻게든 직/간접적으로 연결되어 있다고 생각하기 때문에 이슈 레이징 된 것들이기 때문이다. 여기에서는 어떤 방법이 가장 효과적이고 효율적인지를 확인한다.
- 먼저, 이 문제의 해결이 어느 정도 크기의 유저에게 영향을 주는지를 확인한다.
가령 쇼핑몰이라면 '특정 상품을 본 유저' 보다는 '쇼핑몰에 방문한 유저'를 대상으로 삼는 기능을 만드는 것이 대상이 되는 유저 수가 훨씬 더 클 것이다. 같은 목표를 가진 문제더라도 문제 해결의 대상이 되는 유저 모수가 커질수록 > 뒤의 전환 효율이 다소 낮더라도 모수의 양을 통해 보전되어 > 최종 목표 도달 유저의 수도 커질 확률이 높다.
- 두 번째는 문제의 효율의 확인이다.
여기서 효율은 두 가지를 의미하는데 [개발량 대비 기대 결과의 효율]이 좋을 것인지와 [대상이 되는 유저의 전환 효율]이 좋은지이다. 전자의 경우에는 동일한 기간을 투입했을 때 예상되는 지표 증가량을 비교이다. 후자의 경우에는 모수의 크기가 같다고 가정했을 때 더 탄력적으로 반응하는 유저인지를 살펴보는 것이다. 또한 퍼널의 끝보다는 앞을 개선하는 편이 더 효율적이다.
- 마지막으로는 치명성이다.
대상이 되는 유저의 수가 적더라도 그 유저에게(혹은 비즈니스에게) 치명적인 문제를 제공하고 있다면 그 고객은 영원히 우리를 떠날 뿐만 아니라 미래의 잠재 고객까지 잃는 결과를 만들 수 있다.
프로젝트의 예상 가치를 구하는 공식을 대략적으로 도식화하자면 이렇다.3) MVP를 쪼갤 수 있는가?
- 앞선 두 단계는 사실상 예측 단계에 불과하다. 현실에서 예측을 벗어나는 일은 너무나 자주 일어난다. VC로부터 투자받은 스타트업 중 75%가 실패한다고 하니 하물며 우리의 예측은 어떻겠는가.
- 목표지표에 크고 긍정적인 영향을 줄 수 있을 것이라고 생각했지만 제품을 배포하고 나서 오히려 예상을 벗어나 역행시킬 수도 있고, 유저가 탄력적으로 반응하지 않을 수도 있다. 그렇기에 '요구사항을 쪼개서 유저에게 빠르게 도달시킬 수 있는지, 그리고 그 결과를 자주 실험할 수 있는지'는 무척이나 중요하다.
3. 그리고, 무엇을 하지 않을 것인가?
더 좋은 서비스를 만들고 싶다는 마음은 끝이 없는 백로그 리스트를 만들게 된다. 물론 모두 필요한 일이고, 중요한 과업들이다. 하지만 안타깝게도 한정된 시간과 자원 속에서 모든 일은 다 해결될 수 없다. 기존 문제를 해결하는 사이 새로운 백로그가 등장하는 패턴은 제품팀에게 영원한 굴레다.
그렇기에 무엇을 '지금' 하지 않을 것인가에 대한 기준을 가져가는 것이 중요하다.
이것은 일을 하지 않기 위해서라기보단 정말 중요한 '무엇을 할지'에 더 몰입하기 위한 행동이다.
단호하게 결정하기 어렵다면 최소한 이번 분기에 집중해야 할 목표와 이를 벗어나는 것들에 대한 기준을 세워보자. 가령 나의 경우에는 전체 백로그와 1분기, 1달 이내에 의사결정이 필요한 백로그를 구분하고 있다. 제품 없이 해 볼 수 있는 시도를 구분하고 효율이 낮거나 타깃에서 벗어나는 이슈는 (여전히 어려운 결정이지만) 과감히 제거하기도 한다.
하지만 현실에서는 (1)보다는 (2)에 가깝다. 어디까지를 Do / Don`t의 선으로 둘지 판단하기 여전히 매우 어렵다.마무리하며
본 글은 프로젝트를 디벨롭하기 이전, 프로젝트를 선정하는 단계와 백로그의 우선순위를 결정하는 과정에서 어떤 기준점을 바탕으로 정보 수집 및 의사결정을 하는지 다루었다.
복잡하게는 위에 제시된 것 외에도 수많은 변수와 상황들을 고려하지만, 결국 이 모든 시도는 '제품과 고객의 갭을 줄이면서, 어떻게 목표에 효율/효과적으로 도달시킬 것인가?'에 대한 질문의 답을 찾아가는 과정이다.
고객의 니즈를 해소하면 비즈니스/제품 목표는 자동적으로 이루어질 수 있다는 믿음은 신기루다. 만약 이 말이 맞았다면 우리가 넷플릭스에서 더 좋은 화질을 감상하기 위해 돈을 더 내야 하는 일은 없었을 것이다. (나는 저렴한 비용으로 더 높은 화질의 영상을 보고 싶다...)
때로는 상충하기도 하는 복잡한 관계에 있는 이 둘을 모두 win-win 하는 제품을 만들기 위해 최선의 선택을 고민하는 분들께 조금이라도 도움이 되기를 바라며 글을 마무리한다.
모든 시도들을 응원합니다.
