brunch

매거진 프로덕트 매니징 입문

라이킷 48 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by DANYA May 07. 2023

기획 직무와 PM 유형 구분 방법, PRD 이해하기

전략/사업/경영/서비스기획, 프로덕트 매니저/오너 등등.. 그리고 PRD

들어가는 말

기획자의 삶을 살아가야 할지, 살아갈 수는 있는지 고민이 많았다. 어쩌면 미친 놈처럼 이 일을 이해하고 전문성을 키우려 노력했던 시간이 무의미해질 수도 있겠다는 생각마저 들었다. 그러나 '일상의 모든 것이 기획이다'라는 말을 기억하고, 어떻게 살아가든 상관 없이 한 번쯤은 이 일을 정리해둘 필요가 있다고 느꼈다. 한국에는 기획이 너무 광범위한 범위로 쓰이고, 산업과 업종에 따라 다른 일을 하면서도 같은 '기획 직군'으로 묶이고 불리는 일이 잦다. 그렇기 때문에 이 직군은 신입이 거의 없고 다른 일을 경력 삼아 일하다가 넘어오는 경우가 잦은 것. 뭐, 업계 자체도 3년차 이상을 원하고, 100만 MAU를 가진 서비스에서의 경험과 다양한 스킬 및 능력을 갖춘 인재를 채용하려는 것처럼 꽤 높은 허들이 존재하는 것도 사실이다.

앞으로도 계속 이런 하드스킬적인 요소와 관련된 글을 쓸지는 모르겠다. 조금이라도 더 이해하고 습득해서 실무에 적용해보려고 용어와 개념부터 여러 방법론적인 걸 업무 시간 외에 공부하고 정리했었다. 일의 개념을 익히고, 그에 필요한 스킬을 갈고 닦고, 여러 방법들을 실무에 적용하는 일을 하다 보면 또 다른 기회가 있을 것이라 믿었고, 그게 내 가치가 될 거라 여겼다. 하지만 기획 일은 본디 경험과 경력이 중요한 분야 같다. 10여 년을 아팠던 사람은 못미더운 사람일 수밖에 없는 것이다. 게다가 사실 이런 글은 누구나 쓸 수 있고, 이미 많이 쓰이고 있다. 2013년도에 쓰였다면 작은 의미를 지닐지도 모르지만 지금은 도처에 널려 있다. 더 가치있는 글을 쓰고, 인사이트가 담긴 글을 쓰려면 더 깊고 넓은 경험을 해야 하지만, 나는 용어와 개념 정리에서 막힌 모양이다. 믿음을 주지 못한 내 탓도 있겠지. 아무튼 글 한 번 정리하고 넘어가자.

장문 주의!

Table of Contents
  1. 기획 직무 구분하기
  2. PM 유형 구분하기
  3. PRD 이해하기

기획 직무 구분하기

1. 들어가기 전에

전략기획과 사업기획은 일정 부분 혼재되어 있다는 점을 잊지 말자.

업종과 회사에 따라 Role과 업무범위는 다를 수 있다는 점을 참고하자.

2. 전략 기획

회사의 중장기 전략을 수립, 관리하는 일로써 시장/산업/트렌드의 변화를 감지하고 분석해서 회사가 나아가야 할 중장기 전략방향을 설정하는 일을 맡는다. 사업의 중장기 전략 수립 외에 사업성을 검토하거나 핵심성과지표(KPI)를 수립하고, 관리도 한다.

사업 기획

사업을 이루는 핵심 요소를 만들어내는 일로써 다소 추상적인 사업아이템을 구체화해서 명확한 실체가 드러나도록 하는 일을 말한다. 사업 비전/목표 확립, 사업기회 발굴, 사업 타당성 검토 및 실행계획 수립, 실행에 필요한 자원 정의 및 확보 방안 마련, 사업 실적에 대한 평가와 실적 개선 방안 마련 등이 이에 해당된다. 전략기획이 ‘앞으로 AI 분야에 진출해야 한다’고 하면, 사업기획은 ‘차량용 AI 기반 음성인식 스피커를 개발해야 한다’라고 말하는 직무다.

경영 기획

기획보다는 관리에 가까운 개념. 사내 각 부서가 세운 사업계획의 실적을 취합하고 분석, 실적을 관리하는 일을 한다. 보통은 전략기획/사업기획보다 재무쪽에 가까운 직무로 회계 지식이 필수적이다.

서비스 기획

구축된 비즈니스 모델의 세부 요소를 구체화해서 실제 서비스를 탄생시키는 일을 한다. 비즈니스가 해당 사업을 왜(WHY)하고 무엇을(’WHAT)할지에 방점이 찍혀 있다면, 서비스기획은 그 비즈니스를 누구(WHO)에게 어떻게(HOW) 제공할 것인가에 방점이 찍혀 있다고 볼 수 있다. 기본적으로 기획할 비즈니스 모델에 대한 명료한 이해가 필요하다.

주로 사용하는 도구/방법들

페르소나 (Persona)

유저 시나리오 (User Scenario)

요구사항 정의서 (Requirement Specification)

플로차트 (Flow Chart)

화면설계서 (Wireframe, Storyboard)

기능정의서 (Functional Specification)

정보 구조도 (Information Architecture, IA)

서비스 정책서 (Servie Policy Document)

서비스 기획 프로세스 (신규 서비스 기획) 참고 :: 링크

문제 발견 및 리서치

문제 정의

프로토타이핑

솔루션 디자인

프로덕트 빌딩

브랜딩

런칭 및 운영

홍보 및 개선

서비스 기획 프로세스 (사업기획부서, 클라이언트가 따로 존재할 경우) 참고 :: 링크

비즈니스 모델 분석 (요구사항 분석)

서비스 프로세스/정책 정의

목업 제작 (IA, Wireframe, 기능정의서, 요구사항정의서 등)

목업 기반 킥오프 미팅 (서비스 컨셉, 핵심 기능 공유)

리뷰사항을 반영한 프로토타입 제작

서비스 오픈 전략 수립 (시드유저 모집방안, 오픈 프로모션 설정)

디자인 시안 검토

QA (Quality Assurance) 시트 작성

테스트 진행

서비스 배포 및 모니터링

오픈 성과 보고 및 운영방향성 제시

상품 기획(Merchandiser, MD)

상품을 직접 기획하거나 외부에서 가져오는(소싱) 일로써 시장 트렌드를 분석해 잘 팔릴 만한 상품을 기획, 소싱, 판매하는 역할을 한다. 주로 상품판매와 유통의 관점에 치중된 개념으로, 제품을 생산하는 데 좀 더 치중된 개념인 제품기획자 (Product Planner, PP)와는 결이 조금 다르다. MD가 상품 판매에 중점을 둔다면, PP는 제품의 기획, 개발, 양산에 중점을 둔다.

PM 유형 구분하기

1. 들어가기 전에

직무를 무 자르듯 구분할 수 없다는 점을 이해하자. 모든 일은 회사가 속한 업계와 서비스, 조직의 직무 체계에 따라와 Role과 업무범위는 천차만별이다. 결국, 개념을 정의하고 용어를 아는 것보다 이들은 무엇을 하며, 어떻게 그들처럼 성장할 수 있을까 등을 고민하고 학습하는 일이 중요한 듯하다!

2. 프로덕트(Product)란?

프로덕트(Product)는 일반적으로 제품/상품을 말한다.

흔히 프로덕트 매니저(Product Manager)에서의 프로덕트는 제품/서비스를 말하고, 프로덕트 오너(Product Owner)에서의 프로덕트는 세분화된 서비스 기능 단위를 뜻하는 경우가 많다. 예를 들면, 금융 서비스에서는 ‘대출, 외환, 예금 등’ 각 부문을 프로덕트라고 할 수 있고, 이커머스 서비스에서는 보통 ‘회원, 주문, 결제, 물류, 배송 등’을 각각의 프로덕트라고 명명할 수 있다. 프로덕트를 어떻게 구분하고 구성하느냐는 전적으로 회사/조직에 달렸다.

