책 <조직을 성공으로 이끄는 프로덕트 오너>

김성한

• 프로덕트 오너 PO는 미니 CEO이다.

  • PO는 중심에 있다. 회사 내 모든 사람들이 그를 지켜본다.

  • 절대로 감정이나 직관에 치우치지 않고 사실을 기반으로, 데이터를 기반으로 모두를 위한 최선의 우선순위와 결정을 내려야 할 책임이 있다.

  • PO는 독재자로 군림해서는 안된다. 오히려 CEO보다 미니 CEO로 불리는 PO가 더 어려운 역할일 수 있는데, 주어진 권한이 없기 때문이다. 그렇기에 PO는 항상 명확한 사실과 데이터를 가지고 설득해야한다.

  • 부여된 책임감은 많지만 권한이 없는 PO는 언제나 겸손해야한다.

  • 늘 설득의 연속이다. 최대한 구체적인 사실을 서술하거나 설명해주는 것이 역할이다. 자신의 실력을 끊임없이 증명하면서 다른 이들에게 존중받아야 한다.

  • 고객에게 집착해야한다. 그리고 주변 동료들에게 고객에 집착하는 사고 방식을 전파해야한다. 단순히 개발을 하거나 디자인을 하는 것이 아니라 그것이 고객에게 얼마나 큰 감동을 줄 수 있는지 각자 충분히 인지할 수 있도록 설명해주는 것도 PO의 역할이다. 모두가 고객에 집착할 때까지 직접 현장에서 터득하고 정보를 공유해야하는 책임이 있다.

  • PO가 되기 위해 필요한 자질 3가지

    • 학력 및 전공 : 컴공이면 좋다. 그렇게 중요하지는 않다.

    • 업무 경험 : 개발 프로젝트를 처음부터 끝까지 해보는 것이 좋다.

    • 성향 및 능력 : 가장 중요하다. 이성적으로 수치화하고 논리적으로 설득하는 능력. 다양한 정보를 파고들어 논리적인 인사이트를 얻어낼 수 있는 것도 중요한 능력. 고객에게 최상의 경험을 제공하고자 하는 끈질김이 필요.

• 고객의 목소리를 어디까지 반영할 것인가

  • 밀크쉐이크 이야기

    • 고객 인터뷰를 대상으로 출시한 밀크쉐이크는 인기가 별로 없었다.

    • 직접 매장에서 하루종일 사람들을 분석해본 결과 아래와 같은 인사이트를 얻을 수 있었다.

      • 고객의 40%는 아침에 출퇴근 시간에 길고 무료한 출근시간을 출출함을 달래기 위해 이용하는 직장인 → 걸쭉한 농도 선호

      • 나머지는 오후에 아이들 간식 용으로 밀크쉐이크를 사주는 부모들 → 묽은 농도 선호

  • 고객은 제품을 구매하지 않고 고용한다. 고용의 관점에서 서비스를 분석하다보면 고객이 왜 그것을 고용하는지 쉽게 알 수 있다.

  • 고객은 언제나 해결할 문제들로 둘러쌓여있고, 우리는 고객의 문제를 해결해줄 프로덕트를 만들어 고용되어야 한다.

  • 서비스는 하나지만 이용하는 고객들은 모두 다른 이유에서 서비스를 고용한다. 이 다양성 속에서 동일한 의도를 찾아 고객을 분류해야한다. 분류된 각 집단별로 프로덕트를 고용하는 이유를 파악한 후, 그것에 맞춰 프로덕트를 개선해야한다. 고객 분류만 잘해도 성공적일 것이다.

  • 가장 중요한 역할 중 하나가 한정된 자원을 가지고 있는 상황에서 일의 우선순위를 정하는 것이다. 이를 위해서는 두 가지 방법을 따른다.

    1. 강박적으로 정보를 요구하고 직접 그 수치를 검증한다.

    2. 극단적으로 생각한다. : 두 고객 부류 중 한 쪽이 없다면?

  • 자신이 책임지고 있는 프로덕트에 대한 원칙을 반드시 정해야한다. 신규 론칭의 경우 특히나 더 많은 시간을 들여 최대한 많은 부분에 대해서 고민 후 원칙을 정해야 한다. 꼼꼼히 검토하지 않고 원칙을 정해버리면, 나중에 방향성을 바꿔야 할 수도 있기 때문이다. 원칙은 매 분기별로 점검한다. 고객과 사업이 요구하는 것들을 종합하여 원칙을 재정비하면 명확한 방향성을 잡을 수 있다.

  • 고객과 회사의 입장이 상충할 때에는 회사의 사업방향을 최우선으로 생각한다. 회사가 있어야 프로덕트도 있고 고객도 있다. 프로덕트는 회사의 사업방향에 맞춘 액션 중 하나이다.

  • 내가 꼭 하고 싶은 프로덕트가 있을 때 회사를 설득해볼 수 있다. 이때는 단순히 고객에 기대는 것이 아니라 비용, 회사에 끼치는 영향 등을 두루 설명해야 한다. 사업적인 관점에서 논리를 정리하도록 한다. 왜 그런 투자를 해야하는지 납득시켜야 하기 때문이다.

  • 페르소나와 고객을 혼동하지 말자

    • 실제 고객이라고 가정하고 페르소나를 설정하지만, 이는 고객을 충분히 대변하지 못한다.

    • 고객을 파악할 때에는 데이터와 사용패턴을 감안하여 최대한 포괄적으로 접근해야 한다.

      • 프로덕트를 사용하는 사람는 누구인지, 개인이 아니라 법인일 수 있는지

      • 어떤 가치를 얻으려고 하는지

      • 그 가치를 프로덕트가 직접적으로 제공할 수 있는지

      • 그것이 데이터로 증명가능한지

      • 동일한 가치를 추구하는 사용자 집단을 묶을 수 있는지

    • 가치를 추구하는 고객들을 하나씩 그룹화하고 더이상 통합할 수 없는 단계까지 간다면 그게 PO가 고려할 고객의 목록이 된다.

