1.1 프로덕트 정의

• 프로덕트 관점에서 보면 부품은 ‘컴포넌트(component)’다. 컴포넌트는 프로덕트로 동작하지 않으며 프로덕트로 릴리스하지도 않는다. 다른 컴포넌트나 프로덕트에 의존성을 가지면서 협업을 통해 전체 프로덕트를 구성하고 동작하게 하는 데 목적이 있다.
• 컴포넌트 → 컴포넌트 세트(인스턴스) → 프로덕트
  • 인스턴스는 여러 컴포넌트를 조립한 형태이다. 릴리스 가능하다
  • 인스턴스가 프로덕트가 되려면 시장이 원하는 형태의 패키징을 해야 한다.
  • 인스턴스는 마이크로 서비스나 오픈 소스 같은 것들이다
• 운영체제는 하드웨어 디바이스와 연결해 애플리케이션이 동작하게 하는 ’플랫폼 프로덕트(platform product)‘이다.
• 서비스 기능으로 나누는 것, 각 기술 도메인이 확실하게 나누어지는 것을 수직적(vertical) 분류라고 한다
• 전체 프로덕트 형태가 지원하는 플랫폼에 따라 변하지 않게 관리하면서 서로 다른 OS 플랫폼에서도 기능이 원활하게 동작하게 하는 것을 해당 시스템에 포팅(porting) 한다고 한다. 이런 식으로 기능으로 PM 업무를 분할하지 않는 방식을 수평적(horizontal) 분류라고 한다.
• 프로덕트란 소비자가 보는 전체 프로덕트일 수도 있고 기능에 따라 더 작은 부분으로 나눠질 수도 있다
  • 유튜브는 영상 순위, 광고, 회원 정도 등의 프로덕트로 이루어진 하나의 프로덕트이다.

1.2 PM 정의

• PM은 프로덕트 성공에 대한 모든 책임을 지는 역할이다.
• PM에 대한 오해 6가지
  • 보고 라인에 있는 팀 상사
    • PM은 상사가 아니다. 함께 일하는 구성원을 설득하고 영감을 주는 역할을 한다.
    • 양보나 타협이 아닌 ’왜‘에 대한 비전을 명확하게 이해시켜 엔지니어 및 디자이너와의 협업을 이끌어낸다.
  • 능숙한 기술자
    • PM은 기술자가 아니다. 기술적인 역할보다 고객의 불편함에 공감하고 비즈니스를 파악해 제품에 반영하고 릴리스까지 책임지는 역할을 한다.
    • 모든 기술 지식을 이해하고 있지 않다.
  • 마케터
    • PM은 프로덕트가 우수한 점을 누구보다 분명하게 설명할 수 있어야 한다.
    • PM은 고객을 직접 상대하는 마케터와 세일즈 담당자가 제품의 강점을 잘 인지한 상태에서 고객의 문제에 집중해 홍보와 판매를 하고 있는지 면밀히 모니터 하는 것이 중요하다. 그 과정에서 얻는 정보가 프로덕트 품질 향상을 위한 기회를 제공하기 때문이다.
  • 프로덕트 오너
    • PM은 PO와 다르다
    • 가장 큰 차이는 디스커버리 프로세스에 더 많은 시간을 할애한다는 것이다.
    • PM은 사용자가 원하는 것과 시장이 원하는 것을 파악해 전략적 계획을 세우는 사람이다.
  • 애자일 전문가
    • PM이 애자일 전문가처럼 애자일 방법론에 능숙해야 한다는 것은 오해다
    • 다양한 주변 상황과 환경에 맞는 개발 방법을 찾아 개선해 나가는 역할을 할 뿐이다
    • 실제 개발 프로세스를 진행하는 역할은 PO나 스크럼 마스터가 한다
  • 데이터 분석가나 사용자 리서처
    • 린 스타트업 관점에서 PM의 목표는 ‘최종 사용자에게 가치를 제공하지 않는 활동을 제거하는 것‘이다.
    • 최종 사용자를 위한 가치에 대해 내부 이해관계자가 프로덕트 비전과 미션을 이해하도록 도와야 한다. 그 후 데이터를 적용하고 공유해야 한다. 이 과정에서 데이터 수집은 사용자 조사 팀이나 데이터 분석 팀에 의뢰한다.