3. 프로덕트 매니저란 (Product Manager, PM)?

프로덕트 매니저는 제품/서비스의 전략을 세우고 관리하는 전문가다.

프로덕트 매니저는 대개 마켓과 고객, 비즈니스 모델에 대한 명확한 이해와 전략 분석을 기반으로 프로덕트가 나아가야 할 전략과 로드맵, 우선순위 등을 세우고, 다양한 이해관계자(Stakeholder) 및 엔지니어 등을 설득한다. 간단히 말해서, 프로덕트와 마켓을 이해하고, 그에 따른 비전을 세우며, 여러 이해관계자들과 함께 프로덕트를 성공으로 이끄는 일을 하는 기획자로 볼 수 있겠다.

3-1. 좋은 프로덕트 매니저가 되기 위해서는...

세 가지 영역에 중심에 있는 역할자로써, 최소 한 개 이상의 분야에서 일정 부문 이상의 깊은 이해도와 경험을 필요로 하고, 나머지도 원활한 커뮤니케이션과 의사결정을 위해 일정 정도의 이해도를 필요로 한다.

BUSINESS

무엇보다 프로덕트의 비즈니스 가치를 극대화하는데 주력해야 한다. 그러기 위해서 프로덕트 매니저는 투자 수익률을 극대화하면서 비즈니스 목표(Goal)를 달성하기 위해 프로덕트를 최적화하는 데 집착하는 게 필요하다.

TECH

프로덕트가 어떻게 만들어지는지 모른다면, 무엇을 만들지를 정의할 수 없다. 그렇다고 해서 프로덕트 매니저가 코딩을 해야 한다는 뜻은 아니지만, 올바른 결정을 내리려면 관련 기술 스택과 작업 수준을 이해하는 게 중요하다. 개발팀과 소통이 중요한 지점이 되겠다.

프로덕트 매니저는 비즈니스 내부 사용자의 목소리와 사용자 경험에 대해 열정적이어야 한다. 신생기업은 특히, 프로덕트를 테스트하고 사용자와 대화하면서 피드백을 직접 받아야 한다.

3-2. 무엇부터 해야 할까?

3-2-1. 비전 설정하기

당연한 말이지만 제품(프로덕트)의 비전을 설정하는 것부터 시작이다. 이를 위해 시장, 고객 및 고객이 느끼는 어려움(Pain Point)를 조사해야 한다. 피드백과 웹/앱 분석, 마켓 트렌드 및 통계 등 다양한 부문의 정보를 캐치하고 수집해야 한다. 중요한 것은 프로덕트가 속한 시장과 고객을 아는 것이고, 개발하려는 프로덕트가 타 서비스/프로덕트에 비해 어떤 강점과 차별점이 있는지, 고객의 가장 중요한 Pain Point를 해결할 수 있는지를 알고 설정하는 일이다.

비전을 설정했으면 비즈니스/조직에 퍼트리자. 고객에 앞서 함께 제품(프로덕트)을 개발하는 개발자, 디자이너, 영업부서, 마케터 등을 설득할 수 없다면, 그 비전은 명확하지 않거나 잘못 설정되었다는 뜻일 테니까 말이다. 제품의 성공은 모든 구성원에게 달려 있다는 점을 잊지 말자.

3-2-2. 로드맵 설정하기

이제 실행 가능한 계획을 세우자. 점진적인 개선과 수차례의 개발 로드맵 리뷰를 통해 명료하고 디테일한 계획을 세워보자.

3-2-3. 제품 개발

