내가 프로덕트 매니저로 전환하며 바뀐 것
서비스 기획자와 프로덕트 매니저의 차이점
IT 부문에서 프로덕트 매니저, 프로덕트 오너라는 직무가 언급되고 또 채용이 열리면서, 기존의 서비스 기획자 혹은 프로젝트 매니저와는 무슨 차이인가? 하는 질문과 이에 대한 설명이 넘쳐난다.
"서비스 기획자와 프로덕트 매니저는 무슨 차이인가요?"
"프로덕트 매니저와 프로덕트 오너는 무슨 차이인가요?"
"프로젝트 매니저와 프로덕트 매니저는 무슨 차이인가요?"
"프로덕트 매니저가 되고 싶은데 무얼 준비하면 되나요?"
기타 등등...
나의 경우 대기업, SI 에이전시가 아닌 작은 스타트업에서 어쩌다 보니 서비스 기획자겸 웹/앱 구축을 담당하는 프로젝트 매니저가 되어 있었고, 이후 기존의 서비스 운영, 운영관리 경험 등과 합쳐져 프로덕트 매니저로 전향한 케이스다.
그래서 내가 가진 지식과 경험이 서비스 기획에 대해 일반적인지, 또한 지금 하는 프로덕트 매니저로써의 고민과 업무가 일반적인지는 확답할 수 없지만 (모든 조직과 팀과 상황마다 다 다른데 이걸 누가 '일반적이다'라고 확답할 수 있을까)
적어도 서비스 기획자 / 프로젝트 매니저에서 프로덕트 매니저로 직무가 바뀌며 함께 바뀐 역할과 마인드셋 등을 공유하여, 위 질문에 대한 답을 얼추 해보고자 한다.
1. 어떻게(HOW)가 아니라 방향성(WHY)이 더 중요해졌다
내가 체감하는 가장 큰 변화는 바로 이 부분이다.
서비스 기획자 및 프로젝트 매니저의 역할을 하던 때에는, 어떤 기능을 어떻게 구현할지가 매우 중요했다. 그리고 이를 위해 각종 문서를 들여다보며 논리적 오류가 없는지, 빠트린 부분은 없는지, 혹시 이슈가 되는 부분은 없을지 들여다봤다.
나의 경우 코리빙/코워킹 비즈니스를 위한 멤버십 웹/앱을 기획, 구축했는데, 서비스에 들어가는 각종 기능-멤버십 구매, 정기구독, 회의실 예약, 피드형 게시판, 마이페이지 등-에서 파생되는 복합다단한 케이스/시나리오를 파악하고 서로 상충되지 않는 정책을 마련하는 게 제일 중요한 일이었다.
▶ 즉, 서비스 기획자 혹은 프로젝트 매니저로써의 내 업무와 역할은, 어떤 제품을 왜 만드는지는 이미 정해져 있는 상황에서 이걸 구체적으로 어떻게 만들지를 정하는 실무자에 가까웠다.
반면 프로덕트 매니저로써 가장 많은 시간 혹은 고민을 들이고 있는 일은 제품의 방향성에 관한 내용이다. 제품이 성장하기 위해선 어떤 지표가 핵심인가? 제품이 성장하기 위해선 어떤 행동을 취해야 하는가? 이를 위해서 고객에 대해 알아야 하는 것은 무엇인가? 이 가설은 무엇으로 검증할 수 있나?
▶ 즉, 지금은 제품의 목적과 방향성을 생각하는 전략가/책임자의 태도와 시각이 가장 필요하다.
내가 체감하는 역할의 변화. 물론 100% 깔끔하게 분류되진 않는다. 작은 조직/팀이라면 결국 이것저것 다 하게 되어있다.2. 문서를 쓰긴 쓰지만 그게 핵심이 절대 아니다
위와 같이 핵심 역할이 바뀌었다고 해서, 일상에서 구체적으로 하는 일이 100% 달라진 건 아니다. 작은 조직이기에, 때에 따라 기존의 업무를 하는 경우는 발생한다. 각종 세부 사항과 문서를 챙기는 게 "핵심이 아니다"라는 뜻이지, "어? 저는 이제 그런 거 안 할 건데요?ㅎㅎ"가 아니다. 제품의 성장 그리고 그 과정에 필요하다면 (or 나 말고 할 사람이 없는 '나다 싶은' 순간이면) 당연히 여러 세부 업무는 병행하게 된다.
다만 그럼에도, 주요하게 차이가 생긴 부분이 있다면 아래와 같다
1) 스토리보드 대신 User Story, 혹은 Lo-fi 수준의 와이어프레임만 작성하고 있다
기존에는 UX/UI를 고려한 스토리보드를 작성했다. 어느 위치에서 어떤 형태로 출력할 건지 등등을 세부적으로 모두 그려냈다. 반면 지금은 User Story를 통해 사용자가 어떤 문제를 어떻게 해결할 수 있어야 하는지를 정의한다. 혹은 상황에 따라 이를 조금 더 가시적으로 전달하기 위해 아주 대략적인 와이어프레임을 그리고 있다.
- Before : 어느 위치, 어떻게, 어떤 형태로 등등... (How)
- After : 사용자가 이런 문제를 해결하기 위해 서비스에서 이런 행동을 할 수 있어야 합니다 (Why)
2) 와이어프레임을 쓰지만, UX/UI는 프로덕트 디자이너의 몫이다
다만 와이어프레임은 필요한 경우 User Story를 조금 더 가시화하기 위한 용도로 작성하고 있다. 가령 어드민admin의 경우 디자인을 거치지 않고 바로 개발팀에 요청하고 있는데, 이 경우 간략한 와이어프레임을 요청하기도 한다.
경우가 뭐가 되었든, 와이어프레임을 작성하더라도 이는 "사용자가 이런 행동을 할 수 있어야 하니, 통상적으로 이런 구성 자체는 필요하다"를 조금 더 명확하게 전달하기 위한 용도다. 즉, 위치며 형태며 구체적인 방식은 모두 프로덕트 디자이너에게 위임한다.
- Before : 어느 위치, 어떻게, 어떤 형태로 등등 다 챙기는 깐깐 실무자
- After : 사용자가 이런 문제를 해결하기 위해 서비스에서 이런 행동을 가장 편하게, 직관적으로, 혼선 없이 할 수 있기만 하다면 전반은 디자이너에게 위임
3) Description을 쓰긴 쓰지만, 개발팀을 믿는다
와이어프레임을 작성하는 과정에서 세부 Description을 쓰기도 한다. (결국 스토리보드에 가까워진다). 다만 이는 가벼운 실험 또는 개선에서 필요한 Description은 통상적이기에 리소스 부담이 없는 탓이기도 하고, 팀에 별도로 '기획자' 직무가 있는 게 아닌 탓이기도 하다.
그렇지만 결국 세부적인 내용은 개발팀을 믿는다. 내가 해야 하는 역할은 '목적을 달성하기 위해 사용자가 이런 행동을 할 수 있어야 합니다'를 정의하는 역할이지, '그런데 그걸 이런이런 논리로 이런이런 식으로 구현해주세요'가 아니기 때문이다.
단, 기존 서비스 정책/특성상 고려가 필요할 것 같은 부분은 세부적으로 확인하거나, 정의하고 있다.
- Before : 세부 정책, 예외 케이스, 특수 케이스, 미출력 케이스, 오류 케이스 등등...
- After : 사용자가 이런 문제를 해결하기 위해 서비스에서 이런 행동을 할 수 있어야 하는데, 다만 우리 기존 서비스 정책/특성상 이런 부분은 고려가 되어야 할 것 같습니다
3. 이런저런 일 다 하는 건 동일하다, 그러나...
그러나 결국 프로덕트 매니저와 서비스 기획자가 각각 별도로 있는 구성 혹은 규모의 조직/팀이 아니라면, 프로덕트 매니저는 여전히 서비스 기획자 혹은 프로젝트 매니저 시절의 일을 하게 되는 듯하다.
일례로, 지금도 고객 이해와 문제정의, 실험 설계 외에도 프로젝트 단위에서는 Test Case를 작성하고, QA에 참여하고, 주요 정책 문서를 업데이트해두고, VOC에 대응하고, 등등의 업무를 하고 있다. 많은 일들이 이전과 겹친다.
어쩌면 애초에 서비스 기획자도 프로젝트 매니저도, 그리고 지금 하는 프로덕트 매니저든, IT 조직 내에서의 '제너럴리스트'인건 동일하기에, 제품에 관련된 일이라면 가리지 않고 하게 되는 것 역시 동일할 수밖에 없는 듯하다.
그러나, 그럼에도 불구하고, 프로덕트 매니저로써 단 하나의 역할만 해야 한다면, 혹은 평소의 업무에 휘둘리더라도 잃지 않아야 하는 역할과 마인드셋은 결국 제품의 성장을 위한 방향성과 이를 위한 고객에 대한 이해라고 체감하고 있다.
프로덕트 매니저로써 가장 중요한 역할과 마인드셋은
제품의 성장을 위한 방향성과 이를 위한 고객에 대한 이해라고 체감한다
P.S.
직무에 대한 이해 혹은 실상이 확실히 천차만별임을 느낀다. 각종 부트캠프, 수업에서 "프로덕트 매니저"라고 부르지만 "서비스 기획자"와 똑같은걸 가르치는 곳도 보인다
