brunch

You can make anything
by writing

C.S.Lewis

by 이상현 Aug 13. 2022

[조직을 성공으로 이끄는 -
프로덕트 오너]

쿠팡의 PO가 말하는 애자일 혁신 전략






Key point summary




고객은 제품을 사지 않는다, 고용한다


제품이 단순히 구매된다는 관점에서 벗어나, 고객이 무엇을 해결하기 위해 어떤 제품을 고용했는지 생각해봐야 한다. 모든 제품과 서비스를 고용의 대상으로 바라보면, 각각 어떤 일을 고객을 위해 해줘야 하는지 알 수 있다.


메트로폴리탄 미술관이 넷플릭스나 캔디크러쉬를 경쟁자로 삼듯이, 현재 책임지고 있는 프로덕트의 고객이 대체물로 고용할 수 있는 그 모든 것들을 고려하도록 하자.




모든 사람을 만족시킬 수는 없다


고객에게 최상의 경험을 제공해야 한다고 다짐한 PO가 풀어야 하는 가장 큰 숙제 중 하나는 '우선순위를 정하는 것'이다. 물론 대규모 프로젝트도 추진해야 하지만, 곳곳에 숨어 있는 고효율 개선점을 찾는 노력을 꾸준히 하는 것이 좋다.




고객의 요청과 회사가 정한 목표가 충돌한다면


고객에게 더 나은 경험을 제공하기 위해 집착하는 것도 중요하지만, 사업을 이행하는 회사를 잊지 않도록 한다. PO는 고객과 사업이 필요로 하는 사항을 동시에 고려해야 한다.




자신을 믿지 말고 데이터를 신뢰하라


분석을 하기 전에, 다루는 데이터의 정확도와 순도에 틀림이 없어야 한다.


결과라고 여겨지는 데이터가 얼마나 유효한지 의심을 가져야 하는 이유는, 데이터 속에 거짓이 숨어 있기 때문이다. 


거짓 양성(False Positive) : 1종 오류. 실제로는 음성인데, 데이터상 결과가 양성으로 나오는 경우

    Ex) 영화관에서 실제로 관람한 고객이 작성한 관람평만을 노출하기로 한 알고리즘을 만들었다.

    이때 어떤 관람평은 실제로는 고객이 직접 적은 컨텐츠인데, 알고리즘으로 인해 걸러지게 되었다. 


거짓 음성(False Negative) : 2종 오류. 실제로는 양성인데, 데이터상 결과가 음성으로 나오는 경우. 

    Ex) 실제로 관람하지 않은 사람이 적은 관람평인데, 걸러지지 않아 노출되는 콘텐츠


PO는 개발팀과 협의할 때 반드시 봐야 하는 데이터가 무엇인지 고민해야 한다. "고객 행동을 트래킹할 수 있도록 로그를 다 심어두죠"라는 말은 PO가 어떤 데이터가 가장 중요한지 전혀 모르고 있다는 사실을 반영한다.


PO는 데이터를 기본적으로 의심해야 한다. 특히 결론이 너무 긍정적일 경우 더더욱 검증하자.




행동을 부르지 않는 데이터는 버린다


"도움이 되는 분석은, 데이터를 통해 얻은 인사이트를 토대로 그다음 어떤 행동으로 옮겨야 하는지 명확하게 제시해야 한다고 생각해요."


1) 액셔너블하지 않은 데이터 : 추석 연휴 기간의 수치 변화처럼, 그 어떤 노력으로도 효과적으로 고칠 수 없는 이슈가 있다. 이런 데이터는 참조만 하고 과감하게 무시하자.

2) 액셔너블한 데이터 : 추석 같은 연휴가 아닌데 매출이 줄어든 상황이라면, 원인을 파악해야 한다.

3) 이미 액션을 취해 대응하고 있는 데이터 : 고객 경험을 개선하기 위해 이미 노력 중이라면, 그 매출 데이터는 참조용이다.


데이터를 보면서 '그래서 뭐?'라고 물어본 후, 당장 액션을 취할 수 없는 문제라면 데이터를 무시하는 결단을 내리자.




가설을 세우고 조직의 방향성(OKR)까지 관리하라


가설은 PO의 생각을 증명하기 위해 꼭 필요한 수단이다. 