실제 제품을 개발하는 단계에 돌입하면 간과하는 일이 있다. 스타트업에 다니며 많이 겪었던 문제인데, 자꾸만 왜(Why) 이 제품을 개발하려고 하는지, 고객의 어떤 문제를 해결하기 위해서 이 제품을 개발하려는지를 잊게 된다는 거다. 아무리 비전을 잘 설정해도, 수많은 이해관계자가 모여 투닥(?)거리다 제품의 본래 목적은 점차 희미해지고 부가적인 부분들이 해당 제품의 핵심 기능을 잠식하는 일이 벌어지곤 하는 것이다. 작은 조직일수록 더 그런 듯한데, 이 때문에라도 의사결정자 등을 설득하고 의견을 관철할 수 있는 힘을 기르는 게 중요하다.

3-2-4. 분석, 개선, 디테일

프로덕트가 출시되면, 끊임없이 고객과 시장의 반응을 체크하고, 분석하고 그를 통해 하나씩 개선해나가야 한다. 끊임없이 디테일을 추구하고 제품을 개선해나가는 끈질김이 필요해지는 시기가 온 것이다.

4. 프로덕트 오너란 (Product Owner, PO)?

프로덕트 오너에서 말하는 프로덕트는 보통 세분화된 서비스 기능 단위를 말하기 때문에, 제품/서비스의 비전을 설정하고 개발을 주도하는 프로덕트 매니저와 다르고, 일정과 리소스 관리를 통해 클라이언트의 요구사항을 이행하는 프로젝트 매니저와 다르다.

보통 프로덕트 오너는 고객경험을 최적화하고, 분석해서 담당하는 프로덕트/서비스의 비즈니스 임팩트를 강화하는 데 몰두하는 지휘자 역할을 한다.

여기서 프로덕트는 대개 금융 서비스라면 외환/수신/여신/보험 등으로, 여행 관련 서비스라면 항공/숙박/렌터카/입장권 등으로, 디지털 커머스라면 주문/결제/배송/회원/쿠폰 등으로 나눌 수 있는데, 각 담당 분야의 지휘자로써 팀의 비전을 세우고, 어떤 서비스를 만들어낼지 고민하고, 비즈니스/데이터 분석을 통해 사용성을 지속적으로 개선하는 등 ‘출시된 서비스’를 총괄해서 전두지휘한다.

물론 이때, 서비스기획자나 프로젝트 매니저처럼 화면설계서(스토리보드)나 플로차트를 그리는 등 서비스를 구현하는 데 집중하기보다 해당 프로덕트의 적절한 마켓핏을 찾고 비즈니스 임팩트를 높이기 위해서 어떠한 방법을 시도할 것인지 가설을 세우고 실행하고 검증(데이터 분석)하며 끊임없이 이를 개선해나가는 일을 하는 데 집중한다.

4-1. 그래서 뭐가 달라?

프로덕트/프로젝트 매니저, 혹은 서비스 기획자는 제품/서비스가 출시되기 전, CEO 및 사업기획부서 혹은 클라이언트로부터 요구사항을 전달받아서 제품/서비스를 개발하고 테스트(QA)하는 데 초점이 맞춰져 있다면,

프로덕트 오너는 개발된 제품/서비스를 어떻게 하면 더 나은 서비스로 발전시킬 수 있을지를 세부 기능/서비스 단위로 비전수립 및 분석, 구체적인 실제 액션을 시행하고 평가/개선하는 데 좀 더 초점이 맞춰진 역할로 볼 수 있겠다. 대개 해당 직무는 어떻게 하면 더 나은 고객경험을 제공해서 비즈니스를 성공시킬 수 있을까를 고민하는 역할이다보니 B2B보다는 B2C 서비스에서 주로 활용된다.

5. 프로젝트 매니저란 (Project Manager)?

시간과 비용, 품질, 인력 등 프로젝트를 진행하는 데 필요한 요소들을 관리하고 리소스를 투입해서 계획된 일정과 목표했던 기능/품질을 담은 프로젝트를 완성짓는 기획자이다. 프로젝트 매니저는 개발팀, 디자인팀 등 내부 개발부서 등과 협업해서 프로세스를 설정하고, 적절히 리소스를 투입해서 목표했던 결과를 이끌어내는 프로젝트 리더이다. 흔히 SI(System Integrator)나 에이전시(Agency) 등에서 클라이언트가 요청한 솔루션/시스템을 개발하는 프로젝트 기획 담당자를 프로젝트 매니저라 부른다.