• 데이터 속에서 진실을 찾는 법

  • 절대 직관에 의존하지 않는다. 데이터에 기반한 사고방식을 갖추고 그 데이터가 제대로 얻어진 것인지까지 확인한다. 자신의 관점이 맞는지, 예상이 맞을지 확인하는 것도 데이터로 검증한다.

  • PO는 스스로를 믿지 않고 데이터를 믿어야 한다. 자신의 관점대로 데이터를 해석하지 말자. 긍정적인 데이터일수록 더욱 의심해봐야한다. 데이터의 종류뿐만 아니라 데이터가 쌓이는 방식까지도 검증해야한다. 잡다하게 모든 데이터를 모으려고 하지 말자. 어떤 데이터가 중요한지 모른다는 것을 드러낼 뿐이다.

  • 수시로 데이터를 확인해야한다. 주기적으로 데이터를 볼 수 있는 환경이 아니라면, 이를 팀원들과 함께 구축한다. 데이터를 효율적으로 축적하고 추출해서 분석까지 하는 것은 제대로 된 프로덕트를 만들기 위해 필수적인 요소이다.

  • PO라면 두 가지를 반드시 진행해야한다.

    1. 주요 대시보드를 만들어 기본 데이터들을 수시로 확인할 수 있도록 해야한다.

    2. WBR(Weekly Business Review) 를 만들어 매주 관계자들을 모아 30-60분정도 회의를 한다. 문서에는 주요 요점과 프로덕트 목표, 주요지표를 담는다. 회의 참석자들이 집중해야할 부분을 미리 예리하게 짚어서 확인하고, 해결책을 도출할 수 있도록 도와준다.

  • PO는 다양한 데이터를 접한다. 하지만 당장 액션을 취할 수 없는 데이터는 과감히 버리는 것이 좋다. 예를 들어 전주 대비 매출이 떨어졌다고 가정해보자. 해당 경우, 데이터는 아래와 같은 세 가지 중 하나를 의미한다.

    • 추석 연휴, 택시업계 파업과 같은 단기적 외부 요인인 경우, 당장 액션을 취할 필요 없다. 일시적인 현상이기 때문이다.

    • 특별한 이유가 없는데 수치가 하락한 경우, 경쟁업계나 시스템 장애, 서비스 내부의 문제 등 원인을 조속히 찾아야 한다. 원인을 기반으로 당장 실행할 수 있는 액션을 찾는다.

    • 이미 액션을 취하고 있는 부분의 수치일 경우, 일정 기간 지켜본다. 데이터가 변하는 양상을 본다.

  • 서비스에 포함할 작은 기능을 만들 때나, 조직의 전체적인 OKR을 설정할 때나, PO는 이성적인 가설을 공표해야한다. 다양한 관점에서 고민하고, 다양한 데이터를 분석하여 검증한 가설을 공표해야 조직도, 본인 스스로도 일관성 있게 프로덕트를 만들 수 있다.

    • 데이터를 분석할 때에는 기능의 론칭 전과 후를 비교하는 것이 아니라, 고객 군을 최소 두 개로 나눈 뒤, 동일 기간 동안 한쪽에만 업데이트 한 기능을 노출해서 데이터를 비교하는 것이 좋다.

    • 팀원들과 작업 내용에 대해서 공유할 때에는 가설과 가설을 떠올리게 된 배경, 가설처럼 수행되었을 경우의 결과까지 구체적인 수치로 공유하는 것이 이해도가 훨씬 높다.

  • 여러개의 테스트를 한번에 해야할 때에는 어떻게 할까? 다른 요소 때문이 아니라 이 기능 때문에 수치가 상승한 것이라고 판단할 수 있을까? 그때에는 다음과 같은 방법을 선택해볼 수 있다.

    1. 테스트 일정을 미룬다.

    2. 1번이 불가할 경우, 테스트 대상을 조정한다. 대상고객을 분류하여 각각 다른 테스트를 적용해본다. 여성 중 일주일에 5회 이상 서비스를 이용하는 사람, 남성 중 구매를 1회이상 한 사람 등. 오프라인 매장의 경우 특정 지점을 선택할 수 있다.

    3. 고객 분류가 어렵다면 전체에 테스트를 진행한 뒤에 데이터 분석을 통해서 상관관계를 파악할 수 있다. 상관관계 증명을 위한 P값을 확인한다.

  • 만약 사내에 데이터를 분석할 수 있는 기반이 갖추어져있지 않다면, 그것을 구축하는 것부터 우선으로 한다. 이것이 없다면 PO는 의사결정을 할 수 없다.

    • 고객 행동별로 로그를 심고, 데이터 마트를 만들고, 태블로를 구축하며, A/B 테스트 플랫폼까지 연동해놓아야 한다.

    • 당장 기능 개발이 우선될 수 있겠지만, 장기적으로 볼 때 빼놓을 수 없는 투자이다.

  • 데이터 대시보드도 프로덕트이다. 주로 태블로나 마이크로소프트 파워 BI를 이용하는데 여기서 구축하는 대시보드도 경영진, 내부고객, 다른 직원들이 볼 수 있는 하나의 프로덕트라고 생각하고 세심하게 구축해야한다. 기준은 처음보는 사람도 한번에 무엇을 의미하는지 캐치할 수 있도록 하는 것이다.

    • 타이틀은 명확하게, 각 테이블의 명칭, 열과 행의 명칭도 정확해야한다.

    • 명칭만으로 이해하기 어렵다면 테이블 밑에 부연설명을 붙인다.

    • 영문 등으로 생성할 경우에는 대소문자를 잘 구분한다.

