XXX 기획 : Product Manager가 되자 4

기본적으로 회사가 IT 기반 회사가 아니라 제조업 회사기 때문에,
또 기타 여러 이유로, 서비스 기획을 하면서 개인적으로 아쉬운 점이 많았다.

가장 큰 아쉬움은,
대개 프로젝트를 '단기적, 일시적인 하나의 과정 완료'라고 보는 관점이었다.
좀 더 '장기적, 지속적인 관점'이 배제되는 게 흔했고,
한편 서비스 개발 프로젝트가 서비스의 생애 주기까지의 'Full Life'를 책임진다는 
생각이 보편적이지 않았다. 

그러다보니, 단기적 성과와 홍보를 위해 
기획단계에서 봉황을 그리는 사람들이 많았으며,'
결과로는 닭이 나오기 부지기수였다.

 

나는 그렇게 하기 싫었다. 왜인지는 모르겠다.

하여튼 할 수 있는 데,하지 않는 게 싫었다

위대해질 수 있는 데, 편한 수준에서 멈추는 게 내 일이 아니어도 아까웠다  

---

프로젝트 vs 프로덕트, 그리고 PM 

 

처음 갑작스럽게 웹 기획을 맡았을 때도,
그냥 내가 봐왔던, 되고 싶지 않은 PM처럼 하기 싫었다
다만, PM이라는 말은 너무도 흔한 말이어서 이미 알고 있었음에도
나 역시 PM이 되었으므로, PM이 뭔지가 궁금해졌다. 

서핑을 해보니, Project Manager / Product Manager / Product Owner 등 
여러 가지 비슷하지만 다른 단어들이 쏟아졌다
출처마다 하는 말이 조금씩 달랐기에, 조금 혼돈스러웠다.
어떤 곳에서는 이건 A라고 하기도, 어떤 곳에서는 A'라고 했다
완전히 반대로 B라고 하는 곳도 있었다. 
사실 각각이 어떤 의미로 다른 지는 중요치 않다.
다른 단어에 다른 의도가 있다고 믿는다면, 그 의도만이 내게 중요헀다.

따라서, 이 글에 내가 남기는 
Project Manager와
Product Manager도 정답이라고 볼 수는 없다
그저 분명히 다른 관점이 있다는 것만이 사실이다. 
하지만, 글쓰기의 편의를 위해서, 마치 2가지가 완전히 다른 것인양 서술할 것이다.  

 

기획이라는 말이 일본에서부터 넘어온 말임은 이전 글에서 언급했다.

자연히, 기획자를 대체하는 표현인 PM = Project Manager 이라는 단어 또한

일본식 기획 문화(턴키 방식으로 SI 업체에게 맡긴 채 자원 관리만 하는 방식)과 

유사하게 자리잡은 게 아닌가 하는 생각이다. 

(물론 과거의 방식에 한계를 느끼고, 업무의 영역을 지속 확장해온 

기업과 기획자분들도 많음을 알고 있다.) 

가령, SI성으로 진행되는 대부분의 Project Management는

아래의 관점으로 업무가 진행된다 

- 요구사항 정리

- 개발항목 정리 및 관리 

- 일정 관리 

- 업체 관리

- 자원 관리 etc

주로 프로젝트 하나를 완수하는 일반 관리 활동이다

앞 글에서 언급헀던 지속성, 비즈니스 활동에 대한 고려에 대한 내용이 주로 배제된다.

 

현업 또는 고객 여정에 대한 고려가 부족한 개발은

실제, 고객 또는 사용자 온보딩에 난항을 겪을 수 밖에 없다. 

예컨데, 마우스, GUI 등 오늘날 PC에 있어서 너무도 당연하게 생각하는 것들을

앞서서 착안하고 개발했던 제록스는 

실제 사용자 환경에서 이들 기술을 어떻게 조화하여 하나의 상품으로 내놓을지 생각하지 못했다

결국, 이 아이디어들은 제록스에서 끝내 활용되지 못했다. 

대신 사용자 경험에 미쳐있는 다른 IT회사에서 하나의 상품으로 탄생하며

PC 비즈니스의 지평을 열었는데,

그 회사가 바로 애플이었다. 

 

재미난 점은, 이런 Project Management라는 틀에 박힌 활동과

제약적인 영향력에 의한 비판이 우리나라의 일만은 아닌거 같다는 것이다.  

구글 또는 블로그를 서치해보면, Project Management vs. Product Management 

대결구도로 서로를 비교하며 설명하는 글이 무수히 많은 것을 보면 말이다 

 

그렇다면, 대결구도를 만드는 Product Management는 

Project Management와 무엇이 다른가? 

---

그렇다면 Product Management는 무엇이 다른가? 

 

프로젝트는 기간이 있다. 

시작하는 시점과 종료하는 시점, 따라서, 프로젝트 매니징은

하나의 태스크로 인식되며, 목적물 또한 태스크로서 다뤄지기 마련이다 

태스크란 어떤 목적을 어떤 기한내에 달성하면, 더 이상 다뤄지지 않는다 

오늘의 일기를 쓰고 나면,

남은 하루 동안 더 이상 일기를 뭘 쓸까, 어떻게 쓸까 고민하지 않는 것처럼 말이다

 

하지만, Product는 다르다 

예컨데, Product가 핸드폰이라고 한다면, 

기획 단계부터, 개발과 생산, 판매 전 프로세스의 유기성을 볼 것이다.

더 나아가, 판매된 이후에도 고객 접점에서 일어날 수 있는 모든 유즈케이스와

사후 관리를 생각해야 한다. 

심지어 어쩌면, 단종 이후에도 아직도 핸드폰을 사용하는 고객 경험을 

어떻게 유지/관리할 것인지 고민해야 할지도 모른다 

Product Management는, 시스템 개발 역시 이런 Product처럼 다뤄져야 함을 의미한다

 

시스템 역시, Product처럼

- 라이프 사이클이 있으며

- 비즈니스와 사용자 환경을 고려해야 하며

- 사용자 경험, 더 나아가 장기적인 경험 확장/관리 전략이 있어야 한다는 것이다 

 

따라서, Product Management는 아래의 활동을 포함한다

- 기획-개발완료까지 Project management의 모든 활동

- 사용자 조사와 사용자 경험

- 시스템을 중심으로 한 중장기적인 비즈니스 전략

- 중장기적 운영/전개 로드맵

---

앞선 글에서, 나는 좋은 기획자는 아래의 3가지를 겸비해야하지 않나 정리했다 

- 특정 도메인 환경에 대한 지식 : 전략 해석  

- 기반 기술 지식 :기술요건 정리 

- 비즈니스 그리고 사용자에 대한 일반론적 지식 : 사용자 조사 / 데이터 분석 / IA  

 

Product Manager라는 직무 관점에서, 위의 3가지는 아래의 3가지로 재편될 수 있다 

- 비즈니스 관점에서, 개발하고자 하는 시스템의 목적과 포지셔닝 (중장기적 관점 포함)

- 사용자 조사를 통한 사용자 타겟팅 

- 비즈니스/사용자 인사이트를 구현하기 위한 실현가능한 개발 전략/방향 설정 

 

이어지는 글들에서는, 위의 3가지에 대해서

좀 더 실용적인 방안으로 내용의 글을 차례차례 작성하려고 한다 .

- 비즈니스에 대한 간단한 해석법

- 사용자 조사 방법

- 그리고 상기 2가지를 고려한 초기 단계에서 활용할 만한 방법론