brunch

매거진 프로덕트 매니지먼트 101

라이킷 22 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 파이온티어 사나 Oct 21. 2023

제품개발 수명주기에 따른 PM의 단계별 역할 가이드

제품기회 발견부터 배포 후 개선까지, 단계별로 알아보는 PM의 역할

제품 명세서와 PRD 작성하기, 유저 리서치, 제품 데이터 분석하기, A/B 테스트 설계하기, 개발자와 일정 상의하기, 배포 준비하기, 배포 전략 세우기, 이해관계자 설득/회의잡기...

프로덕트 매니저가 해야하는 수많은 일, 누가 정리좀 해줄 수 없나?

"필(P)요하면 뭐든(M)" 하는 사람이 PM 이라는 말이 나오듯이, PM 취준생이거나 갓 시작한 주니어 PM이라면 PM은 정말 전부 다~ 하는 사람인지, 도대체 무슨 일을 하는 사람인지 궁금할 것이다. 궁금증을 풀기 위해 이리저리 검색해봐도 파편적으로 흩어진 정보만 나열될 뿐, 검색하면 할수록 너무 많은 업무영역때문에 골머리가 아프다.

따라서 이번 글에서는 프로덕트 매니저가 해야하는 업무의 A-Z를 '제품개발 수명주기'의 단계별로 정리하여 설명할 것이다. 제품개발의 초기단계부터 마무리 단계, 그 후 다시 처음으로 돌아가 반복하는 단계들을 살펴보면서 각 단계별로 프로덕트 매니저가 어떤 역할을 해야하는지 하나씩 체계적으로 살펴보자.

*주의

제품개발 수명주기는 절대 일직선으로, 순차적으로 이뤄지는 것이 아니다. 실무에서는 여러 단계가 중첩되기도 하고, 필요에 따라 순서가 누락되거나 추가되고 바뀔수도 있다. 회사, 조직, 프로덕트가 처한 상황이 전부 다르기 때문에 PM과 개발팀이 일을 하는 과정도 각자 다를 수밖에 없다.

하지만 이 글에서 제시하는 수명주기는 '시작하는 PM'들의 이해를 돕기 위한 것으로, 일반적으로 통용되는 패턴을 제시한다. 회사 각각의 업무 프로세스의 상세내용은 모두 다르겠지만, 거의 대부분의 회사에서 제품개발 수명주기의 큰 그림을 보았을땐 이 패턴과 유사하게 진행될 것이다.

Double Diamond Model 을 참고한 Product Development Life Cycle

PM 업무의 양대산맥: '발견(Discovery)'과 '전달(Delivery)'

PM은 한번에 한가지 업무만 하지는 않는다. 보통 여러 일을 동시에 하게되는데, 그 업무들을 큰 두갈래로 분류하자면 '발견'과 '전달'업무로 나뉜다. 두 업무를 쉽게 설명하면 '발견'이란 어떤 문제를 풀기위해 어떤 기능을 개발해야 하는지 발견한다는 의미이고, '전달'이란 그 기능을 개발하고 고객에게 전달할 수 있도록 실제로 구현 및 배포하는 과정이다. 보통 대부분의 실무에서는 이 두 업무가 동시에 진행된다. 동시에 진행하지 않으면 어떤 기능을 배포한 뒤에 개발자들과 그 다음 개발할 기능을 정의하기까지 일정기간 공백이 생겨버리기 때문이다.

* 수명주기 전체에서의 공통업무: 가설 설정과 검증

여기서 잠깐! 수명주기 전체 단계에서 항상 수행되어야할 일이 있다. 바로 '가설 설정'과 '검증'이다.
그렇다면 어떤 영역을 가설로 설정하고 검증한다는 것일까?프로덕트 개발의 초기 단계에서는 풀고자 하는 문제, 고객의 진짜 니즈, 사업적 니즈, 시장 크기 등에 대한 가설을 설정하고 검증할 수 있다. 그 후 단계에서는 해결책, 사용성, 기능성, 배포플랜 등에 대한 가설을 세우고 검증할 수 있다.

1. 진짜 문제를 발견하라 - '발견(Discovery)' 단계

주니어가 종종 하는 실수가 있다. 바로 '곧이 곧대로' 하는 것이다. 이게 무슨 말인지 어떤 상황을 가정해보자.

