읽어야지라고 생각만 하던, 프로덕트 오너를 드디어 읽어봤다.
핀블이 끝난지 얼마 되지 않아서인지 마음에 와닿는 구절이 많았다.
그리고 PM/PO 직무가 더 하고 싶어졌다.
아마 내 기본적 성향 때문에 그런 것 같다.
PO는 권한은 전혀 없지만,
회사, 제품, 동료 더 나아가 사회에 주는 임팩트는 지대하다.
역시 미시적인 것보다 거시적인 걸 좋아하는 걸까 난.
프로덕트 오너는 미니 CEO다
- PO는 독재자처럼 군림해서는 안 된다. ... PO는 최대한 많은 맥락을 설명해줘야 한다.
- CEO보다 미니 CEO로 불리는 PO가 하는 일이 더 어려울 수도 있다. 왜냐하면 주어진 권한이 전혀 없기 때문이다. 그래서 PO는 늘 명확한 사실과 데이터를 가지고 설득해야 한다.
- 그런데 PO는 그렇게 지시할 수 없다. 늘 설득의 연속이다. 최대한 구체적인 사실을 서술하거나 설명해주는 것이 PO의 역할이다. 그리고 자신의 실력을 끊임없이 증명하면서 다른 이들에게 존중받아야 한다. 단기간에 이들의 마음을 얻는 것은 매우 힘들지만, PO는 책임감 있는 모습을 보여주면서 함께 일하는 동료들과 고객이 존중하는 사람이 되려고 노력한다. 그리고 그들에게 "이런 방향으로 나가고자 하니, 이번에는 이걸 개발해보면 어떨까?라고 의견도 물어봐야 한다.
- 문제가 발생하면 PO에게 질문과 눈길이 쏠리지만, 큰 공을 거두면 PO는 함께 이룬 동료들에게 공을 돌린다. 그들이 직접 두 손으로 만든 서비스이기 때문이다. 부여된 책임감은 많지만, 권한이 없는 PO는 언제나 겸손해야 한다.
고객의 목소리를 어디까지 반영할 것인가?
고객은 제품을 고용한다
- 크리스텐슨 교수는 고객은 해결해야 할 일이 생길 때, 그것에 도움을 주는 제품을 고용(구매)한다고 설명했다.
- 밀크셰이크 사례로 알 수 있듯이, 고객이 동일한 제품을 고용하는 이유는 한 가지가 아닌 경우가 다반사다. 그래서 고용되는 이유를 나열하는 목록은 주로 세 가지에서 다섯 가지 정도로 정리하는 편이다. 가장 처음에 내세우는 항목이 물론 제일 중요한 고용 이유이고, 아래 목록으로 내려갈수록 부수적인 것들로 채워진다.
- 만약 오전 시간에 밀크셰이크의 판매량을 당장 뺏어오고 싶다면, 밀크셰이크만큼 오래 섭취할 수 있고, 적당한 포만감을 주며, 더 쉽게 살 수 있는 제품을 선보여야 할 것이다.
- 밀크셰이크라는 제품 자체가 아니라(ex. 콜라, 사이다) 고용하는 이유에 맞추어 경쟁사를 분석해야 함
- 설문조사나 이미 지나간 과거의 데이터를 보고 시장의 수요를 추측하는 것은 PO에게 적절한 방식이 아니다. 당장 직면한 현재의 고객이 어떤 제품을 고용하고 있는지, 그리고 그걸 왜 선택하는지에 대한 관점으로 분석하도록 해야 한다.
서비스는 하나라도 사용자 유형은 다양하다
- PO는 한정적인 시간과 개발 자원을 효율적으로 사용하여 프로덕트가 최대한 고용되길 바란다. 그러기 위해서는 고객이 모두 똑같지 않다는 사실을 받아들여야 한다.
- (몇억 명의 고객은 각기 다른 이유로 아마존을 고용) 출근하는 미국인들이 오전에 패스트푸드 지점에서 밀크셰이크를 고용하는 이유는 동일했다. 수많은 고객의 통일된 의향을 파악하려면, 먼저 고객의 관점에서 바라봐야 한다.
- PO가 범하기 쉬운 실수 중 하나는 프로덕트를 만드는 사람의 관점에서 고객을 바라보는 것이다.
모든 사람을 만족시킬 수는 없다
- 이런 경우에 나는 극단적인 상황을 가정해놓고 결정을 내리는 편이다. 스스로에게 “만약 리테일 거래자와 우량 거래자 중 오직 한쪽만 택해야 한다면, 어느 쪽을 선택할 것인가?”라는 질문을 던졌다. 우선순위를 정하기 어려울 때 이런 질문은 큰 도움이 된다. 머릿속으로 어느 한 부류가 사라졌을 때 프로덕트에 끼치는 영향을 강제적으로 상상해볼 수 있기 때문이다.
식스 페이저로 모두의 동의를 얻어 기록하라
- 내가 식스 페이저 문서를 작성할 때, 고객 분류와 더불어 공을 제일 많이 들이는 것이 바로 원칙이다. ‘가이드 원칙’이라고 부르는 이 부분에는 주로 4~6개의 원칙을 목록화한다. 해당 프로덕트를 개발하거나 운영할 때 꼭 지켜야 하는 법 같은 것이다. 1번이 가장 중요한 원칙이고, 내려갈 수록 부수적인 것들로 채운다.
고객의 요청과 회사가 정한 목표가 충돌한다면
- PO가 회사의 성장 전략을 짜지는 않는다. 기술 전략을 정립하지도 않는다. PO가 고객만 대변해서도 안 된다. 대신 회사 내 전문가들의 의견을 종합하고, 고객의 목소리를 함께 고려하면서 프로덕트가 어떻게 발전해야 최대한 많은 요구사항을 충족할 수 있을지 고민해야 한다.
- 고객의 요청과 사업적인 요구사항 중 하나만 극단적으로 선택하라고 하면 나는 후자를 택할 것이다.
- 그래서 식스 페이저를 작성할 때도 맨 첫 문장부터 프로덕트가 회사 전체 내에서 어떤 역할을 맡고 있는지 명시한다.
- 회사 전체가 고객을 위한 최상의 경험을 제공하려고 한다면, 그중 한 부분인 프로덕트도 그에 걸맞은 역할을 맡아야 한다.
- 회사 전체에 대한 유기적인 고려 없이 독단적으로 고객을 위한다는 취지로 방향성을 잡는 건 옳지 않다.
- 고객의 목소리에 귀 기울이는 것만큼 회사가 정한 목표와 의견에도 집중하도록 하자. 회사가 없으면 고객에게 더 나은 경험을 제공할 기회까지 사라지기 때문이다.
TIP: 페르소나와 고객을 혼동하지 마라
- 고객이 누구인지 파악할 때는, 데이터와 사용 패턴 등을 감안하여 최대한 포괄적으로 접근해야 한다. 다음과 같은 질문을 해보면 도움이 된다.
- 이 프로덕트를 사용하는 사람은 누구인가?
- 개개인이 아닌 법인이나 단체가 이 프로덕트를 사용하는 경우도 있나?
- 사용자는 어떤 가치를 얻으려고 하는가?
- 프로덕트가 그 가치를 직접적으로 제공해줄 수 있나?
- 성공적으로 제공했다는 사실을 데이터로 증명 가능한가?
- 동일한 가치를 추구하는 사용자 집단을 묶을 수 있나?
- 프로덕트를 사용해서 어떤 가치를 얻으려고 하는지 이해한다면, 역으로 그 가치를 각각 추구하는 사용자들을 하나씩 그룹화할 수 있다. 더 이상 통합할 수 없는 단계까지 도달하면, 그게 PO가 고려해야 하는 고객의 목록이 된다.
데이터 속에서 진실을 찾는 방법
자신을 믿지 말고 데이터를 신뢰하라
- 특히 긍정적으로 보이는 데이터일 수록 거짓이라고 가정해본 후 철저하게 파고들어야 한다.
- 결과라고 여겨지는 데이터가 얼마나 유효한지 의심을 가져야 하는 이유는, 데이터 속에 거짓이 숨어 있기 때문이다. 1종 오류인 거짓 양성과 2종 오류인 거짓 음성을 감안해야 한다.
- 거짓 양성 - 실제로는 음성인데, 데이터상 결과가 양성으로 나오는 경우 (EX. 실제 영화를 관람한 고객이 작성한 관람평만을 노출하기 위한 알고리즘을 개발했을 때. 실제로 고객이 직접 적은 콘텐츠인데 알고리즘으로 인해 걸러짐) / 거짓 음성 - 실제로는 양성인데, 데이터상 결과가 음성으로 나오는 경우 vice versa.
대시보드를 통해 정기적으로 확인하라
- 주기적으로 검토하는 데이터는 일별, 주별, 월별로 집계되어 주로 매일 일 회씩 자동 업데이트되어 화면에 노출되면 도움이 된다. 나는 이런 화면을 대시보드라고 부른다.
행동을 부르지 않는 데이터는 버린다
- 그렇게 도출된 결과물을 공유해주는 자리에서 나는 데이터를 보며 계속 한 가지 질문을 속으로 되묻는다: ‘그래서 뭐?’ 조금 더 풀이하자면, ‘그래서 우리가 무엇을 할 수 있지?’ 같은 질문을 던진다.
가설을 세우고 조직의 방향성(OKR)까지 관리하라
- 나는 개발을 시작하기 전, 개발자와 UX 디자이너가 모인 회의에서 설명을 하기 시작했다. 구체적으로 어떤 고객을 대상으로 테스트할지, 그 기간은 얼마나 잡을지, 그리고 어떤 데이터의 불확실성을 제거할지 모두 공유했다. 나는 PO 개인의 발상으로 개발 방향을 좌지우지하는 것은 옳지 않다고 믿는다. 그래서 개발물의 중요도나 규모와 상관없이, 가설을 수치로 설정하고 배경 정보를 최대한 알려주려 노력한다.
- 자기 중심적인 방식을 최대한 배제하기 위해서 PO는 가설을 설정하는 데 많은 노력을 기울여야 하는 것이다.
- 기능별 가설을 설정하는 것에서 벗어나, 가설을 기반으로 조직의 방향성까지 관리하는 방법(OKR)도 있다.
- Objective & Key Results(목표와 핵심결과)의 줄임말인 OKR은 회사 전체의 목표와 직원 개개인의 목표를 맞추기에 효과적이다. 매 분기마다 회사의 목표를 약 세 개 정도 설정한다. 그리고 그 목표를 달성했는지 확인하기 위한 핵심 결과를 수치화한다.
- 목표는 구체적인 액션이어야 하며,
- 핵심 결과는 무조건 수치로 검증할 수 있어야 한다.
리스크를 최소화하기 위한 데이터 검증법
- 로그를 심고, 데이터 마트를 만들고, 태블로를 구축하고, A/B 테스트 플랫폼까지 연동해놓는 것은 장기적으로 빼놓을 수 없는 투자다.
효율적인 일정 관리의 비밀
스토리 티켓으로 누구에게 무엇을 알려야 하나?
- 개발 과정에서 PO가 해야하는 가장 큰 임무 중 하나가 구체적인 요구사항을 정하는 것이고, 그걸 개발팀에 전하는 방식이 바로 티케팅이다.
- 일단 티케팅 단계에 도달하기 전, 새로운 기능을 만들어야 할 때 나는 별도의 문서를 작성한다. 약 두세 장짜리로 한정하고, 이를 장수에 따라 투-페이저 또는 쓰리-페이저라고 칭한다.
- PO가 개발자에게 존중받는 가장 확실한 방식은 요구사항을 명확하게 전달하는 것임을 명심하라.
PO가 해서는 안 되는 일
- 고객의 니즈를 정의하는 데에 집중해라. 모든 걸 하려고 하지 마라.
스크럼 회의 때 해야 할 일
- 기록 잘 해두고 중요한 일은 빠르게 타 부서, 팀원에게 전달하라
디자이너를 최고의 파트너로 삼는 법
디자이너는 PO의 의도를 구현해주는 최고의 파트너다
- 진정으로 고객에게 큰 가치를 전하는 프로덕트를 개발하고 개선하는 일에는 디자인이 매우 큰 비중을 차지한다.
- PO는 디자인을 하는 직무가 아니다. 개발팀을 위한 공유 문서를 작성하고 난 후, 나는 디자이너에게 가장 긴밀하게 설명하고 함께 달성하고자 하는 목표를 설정한다. 특히 대대적인 디자인 개편을 할 때에는 어떤 사항을 지켜야 하는지 알려주는 ‘가이드 원칙’을 중심으로 설명해준다.
- PO는 디자이너가 시안을 완료하기 전에 수시로 작업물을 공유받으려고 해서는 안 된다. … 대신, 언제까지 시안을 공유받아 리뷰를 진행할지는 협의 후 완료 예정 시간(ETA)으로 정해야 한다. 디자인 시안이 완성되어야 개발에 착수할 수 있고, 결국 고객에게 선보일 수 있기 때무니다.
과연 편리하고 직관적인 디자인인가?
- PO는 사용자가 고민하지 않고 편하게 사용할 수 있는 프로덕트가 탄생하도록 질문해야 한다. 나는 절대로 디자인에 대한 시각적 코멘트를 하지 않는다. 오로지 고객이 사용할 때 어떤 느낌이 들지 가정해보며, 조금이라도 모호한 점들을 찾아내려고 노력할 뿐이다.
- 나는 디자인 리뷰 때 다음과 같은 원칙을 스스로 지키려고 하는 편이다.
- PO는 오로지 고객을 대변하는 입장이어야 한다. 감정, 관계 등을 일체 배제한다.
- 개발하고자 하는 기능에 대해 정한 원칙에 기반하여 판단한다.
- 디자이너에게는 질문의 형태로만 의견을 피력한다. 절대로 지시하지 않는다.
- 질문한 후에는 디자이너의 의견을 경청한다. 모든 시안은 고심의 결정체다.
- 구두로 거론된 내용을 회의 직후 기록하여 전달한다. 디자이너가 선호하는 방식을 따른다.
동료 직원을 대상으로 캐주얼 UT를 하라
- 실제 고객을 대상으로 UT를 진행하기 전, 동료 등 내부 직원을 대상으로 간소화된 절차로 진행하는 형태를 캐주얼 UT라고 부른다.
- 프로토타입이란 디자인 시안의 다양한 화면을 서로 순서에 맞춰 링크해둔 파일이다.
TIP: 의견과 요구사항은 다르다.
- PO는 요구사항을 전달해야 한다. 요구사항이란 프로덕트가 갖춰야 하는 기능, 고려해야 하는 제약, 추구하고자 하는 목표 등을 설명하는 것이다. 오로지 고객 중심적인 관점으로 어떤 경험을 제공해야 하는지 객관적으로 설명해야 한다.
- 의견
- 젊은 여성 고객이 선호하는 디자인으로 해주세요.
- 이 버튼을 누르면 팝업이 여기에 떴으면 좋겠습니다.
- 문구 크기는 최대한 키웠으면 합니다.
- 요구사항
- 고객이 구매하기 전, 구매 내용을 최소 1회 확인할 수 있어야 합니다.
- 고객이 결제할 때, 할부 구매 방법을 인지할 수 있어야 합니다.
- 고객에게 궁금증이 있을 경우, 곧바로 고객센터에 연락할 수 있도록 안내해야 합니다.
- 고객이 가입할 때, 다음과 같은 두 가지 이용 약관은 반드시 노출되어야 합니다.
- 의견
개발팀과의 협업을 성과로 이끄는 애자일 전략
확실한 스프린트 수행법, 스프린트 플래닝
- 스프린트 플래닝은 말 그대로 하나의 스프린트를 계획하는 회의다. ‘단거리 전력 질주’라는 뜻의 스프린트는 애자일 방식의 조직에서 2주 단위로 나눠 집중 개발하는 것을 말한다.
- 한 스프린트 내에 끝내지 못해 그다음으로 넘어가는 것을 스필오버(Spilover)라고 부르기도 한다.
완료일을 언제로 잡는 것이 시기적절한가
- 개발에 필요한 공수 산정은 개발자와 개발 매니저에게 맡겨라. 디자인 시안에 필요한 공수 산정 또한 디자이너에게 맡긴다. 하지만 무조건 그들의 의견에 귀 기울여 개발 완료 일자를 정해서는 안 된다.
- PO가 범하기 쉬운 실수 중 하나가 일방적으로 ETA를 개발 조직에 강요하거나, 혹은 반대로 개발 조직의 의견에만 의존하여 ETA를 역으로 산정하는 것이다.
- 적절하게 반문하며 왜 일정을 맞출 수 없는지 충분히 파악하도록 하자. 만약 특정 기능을 하나 제거하거나, 그다음 버전에 적용하기로 잠시 미룰 경우 기존 ETA를 맞출 수도 있기 때문이다. 아니면 우선순위 조정을 통해 불필요한 개발물 하나를 다음으로 미루고, 몇 명의 개발자를 다른 업무에 투입시킬 수도 있다. 혹은 디자이너에 할당된 업무 중 하나를 미룰 경우, 더 중요한 프로젝트 완료에 집중할 수도 있다. 이렇게 PO는 수많은 가능성을 열어두고 검토한 다음, 개발 조직 및 디자이너와 솔직하게 의논하며 최적의 일정을 산정해야 한다.
모든 질문에 대답할 수 있는 소통의 기술
- PO는 개발자나 디자이너가 그 어떤 질문이든 편하게 물어볼 수 있는 환경을 조성해야 한다.
- PO는 늘 다른 팀원보다 조금 더 멀리 내다보고 있어야 한다. 개발자나 디자이너가 궁금해하기도 전에, 최대한 미리 정의를 다 해놓고 제공하는 것이 최적화된 협업 방식이라고 생각한다.
TIO: 속도와 확장성 사이에서 고민하라
- PO는 개발팀과 늘 확장성, 속도, 안정성 등을 함께 논의해야 한다. 적절한 시기에 대규모 투자(EX. 새로운 아키텍처 도입)를 할 수 있도록 백로그를 잘 관리하라.
고객 테스트 결과만큼 강력한 데이터는 없다
사용자 테스트(UT)로 문제점을 보완하라
- 프로토타입이 완성되는 동안, PO는 UT를 준비한다. 일단, 대상군을 정의하여 최소 세 명 이상의 대상자를 선정한다. 조건은 테스트하고자 하는 프로덕트에 맞춰 정하면 된다.
- 예를 들어, 코빗 같은 암호화폐 거래소가 UT를 진행한다면, 단 한 번도 암호화폐를 거래해보지 않은 대상자를 찾아도 되고, 혹은 가장 거래량이 많은 나이대의 헤비 트레이더를 선정해야 된다.
- 신규 유입을 원활하게 할 기능을 테스트할 거면 전자를 선정하는 것이 맞고, 거래 빈도를 높이기 위한 편의성을 테스트해보고 싶으면 후자가 적합하다.
- PO는 질문을 통해 특정 행동이나 답변을 유도해서는 안 된다. 상황을 가정해본 후 어떻게 사용하는지 확인하는 것은 가능하다. 하지만 “화면 좌측 상단에 있는 메뉴를 선택하면 어떤 화면이 나타날 거라 예상하시나요?” 같은 질문은 피해야 한다. 대상자가 화면 좌측 상단에 메뉴가 있었는지 몰랐을 수도 있는데, 알려줬기 때문이다. 그리고 그걸 누르면 다른 화면이 나올 거라고 미리 귀띔하는 꼴이 된다.
빠른 피드백 공유는 동기부여가 된다
- (UT가 끝나면) UT에서 얻은 피드백을 UT 대상자 각각에 맞춰 작성한 다음, 개발 조직 전체에 공유한다. 이때 중요한 것은, 어떤 수정사항이 발생할지 알리는 것이다. 미리 디자이너와 협의한 다음 최종 시안이 완료될 예정 시간을 설정하는 것도 도움이 된다. 무엇보다 개발팀에서 로직을 개발해야 할 경우, 이 단계에서 최대한 신속하고 명확하게 알려주도록 한다.
스프린트 기간 중 언제 테스트하는 것이 효과적인가
- 가장 효과적인 방법은 UT를 스프린트 중간인 금요일이나 월요일에 진행하는 것이다. 그러면 UT가 끝나자마자 결과를 정리하여 공유하고, 곧바로 디자이너가 남은 4~5일 동안 최종본 작업을 할 수 있기 때문이다. 그리고 나서 그 다음 월요일에 새로운 스프린트 플래닝을 하면 일정이 흐트러지지 않고 개발로 이어질 수가 있다.
프로덕트를 출시하는 최적의 시기
배포 일정을 정할 때 플랫폼을 고려하라
- 배포 주기를 정하는 것이 여러모로 효과적이다. 주로 2주에 한 번 정기 배포를 하는 것을 권장한다. 스프린트가 2주씩 진행되는 경우가 많으므로, 하나의 스프린트가 끝나는 주의 목요일에 배포하는 것이 안정적이다.
- 이때 이점은 만약 배포 후 문제가 발생했을 경우 금요일까지 활용하여 고칠 수 있다는 점이다. 스프린트가 끝나기 전, 가장 많은 개발 시간을 확보하고 추가적으로 수정할 수 있는 날까지 마련해두는 이상적인 일정이다.
- 혹시라도 스프린트 도중에 기존 프로덕트에 문제가 발생했다면, 최대한 빨리 고쳐야 한다. 급하게 수정하여 안정화된 버전을 배포하는 것을 핫픽스라고 부른다.
- 가장 이상적인 상황은 2주마다 이뤄지는 정기 배포 일정 중간의 목요일에 핫픽스 배포를 하는 것이다. 그 주간에 고쳐야 하는 것은 핫픽스 날짜에 포함시키고, 미뤄지면 중간 배포 일정에 적용하면 되기 때문이다.
- 하지만 매우 급박한 상황이라면 곧바로 핫픽스를 해야 한다.
- 배포 일정을 정할 때는 적용되는 플랫폼도 고려하도록 한다. 주로 프로덕트는 안드로이드, iOS, PC까지 총 세 가지 플랫폼에서 사용 가능하다.
- 동일한 기능을 고객에게 선보이고 싶더라도, 안드로이드와 iOS 앱 배포 일정은 다를 수 밖에 없다. 주로 안드로이드는 2주마다 진행되는 정기 배포 일자에 맞춰 업데이트를 진행하면 된다. 하지만 iOS는 앱 스토어 검토 기간을 감안하여 배포 일정을 잡아야 한다.
A/B 테스트를 활용해 트래픽을 분산하기
- 일반적인 상황이라면, 점차적으로 (신규 디자인 또는 기능에 노출되는 이용자인) B그룹의 노출 빈도를 높이는 것을 권장한다. 소수에게 먼저 보여준 다음, 시스템 또는 회사 매출 등의 데이터를 보면서 악영향을 끼치지 않는지 검증할 수 있기 때문이다.
- 만약 문제가 발생했다면 B그룹을 꺼버리고 트래픽을 모두 A그룹으로 몰아버리는 것이 가능하다. 이런 방식을 온/오프 스위치라고 부른다.
- 새로운 기능을 선보일 때, 나는 주로 다음과 같은 일정을 따른다.
| A그룹 | B그룹 | |
| 1일 차 | 95% | 5% |
| 2일 차 | 80% | 20% |
| 3일 차 | 50% | 50% |
| 10일 차 | 20% | 80% |
| 14일 차 | 0% | 100% |
- 첫 이틀 동안 문제가 발생하지 않으면, 3일 차부터 A그룹과 B그룹을 동일하게 50:50 비율로 나눈다. 실제 사용하는 이용자의 반은 새로운 디자인이나 기능에 노출된다.
- 이 시점부터 유의미한 통계적 분석을 위해 최소 7일간 이 비율을 유지한다.
- 이 기간 동안 문제가 발생하지 않았다고 해도, 나는 곧바로 B그룹을 100%로 전환하지 않는다. 최소 3일 정도는 80%로 올려본 후 다시 수치를 확인한다. 트래픽이 B그룹으로 급증했을 때 예기치 못한 문제가 발생할 수도 있기 때문이다.
- 이 모든 과정을 거친 후, 약 2주일이 지나면 새로운 디자인이나 기능을 전체 고객에 노출시킨다.
- 기술적인 이유 또는 그 외 법적인 의무 때문에 100%를 곧바로 적용해야 할 경우, PO는 언제든지 롤백할 태세를 취해야 한다.
- 롤백(Rollback)은 그 이전 버전으로 바로 되돌려 배포하는 것을 의미한다. 롤백 시에 사용되는 버전은 그 이전에 가장 안정적으로 운영되었던 것으로 택한다.
내부 직원도 고객이다
- 가장 중요한 것은 사용 안내서다. 새로운 기능을 어떻게 사용해야 하는지 구체적으로 설명해야 하기 때문이다.
- 사용 안내서 다음으로 중요한 내용은, 문제가 발생할 때 어떻게 대처해야 하는지에 대한 안내다.\
테스트 중 가설을 효과적으로 검증하려면
A/B 테스트와 P값을 활용한 가설 검증법
- PO는 P값을 보며 테스트 결과를 판단해야 한다. P값이 0으로 수렴할수록 A/B 테스트의 통계적 유의도는 100%에 가까워진다.
- 내가 사용하는 AB테스트 플랫폼은 P값이 일정 기간에 걸쳐 매우 낮게 수렴하는 트렌드를 보일 때, 그게 유의미하다고 표기해준다.
- 만약 이런 기능이 없을 경우, 나는 P값이 0.01보다 낮을 때까지 테스트를 신뢰하지 않는다.
- 주로 B그룹이 이겼다고 판정하고 새로운 기능을 모든 고객에게 노출할 때, 대부분의 주요 수치의 P값이 0.01보다도 훨씬 낮은 0.01이었다.
- 성공 지표만 사용할 수도 있지만, 새로운 기능이 끼치는 영향을 세밀하게도 보고, 거시적으로도 보려면 다음과 같이 두 가지 타입의 지표를 모두 봐야 한다.
- 예를 들어, 음식 배달 서비스 앱에서 주문 화면 디자인 개편을 했다고 가정해보자.
- 만약 프로덕트 전반의 수치를 안 보고, 특정 기능에 대한 수치만 테스트했다면 분명 PO는 첫 번째 시나리오에서 만세를 하고 B그룹이 이겼다며 신규 디자인을 전체 적용했을 것이다. 프로덕트 전체의 지표인 평균 매출을 보지 않았기 때문이다. 원인 불문하고, 프로덕트의 성공 척도 중 하나인 평균 매출이 급격하게 감소했으면 테스트를 중단했어야 한다.
- 반대로 만약 PO가 기능 관련 수치와 프로덕트 전체의 지표를 모두 봤다면, 시나리오 1에서는 테스트를 중단하고 시나리오 2에서는 B그룹이 이겼다고 판단했을 것이다. 시나리오 2에서 비록 메모 기능 사용 빈도는 조금 줄어들었지만, 메모 기능 사용을 활성화하는 것보다 주문을 더 많이 하는 게 프로덕트의 성공에는 더 큰 도움이 되기 때문이다.
실패를 인정할 줄 알아야 더 나은 경험을 제공할 수 있다
- PO는 가설을 설정하고, 테스트하고, 새로운 기능을 선보일 때마다, 그 과정을 “펀딩받았다”라고 표현하기도 한다. 회사로부터 펀딩, 즉 투자받았으니 테스트도 할 수 있는 것이다. 만약 회사가 PO에게 그 자원을 허용하지 않았더라면, 모든 게 불가능해진다.
- 따라서 PO는 가설을 세울 때마다 신중해야 한다. 그리고 개발 조직과 디자이너에게 티켓을 할당하면서, 회사를 대신하여 귀중한 자원을 투자하는 것이라는 사실을 명심해야 한다.
- PO 자신도 회사에서 펀딩을 받는 사람이라는 점을 인지하자. 테스트 결과에 승복하지 않고 더 많은 시간을 투자하여 그 결과에서 다른 의미를 찾아내려고 하는 것은 회사나 고객에게 전혀 도움이 되지 않는다.
- PO가 결정을 확실하게 내려야 개발 조직과 디자이너도 시간을 허비하지 않고 다른 목표 달성에 집중할 수 있기 때문이다.
통계적인 결과를 토대로 결정해야 진실에 가까워진다
- 직관보다는 통계적인 결과를 토대로 결정을 내려야 한다. 나 스스로보다는 실제로 여러 고객들이 보여준 집단 행동에서 비롯된 추세를 더 믿어야 하기 때문이다. 최대한 이성적으로 판단하려면, 직감을 의식적으로 무시하고 배제하도록 한다.
- 7일이라는 기간을 모두 거쳐야 시기에 따른 편차도 테스트가 감안할 수 있게 된다. 고객은 일요일과 월요일의 행동이 다르고, 목요일과 토요일의 행동이 또 다르기 때문이다.
- 일주일은 모두 거쳐야 기간적 변동(Seasonality)을 통계적으로 헤아릴 수 있게 된다.
- 그리고 일시적으로 낮춰질 수 있는 P값과 더불어, 특정 기간 내내 P값이 어느 정도로 유지되는지 알 수 있는 P값 트렌드도 고려해야 하기 때문이다.
론칭한 서비스의 문제를 바로잡기
업데이트 소식을 고객센터에 먼저 전달하라
- 고객과 가장 가까운 곳에 있는 고객센터에 미리 전달해서 고객 만족도를 높여라 + 다른 유관 조직한테까지
- B그룹을 100%로 올리게 되면 그간 고생했던 이들이 후련함을 느낄 것이다. PO로서 이때 팀원들에게 진심으로 감사를 표하기 바란다. 그들이 없었다면 새로운 디자인이나 기능을 고객들에게 선보일 수 없었을 것이기 때문이다. 프로덕트가 개선될 때마다 그 공을 PO 자신에게 돌리지 않도록 하자. PO 혼자서는 그 어떤 것도 할 수 없다는 사실을 늘 명심하자.
프로덕트는 완벽할 리 없다
- (프로덕트에 문제가 생긴 경우) PO는 필수적으로 대기해야 한다. 결정을 내려줘야 하기 때문이다. PO는 계속 상황을 파악하여 다음 중 하나를 선택해야 한다.
- 심각한 문제일 경우, 당장 이전 버전으로 롤백한다.
- 금방 고쳐질 문제일 경우, 잠시만 기다려달라고 안내한다.
- 금방 고쳐질 줄 알았지만 시간이 지체될 경우, 롤백하거나 차선책으로 대응한다.
- 결정했으면, 무조건 일관성 있게 집행하라. 롤백을 안 한다고 했다가, 롤백을 부탁했다가, 다시 고치자고 하면 모든 이들이 혼동에 빠진다. PO는 모든 상황의 중심에 있다. 개발자는 기술적으로 해결하는 책임을 지녔을 뿐, 어떤 선택을 내려야 하는지는 PO의 몫이다. 고객과 유관 부서도 PO가 결정을 내려서 안내해주기만을 기다리고 있다. 절대 우유부단하게 해동해서는 안 된다.
- 고객은 PO나 개발 조직이 예상하지 못했던 방식으로 프로덕트를 사용하기도 한다. 아무리 테스트를 오래 해도 모든 경우의 수를 검증할 수 없다. 프로덕트는 계속해서 개선될 뿐, 완벽한 프로덕트는 없다.
시간 낭비를 최소화하기 위한 전략
- PO는 거쳐야 하는 주요 과정을 이해하고, 각 직무별로 다른 이의 결과물을 기다리는 동안 시간을 낭비하지 않도록 계획하는 것이다. PO의 요구사항이 있어야 디자인 시안 작업이 가능하고, 디자인 시안이 제공되어야 개발 조직이 개발에 착수할 수 있다. 그러므로 서로 다른 업무에 집중하고 있는 동안, 각자 맡은 바를 흐름에 맞게 진행하면 시간 낭비를 최소화할 수 있다.
고객의 소리를 들을 수 있는 환경을 조성하라
- 주요 불만 사항을 위주로 VOC 리포트를 보내달라고 고객센터에 말해라, 그리고 분기마다 콜센터에 직접 가서 고객과 통화 내용을 들어봐라
- 어찌 보면 VOC 리포트는 PO의 수고를 많이 덜어주는 툴이라고 할 수 있다.
멀티태스킹으로 문제를 해결하는 세 가지 원칙
- PO의 삶에서 가장 고된 요소 중 하나는, 하루 종일 수많은 정보를 흡수하고 곧바로 생각을 정리해야 하는 것이다.
- PO가 요점을 빨리 파악하고 결정을 내려야 하기 때문에 회의에 들어가면 최대한 빨리 내용을 이해해야 한다.
- 그렇게 하다 보니 스스럼 없이 질문하는 성향이 생겼다. … 다른 이들에게는 무조건 착한 PO보다는 신속하고 정확하게 이해하는 PO가 더 필요하기 때문이다.
- 이런 PO의 삶에 적응하려면 3가지를 꼭 지켜야 한다.
- 꼼꼼해야 한다. PO의 입장에서는 하루에 회의를 10개 참석하고 수십 명을 만난 거지만, 그들에게는 자신에게 가장 중요한 요청을 PO에게 딱 1번 전달한 것이다. 그 자리에서 그 내용을 요약하여 어디엔가 기록해두지 않으면 놓치게 된다.
- 그러고 나서 우선순위를 이성적으로 정하도록 한다. … 인정 없이 우선순위를 정하라. 개인적인 감정을 모두 배제하고 가장 중요한 게 무엇인지 알아내는 게 PO의 의무다.
- 그런 후, 커뮤니케이션을 잘해야 한다. 나는 이를 기대치 관리라고 부른다. PO에게 요청사항을 전달하는 모든 이에게는, 자신의 요청사항이 제일 중요하다. 하지만 PO와 개발 조직에게는 우선순위가 따로 정해져 있다. … 나는 언제나 그 분기에 달성하기로 결정한 OKR과 성공 지표, 그리고 각 프로덕트별로 설정한 지침을 떠올리며, 각 요청사항이 어느 정도의 우선 순위인지 상대방에게 알려준다. 회의 중에 결정할 수 없다면, 회의가 끝나고 나서 최대한 이른 시일 내에 설명한다.
- 이해한 바를 꼼꼼하게 기록하고, 우선순위를 정하고, 올바른 기대치를 형성하는 것. 이 세 가지만 잘 지켜도 큰 어려움 없이 정보의 홍수 속에서 가장 중요한 것에 집중할 수 있게 된다.
어떤 인재를 PO로 선발해야 하는가
PO 채용에 앞서 일감부터 확인하자
- PO가 정말 필요한지 생각해보고, 단순히 일감이 딸리는 거면 PM이나 TPM을 뽑아라
무한한 잠재력을 알아보는 법
- PO 면접 뿐만 아니라, 그 어떤 직무의 면접에 들어가도 나는 제일 먼저 최근 업무에 대한 설명을 부탁한다. … 오래전부터 꾸준히 거쳐온 경험의 결과물인 현재의 사고방식을 이해하는 데 시간을 투자하고 싶다.
- 상대방에 대한 판단을 내리기 전, 그 지원자가 처했던 상황을 충분히 이해해야 한다. 맥락 없이 평가를 할 수는 없기 때문이다.
- 어떤 상황에서 무엇을 책임졌는지 충분히 이해하게 되면 …
- 일단 지원자가 책임진 프로덕트가 어떤 고객을 위해 무슨 가치를 제공하고 있는지 알고 있어야 한다.
- 그리고 자신이 맡은 프로덕트가 회사 전체의 목표에 어떤 역할을 하고 있는지 알고 있어야 한다.
- 회사 전체에 대해 넓은 시각을 가지고, 고객 중심적인 사고방식을 통해 성공 지표를 설정해본 경험이 있는지 확인하는 것이 중요하기 때문이다.
- (장난감을 검색창에 입력한 유저에게 어떻게 특정 고객이 가장 만족할 만한 장난감 제품을 결과 맨 상단에 노출할지 물음) 일단, 요구되는 상황을 정확하게 파악했는지 확인한다. … 정말 뛰어난 지원자라면, 이 질문에서 ‘만족’이라는 단어를 포착한다. … 만족이라는 단어 하나 때문에, 이 케이스는 개인화 영역까지 포함한다.
- 문제를 잘 파악했다면, 활용 가능한 데이터가 뭔지 파악해보는 게 좋다. … 각각에 대한 데이터를 어떤 구조로 나눠서 활용할지 고민해보는 지원자는 드물다. 하지만 그렇게 사고할 수 있는 지원자는 오랫동안 기억에 남는다.
- 가장 이상적인 지원자는 이런저런 구현 방법을 설명한 다음 그 모든 절차가 정말 성공적인지 검증하는 방법까지 제시하는 자다. … PO는 가설을 설정하고, 개발 조직과 구현한 다음, 테스트까지 해야 하는 직무이기 때문이다. 자발적으로 자신의 방식을 검증하는 프로세스까지 설명한다면, 매우 훌륭한 PO 지원자로 인식될 것이다.
- 고객과 진정으로 공감하고
- 더 나은 경험을 선사하고 싶다는 진심이 있고
- 그걸 올바른 프로덕트로 만들어 하루 빨리 제공하려는 절박감이 있다면
분명 훌륭한 PO가 될 수 있다.
그 일련의 과정에서 PO는 체계적으로 생각하고 깊게 파고들어야 한다.
이 세 가지를 갖췄다면, 체계적으로 생각하고 깊게 파고들려는 성향은 필수적으로 자리 잡힐 것이다.
'BOOK' 카테고리의 다른 글
| 비트겐슈타인의 말 (0) | 2024.06.24 |
|---|---|
| 바바라 민토 논리의 기술 (1) | 2023.05.10 |
| 비전공자를 위한 이해할 수 있는 IT 지식 (0) | 2023.04.23 |
| 린 분석 (velog 이관) (1) | 2023.04.17 |
| 데이터 문해력 (velog 이관) (0) | 2023.04.13 |
