프로젝트 성공률을 올리는 PO의 질문
일잘러 PO 이야기 5편: 목표 달성을 위한 건강한 의심
PO 커리어를 시작한 지 3년 반 동안 26개의 PRD(Product Requirements Document)를 작성했습니다. 1.6개월마다 하나씩 썼네요. PRD를 쓰지 않고 단타로 진행한 제품 개선까지 합치면 매일 가설의 바다에서 물장구 친 기분입니다.
그중에는 회사 전체를 움직일 만한 큰 변화를 만든 프로젝트도 있었고, 아무도 사용하지 않아 제 입으로 제거를 요청한 비운의 프로젝트도 있었습니다. 그냥저냥 적당히 중박 친 것도 많고요. 변명이 아니라 만드는 제품마다 성공할 수는 없습니다. 그런 마이다스의 손을 갖고 태어났다면, 사무실에 앉아 머리를 쥐어뜯으며 스트레스받을 필요도 없겠죠.
마이크로소프트에서 시험한 아이디어의 3분의 1만이 개선을 위해 고안된 지표를 개선했다. 빙이나 구글과 같이 최적화된 도메인에서는 성공률이 더 낮다. 일부 지표의 성공률은 약 10-20%이다.
슬랙의 제품 및 라이프사이클 담당 이사인 파리드 모사밧은 그의 트위터에서 슬랙의 경험으로부터 수익화 실험의 약 30%만이 긍정적인 결과를 보여준다고 밝혔다. “실험을 주도하는 팀에 있다면 최소한 70% 이상의 작업이 버려지는 것에 익숙해져야 한다.”
론 코하비, 다이앤 탕, 야 쉬, ⌜A/B 테스트 신뢰도 높은 온라인 통제 실험⌟
4번 타자들이 매 타석 홈런을 치는 것은 아닙니다. 그들 또한 중요한 경기에서 실수하고, 따끔한 패배도 경험하죠. 그럼에도 그들을 4번 타자로 만드는 차이는 타율입니다. 매 타석 출루를 하지는 못하더라도 4할의 확률로 안타를 칠 수 있는 안정감이 그들을 리그 최고의 타자로 만듭니다.
제품을 만드는 PO를 타자에 비유하고 싶습니다. 매번 대박 아이템을 만들진 못하더라도 자책하지 마세요. 하지만 ‘실패의 리스크를 최소화하고, 성공 확률은 최대화할 수 있게 일하고 있는가?’는 스스로 냉정하게 물어봐야 합니다.
제품 출시 과정을 아래와 같이 나누고, 성공 확률을 조금이라도 높이기 위해 각 단계에서 해볼 수 있는 시도를 이야기해보려 합니다. (개발 기간 제외)
백로그 수집
좋은 아이디어는 어느 날 갑자기 하늘에서 반짝 떨어지지 않습니다. 당장 만들지 않을 제품일지라도 언제나 고민을 해야 필요한 순간에 뾰족한 무기를 꺼낼 수 있습니다. 추운 겨울을 위해 곳간을 채워두는 개미처럼요. (물론 저는 언젠가 아티스트로 성공할 베짱이의 삶을 동경하긴 합니다.)
VoC(Voice of Customers): 서비스를 사용하는 고객들의 불편 사항이나 피드백입니다. 사용자를 매번 만날 수 없는 상황에서 길잡이가 되어줍니다.
사내 의견 듣기: 회사에는 다양한 직무와 배경지식의 사람들이 모여 있기 때문에 시야를 넓힐 수 있는 자원이 충분합니다.
영감 받기: 벤치마크 등 타 서비스를 보면서 필요한 것을 적절히 취할 수 있습니다. 트렌드도 파악할 수 있어 우물 안에 갇히는 상황을 견제할 수 있죠.
제품 백로그들은 놓치지 않게 정리해둡니다. 오픈된 공간에 수집하여 제품팀이 모두 볼 수 있다면, 여유가 생길 때마다 상시로 처리할 수 있는 장점도 있습니다.
가설 선정
이렇게 쌓아둔 백로그를 다 할 수 있으면 좋겠지만, 어느 조직이든 시간과 자원은 한정적입니다. 여기서 무엇을 고르느냐가 결국 ROI(Return on Investment)를 결정짓기 때문에 가장 중요하고 부담되는 순간입니다. 물론 완벽하게 미래를 예측하긴 어렵습니다. 몇 년 동안 빛을 보지 못했던 Rollin이 역주행해서 인생을 바꿔줄 수 있을 거라고 그 누가 상상했을까요? 완벽하진 않더라도 최선의 선택을 하기 위한 방법을 간절하게 탐색해보세요.
사업의 핵심 문제를 해결할 수 있는가? (=사업의 목표를 달성하는가? 사업의 방향성과 일치하는가?)
기대 효과가 충분한가?
ㄴ 데이터를 통해 배포 후 임팩트를 대략적으로나마 예측해볼 수 있습니다. (안타깝게도 성격에 따라 임팩트를 예측하기 어려운 케이스도 있습니다.)
(예측할 수 없다면) 참고할 수 있는 유사한 기능이 우리 제품 내에 있는가?
(예측할 수 없다면) 타사에 유사한 서비스가 있는가? 그 서비스의 성과는 대략 어떤가?
(예측할 수 없다면) 제품을 개발하지 않더라고 테스트해볼 수 있는가?
ㄴ 구글 설문지로 수요를 예측한다거나, 이메일로 세일즈해본다거나.
(예측할 수 없다면) 제품 개발을 최소화하여 테스트해볼 수 있는가?
ㄴ AB Test 또는 MVP 개발을 통해 유저의 반응 살피기
PRD 작성 & 리뷰
PRD는 제품 요구사항 문서입니다. 기획서와는 조금 다릅니다. PRD 작성의 목적은 화면 단위의 스펙 정의보다는 전략을 정의하는 것에 가깝습니다. 물론 필요에 따라 화면 단위의 스펙을 포함할 수도 있습니다. (이것은 PO 역할의 범위에 따라 달라질 수 있습니다)
작성한 PRD는 꼭 팀과 공유하여 프로젝트 이해도를 맞춰야 합니다. 이것이 PRD를 문서화해야 하는 이유입니다. 전략 없이 화면 기획서만 전달한다면 팀원들은 이걸 왜 만들어야 하는지 이해하기가 어려워집니다. 또한 스스로를 같이 제품을 만드는 동료가 아닌 탑다운으로 주어지는 일을 하는 수동적인 직원으로 인지하게 됩니다.
문서가 있으면 제품을 만드는 멤버들, 제품을 만들지 않지만 직접적으로 관련된 멤버들, 간접적으로 영향을 받는 멤버들에게 전파가 쉬워집니다. 특히 제품을 만드는 멤버들은 프로젝트 진행 과정에서 의문이 생길 때 PO에게 일일이 물어보는 게 아니라 문서를 찾아 보고 이해할 수 있죠. 모든 구성원이 같은 꿈을 꾸며 협업해나갈 수 있는 장점이 있습니다.
회고
프로젝트 성공에는 좋은 아이디어만 있는 게 아니라, 단단한 팀워크도 중요하죠. 제품이 성장하는 과정에서 팀도 성장해야 합니다.
회고는 전체 업무 과정을 돌아보는 과정입니다. 회고 방식은 조직에 따라, 주관하는 사람에 따라 달라질 수 있습니다만, 일반적으로 사용하는 방식은 KPT(Keep, Problem, Try)입니다. 제품 제작 과정에서 좋았서 유지하고 싶은 점(Keep)과 아쉬웠던 점(Problem)을 솔직하게 나누고, 더 개선된 방식으로 일하기 위한 액션 아이템(Try)을 도출하여 시도합니다. 다음 제품 제작 과정에서는 좀 더 나은 또는 생산적인 방식을 적용할 수 있을까요?
성과 측정
제품이 배포되면 PO의 할 일은 끝났을까요? 마지막 관문이자 프로젝트의 백미가 남았습니다. 두 번째 단계에서 선정한 가설을 평가하는 잔인하고도 살 떨리는 단계입니다. 실패를 덮어두고 외면한다면 똑같은 실패를 저지를 확률이 높아집니다. 두렵더라도 실패를 마주하고, 다음에 동일한 상황이 오면어떻게 해야 할지 레슨런을 도출하고 내 것으로 만들어야 성공 확률이 점점 높아집니다.
성과를 확인했는데 성공한다면요? 당연히 열렬하게 축하해야죠!!!
성공했든, 실패했든 그 결과는 제품팀에게 그리고 동일한 고민을 하고 있을 누군가에게도 공유해주세요. 전체 구성원이 성장할 수 있는 최고의 방법입니다.