• PM의 역할
  • 커뮤니케이션 허브 역할
    • PM은 좌직에서 프로덕트 관련 정보의 중심이다
    • 모든 이해관계자를 위한 커뮤니케이션 허브 역할을 한다
  • 우선순위 조정 역할
    • 모든 이해관계자는 본인과 관련 있는 업무가 가장 빠르게 처리되길 원한다.
    • 이때, 합리적이 기준으로 우선순위를 조절하고 모든 이해관계자를 설득하고 합위를 이끌어내야 한다.
  • 프로덕트 대표이자 치어리더 역할
    • PM은 다양한 이해관계자의 피드백과 다양한 지표를 통해 우선순위를 결정하고 시간을 효율적으로 활용하게 한다. 이를 통해 엔지니어와 디자이너가 최상의 성과를 낼 수 있게 이끈다.

1.3 B2B와 B2C

• B2B
  • PM은 제공한 프로덕트가 비즈니스 요구 사항을 충족하는지 정기적으로 확인하고 업무 프로세스를 표준화하면서 발전시켜야 한다
  • 내부 관계자: 개발, 디자인, 테스트를 진행하는 엔지니어링 팀
  • 외부 관계자: 제품을 직접 사용하는 고객, 고객 담당 매니저
  • 고객의 비즈니스를 이해하는 능력과 산업 및 고객별 비즈니스 흐름을 표준화하는 기술 능력이 필요하다
• B2C
  • PM은 비전과 아이디어를 구현하기 위한 창의성과 광범위하고 급변하는 기술을 빠르게 프로덕트에 적용하는 능력이 필요하다
  • 개인을 타깃으로 하는 PM은 무엇을 구축할지 정확히 예측하기 어렵다. 따라서 사용자 선호를 파악하고 많은 사용자와 대화해서 다양한 프로토타입을 만들어 A/B 테스트를 하고 데이터 분석하는 데 많은 시간을 할애한다
• B2C와 B2B는 프로덕트를 처음 구상할 때부터 차이가 존재한다
  • B2B는 고객의 비즈니스를 이해하고 기존 프로세스 내에서 어떤 시장 이점을 가져다줄 수 있는지 고민하고 고객과 ‘협업’하는 개념으로 제품화 과정을 발전시킨다
    • B2B는 A/B 테스트를 진행할 수 없다.
    • B2B 비즈니스 워크플로의 최고 가치는 표준화와 안전성이기 때문이다.
      • 서로 다른 UX, UI가 동일한 비즈니스 환경에서 돌아간다고 생각해 보자. 대출 업무 UX가 서로 다르다면 대출 후 이어지는 비즈니스 워크플로에 상당한 영향을 미칠 수 있다.
      • 대신 ‘라이브 실험’방법을 활용할 수 있자. 현재 고객에게 모니터링에 대한 허가를 받고 워크플로에 나타나는 비용, 시간, 인원, 사용 수를 면밀히 분석해 효율성을 찾는다.
      • B2B에서 고객 조사는 업무 특수성에서 오는 차이가 크고 사용자가 특수성을 모두 공개하려 하지도 않는다. 즉, 피드백을 많이 받거나 인터뷰가 어렵다.
        • 오랜 시간 고객과 깊은 신뢰를 쌓고 비즈니스를 이해할 수 있도록 해당 분야 업무 지식을 갖춰야 한다.
    • B2B는 CI/CD 주기를 짧게 가져갈 수 없다. 익숙해진 업무 프로세스가 빈번히 바뀐다면 적응하기까지 업무 생산성이 떨어진다.
  • B2C는 불특정 다수를 대상으로 하므로 최적점을 찾고자 지속적으로 시도하고 배우고 실험하면서 제품 시작 적합성(PMF - product market fit)을 찾아간다
    • B2C에서는 PMF를 위해 A/B 테스트를 진행한다
    • B2C는 최대한 많은 사용자의 피드백을 기반으로 패턴을 찾고 인터뷰를 통해 프로덕트 강점을 찾는다.

1.4 프로덕트 매니저, 프로젝트 매니저, 프로그램 매니저는 어떻게 다른가?