• 효율적인 일정 관리의 비밀

  • 스토리 티케팅 전, 2-3장 문서를 작성하여 조직 전체의 이해를 돕는다.

    1. 목적

    2. 배경정보

    3. 고객을 위해 어떤 일을 하는가

    4. 원칙

    5. 목표

    6. 주요지표

    7. 개발계획

    8. 자주묻는질문

  • 신규 개발을 위해 티켓을 생성할 때에는 주로 세가지를 활용한다.

    1. 에픽을 통해 큰 목표를 잡는다.

    2. 스토리를 통해 통상적으로 사용자가 어떤 것을 할 수 있는지 설명한다.

    3. 테스크를 통해 하나의 스토리가 완료되기 위해 개발되어야 하는 것들을 잘게 나눈다.

  • 매주 개발팀 관리자들과 개별 면담을 통해서 나의 역할을 상기시킨다. 내가 잘 하고 있는지, 개선할 점은 없는지

  • PO는 다재다능하게 여러 재능이 있다고 해도 직접 기획을 하거나, 디자인을 하거나, 코딩을 해서는 안된다. 그 업무에 집중함으로써, 실제로 각 파트의 사람들이 임무를 잘 이행할 수 있도록 요구사항을 명확하게 전달하고 방향성을 제시하는데 집중할 수 없게 된다.

  • 이것저것 다하는 직무가 아니기 때문에, 더 효과적으로 시간을 투자하는 방법이 분명 존재한다.

  • 평소 수많은 변경사항에 대해 문서에 업데이트 한 뒤, 스크럼 회의 때에는 그 변경사항을 한 번 더 구두로 명확하게 전달해야한다.

  • 수많은 요청사항들은 커뮤니케이션 통로를 한 곳으로 통일하여 문서화될 수 있도록 하고, 해당 링크를 공유하는 것만으로도 관련자들이 상황을 같이 이해할 수 있도록 해야한다.

  • 수많은 티켓을 발행하다보면 자기 자신도 세부 내용을 기억하기 어렵다. 계속 검색해야한다. 그래서 자신만의 백로그를 별도의 스프레드 시트에 관리하는 것이 좋다.