어느날 여러분 회사의 경영진 중 한명이 당신을 불러세우고는 '엑셀 파일 내보내기' 기능을 추가해달라고 말한다.

"사나씨 엑셀파일 다운받는 기능좀 만들어주세요."
(더이상 묻지않고.. 곧이곧대로) "넵!"

이런 요청은 굉장히 간단해보이는 요청이다. 하지만 기존 코드 위에 이 기능 하나를 추가하기 위해 몇주가 소요되고, 당신은 성공적으로 버그없이 기능 배포까지 마쳤다. 하지만 배포하고보니 '아무도' 사용하지 않는다. 당신의 성과를 평가하는 연간리뷰 시간이 돌아오고, 안좋은 성과의 모든 책임은 기능개발을 요청한 '그 경영진'이 아니라 바로 '당신'에게 돌아온다. 자, 도대체 뭐가 잘못된걸까?

당신이 PM으로서 놓친 부분은 경영진의 요구를 너무 곧이곧대로 받아들였다는 점이다. 만약 당신이 경영진의 요청에 대해 그 근저에 깔린 진짜 의도와 문제를 보려고 더 깊게 접근했다면 결과는 더 나았을것이다. 즉, 여러분이 시작하는 첫 단계에서 가장 먼저 거쳐야할 단계는 '어떤 문제가 진짜 풀어야 하는 문제인가?'를 제대로 알아내는 '발견'단계이다.

모든 개발주기의 처음은 초기의 단순한 아이디어부터 시작한다. 이 단순한 아이디어는 당신이 스스로 인지하게 된 문제에서 나올수도, 누군가로부터 요청받은 기능일수도, 성과가 낮은 지표를 개선하기 위함일수도, 새로운 시장의 등장에 적응하기 위함일수도, 그 외에도 여러 원천에서 영감을 받아 생긴 것일수도 있다. 이 '발견'단계 동안, 여러분은 초기의 아이디어를 고객의 니즈, 문제, 목표를 정확하게 이해하면서 확장시켜나가야 한다.

많은 신규 기능들이 런칭되고 실패한다. 그 이유가 뭘까? 어떤 문제가 진짜 문제인지 잘못 짚었기 때문이다. 고객이 개발해달라고 말했던 기능의 세부사항을 잘못 이해했거나, 관성을 뛰어넘을 만큼의 큰 문제가 아님에도 불구하고 너무 작은 문제에 집착했거나, 전체 문제의 근본 원인을 보지 못하고 부분에만 매달렸을 수도 있다.

PM은 풀만한 가치가 있는 정도의 '큰 문제'이면서도, 개발팀이 성공적으로 구현할 수 있는 '실현 가능한 수준의 문제'에 집중해야한다.

그렇다면 PM은 '문제를 발견하기 위해' 무슨 역할을 수행할까? 업무 리스트를 나열해보자.

- 기능 요청서 분석
- 퍼널 지표 분석
- 고객 인터뷰
- 컨셉 목업 테스트
- 장기 전략에 대한 논의
- 경쟁사 리서치
- 시장 조사
- 브레인스토밍 세션 열기
- 디자인 스프린트 열기

2. 어디까지 풀 것인가? - '정의(Define)' 단계

이제 앞 단계에서 여러분은 충분히 고객에게 공감하여 진짜 문제를 알아냈고, 모든 팀에게 그 중요성을 인지시키기까지 했다. 그래서 여러분은 UX/UI 디자이너와 함께 일을 시작한다. 하지만 디자이너가 훌륭한 솔루션을 들고 여러분께 보여준 것이 무려 6개월의 개발이 필요한 정도의 큰 규모이며, PM인 여러분이 기능 몇가지를 제외하려고 하자 고객을 위해 반드시 필요한 기능이라며 의견충돌이 발생한다. 자, 여기서는 도대체 뭐가 빠졌길래 이런 문제가 발생할까?

여기서 빠진 단계는 바로 명확한 '정의'의 단계이다. 당신은 PM으로서 문제의 명확한 범위를 정의하고 문제를 풀었을때의 성공적인 모습이 어떤 모습인지에 대해 팀원들과 명확하게 싱크를 맞추지 않았다. 당신은 첫 배포때 단지 간단한 수준의 개선을 생각했을지 몰라도, 디자이너는 그 의도를 이해하지 못했던 것이다.