5-1. 좋은 프로젝트 매니저 (Project Manager)가 되기 위해서는...

보통 프로젝트는 명확한 데드라인이 있고, 한정된 리소스를 갖고 운용해야 한다. 이를 위해 정해진 일정에 제품/서비스/솔루션을 개발/납품할 수 있도록 일정을 관리하고, 한정된 자원을 어디에 얼만큼 투입할 것인지 판단하고, 어떤 차별화된 솔루션을 제공할 수 있을지 고민하고, 수많은 이해관계자와 커뮤니케이션을 통해 원활히 프로젝트를 완수할 책임을 갖는다.

좋은 프로젝트 매니저란 결국, 일정/비용/시간을 효율적으로 관리해서 차별화된 결과물(제품/서비스/솔루션 등)을 이끌어낼 줄 아는 사람일 것이다.

6. 프로그램 매니저란 (Program Manager, PgM)?

프로그램 매니저에서 프로그램이란 여러 프로덕트/프로젝트들의 묶음을 뜻한다.

결국, 유사한 프로젝트/프로덕트를 관리하는 역할인데, 대개 이러한 프로젝트/프로덕트의 묶음이 가져올 비즈니스 임팩트가 어떠할지, 이를 관리하고 발전시켜나갈 장기전략은 무엇일지를 설정/분석하는 일을 한다고 보면 되겠다. 여러모로 다른 직군에 비해 상위직급일 수밖에 없다. 이에 대해서는 (링크)에서 잘 설명하고 있는 듯하니 참고하자.

PRD 이해하기

1. 제품 요구사항 정의서란? (Product Requirement Document, PRD)

제품 요구사항 정의서(PRD)란 신규 개밫 및 기능 개선이 필요한 특정 제품(Product)의 요구사항을 정리한 문서이다. PRD는 소프트웨어 제품용으로 가장 자주 작성되지만, 모든 유형의 제품과 서비스에 사용할 수 있다. 일반적으로 기획/마케팅부서에서 작성되고, (잠재적) 제조업체/공급자가 보다 기술적인 관점에서 요구사항을 분석해 기술 요구사항 문서(Technical Requirement Document)에 자세히 설명한다. [위키 참조]

2. PRD는 어떻게 쓰는 걸까?

PRD 작성법은 통일되어 있지 않고, 통일될 수 없다는 점을 참고하자.

핵심은 크게 네 가지다.

왜 만들어야 하고, 만들어서 얻을 수 있는 목적은 무엇인가?

누구를 위한 제품(Product)인가?

어떻게 구현할 것인가?

구체적인 실행 계획은 무엇인가?

WHY and GOAL

해결하려는 문제가 무엇이고, 그것이 사용자에게 얼마나 고통스러운 문제인가.

이런 문제가 존재한다는 걸 알게 한 사실들은 무엇인가.

그 문제를 해결할 핵심 솔루션은 무엇인가. 그것으로 사용자가 얻는 이득은 무엇인가.

WHO

주요 사용자(Target User)는 누구인가?

그들의 사용자 여정(User Journey)는 어떻게 되는가?

HOW

제품 구현에 필요한 기능(Function)은 무엇인가?

제품을 구현하기 위한 UX 참조 사례 및 사용 케이스는 무엇이 있는가?

엔지니어/디자이너가 참조할 수 있도록 비슷한 사용자경험을 제공하는 제품을 참조하기

GOAL

PRD가 목표하는 바가 성공적인지 아닌지를 판단할 근거는 무엇인가?

성공여부를 분석할 이벤트/지표를 정의하고 구현하기 이 과정에서 정량/정성적 분석 모두 시행할 것

PLAN

구현 가능한 실제 실행계획은 어떻게 되는가?

투입 조직 및 인력, 각 작업공정별 소요 예상 시간 등을 적시한 문서 작성하기

3. 잘 쓴 PRD란?

처음부터 완벽하게 작성하려 들지 말 것

초안 작성 후, 엔지니어 파트에 리뷰하고 피드백을 받자 (솔루션은 항상 엔지니어파트와 협업하면서 정의해야 불필요한 시간 소모를 줄일 수 있다)

가장 먼저 할 일은 팀원들에게 ‘왜’ 이 문제가 중요하고, 중요하게 해결해야 하는 문제인지를 설득해서 이해와 공감을 불러일으키는 것임을 이해하자

서술형을 피하고 구조화되고 조직화된 형태로 문서를 만들자

잘 쓴 글을 공유하는 것보다 이해하기 쉬운 문서를 공유하는 것이 중요하다.

문제/핵심에만 집중해서 작성해보기

여러 도식이나 표를 활용해서 한눈에 들어오는 문서로 제작해보기

중요한 건 문서를 접한 사람이 이해하는 데 오랜 시간이 걸리지 않거나 불필요한 노력을 하지 않아도 되도록 만드는 것임을 이해하자

4. PRD를 잘 활용하기 위해서는

PRD는 제품 개선/개발 목적을 분명히 하고, 여러 파트의 담당자들이 함께 같은 목표로 나아갈 수 있도록 하는 합의 문서이다.

그 과정에서 핵심 이슈 사항(의견이 불일치하거나 논쟁 여부가 있는 사안)을 논의할 때, 이슈에 집중할 수 있도록 관리/정리하는 게 필요하다.

논의를 끝마쳤으면 (모두가 합의를 완료했다면) 그 결과를 PRD에 정확히 기록해두자. 분명하게 완결짓고 다음으로 넘어가는 연습은 꼭 필요하다.

다른 건 없다. 위 전 과정을 무한반복하는 수밖에.

번외의 말

고민이었다. 열리지 않는 문 같은 기획자의 삶을 꿈꾸고 고군분투하며 살아가는 일이 맞는지, 문조차 보이지 않는 다른 삶을 꿈꾸며 찾기를 바라는 일이 맞는지를 두고 갈팡질팡했다. 기획은 늘 나를 최대로 살아가기를 바랐고, 다른 길은 먹구름과 안개가 가득한 거리를 계속해서 헤쳐나가야 할 것이라며 겁을 주었다. 현실은 냉혹하고 이상은 고매해서 나는 항상 나를 지키는 일을 찾고 싶었지만, 몸과 정신을 지킨다고 해서 생활이 해결되는 것은 아니어서 고심이 깊었다. 번뇌의 나날이었다.

마음은 기울었지만 확신은 없었다. 나는 여러 문을 두드렸고, 지난 몇 년간 기획 공부를 하겠노라고 업무 시간 외에 쏟은 시간이 얼마인지 가늠조차 되지 않았지만, 현실의 평가는 준엄했다. "어떤 기획자인지 모르겠어요." 그 말이 폐부를 찔렀고, 한동안 나는 나를 잃어버린 듯하였다. 함께 할 사람은 나를 몰랐고, 함께 한 사람은 자신을 몰랐다.

어떤 일을 하며 살지는 모르겠다. 지난 회사에서 어이없는 일로 퇴사한 이후, 여러 상황이 생겼고 또 사라졌다. 나는 다시 기로에 서 있다. 하지만 일상의 모든 것이 기획이다. 이곳의 글 또한 '나의 생활'과 '나의 일'로 접점 없이 구분된 영역처럼 보이지만 결국은 하나다. '문제를 발견하고, 알맞는 질문을 하며, 적절한 해결 방법을 찾는 일'은 삶에서 떼려야 뗄 수 없는 일이다. 그러므로 무엇을 하든 현실에서 민낯을 발견하고 해석하고 해결해나가는 일은 계속될 것이다.