• 디자이너를 최고의 파트너로 삼는 법

  • PO는 디자인 전문가가 아니다. 자신이 떠올린 기획을 디자이너에게 강요해서는 안된다. 요구사항만 전달할 뿐, 의견을 전달해서는 안된다. 만약 그렇게 할 경우, 프로덕트는 고객을 위한 것이 아닌, PO 자신을 위한 것이 된다.

  • 무조건 디자이너에게 고객의 경험과 관련된 결정 권한을 위임해줘야한다. 개발자에게 코드를 어떻게 짜야 하는지 알려주지 않듯이, 디자이너에게 어떤 방식으로 결과물을 도출해야하는지 알려주는 것은 올바르지 않다.

  • 자신의 프로덕트가 있다면 고객보다 많이 사용해보자.

  • PO는 디자이너와 협업할 때 고객 입장에서 대변해야한다. 모든 감정과 개인적인 선호도를 철저하게 배제한 후, 순전히 고객이 느낄 불편함을 제거할 목적으로 질문해야 한다. 그 과정에서 동료의 기분이 상할 것을 크게 신경쓰지 말자. 우선순위는 고객을 위한 최적의 프로덕트를 탄생시키는 것이지, 동료의 감정을 살피는 것이 아니기 때문이다.

  • 동료는 최고의 캐주얼 User Test 대상자이다. 인비전 혹은 플린토 등의 프로토타이핑 툴로 만든 시안 프로토타입 파일이 설치된 스마트폰을 전달하고 가만히 동료의 움직임을 관찰한다. 최초 1회에는 절대 끼어들지 않는다. 2회차부터 왜 버튼을 눌렀다가 다시 돌아갔는지, 한곳에 왜 오래 머물렀는지 등을 물어보며 사용자의 의도를 파악한다.

  • 캐주얼 UT를 진행할 때에는 대상자 한 명으로부터 너무 많은 것을 얻어내려고 하지 말고, 짧게 짧게 다수의 대상자를 통해 진행한 후 대다수가 느끼는 부분을 확보하는 것이 더 유용하다.