즉 '정의' 단계에서는 당신이 팀원들과 나눈 고객의 진짜 문제에 대하여 보다 구체적으로 실현가능한 수준으로 수렴하도록 정의해야한다. 다만, 이 단계에서 구체적으로 구현될 기능의 설계까지 당신이 전부 마쳐야한다는게 아니다. 물론 대략적인 가설로서 구현될 기능을 제시할 수는 있겠지만, 궁극적으로 이 단계는 문제를 해결했을때 나와야 하는 결과가 어떤 결과인지 '성공'을 정의하고 문제의 범위에 대하여 팀원들과 정의하는 단계인 것이다.

그렇다면 PM은 '풀어야 할 범위를 정의하기 위해' 무슨 역할을 수행할까? 업무 리스트를 나열해보자.

- 발견 단계에서 발견한 문제들의 우선순위 설정
- 주요 타겟 고객 정의
- 고객 여정 매핑
- 성공 지표 정의
- 제품 비전 수립
- 고수준 제품 로드맵 정의
- 타임라인 초안 설정

3. UX와 사용성을 고려하자 - '설계(Design)' 단계

상상해보자. 드디어 여러분은 다같이 합의한 정의에 따라 기능을 빠르게 설계하고, 개발하고, 배포하여 고객의 반응을 살펴본다. 그런데 이번에도 문제가 발생한다. 고객이 기능이 너무 어렵다며 컴플레인을 걸어온다. 어떤 단계가 빠져서 발생한 문제일까? 바로 '설계' 단계에서 여러 구현 방안과 사용성에 대한 고려가 제대로 이뤄지지 않았기 때문이다.

'설계'단계란 단순히 아이디어를 그림으로 그려내는 것이 아니다. 이 단계에서는 목업이나 프로토타입을 통해 실제로 사용할 유저들을 대상으로 사용성에 대해 미리 테스트해보고, UX에 대해 깊게 고민해보는 단계이다. 또한 기술적 해결책에 대해서도 여러 방면으로 고민해야하는 단계이다.

이 단께는 보통 구현단계의 가장 초기 단계이다. 그런데 프로젝트가 충분히 복잡하거나 대규모라면 설계를 모두 마치고 구현에 들어가는 것이 아니라 설계와 구현단계가 중첩되어 진행되기도 한다. 이러한 방법론은 종류가 많다. 워터폴, 애자일 등의 여러 방법론을 들어보았을 것이다. 또한 디자이너의 설계 후 개발자가 구현하는 것이 일반적이나, 먼저 개발자가 기초적인 디자인으로 프로토타입을 구현한 후에 디자이너와 함께 구체적인 디자인을 설계하기도 한다.

그렇다면 PM은 '사용성 높은 설계'를 위해 무슨 역할을 수행할까? 업무 리스트를 나열해보자.

- 제품 명세(스펙) 작성
- 어떤 기능을 넣고, 뺄지 결정
- 다른 팀과 협업이 필요한 부분 논의
- UX/UI 디자이너, 개발자와의 설계 회의
- 설계에 대한 피드백 받기
- 사용성테스트

4. 걸림돌을 치우자! - '구현(Develop)' 단계

드디어 아이디어를 코드로 옮기는 '구현' 단계이다. 이 단계가 바로 프로덕트 매니저가 '프로젝트 매니지먼트'에 대한 책임을 부여받는 단계이다. (혹은 PM이 아니라 다른 테크리더가 이 단계의 책임을 지기도 한다.) 이 단계에서는 실제 구현단계이기 때문에 사전에 미처 예상하지 못했던 일이 여기저기서 발생한다. PM이라면 이런 예상치 못한 일들로 인해 팀원들이 어려움을 겪지 않도록 적극적인 자세로 상황을 살피고 핸들링해야한다. 당신이 팀에 대해 더 적극적으로 책임지면 질수록, 프로덕트의 구현은 더 빨리질 것이다.

그렇다면 PM은 '걸림돌 없는 원활한 구현'를 위해 무슨 역할을 수행할까? 업무 리스트를 나열해보자.