• 프로덕트 매니저는 프로덕트(서비스)를 관리한다
  • 전략적인 사업 목표/비전에 맞춰 비즈니스 목표치(business objectives) 정의
  • 고객 요청을 수렴해 요청에 부합하는 솔루션 제공
  • 고객 요청을 우선순위로 정리하고 프로덕트 라이프 사이클 정의
  • 경쟁 프로덕트와 비교하며 프로더트의 지속 가능한 장점 구축
  • 해당 프로덕트의 전체 책임자 역할(디자인, 개발, 디플로이먼트, 프로덕션)
  • 수익 모델, 홍보 마케딩은 그룹 내 판매나 마케팅을 담당하는 부서와 협의
• 프로젝트 매니저는 시간, 비용, 리소스를 관리한다
  • 프로젝트 매니저는 예상하지 못한 상황을 헤쳐하면서 가용한 리소스로 정해진 시간에 계획된 품질을 가진 프로덕트를 출시하는 것이 목표인 역할이다.
  • 위험 관리
  • 자원 관리
  • 범위 관리
• 프로그램 매니저는 특정 기능을 관리한다
  • 테크 기업에서 프로덕트 매니저와 비슷하지만 책임의 한계에서 특정 기능을 소유한 프로덕트 오너로서의 역할을 한다.
    • 자사 여러 서비스에서 사용하는 공통 기능에 대한 관리를 한다. 즉, 컴포넌트와 인스턴스의 오너이다.
  • 또는 연관성 있는 다양한 프로젝트를 모아 관리하는 역할을 하기도 한다. 딜리버리 매니저라고 칭하기도 한다.
  • 각 프로젝트에 대한 자세한 이해를 갖기보다는 모두를 조율해 하나의 suite로 나가는 역할을 수행한다.
    • suite란 고객의 요구에 종합적인 솔루션을 제공하기 위한 관련 제품 또는 서비스 모음이며, 다양한 관련 제품을 함께 패키징 하여 추가적인 가치와 편의성을 제공한다.

1.5 글로벌 기술 기업의 조직 구조 이해하기

• 조직 구조는 기업이 효율적인 의사 결정 프로세스를 구현하는 것이 궁극적인 목표다
• 글로벌 소프트웨어 기업의 사업 구획은 기업마다 다소 차이가 있지만, 기본적으로 다음과 같이 나뉜다.

• 수익 창출에 속산 부서는 직접 수익을 만드는 부서이다.
• 수익 활성화에 속한 부서는 수익이 발생할 수 있도록 활성화해주는 그룹, 즉 수익을 만들어낼 수 있는 원천을 제공하는 그룹이다.
• 위와 같이 여러 부서가 있는 상황에서 PM은 모든 이해관계자와의 커뮤니케이션 허브 역할을 한다.

1.6 프로덕트 리더십 팀의 역할과 책임

• 개발과 출시를 담당하는 프로덕트 엔지니어링 그룹 최상위에는 ‘프로덕트 리더십’이라는 매니지먼트 그룹이 존재한다.
• 프로덕트 리더십 그룹은 프로덕트 기능을 정의하고 구현 방법을 지휘하는 PM 과는 다른 상위 역할을 담당한다. 또한, 시장이나 고객의 니즈를 충족시키면서 경쟁 프로덕트와 확실한 차별화 방법 및 성공적인 프로덕트가 될 수 있게 항상 고민해야 한다.
• 프로덕트 리더십 팀 구성원이 모두 회사 보고 라인에 있을 필요는 없지만 프로덕트 사이클 결정에 상위에 있어야 한다.
  • 구성원은 VP(Vice President), CPO(Chief Product Officer), GPM(Group Product Manager), CPA(Chief Product Architect)라는 타이틀을 가진다.