• 개발팀과의 협업을 성과로 이끄는 애자일 전략

  • 스프린트 플래닝은 말 그대로 하나의 스프린트를 계획하는 회의다. 단거리 전력 질주라는 뜻의 스프린트는 애자일 방식의 조직에서 2주 단뒤로 나눠 집중 개발하는 것을 말한다.

  • 매 스프린트마다 무엇을 할지 결정하고, 방향성을 올바르게 잡아주는 것이 매우 중요하다. 그 역할을 PO가 얼마나 잘 수행하는지에 따라, 그 조직의 성과는 눈에 띄게 차이가 난다.

  • 스프링트 플래닝 전, 아래와 같은 내용이 정리된 문서를 작성해 개발 조직과 공유한다.

    1. 이전 스프린트에 개발 완료된 것

       1. 고객과 회사에 끼친 영향을 설명한다. 주요지표 등 공유.

       2. 개발자와 디자이너가 자신이 기여한 바가 무엇인지 명확하게 이해해야 하기 때문이다.

    2. 이전 스프린트에서 개발을 완료하지 못한 것

       1. 중대한 실수로 인한 것이 아니라면, 한 스프린트 내에 완료하지 못했다는 사실을 비판적으로 명시할 필요가 없다.

       2. 완료하지 못한 것을 그다음 스프린트에 이어서 개발할지 명확하게 알려줘야 한다.

    3. 이전 스프린트에 발생한 기술적 이슈 또는 버그

       1. 큰 이슈가 생겼을 때는 반드시 기록하고 논의해야한다.

       2. 개발팀이 곧장 대응한 뒤에는 별도 회의 소집해 30분에서 한시간, 인시던트 리뷰를 진행한다. 원인, 대응방식, 개선책 등을 심도있게 논의

       3. 인시던트 리뷰에서 논의한 내용을 스프링트 플래닝 회의에서 한번 더 언급한다. 무엇이 문제였고 재발하지 않으려면 어떻게 해야하는지 상기하는 것이 목적

       4. 반드시 누군가를 비판하기 위함이 아님을 명확히 해야한다.

    4. 이전 스프린트에 대한 회고

       1. 2주간 조직원이 각자 느꼈던 좋은 점과 개선해야할 점에 대해 기록하고 공유하는 세션

       2. 스프린트 참여 전에 각자가 자신에게 할당된 빈 칸을 미리 채우고 회의에 참석하기를 요청한다.

       3. 서로가 서로에게 잘한 점, 개선할 점을 피드백하며 성장한다. 절대 개인적 비판이 아니라 더 나은 성장을 위한 피드백이라는 과정을 이해해야한다.

    5. 이번 분기의 OKR 달설상황

       1. 개발조직이 매번 수치를 보는 것은 힘들다. 때문에 PO는 주의깊게 수치를 살피고 미리 관련 수치를 문서에 기입해둔다.

    6. 이번 스프린트에 개발해야하는 것

       1. 가장 중요한 세션이다.

       2. 주로 10-15개의 기능을 나열한다.

  • 스프린트 플래닝과 회고를 같이 진행하는 이유

    • 서로를 비판하는 것이 아니라 함께 발전하기 위한 방식이라는 점을 충분히 이해한다면 감정이 상할 이유도 사라진다.

  • 일정산출을 할 때에는 무조건 강요하거나 그들의 일정을 100% 신뢰해서는 안된다. 8일짜리 작업이 있는데 4일만에 하라고 해도 개발 결과물은 좋지 않다. 경영진과 프로덕트 팀 사이에서 일정을 잘 산출하는 것은 PO의 몫이다. 개발팀의 말도 100% 신뢰해서는 안된다. 생각보다 일정이 길게 산정된 경우에는 그 이유를 물어봐야 한다.

  • 프로덕트를 고객에게 원활하게 선보이려면, 팀원들이 집중할 수 있도록 PO는 모든 것에 미리 대답해둬야 한다. 단 한순간도 개발이 정체되는 것을 스스로 용납하지 않는다.

  • 개발자가 직접 고객과 소통하거나 유관 부서와 협의하는 상황이 발생해서는 안된다. 그들은 본연의 업무에 집중할 수 있도록 PO는 대신 소통에 책임을 져야한다.

  • 회의 도중에 개발조직이 궁금해하는 점이 있다면 당장 전화를 해서라도 물어본다. 예의가 아니라고 느껴질 수 있지만, 팀원들의 궁금증을 최대한 빨리 해소한 뒤, 명확한 요구사항을 정립하는 것이 훨씬 중요하다.

  • 속도와 확장성 사이에서 잘 고민해야한다. 개발팀과 늘 확장성, 속도, 안정성 등을 논의해야한다. 적절한 시기에 대규모 투자를 할 수 있도록 백로그를 잘 관리해야한다. 아래와 같은 질문을 하여 그 사이에서 결정을 한다.

    • 당장 확장성을 고민해야하는지

    • 현재와 미래 고객에게는 어떤 것이 더 중요한지

    • 개발자들이 온전히 확장성을 위해 몰두할 수 있ㄷ록 백로그 관리를 할 수 있는지

    • 새로운 아키텍처 도입시에, 소요되는 시간 동안 다른 개선을 안해도 되는지

• 고객 테스트 결과만큼 강력한 데이터는 없다.

  • 기획 - 디자인 (2차) 까지의 단계가 지나면, 사용자들을 직접 불러 테스트를 해본다. 사용자 테스트를 통해 고객의 행동을 직접 관찰하고 직접 물어볼 수 있다.

  • UT 결과를 빠르게 개발조직과 공유하는 것은 개발일정에 차질 없도록 해주며, 작업자들에게 좋은 동기부여가 된다.

  • 그렇다면 언제 UT를 하는 것이 가장 좋을까? 가장 좋은 것은 스프린트 중간인 금요일과 월요일이다. (1주차 금 혹은 2주차 월) 그래야 디자이너가 UT 결과 피드백을 빠르게 적용하여 다음 스프린트 플래닝이 시작할때 빠르게 개발자들에게 결과물을 전달할 수 있다.

  • UT는 설문조사가 아니다. 많은 사람들의 의견을 듣는 것이 중요한 고객 서베이나 집단을 대상으로 하는 포커스 그룹 인터뷰와는 전혀 다르다. 한 사람의 고객이 프로덕트를 사용하는 모습을 보고 떠오르는 생각을 직접 접하면서 인사이트를 도출해내는 것이 중요하다.

