PM/PO/서비스기획자는 어떤 제품을 만드는가?

※ 중요 : 아래 내용은 패스트캠퍼스의 "PM/PO 실무 완전 정복 초격차 패키지 Online "강의 내용을 정리한 것으로, 강의 내용 중 일부를 캡처한 이미지는 저작권에 문제가 있는 경우 삭제될 예정입니다.

Part 01 - Chapter 02. 제품의 이해 [패스트캠퍼스 초격자패키지 PM/PO 스터디]

 

I. 제품의 정의

프로덕트=제품인데, 우린 상품 또는 서비스라는 용어와 혼동하여 사용하는 경우가 많아서
제품이란 무엇인지 정의를 먼저 해보도록 한다.
그리고 이 강의는 PM/PO에 대한 강의이므로, 우리에게는 '제품'이란 'Software 기반의 제품'에 한정된다.
 

II. 제품의 유형

왜 제품의 유형을 알아야하는가?
원론적인 카테고라이징이 아니라, 사업의 방향을 기준으로 나눠보도록 한다.
제품 유형의 이해성을 파악하지 않은 채 제품을 관리하게 된다면 갈등이 많이 생길 수 있다. 이 갈등은 설계/개발하는 조직과 매출달성/운영을해야하는 조직 간에 자주 발생하는데, 발생하는 이유 중 대표적인 이유는 제품의 방향성을 사전에 협의하지 않고 빨리빨리 진행하는것에 집중되어있다보면 다 만들어놓고 보니 다른 제품인 경우가 많고, 이미 개발리소스가 투입된 상황에서 다시 되돌리는 것은 조직에 큰 스트레스를 주기 때문이다. 예, B2B 솔루션 제품의 갈등 : 영업조직 "커스터마이징이 필요하다"  vs 제품관리조직 "일반화의 오류를 피하자"
이 갈등포인트는 제품의 유형별로 다를 수 있다.
 
 
[갈등의 유형]
Case 1. 사업의 단계에 따라 해결방법이 다를 수 있다.
최초로 시장에 도입하는 단계라면 애자일하게 빠르게빠르게 있어야하는 기능에 집중하여 제품관리의 설계역량과 제품이해도에 의존하는것이 낫고, 제품이 돈을 많이 벌어야하는 단계라면 제품의 차별성이 중요하기 때문에 헤비유저들을 위한 특별 기능들에 집중하여 제품을 개발하는것이 낫다.
 
 

→ STUDY : 내가 속한 회사는 판매를 극대화 하는 단계이기도 하면서 새로운 제품을 시장에 내놓는 단계이기도 하다. 공통 제품이 없었기 때문에(플랫폼) 새롭게 출시를 하는 단계이고, 기존에 있던 c2c/b2b는 판매를 극대화 해야하는 단계이다.
 
Case 2. 누가 제품유저를 가장 잘 아는가?
솔루션을 제공하는 형태에 따라 제품유저를 가장 잘 아는 조직은 다를 수 있다. 예를들어, 대면 스킨십이 중요한 시장이라면 고객/고객사를 직접 마주하는 영업조직이 제품유저를 가장 잘 안다고 할 수 있지만 슬랙/노션과 같은 솔루션은 영업조직을 통해서 제품을 사용하는 것이 아니라 무료 test 기간을 거친 후에 가입하는 유저들이 더 많아서, 데이터를 통해 유저의 형태를 파악하고 이용할 수 있으므로 영업관리자보다는 제품관리자가 유저에 대한 이해도가 더 높다고 할 수 있다.
그러나 어떠한 형태라 할지라도 유저에 대한 스터디, 분석, 데이터 축적은 필요하다. 그렇지 않을 경우 제품 ownership이 사라진다.
포지셔닝이 어디인지 확인해야한다. 제품의 가치는 어디에서 오는가?를 파악해보는 것이 좋다.

→ STUDY : 우리 회사에서 제품의 유저를 가장 잘 아는 것은 사업별로 상이하다. C2C는 제품관리자가 유저의 행동을 분석하므로 가장 잘 알고 있고, B2B는 직접 영업을하고 관리를 하는 매출조직이다. 
 