• 프로덕트 리더십 팀은 다음과 같은 업무를 맡는다
  1. 프로덕트 리더십 팀은 프로덕트 방향을 올바르게 결장해야 한다. 결정 과정은 다음과 같다
     • 비전 제시: 장기적이고 지속적으로 어떤 가치를 고객에게 제공하는가?
     • 전략: 가치를 어떻게 제공하고 경쟁에서 이길 것인가?
       • 전략은 다음 내용이 포함돼야 한다
         • 고객에게 프로덕트 차기를 어떻게 전달할 것인가?
         • 경쟁 프로덕트와는 어떤 차별화가 있는가?
         • 타깃층은 누구이며 시간이 지나면 어떻게 확장되는가(비즈니스 모델)?
     • 로드맵: 제품/서비스의 테마를 결정하고, 제공 시기를 구분하기
       • 테마는 자세한 기능 목록이 아닌 전략을 담은 큰 목표성 테마를 담아야 한다.
     • 목표치 설정: OKRs(Objectives and Key Results) 결과의 우선순위 정하기
     • 커뮤니케이션: 일관되게, 충분히 자주 소통 및 피드백하고 가이드라인 정하기
  2. 프로덕트 리더십 팀은 프로덕트를 만드는 팀을 구성하고 조직하는 역할도 한다
     • 구성원을 조직할 때 다음과 같은 세 가지 기준이 필요하다 =
       • 프로덕트/프로그램 매니지먼트
       • 디자인 매니지먼트(UX, 리서치 포함)
       • 엔지니어링 매니지먼트
  3. 프로덕트를 출시하는 프로세스를 만든다
     • 프로덕트를 위해 일하는 많은 팀이 어떤 구조를 가질지 정한다.
       • 프로덕트를 만드는 프로젝트가 진행되면 상호 간 업무 내용, 진행 사항, 결과가 유기적으로 공유되고 보고돼야 한다.
     • 각 팀의 범주를 넘어서는 것을 정해야 한다.
       • 프로덕트 축시 시기와 단계를 정의하고 각각의 품질 게이트 키퍼(gate keeper, 어떤 툴을 기준으로 어떤 측정치로 통과 여부를 결정하는지)의 기준을 마련해야 한다.
     • 기업 내 다른 조직과의 연결성을 정의한다.
       • 팀 간의 커뮤니케이션을 어떻게 할 것인가

1.7 PM과 PO의 차이

• 소프트웨어 프로덕트 구체화 과정은 다음과 같은 4단계를 거친다
  • 미션
    • ‘왜’에 관한 것을 답한다. 해당 프로덕트가 존재해야 하는 목적을 설명한다. 프로덕트 그룹의 리더십 팀이나 그룹장이 결정하고 하위 팀으로 커뮤니케이션하게 된다.
  • 비전
    • 프로덕트를 사용할 때 고객이 어떤 혜택을 볼지 기술한다. 해당 내용이 구체화돼야 프로덕트 로드맵을 작성할 수 있다. PM 역할이다.
  • 전략
    • PM이 가장 중점적으로 해야 하는 과정이다. 시장을 분석하고 테마 기능별 우선순위를 정한다. 프로덕트 성공에 관한 실제적이고 구체적인 지표를 설정하는 과정이다
  • 전술
    • 실제 프로덕트를 만드는 과정이다. 프로덕트를 완성하기 위한 백로그 아이템을 만들고 기능별 릴리스 플래닝을 세우고 진행한다. PO라는 직군이 조직 내 존재한다면 전술 과정을 담당한다.
• 위 과정 중 비전, 전략에서 PM은 시장을 조사하고, 고객층 접촉하고, 경쟁자 제품을 조사하면서 애널리스트와 회의를 진행한다. 또한, 개발 및 디자인, 데브옵스, QA 매니저와 커뮤니케이션을 한다. 이렇게 만들고자 하는 제품을 알아가는 과정을 product discovery라고 한다.

• Product discovery 과정이 끝나면 product delivery 과정으로 넘어간다. 이때 기능과 릴리스 플래닝을 작성해 각 개발, 디자인, QA 리더와 함께 작업하는 실제 스크럼 프로세스가 진행된다. Product devlivery를 위해 개발, 디자인, 데브옵스 등 기능별로 실행하는 것을 진두지휘하는 역할을 PO라고 한다.

• 출처: 프로덕트 매니지먼트

• Previous
  분산 데이터베이스 시스템과 트랜잭션
• Next
  Chapter 1. 프롬프트 엔지니어링은 질문을 잘하는 것이 아니다.