• 프로덕트를 출시하는 최적의 시기

  • 프로덕트는 언제 출시하는게 가장 좋을까? 2주 스프린트가 있다면 2주차 목요일에 배포하는 것이 가장 좋다. 그래야 금요일에 혹시라도 발생할 버그에 대응할 수 있기 때문이다. 스프린트 중간에 핫픽스 배포를 해야한다면 어떡하는가? 1주차 목요일로 잡으면 좋다. 이처럼 정기적인 배포 일정을 갖는 것은 좋다. 이력을 파악하기도 좋고, 고객에게도 안정적인 경험을 줄 수 있다.

  • 프로덕트가 가장 활발하게 사용되는 시기에는 배포를 가급적 하지 않는 것이 좋다.

  • 신규 배포 전에 미리 공지해야할 사항들을 확인하면 좋다.

  • A/B 테스트를 활용해 고객 트래픽을 분산한다. 새로운 UI 나 기능을 선보여야할 때, 신규 화면과 기능이 노출되는 고객의 대상을 점진적으로 늘리는 것이 좋다. 그래야 매출과 트래픽, 오류사항 등에 적절하게 대응하며 안정되게 적용시킬 수 있다.

  • 내부 고객도 고객이다. 내부 고객의 경우는 최대한 그들의 의견을 많이 들을 수 있도록 한다. UX디자이너는 최대한 작업에 투입하지 않는 것이 좋은데, 일반 사용자의 프로덕트를 다루는 것이 회사 전체에 더 큰 이익이 되기 때문이다.

  • 24시간 365일 동료들의 전화를 받을수도 있다. 전화로 일이 해결될 것이라는 믿음조차 없으면 아에 전화도 하지 않았을 것이므로, 이를 기분좋게 생각하자.

  • 건강한 배포문화를 만드는 것이 중요하다. 각 조직별로 차이가 있지만, 스피드 추구형 조직과 안정 추구형 조직이 있을 수 있는데, 둘 중 어느 집단도 지속가능하지 않다. 빠른 속도로 진행하지만 안정성이 높은 개발물을 추구해야한다.

• 테스트 중 가설을 효과적으로 검증하려면

  • A/B 테스트를 하면서 P값을 활용하여 가설을 검증한다. 유의확률 값을 뜻하는 Probability Value 의 줄임인 P값은 실험 결과가 우연히 나타난 것인지 아닌지 확인할 때 사용되는 값이다. 보통 P값은 A/B테스트 플랫폼에서 제공해주기 때문에 이를 직접 계산할 필요는 없다. 이 값은 0과 가까울수록 통계적 유의도가 100%에 가까워진다.

  • 테스트를 설계할 떄 어떤 수치를봐야할 지 미리 결정하는 것이 좋다. 각가 수치마다 P값을 보고 유의미한지 판단해야하기 때문이다. 이때는 특정 기능에 대한 결과와 거시적인 측면에서의 그림을 함께 보는 것이 좋다.

    • 특정 기능과 직결된 수치, 프로덕트 전반의 수치 두 가지를 직접 확인해야 한다.

    • 메모 기능을 사용한 수치가 늘었지만, 주문량이 줄었을수도 있다. 메모 기능을 사용한 수치가 줄었지만, 주문량이 늘었을수도 있다.

  • 만약에 P값이 낮아지지 않아서 유의미한 결과를 얻을 수 없다면, 여러가지 선택지 중에서 하나를 선택한다.

    • 더 많은 고객에게 노출될 떄까지 기다린다.

    • 테스트 중단 후 신규 기능 또는 디자인이 의미없다고 판단한다.

    • 유의미한 결과가 없었지만, 프로덕트 전체에 악영향을 미치지 않아 B그룹이 이겼다고 판단한다.

  • PO는 가설검증을 위해 개발조직부터 다양한 리소스를 ‘펀딩 받는다’. 많은 도움을 받고 시도한 A/B테스트의 결과가 안좋다면, 빨리 접고 다음 스텝으로 이동해야한다. 테스트 결과를 편향적으로 해석해서는 안된다. 실패를 인정하고 원인을 명확하게 파악한 후 그 다음 목표를 향해 나아가야 한다.

  • PO의 직관이 아니라 통계적 결과를 토대로 결정을 해야 진실에 가까워진다. 큰 조직에서 작은 조직으로 이동하면 수치적으로 충분한 결과가 나오지 않아 직관으로 판단하고 싶은 유혹이 들 수 있다. 하지만 그럼에도 불구하고 통계적 결과를 기반으로 판단해야한다.

  • 테스트 전에 검증하려는 수치를 미리 정해야한다. 그래야 테스트 중 발견하는 다른 유의미한 수치 등에 시선을 뺏기지 않고 차분하게 의사결정을 할 수 있다.