[제품의 유형]
유형 1. 제품과 서비스(내부운영) 결합형 : 무신사, 지그재그, 브랜디 등 (주문을 중개하는 MD조직의 능력이 차별화)
유형 2. 제품과 서비스(외부노동) 결합형 : 숨고, 크몽 등 (외부 프리랜서를 관리하는 것이 차별화)
유형 3. 제품과 서비스(내부운영과 외부노동) 결합형 : 로켓배송, 마켓컬리 (소프트웨어와 외부노동의 퀄리티가  차별화)
  ㄴ EndToEnd유저스토리(서비스를 이용하는 프로세스)가 길기 때문에 각 단계별로 끊어서 제품을 관리하는 경우가 있는데, 이 경우 PO와 PM의 갈등이 일어날 가능성이 있다.
유형 4. 제품 단독형(IT솔루션) : 슬랙, 카카오톡
유형 5. 서비스 지원형 : 고객상담시스템, 쿠팡 internal product 팀
  ㄴ 현장의 이해가 높아야한다. 
 
강사 왈 "제품의 유형을 파악하지 않고 제품을 관리하게 된다면 제품관리자는 경영자와 운영자 사이에서 샌드위치가 될 수 있다"

 
 

III. 도메인에 대한 이해

 
왜 도메인을 알아야하는가?
제품관리자/유관부서/경영진의 기업의 비즈니스 내에서 제품의 '역할'에 대해 명확히 이해하여 업무의 방향성을 일치시키기 위함이다. 더불어, 투입되는 리소스를 효과적으로 배분하고 제품의 '범위'별 다양한 제품 전략과 관리 방식(워터폴, 애자일)을 전개할 수 있는 제반환경을 마련하기 위함이다. 
 
빅뱅으로 만들어서 빅뱅으로 나가는 백엔드 제품이 있는가 하면 유저의 방식을보고 상품을 개발하는 제품도 있다(요즘 트렌드). 어떤 방식이 맞다고 할 수 없지만 보통 cpo, po의 취향에 따라 관리 방식이 달라진다.
 
 
제품의 생애주기란?
1. 시장초기진입 : 엔드유저가 사용하는 제품만 나오는 단계
2. 시장반응검토 : 운영해야하는 단계이기때문에 운영어드민 제품이 나오는 단계
3. 제품고도화 : 제품 로드맵을 수립하여 유저의 문제를 해결하는 단계
4. 사업고도화 : 매출 성장의 단계 (이 때는 제품을 체계적으로 잘 만들어야하기 때문에 워터폴 방식이 낫다)

→ STUDY : 우리 회사는 제품을 개선하는 것이라 아예 다시 만들기 때문에 시장초기진입 또는 시장 반응 검토와도 맞물리지만, 이미 C2C, B2B 제품 출시 후 시장반응검토는 끝났고 이를 고도화하는 단계이기도 하다. 두가지 상황이 중복되어있는데, 회사는 전자를 선택하고 전략을 설정하였다.
 
[도메인 분류 유형]
유형 1. 사용유저 중심 구분
사업 또는 조직이 커지면 가장 쉽게 업무를 분할하는 기준이 프론트와 백엔드이다.
프론트는 EndToEnd 유저에게 보여지는 제품이므로 아하!모먼트(액션을 유도할 수 있는 포인트)가 중요하고,
백엔드는 사업 구조 이해하는 것이 중요하다.
강사 왈  "비즈니스를 이해하기에는 백엔드를 담당하는것이 도움이 된다"

→ STUDY : 나는 BackEnd 제품 관리자이다.
 
유형 2. 기능 혹은 시스템 단위로 구분
각각의 기능 별로 mission이 다르다. 예를 들어, '검색'을 담당한다면 빠른 시간 안에 빨리 찾게해주는게 미션이라면, '장바구니' 기능은 장바구니에 담긴 것이 결제로 연결되는 것이 mission이다. 기능이 구분되는 경우, 하나의 기능이 바뀌면 다른 기능의 PO의 의존성(디펜던시)가 발생하는데, 이때 각 기능별로 우선순위 기준이 다르다면 싸울 수 밖에 없다 .이 때 기준을 잡아주는 것이 PO헤드와 CPO가 해야할 일이다. 타 기능으로 인해 의존성이 걸리는 경우 방어기조가 생길 수 밖에 없는데, 이 분위기를 깨는 방법 중 하나는 '협업기준, '협업프로세스', '통합목표'수립하여 제품 별 갈라지는 것을 방지해야한다.
강사 왈 "하나의 도메인을 세련되게 깊숙하게 아는 것보다는 업무를 가로로보는 능력이 필요하다."
 

→ STUDY : 나는 그중 송금을 Main으로 담당하고 있고, 부수적으로 회원을 담당하고 있다. 
 
유형 3. 사업단위로 구분
제품이 아니라 '사업'의 범위로 구분하는 것. 이 경우, 비즈니스 성공을 위해서는 차별화 포인트를 매우 정교하게 고민해야한다. 유저의 문제를 해결할뿐만 아니라 지불의지를 끌어내는 것이 중요하다. 제품 출시 초반에는 제품의 편의성이 중요할 수 있겠지만 제품이 커질수록 제품의 정교함이 중요하다.

→ STUDY : 우리 회사는 C2C 사업과 B2B 사업으로 나뉘고, 내가 담당하는 제품은 현재는 B2B에만 속하지만 C2C까지 사용하는 플랫폼이므로 두개의 사업에 걸쳐있다.
 
[위의 제품 유형에 따른 예시]
이륜사업과 신사업은 고객향 제품이고, 공통은 백엔드 제품이다.
고객향 제품은 트렌드파악, 유저의 액션 유도, 유저의 지불가치 유도, 유저 반응 분석이 중요하지만,
백엔드 제품은 하나만 바뀌어도 고객향 제품에 영향을 미칠 수 있기 때문에 애자일하게 했을때 문제가 발생하여서 완전 워터풀로 해야한다.

→ STUDY : 내가 관리하는 제품은 위의 예시에서는 '공통'에 해당한다.

타 도메인(기능)에 영향을 미치지 않는 Case A는 자율적으로 제품을 관리해도 되지만,
제품의 연관이 있는 경우에는 작은 수정 하나도 연계되는 기능의 도메인 담당자와 긴밀한 협의가 필요하다.
PO의 도메인 간 우선순위 네고 능력이 중요하다.
 

→ STUDY : 우리 회사는 도메인간 협업이 되어야하는 경우로, 내 기능에 변화/추가가 발생하는 경우 연계된 타 기능에 사전협의가 필요하다.
 

IV. 제품의 개발 및 운영방식의 이해

회사 별, 도메인 별, 기능 별 환경이 다르기 때문에 개발/운영방식을 알아야 한다.
보편적인 제품 개발 프로세스는 아래와 같다.

[제품의 개발/구현 방식]
Case 1. 개발 리소스에 대해 외주주는 경우
외주 개발의 일정 의존성이 높고, 추가 요건이 나오거나 상황이 바뀔 때 행정절차가 발생하므로 유연하게 대응이 어렵다.
개발 속도가 기획 속도를 따라가지 못하는 경우가 있다. 사업/서비스 기획에서 변화가 자주 일어날 수 있지만, 개발조직은 개발적시성이 중요하기 때문에 변화에 민감하다.
 

 
Case 2. 개발 / 기획 리소스가 모두 외주주는 경우
이 경우, 개발뿐만 아니라 사업/서비스기획도 변화에 예민할 수 밖에 없고 개발 속도가 느려지는 것이 보편적이다.

Case 3. Inhouse 이지만, 사업조직 vs 제품기획 조직이 분리하지 않은 경우
사업기획=제품기획이기 때문에, 매출전략이 제품전략이다. 비즈니스 속도와 개발속도가 비슷하다. 이때 개발 인력을 확보하는 것이 중요하다. 사업이 커질 수록 제품의 개발 우선순위가 중요해지는데, 우선순위를 조정하지 않을 경우 '모든 기능이 다 중요해,'모두 동시 진행해'와 같은 상황이 발생하면서 개발자를 계속해서 증원해야하는 문제가 발생한다. 
 

Case 4. Inhouse 이지만, 사업조직은 분리되어있지만 제품기획 / 개발조직을 분리하지 않는 경우
제품의 목표와 비즈니스의 목표를 동기화하는 것이 중요하다. 그렇지 않은 경우 따로 논다.(목표이원화)
비즈니스 별로 목적을 달성하는 방식이 제품이 아니라 영업이나 마케팅일 수 있지만, 제품기획조직과 개발조직이 분리되지 않은 경우, 기획과 개발이 하나의 목적으로 가기때문에 제품관리자가 추구하는 '유저의 문제를 해결하는 것'에 집중하여 개발된다. 즉, 비즈니스가 필요한 전략과 제품/개발이 취하는 전략이 상이한 문제가 발생한다. 목적조직으로 움직이는 조직은 빠르게 의사결정을 하는 장점이 있다.
(목적조직이 아니라 기능조직이라 할지라도 비즈니스를 적시 대응하는 것이 중요하다)
 

→ STUDY : 우리 회사는 사업조직과 제품기획조직이 분리되어있다. 그러나, 제품기획조직과 개발조직은 플랫폼 출시라는 공통 목적을 가지고 있지만, 다른 팀에 속해있다. 
 
[제품 관리/운영 방식]
Case 1. 기업규모에 따른 분류
소규모일때는 제품관리자가 비즈니스 전략을 선택한다. 빠르게 빠르게 사업 방향을 선택하고 제품을 개발하는 것이 중요하다.
중규모가 될때는 비즈니스 전략과 제품 전략이 나뉘며, 제품관리자의 전문적인 능력이 필요하다. 즉, 매출을 올리는 방법이 유저의 문제를 해결하지 않을 수 있다. PO/PM과 같은 제품관리자 직군과 헤드/리드를 두는 경우가 있다. 제품 담당자의 오너십이 내려간다. 나 혼자 독단적으로 선택할 수 없다.
대규모가 될때는 제품 자체가 당연히 중요하기도 하지만 이미 모든 내부운영자와 사용자가 아는 단계이기 때문에, 사업전략의 다변화가 중요하다. 

→ STUDY : 우리 회사는 2022년에 Series C를 받았으므로 중규모에 해당하며, 제품관리자의 Ownership은 내려가고 전문적인 능력은 높아지는 단계이다
 
Case 2. 조직에 따른 분류
목적조직(Feature team)은 제품관리자의 오너십이 높아진다. 제품이 빠르게 나와야하는 것이 중요하기때문에, 비즈니스 방향성과 개발이 모두 한 조직에서 결정된다.
기능조직(Component team)은 사업/운영/마케팅 등 조직이 나눠져있는 경우 인데, 사업/운영/마케팅과 제품조직은 누가 우위에 있는 것이 아니고, 같은 레벨에 있다. 제품담당자가 독단적으로 기능을 개발할 수 없다. 
 
 

→ STUDY : 내가 관리하는 제품은 기능 별로 담당자가 구분되어 있어 기능조직이라고도 볼 수 있지만, 위의 개발/구현 유형에 따르면 큰 목적조직이기도 하다. 개발팀과 제품관리팀이 하나의 목적 "플랫폼 출시"을 가지고 있기 때문이다. 여기서 궁금증이 생겨 강사에게 질문을 하기로 했다. 같은 팀에 소속되어있지 않지만 같은 목적을 갖고 있는 경우에는 목적조직인지 기능조직인지 말이다! 답변은 기능조직!
 
 
 
[참고]
목적조직과 기능조직에 대한 추가 Search를 해보았다
 
1. 목적조직(Feature team)은 개발/기획/디자인 등 여러 영역의 담당자들이 함께 속해있는 조직이고, 기능조직(Component team)은 각 영역의 담당자들이 각각 팀으로 구분되어 있는 조직이다.
2. 사업 초기에는 목적조직이 유리하고, 시장 Fit을 확인했을때부터는 기능조직이 유리하다.
 

 
 
 
 

---

 
Chapter 2를 시작하기 에 앞서, 강사님께서 아래의 질문에 답을 하는 것이 
이번 Chapter 의 목적이라고 하였다.
 
"OOO님은 어떤 제품을 담당하세요?"
"OOO님이 담당하시는 제품은 어떤 특성이 있나요?"
"OOO님이 담당하시는 범위는 어느 정도인가요?"
"OOO님의 제품은 어떤 구조로 운영되나요?"
"OOO님의 제품은 어떤 프로세스로 개발되나요?"
 
그리고, Chapter 수강을 마친 후 스스로에게 답해본다.
마지막 질문은 내가 올린 질문에 대해 강사로부터 답변을 받아야 내가 답변을 달 수 있을 것 같다.
 
"OOO님은 어떤 제품을 담당하세요?"  "저는 C2C, B2B 해외송금 서비스를 뒷받침하는 플랫폼 제품을 담당합니다"
"OOO님이 담당하시는 제품은 어떤 특성이 있나요?" "제가 담당하는 제품은 제품과 서비스(내부운영)이 결합된 제품으로, 매출조직의 과 협업이 중요한 특징을 갖고 있습니다"
"OOO님이 담당하시는 범위는 어느 정도인가요?" "저는 '공통'사업의 '송금기능'의 'BackEnd' 제품을 관리합니다"
"OOO님의 제품은 어떤 구조로 운영되나요?" "제가 관리하는 제품은 기능 별 전문적인 제품담당자를 두고, 여러 기능들과 협업하는 기능조직으로 운영됩니다."
"OOO님의 제품은 어떤 프로세스로 개발되나요?" "?"
 
 

---

 

패스트캠퍼스 "PM/PO 실무 완전 정복 초격차 패키지 Online" study 시작