- 개발자를 위한 스토리와 티켓 작성 (*티켓이라함은 Jira와 같은 협업툴의 티켓을 말하는 것이다.)
- 어떤 세부지표를 추적할건지 결정
- 버그 해결
- 팀원들이 고뇌하는 문제가 없는지 지속적으로 체크
- 구축중인 기능들을 사용해보고 피드백 제공
- 이해관계자, 의사결정 승인자와 지속적으로 싱크맞추기

5. 사실 제일 무서운 단계 - '배포(Delivery)' 단계

기다리고 기다리던 '배포' 단계다. 드디어 여러분의 솔루션이 고객에게 전달된다. 고객에게 배포할때는 아무도 모르게 조용히 배포하기도 하고, 배포를 동네방네 알리며 고객에게 이벤트를 열고 성대하게 축하하기도 한다.

어찌되었든, 배포 단계는 절대 안심할 수 있는 단계가 아니다. 배포후 발생할 수 있는 여러 문제가 도사리기 때문에 오히려 PM이 촉각을 곤두세워야 하는 시기다. 필자 역시 배포날이 제일 긴장된다. 제품이 출시 직후에야 버그가 있다는게 발견되고, 출시일에 서버가 다운되는 모습을 보고싶지 않을 것이다. 미리 영업 및 지원 팀에게 수정사항을 알리지 않고 고객이 갑작스러운 변화에 놀라 컴플레인을 거는 모습을 보고 싶지 않을 것이다. 어쩌면, 수천 명의 사람들에게 앱 스토어에 아직 오픈되지 않은 앱을 다운로드하라는 이메일을 실수로 보내고 싶지도 않을 것이다.

따라서 PM은 '문제없는 성공적인 배포'를 위해 무슨 역할을 수행할까? 업무 리스트를 나열해보자.

- 검증 절차 수립하기 (도그푸딩, 베타테스트, A/B테스트, 안정성 테스트 등)
- QA과정 조직하기
- 출시에 관련된 파트너들과 출시준비 마치기 (승인받기 포함)
- 배포/런칭계획에 대한 마케팅 팀과의 제휴
- 영업팀 교육 및 고객지원팀과 함께 축하하기

6. 절대 무시해선 안되는 핵심 - '회고(Debrief)' 단계

이제 문제없이 배포도 완료했겠다. 드디어 끝~ 이 아니다!!! 절대 무시해선 안되는 핵심적인 단계가 남았다. 바로 '회고' 단계다. 많은 사람들이 하나를 배포했으니 곧바로 다음 런칭을 준비하려고 한다. 그러나 사실 굉장히 중요한 마무리 단계가 남았는데, 프로덕트 개발과정을 평가하고 과정상의 시사점을 도출하는 일이 필요하다. 이 단계에서 다음 개발에 혁신을 가져다줄 좋은 인사이트가 나올 수도 있다. 또한 당신을 훌륭한 PM으로서 성장하게 하고, 팀 내외로 당신에 대한 신뢰도 높일 수 있는 단계가 바로 이 단계가 될 것이다.

그렇다면 PM은 '훌륭한 인사이트를 도출할 회고'를 위해 무슨 역할을 수행할까? 업무 리스트를 나열해보자.

- 무엇을 잘하고, 못했는지 회고
- 런칭관련 지표 데이터 분석
- 런칭에 대한 고객 피드백 읽기
- 고객 피드백을 통해 '빠른 후속 조치'가 필요한 작업의 우선순위 결정
- 런칭 성공여부 평가
- 사내에 런칭 결과 공유
- 다음 단계를 위한 플래닝

이번 글을 쓰기 위해 여러 제품개발 라이프사이클의 예시를 검색하고, 선별하고, 취합하느라 꽤 시간이 오래걸렸다. 하지만 필자도 그동안 어렴풋이 머리속으로 그렸던 단계들을 종합하는 과정에서 더 알게된 것이 많아 뿌듯하다. 맨 처음 필자가 창업을 위해 프로덕트 개발을 진행했을땐 이론적인 부분에 대해 아무것도 모르는 상태로 무작정 경험으로 부딪히며 깨달았었는데, 이 글처럼 정리된 가이드가 있었다면 프로덕트 개발을 진행하면서 우리가 제대로 하고있는게 맞는지 의심이 덜했을 것 같다. 이 글을 읽는 독자들에겐 시행착오를 조금이나마 줄여줄 수 있는 좋은 가이드가 되길 바라며 글을 마친다.