• 론칭한 서비스의 문제를 바로잡기

  • 신규 기능이 업데이트 되면 무조건 내부 고객센터 및 유관 부서에 기능 사용법과 함께 자료를 배포하도록 한다. 그래야 해당 부서에서도 그에 맞는 대응들을 할 수 있다.

  • 새롭게 적용한 기능이 100%의 범위로 적용된다면, 팀원들에게 진심으로 감사를 표한다. 그들이 없었다면, 새로운 디자인이나 기능을 고객에게 선보일 수 없었을 것이다. 프로덕트가 개선될 때마다 그 공을 자신에게 돌리지 않아야 한다. PO 혼자서는 그 어떤 것도 할 수 없다는 사실을 명심하자.

  • 새로운 기능을 100%로 적용했다는 기쁨은 잠시이다. 곧바로 최악의 상황을 대비해야한다. 미리 그런 가능성을 충분히 인정하고, 개발 조직과 함께 대응할 준비를 하도록 하자.

  • 프로덕트는 완벽할리 없다. 고객은 PO나 개발조직이 예상하지 못했던 방식으로 프로덕트를 사용하기도 한다. 프로덕트는 계속해서 개선될 뿐이다.

  • 쿠팡에서는 15가지 리더십의 원칙이 있다. 모든 일원이 추구해야하는 가치이다. 그 중 가장 중요한 것은 “Hate Waste” 이다.

  • 각 직무별 시간을 조금이라도 낭비하지 않도록 아래와 같이 일정을 계획한다.

    PO	요구사항	시안검토	UT	요구사항	시안검토	UT	요구사항
    디자이너		1차시안	2차시안	최종시안	1차시안	2차시안	최종시안
    백엔드		개발시작	개발	개발	기타개발	QA	개발시작
    프론트엔드		기타개발	개발시작	개발	개발	QA	버그수정

  • PO가 독하다는 소리를 들어도 결국 고객에게 칭찬 받으면 구성원들은 모두 뿌듯해한다.

  • 고객의 소리를 들을 수 있는 환경을 조성해야한다. VOC 리포트를 태블오 등이나 내부 시스템으로 취합하여 매일 특정 시간에 발송되도록 한다. 이 리포트 내에 고객의 목소리가 담겨있으므로 이들이 겪는 불편함을 해소하기 위해 새로운 기능을 고안하는 것만으로도 엄청난 힌트가 된다.

  • 분기별로 하루 날을 잡아 고객센터에 하루종일 있어보는 것도 좋다. 직접 고객의 목소리를 들다보면, 새로운 아이디어도 떠오르고, 반성도 하고 기쁨도 느낄 수 있다. 고객과 더욱 가까워질 수 있다.

  • PO는 매우 바쁘다. 프로덕트와 관련된 모든 회의에 참여하며 다양한 정보를 흡수하고 곧바로 생각을 정리해야한다. 멀티태스킹 능력이 중요하다. 이상하게 말이 길어진다 싶으면 곧바로 자르고 핵심을 질문한다. 그 많은 시간을 기다릴 수 없다.

  • 3가지 기술을 이용해서 멀티태스킹을 한다.

    • 꼼꼼히 메모한다.

    • 이성적으로 감정을 깔끔히 배제한채 우선순휘를 판단한다.

    • 커뮤니케이션을 통해 기대치를 관리해야한다. 무조건 수용하지 말고 요청사항의 중요도를 말해주는 것이 좋다.

  • PO는 문제해결사이다. 고객, 유관부서, 경영진이 겪는 불편함을 해결해줘야한다. 특히 자신이 맡고 있는 프로덕트는 무조건 책임지고 문제를 해결할 수 있어야 한다.

  • 5why 방식을 통해 이슈상황을 대응한다. 인시던트 리뷰를 열어 개발 조직의 5why를 검토하고 다음에 다시 같은 장애가 발생하지 않도록 하는 것이 중요하다.