"우리가 동영상 상품평 기능을 선보일 경우, 동영상 상품평이 게시된 상품의 구매율이 N퍼센트 증가할 거라 예상합니다."


OKR(Objective & Key Results, 목표와 핵심 결과)는 회사 전체의 목표와 직원 개개인의 목표를 맞추기에 효과적이다. 목표는 구체적인 액션이어야 하며, 핵심 결과는 무조건 수치로 검증할 수 있어야 한다.




디자이너는 PO의 의도를 구현해주는 최고의 파트너다


개발자에게 코드를 어떻게 짜야하는지 알려주지 않듯이, 디자이너에게 어떤 방식으로 결과물을 도출해야 하는지 알려주는 것은 올바르지 않다. 가장 중요한 건, 디자이너가 동일한 목적의식을 갖고 작업할 수 있도록 도움을 주는 것이다.


PO는 사용자가 고민하지 않고 편하게 사용할 수 있는 프로덕트가 탄생하도록 질문해야 한다. 나는 절대로 디자인에 대한 시각적 코멘트를 하지 않는다. 오로지 고객이 사용할 때 어떤 느낌이 들지 가정해보며, 조금이라도 모호한 점들을 찾아내려고 노력할 뿐이다.




확실한 프로젝트 수행법, 스프린트 플래닝


스프린트 플래닝은 말 그대로 하나의 스프린트를 계획하는 회의다. '단거리 전력 질주'라는 뜻의 스프린트(Sprint)는 애자일 방식의 조직에서 2주 단위로 나눠 집중 개발하는 것을 말한다. 2주마다 성과를 측정하고 그다음 2주를 계획하는 것이다.



A/B 테스트와 P값을 활용한 가설 검증법


A/B 테스트 : A그룹과 B그룹으로 트래픽을 나눠 서로 비교해보는 방식. 


A그룹 : 신규 디자인 또는 기능에 노출되지 않는 이용자

B그룹 : 신규 디자인 또는 기능에 노출되는 이용자                                    


P-Value(Probability Value, 유의 확률) : 실험의 결과가 우연히 나타난 것인지 아닌지 판단할 때 사용되는 수치. A/B 테스트의 통계적 유의도가 100%에 가까워야 신뢰할 수 있다.                               


새로운 디자인이나 기능을 선보이기 전, A/B 테스트를 활용하는 것은 거의 필수적인 요소다. 만약 A/B 테스트 결과가 원래 설정해뒀던 지표를 달성할 수 없을 것 같으면 포기해야 한다. 그동안 투입된 자원과 시간을 아까워해서는 안 된다.





Outro


약 4주 동안 PMB 수강을 통해 학습했던 내용들을 전반적으로 가볍게 복습하는 느낌이었다.


JTBD, Actionable/Vanity Metrics, OKR 같은 개념들이 실무에서 어떤 필요성에 의해 생겨나고 사용되고 있는지 파악할 수 있었다. 또한 PM이 고객의 문제를 어떻게 파악하고 정의하며, 무엇을 만들어야 하는지 결정해 실행에 옮기고 성과를 측정하는 일련의 과정을 상세히 이해할 수 있었다.


또 위클리 과제로 한 프로덕트를 분석하면서, PM에게 대단히 기발한 아이디어나 창의성이 매우 중요하지는 않다는 생각이 들었다. 그보다 가장 중요한 역량은 '논리적 사고방식'이라고 생각한다. 이것이 없으면 PM의 핵심이자 업무의 출발점인 '문제 정의'를 제대로 할 수 없기 때문이다. 그저 상황을 정확히 보고, 듣고 무엇이 문제인지 정확하게 파악해서 논리적으로 풀어나가야 한다.


커뮤니케이션 능력, 데이터 리터러시, 도메인에 대한 지식 등 PM/PO의 채용 공고만 봐도, PM/PO에게 중요하며 요구되는 역량은 다양하다. 하지만 책에서 이야기하는 것처럼 이성적으로 수치화하고, 원칙에 의거해 판단할 수 있는 논리적 사고방식이 없다면, 정확한 문제 정의에서 시작해 가설을 설정하고 실제로 검증하는 과정을 책임질 수 없을 것이다.




브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari