[패스트캠퍼스 부트캠프 : PM 2기] Day 1

첫날이 밝았다.

새롭게 시작한다는 마음에 설래기도 OT 때 마주친 수강생분들이 다들 잘하시는 것 같아 걱정이 되기도 하지만, 좋아하고 관심있는 것을 탐구하는 것에 대한 설램이 더 큰 것 같다.

1주차 계획은 1주차에 들어야하는 필수 강의를 다 듣고(1주차가 모두 이론 강의라면 2주차까지..) 주말에 피그마 툴 파이널 과제까지 끝을 내는 것이다 

각설하고 들어가 보자

 

현재 필수강의로 지정된 강의는 SAP Senior PM 김영욱님의 모든 비즈니스를 성공으로 이끄는 Product Management Essential이다

 

Product? 

예를 들어 눈앞에 스마트폰이 있다고 해보자 

우리의 눈앞에 놓여진 스마트폰의 측면의 버튼들과 눈앞에 보이는 화면은 '물리적 하드웨어' 이다. (앞단이다)

우리의 눈에는 보이지 않지만 우리가 앱을 눌렀을 때 스마트폰의 뒷단에서는 저장을 담당하는 스토리지, 회로 등 내부 구성요소들이 작동을 하는 구성요소이다. 이는 '내부 동작 프로세스' 이다.

이 내부 구성요소 즉 스마트폰을 이루는 전부가 다 Product이다 

 

Product? 상품아냐? 왜 내부적인 것도 Product라 하지? 라는 의문이 들었다.

 

Product를 알기 위해서는 Component를 알아야 한다.

Component는 대부분 Product라 하지 않고 어원 그대로 부품이라 한다

 

즉 Component는 스스로 동작을 구성하지 않는다

 

이 때문에 Component는 Component 간의 협업을 통해 전체 Product를 이룬다

 

스마트폰의 경우 Componet 요소를 보게 된다면 HW/SW라 할 수 있다

-> 많은 Component들이 모여서 Product를 이루는 것을 알 수 있다 

 

 

Product의 범위가 생각보다 광범위 하는 것을 이해했으니 유튜브를 살펴 보자 

유튜브를 사용해봤다는 가정하에 동영상 댓글 랜딩페이지 광고 숏츠플랫폼 등 다양한 기능이 있는 것을 우리는 알고 있다. 

위에서 말했듯 이 모든 것은 Product의 해당한다 

 

이 Product를 관리하는 사람들이 PM이다

 

유튜브에서의 예시와 같이 우리는 PM의 역할이 소비자가 보는 전체 Product 일수도 더 작은 부분으로 나누어진다는 것을 알 수 있었다

-> 더 나아가면 Process, Document도 Product가 될 수 있다

 

단순히 우리가 보는 유튜브가 오류 없이 소비자가 원하는 대로, 예상하는 대로 움직이려면 '누군가로 부터 시작이 필요하다'(갑자기 하늘에서 이 기능하게 좋겠구나 점지해주는 것이 아니기 때문에) 

 

-> 누군가로 부터의 시작, 이것을 담당하는 것이 PM의 역할이다.

PM은 Product의 설계 개발 테스트 릴리즈 릴리즈 테스트 후에 사이클까지 책임지는 역할이라 할 수 있다

 

(대충 엄청난 사람인거 같은데 너무 광범위하고 모든 부분에 있는 것 같아서 정확하게 뭐하는 사람이냐? 라는 의문이 들 수 있다)

역으로 이러한 의문을 해결하기 위해서는 PM이 아닌 6가지 유형을 알아보는 것이 좋겠다.

 

PM이 아닌 6가지 유형

1. PM은 Boss가 아니다

사람을 관리하는 메니져가 아니다.

상사, 보고 받는 사람, 강요하는 사람, 지시를 내리는 사람이 아니다.

-> 설득을 하고 양보와 타협을 하며 Product가 왜 필요한지 소통하는 사람이며 협업을 중시하는 사람이다

 

2. PM은 능숙한 기술자가 아니다

기술적인 역할 보다는 비즈니스 역할에 해당된다 

소통을 위한 최소한의 지식을 가지고 있는 사람이다

-> 기업이 어떤 제품을 만들고 무엇을 판매 할 수 있는지 이해하는 것이 더 중요하다

 

3. 마케터가 아니다



상품의 이점은 설명할 수 있지만 이러한 이점을 고객에게 직접 설명하는 사람이 아니다

무엇을 판매하고 왜 판매하는지 고객에 문제에 대한 지식만 있으면 된다

 

4. PO가 아니다

 

Scrum에서 PO는 모든 백로그에 대한 우선순위를 지정하고 오너쉽을 가지고 있는 사람이다 

때로는 PM이 Delivery나 Build에 크게 관여하지만 보통은 Discovery에 더 시간을 쏟는다

-> 생각할 시간이 PM에게는 더 중요하며 전략적 계획을 내놓는 역할이다

 

5. Agile 숭배자가 아니다 

 

상황과 환경에 맞는 방법과 개발 방법을 대입 할 수 있어야 한다.

 

6. User Researcher, 데이터 분석가가 아니다.

 

데이터를 해석하고 다음 질문을 받고 답변을 고객이 매력적으로 느끼게 바꾸는 역할이다

최종 사용자에게 가치를 제공하지 않는 것 들을 제외하는 것을 목표로 한다 

내부이해관계자가 Product 비전과 미션을 이해하는데 있어 데이터 공유는 하지만 모든 데이터는 수집하지 않는다

 

PM은

Communication Hub, 우선순위를 정하는 사람(Prioritizer), 표현하는 사람(Presenter), Product 성공 여부를 책임지는 사람이다 

 

PM(Product Manager) vs PO vs PM(Project Manager)

Project Manager

- Scrum Master, Scrum of Scrum

- Project 타임라인이나 진행 스피드 관리

- 리소스 사람 시간 비용 효과적으로 투입하는 사람

- 예정된 시간에 목표한 기능을 포함하여 배포하는 것을 목적으로 하는 사람 

 

Product vs Project 

끝의 의미

Project -> 끝 즉, End State

Product -> Version 갱신 즉, 계속 진행되는 상태 유지상태(Maintenance)

 

예를 들자면 엑셀 워드 파워포인트와 같은 제품을 책임지고 있는 사람이 Product Manager라면 

여러 제품에 같은 기능을 책임지고 Delivery하는 사람은 Program Manager이다

 

PM vs PO

 

프로덕트 구체화 과정과 책임에서 구별이 가능하다 

프로덕트 구체화 과정은 Misson -> Vision -> Strategy -> Tactics 과정을 거친다

 

이 과정에서 Mission은 Product Leadership Team에서 제공하고 

PM은  Vision, Strategy 과정에 참여하여 프로덕트 비전, 로드맵을 구성한 뒤 우선순위를 정하고 Product 지표를 세팅한다

-> 왜 Product가 필요하고 고객이 Product를 어떻게 사용하는지에 초점을 맞춘다

이후 PO는 Tactics 과정에 참여하여 Product 백로그를 작성하고 기능 피쳐, 릴리즈 플래닝을 수행한다

-> 실제 Product를 만든다

 

PM과 PO의 차이점은 Project Group에서도 나타난다

PM은 Product Discovery 단계를 담당한다

위의 Product 구체화 과정에서 본다면 Header가 사용자 조사, 경쟁 제품 분석, 시장 흐름, 고객 요청 등을 취합해서 비즈니스 목표를 설정하고 테마를 던져준다.

 

이후 PM은 Project Discovery의 과정을 거치는데 이 때 

Collect -> 최대한 여러 관점의 아이디어와 데이터를 수집하고

Validate -> 모여진 아이디어 중에서 Product Mission과 Vision에 맞는 것을 우선 선택하고

Prioritize -> 유효화 된 선택항목의 우선순위를 선정하고 정렬한다 

 

이후 PO는 Product Delivery 과정을 이행한다 

우선순위와 타임라인에 맞추어 Product Delivery를 이행한다 

PO는 개발이나 디자인 팀에 속하는데(주로 기능) Product 기능에 릴리즈를 담당한다. 

 

 

위의 경우 작은 조직이라면 Validate와 Prioritize를 담당했던 PM이 백로그를 만들고 기능과 릴리즈 플랜을 작성하여 각 분야의 리더들과 함께 Scrum, 프로세스를 진행한다 

큰 Product의 경우는 기능ㅇ을 분류하고 백로그를 만들때는 구체화 되는 과정이 필요하기 때문에 각 기능에 전문지식을 갖춘 사람들도 필요하게 된다 

 

PM이 가져야 하는 최고의 기술은 뭘까?

협력적 사고 방식, 고객 우선, 업무 효율성 3가지가 있다 

 

협력적 사고 방식

PM은 모든 커뮤니케이션의 허브로서 작동을 한다 

주변의 모든 사람을 프로세스에 참여시켜야 한다

PM의 기능이 소셜 그 자체이다

최고의 기능은 누구 한 사람의 머리에서 나오는 것이 아닌 항상 개발자 디자이너 마케팅 등 다양한 이해관계자와 설계

스펙을 공동으로 만들어야 한다

도메인과 다른 도메인에 있는 사람들에게 스펙 검토를 요청 해야한다

특정 사례의 누락을 방지 해야한다

친구를 많이 만들어야 한다

업무를 많이 수행하기 때문에 이해관계자와 그 사람들을 찾고 그들과 가장 좋게 협력하는 방법을 찾아야한다

가장 중요한 점은 영향력을 통해 사람들을 이끌어야 한다

단지 일의 진행 상황을 이끄는 것이 아니다

Product 팀은 고객에게 어떤 도움이 될 지 명확하지 않을수도 있고 문제에 대한 해결책이 없을수도 있다

항상 열린 마음으로 들어야한다

항상 팀으로 부터 제안을 들을 수 있는 방법을 가지고 있어야 한다

 

고객우선

지속적으로 사용자 현재의 고객 미래의 고객 잠재 고객과 대화하여 배워야 한다

사용자와 대화를 해야한다

현장에 나가서 실제 상황을 직시 해야한다

 

업무 효율성

자신의 프로덕트를 누구 보다 잘 알아야 한다

새로운 워크플로우를 계속 시도 해봐야한다

책임과 오너쉽을 가져야 한다

중요할 때 아니오라고 말할 수 있는 것을 배워야 한다

스스로 결정을 내리는 방법을 알아야 한다

현재의 툴을 잘 사용 할 줄 알아야 적재적소에 사용 가능 할 수 있다

시간 관리 기법 활용 일/주/월 목표를 세워야 한다

 

이외에 기타 역량으로는 공감, 미션 정의, 성장 마인드, 문제 프레임 및 솔루션 설계가 있다