• 어떤 인재를 PO로 선발해야 하는가

  • 모든 회사에서 PO 가 필요한 것은 아니다. 아래 두 가지의 조건을 명확히 해야한다.

    1. PO 에게 프로덕트에 대한 권한을 전적으로 위임할 수 있어야 한다.

    2. PO 가 밀접하게 협업할 수 있는 개발 전담 조직이 있어야 한다.

  • PO는 전략가이다. 이미 정해진 일을 하는 것은 그가 할일이 아니다. 오히려 실행가인 PM이나 TPM 이 해야할 일이다.

  • 고객 데이터를 통해 신속하게 가설을 만들고 MVP 를 만든 후 테스트를 진행해서 검증하는 것을 지속적으로 할 수 있어야 한다.

  • 무한 잠재력을 알아보는 방법

    • 책임진 프로덕트의 고객은 누구인가요?

      • 내/외부 고객을 분류할 수 있는 능력을 파악

      • 은행앱 예시

        • 자산을 확인하는 고객

        • 송금을 자주하는 고객

        • 대출을 신청하는 고객

        • 가입했으나 활동하지 않는 고객

      • 유튜브 예시

        • 콘텐츠를 생산하는 고객 - 양질의 콘텐츠, 낮은 가치의 콘텐츠를 여러개

        • 콘텐츠를 소비하는 고객

    • 과연 그 고객뿐인가요?

      • 많은 지원자가 제대로 답하지 못한다.

      • 유능한 지원자라면 대화를 통해 자신의 프로덕트가 생각보다 많은 고객들에게 가치를 제공해왔다는 것을 알게 된다.

    • 만약 두 가지 고객 중 하나만 우선적을 택해야 한다면 어떻게 하실건가요?

      • 전략적 거시적 사고 측정

    • 설명하신 방법을 더 간소하게 구현하려면 어떻게 해야할까요?

      • 기술적인 이해도를 측정한다.

    • 케이스에 대한 프로덕트 개발 과정 설명하기

      • 장난감이라고 검색한 고객에게 최고로 만족할만한 상품을 맨 상단에 노출하고 싶다면 어떻게 해야할까?

        • 만족 → 단순히 베스트 셀링이 아니라, 개인화의 영역이다.

        • 활용 가능한 데이터를 파악한다. 고객 데이터, 상품 데이터 등

        • 구현 방법 설명 후 어떻게 성공적인지 검증하는 방법까지 제시하는 사람

      • 처음부터 끝까지 문제 해결하는 과정을 지켜보기 위함이다.

  • 능력있는 PO가 되려면 오너십이 가장 중요하다. 오너십을 잃는 순간 그 PO는 끝이다. PO 가 빠르게 적응을 하려면 프로덕트에 대한 지식을 빨리 쌓아야 한다. 입사 후 다른 PO들과 개별적으로 면담할 수 있도록 돕는 것이 필요하다.

  • 작은 것부터 천천히 책임지도록 해야한다. 스스로 책임지는 능력을 길러야 한다.

  • 사업상 급하게 전달된 건이더라도 PO는 절대 상사가 시켰어, 대표가 시켰어와 같은 말을 해서는 안된다. 회사의 목표를 인식할 수 있도록 주도해야지, 그것을 강요해서는 안된다. 왜 개발해야하는지 그 당위성을 설명해야한다.

  • PO의 자질을 완벽하게 갖춘 사람을 뽑기는 사실상 힘들다. 오히려 잠재력을 가진 사람에게 기회를 주어 작은 일들부터 맡기며 성장하는 모습을 지켜보는 것이 좋다.

  • 고객과 진정으로 공감하고, 더 나은 경험을 선사하고 싶다는 마음이 있고, 그것을 올바른 프로덕트로 만들어 하루 빨리 제공해야한다는 절박감이 있다면, 훌륭한 PO가 될 수 있다. 그 과정에서 체계적으로 생각하고 깊게 파고드려는 성향은 필수적으로 자리잡아야 할 것이다.

  • 결국 PO는 이타적이어야 한다. 고객 감동을 통해 세상을 더 낫게 변화시켰다는 것을 확인하며 만족할 수 있어야 한다.