오라클에서 나의 직함은 Principal Product Manager이다. 내가 하는 일은 자바 개발자들을 위해 우리가 만든 각종 소프트웨어에 추가할 기능을 정의하는 것이다. 회사에 있으면서 “오라클의 프로덕트 매니저가 어떤 일을 하는 사람인가요?” 와 같은 질문을 종종 받는다. 한국뿐 아니라 미국에서 회사에 다니는 사람들도 종종 이런 질문을 한다. 그래서 여기서 간략하게 하는 일과 자격 조건 등을 설명해보고자 한다.
프로덕트 매니저(Product Manager, PM)는 무슨 일을 하는가?
PM의 가장 중요한 역할은 ‘상품 전략’을 관리하는 것이다. 아주 간략하게 도식화하면, 상품은 다음과 같은 과정을 거쳐 만들어진다.
아이디어가 정교화되어 제품이 되고, 출시된 후 피드백을 받아 업그레이드하고, 출시된 제품을 통해 고객의 피드백을 받는 과정에서 프로덕트 매니저(PM)는 ‘상품 전략’을 세우고 관리하는 역할을 한다. 아이디어는 누구에게서든 나올 수 있다. PM은 이 아이디어가 시장의 필요에 맞는지, 그 시장의 마켓이 충분히 큰지, 경쟁 제품과 비교해서 우위가 있는지 등을 먼저 생각해봐야 하고, 그 결과물로 사람들을 설득할 수 있어야 한다.
한편, 제품(product)은 기능(feature)의 집합이다. 예를 들어 얼핏 보기엔 간단하게 보이는 아이폰 하나에는 셀 수도 없이 많은 기능이 들어가 있다. 예를 들어 앱 실행중에 ‘홈’ 버튼은 한 번 누르면 메뉴 화면으로 나가지만, 메뉴 화면에서 홈 버튼을 누르면 검색 화면으로 간다. ‘최근 통화 목록’에서 오른쪽 화살표를 눌렀을 때, 이미 연락처에 들어있는 번호라면 연락처를 보여주지만, 모르는 번호라면 ‘새로운 연락처 등록’이라는 메뉴가 뜬다. ‘어떤 화면에서 어떤 버튼을 눌렀을 때 무슨 일이 일어나는가’는 사실 UX 디자이너(User Experience Designer)가 정의하지만, 그 안에 어떤 기능이 들어가야 할 지 정의하는 것은 PM의 몫이다. 각 기능에 대해 설명하고, 우선 순위를 정하고, 이 기능들을 개발자 및 다른 조직과 공유하기 위해 필요한 것이 제품 요구 조건 문서 (Product Management Document, PRD)이다. PRD에는 다음과 같은 것들이 정의된다.
- Requirement (요구 조건)
- Problem (해결하려고 하는 문제점)
- Use Case (사용 예)
- Background (배경 이유)
- Dependencies (다른 요구 조건과의 연관성)
- Priority (우선 순위)
- Release Version Number (제품 버전)
문서는 파워포인트, 워드, 또는 엑셀로 만들기도 하는데, 아무래도 자주 업데이트하는 문서이다보니 전용 소프트웨어를 사용하는 것이 편리하다. Accompa, Access 360, Borland의 CaliberRM등 많은 소프트웨어가 나와 있다.
1. 고객 피드백
가장 중요한 경로이다. 사람들은 다양한 경로를 통해 그들이 원하는 것을 표현한다. 이를 잘 잡아내고, 잡음을 제거하고, 그 중 중요한 것을 추려내어 우선순위를 정하는 것은 프로덕트 매니저의 몫이다. ‘고객의 목소리를 어떻게 듣는가?’는 아래에서 다시 설명하겠다.
2. 경쟁 제품 분석
경쟁 제품을 보고 분석하는 것도 물론 당연히 중요한 절차이다. 경쟁 제품의 장점을 보고 따라할 수도 있고, 단점을 개선하여 제품을 만들 수도 있다. 그대로 베껴서는 안되지만, ‘창조적 모방’은 죄가 아니라고 생각한다. 예를 들어, 틱톡은 카카오톡과 비슷하게 생겼고, 기능도 비슷하지만, 사람들이 더 빠른 속도를 원한다는 점에 착안하여 개발했고, 지금 매우 빠른 속도로 카카오톡을 따라잡고 있다.
제안은 어디서든 올 수 있다. 그리고 조직 내에서 그 제안이 오는 경우가 사실 많이 있다. 제품을 개발하는 엔지니어들와, 품질을 테스트하는 QA 부서에 있는 사람들은 제품에 대해 아주 잘 알고 있기 때문에 좋은 제안을 할 수 있는 사람들이다. 이러한 아이디어들을 모으고, 명확히 정의하고, 구체화하는 것은 PM의 일 중 하나이다.
4. 직관
PM은 대개 그 제품의 전문가이다. 따라서 무엇이 개선되어야 하는지, 어떤 기능이 추가되면 좋을지 직관적으로 알 가능성이 높다. “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them. (포커스 그룹을 통해 제품을 디자인하는 것은 정말 어렵다. 사람들은 보여주기 전까지는 그들이 무엇을 원하는지 모른다.) – Businessweek, 1998″ 라고 했던 스티브잡스는, 직관이 가장 훌륭했던 PM이었다는 생각이 든다.
고객의 목소리는 어떻게 듣는가?
고객의 목소리를 듣는 것 못지 않게 중요한 것이 이를 분석하는 것이다. 잡다하게 흩어져있는 정보는 그다지 쓸모가 없는데다, 편견을 주기 쉽다. 보통 목소리는 ‘매우 만족스럽다’와 ‘매우 불만족스럽다’의 양 극단으로 갈라지기 때문이다. 게다가, 보통 불만 있는 사람들이 목소리가 큰 경우가 많기 때문에 이를 또한 고려해야 한다. 그동안 내가 사용했던 툴이나 방법은 다음과 같다.
1. UserVoice
고객들이 그들이 원하는 아이디어를 제안하고, 다른 사람이 이미 비슷한 아이디어를 제안했다면 그것에 투표할 수 있는 시스템이다. 가격은 월 $15부터 시작한다. 따로 정리하지 않아도, 사람들이 원하는 아이디어는 자연스럽게 위로 올라오는데다, 그 아이디어에 내가 커멘트를 할 수 있고, 제안한 사람들에게 그 기능이 구현되었다는 것을 알리기도 쉽게 되어 있어서 편리하다.
회사에 들어온 지 얼마 되지 않아 약 20,000명을 대상으로 설문조사를 하고 결과를 분석하는 일을 한 적이 있다. 효과적인 설문조사 방법론에 대한 이야기는 여기선 생략하겠다. 온라인 설문조사 툴은 Vovici, Survey Methods, QuestionPro, LimeSurvey, Zoomerang, Qualtrics 등 여러 가지가 있는데, 이것 저것 써보고, 가격 비교를 해본 후 가장 만족스러웠던 것은 SurveyMonkey였다. 간단한 설문이라면 무료 계정으로도 충분히 쓸 만하고, 아니면 월 $17를 내면 된다. 설문조사가 끝난 후, SurveyMonkey가 제공해주는 분석 툴을 이용해도 되고, 결과를 엑셀로 export해서 직접 분석해도 된다. 설문을 할 때 가장 중요한 것은 패널의 질이다. 즉, 의도적인 경우가 아니라면 설문 조사에 응답하는 사람들이 어느 한 지역, 어느 한 언어, 어느 한 나이대, 또는 어느 한 전문 분야로 치우치지 않도록 주의해야 한다. 그렇지 않으면 결과 전체가 쓸모없게 될 수가 있다.
모든 웹 서버는 로그를 기록한다. 이 로그에는 누가, 몇 시에 들어왔고, 무엇을 요청했고, 무엇을 받아갔는지에 대한 정보가 있다. 이 웹 로그를 분석하면 아주 많은 정보를 얻어낼 수 있다. 직접 분석할 수도 있지만, 이 역시 툴을 이용하면 편한데, 이 분야의 독보적 1위 회사는 지금은 어도비(Adobe)에 인수된 Omniture이다. Omniture에서 제공하는 데이터를 분석해서 고객 인사이트를 많이 얻을 수 있다. 한편, 무료로 사용할 수 있는 구글 웹 분석툴(Google Analytics)도 매우 유용한 정보를 제공한다.
사람들이 제품을 사용하는 모습을 직접 관찰하는 것 만큼 많이 배울 수 있는 방법이 없다. 이를 적극적으로 잘 활용한 회사로는 회계 및 세금 소프트웨어 회사인 인튜잇(Intuit)이 유명하다. 창업자인 스캇 쿡(Scott Cook)은 스토어에서 사람들이 회사 제품을 사기를 기다렸다가 누군가가 제품을 사면 그 사람 집에 따라가서 제품을 설치하고 사용하는 것을 관찰했다고 한다. 하버드 MBA를 졸업하고, P&G에서 브랜드 매니저로 일했던 그는, 제품의 포장을 뜯고 설치하는 과정에서 고객이 혼란을 느끼면 그것은 고객 책임이 아니라 회사 책임이고, 제품의 문제점이라고 믿었다.(주: Inc.com: Scott Cook, Intuit) 이런 관찰을 통해 제품을 끝없이 개선했고, 그 결과 현재 업계 1위가 되었으며 회사 가치는 무려 17조원이 넘는다. 난 연말 세금 보고를 할 때마다 Intuit의 Turbotax 온라인 버전을 사용하는데, 쓰기가 너무 편해서 복잡한 세금 보고는 나에게 전혀 골치거리가 아니다. Intuit의 이 방법은 매우 효과적이어서, 20년이 지난 지금도 그들은 고객의 집 또는 사무실에 찾아가서 그들이 제품을 사용하는 모습을 관찰하곤 한다고 한다. (주: What is a “Follow Me Home?”, Intuit 블로그)
5. 컨조인트 분석 (Conjoint Analysis)
사람들이 설문 조사에서 진실을 이야기할까? 그렇지 않다. 예를 들어서, 이런 질문이 있다고 생각해보자.
당신이 생각하기에 이 제품의 가격은 얼마가 적당할까요?
1) 20달러 2) 10달러 3) 5달러 4) 무료
또는,
저희 제품이 클라우드 자동 백업 기능을 추가한다면 얼마를 더 낼 의향이 있습니까?
1) 20달러 2) 10달러 3) 5달러 4) 추가 지불 의향 없음
사람들은 무엇이라고 대답할까? 대부분 5달러 또는 무료라고 할 것이다. 그 마음은 진실이다. 그러나 이를 듣고 제품 전략에 그대로 반영해서 가격 책정을 한다면 어리석은 것이다. 이런 질문으로는 정확한 ‘지불 의사(Willingness to pay)‘를 찾아낼 수 없다. 실제로 사람들은 물건을 살 때 끊임없이 트레이드 오프(Trade-Off)를 한다. 비싼 게 좋다는 건 누구나 안다. 하지만 성능과 가격을 끊임없이 재 보고, 자신이 생각하기에 최소의 비용으로 가장 좋은 성능을 살 수 있다고 생각할 때 그들은 지갑을 연다. 아래 예를 보자.
당신은 어떤 제품을 택할 것인가? 값은 60달러 더 비싸지만 화면이 더 큰 Vizio? 아니면 브랜드와 디자인을 생각해서 크기가 작더라도 삼성? 답은 사람들마다, 그 때의 필요에 따라 다를 것이다. 어떤 사람에게는 화면 크기가 더 중요하고 어떤 사람에게는 디자인이 더 중요하다. 이런 때에 아주 유용한 것이 컨조인트 분석이다. 파라미터를 약간씩 바꾸면서 위와 같은 질문을 반복적으로 하고 나면 사람들이 어떤 기능 또는 어떤 브랜드에 얼마만큼의 가치를 지불하기 원하는지를 알아낼 수 있다. 분석이 끝나면, 시뮬레이션도 할 수 있고, 세그멘테이션(segmentation)도 할 수 있다.
PRD가 1차적으로 완성되면 PM은 엔지니어 팀과 함께 항목을 하나하나 점검한다. 불분명한 내용은 없는지 보고, 구현가능 여부도 함께 검토한다. 이 과정이 끝나면 요구 조건을 동결(freeze)시킨다. 이 과정이 끝나면 이 문서는 PM과 엔지니어 사이의 일종의 ‘계약서’가 된다. 이제 이를 구현하는 것은 엔지니어의 몫이다. 이제부터는 PM의 역할은 줄어든다.
제품이 완성될 즈음에는 출시를 준비해야 한다. 이는 주로 마케팅 부서가 담당하지만, PM은 그 제품을 애초에 기획하고 정의했던 사람이므로, 전달해야 할 가장 중요한 메시지가 무엇인지 결정하는 것은 여전히 PM의 몫이다.
어떤 사람들이 프로덕트 매니저가 되는가?
내가 주변에서 관찰하는 가장 일반적인 프로필은 “컴퓨터과학(Computer Science) 학사+MBA” 이다. 실제로, LinkedIn에서 ‘product manager’로 검색해 보면 그런 프로필을 가진 사람들을 가장 흔하게 볼 수 있다.
- Proven track record of defining product requirements on schedule and shipping successful products.
- MBA required.
- Leadership experience in Business Intelligence or Customer Intelligence a plus.
- Excellent verbal and written communication skills.
내가 일을 해 보니 MBA 학위가 반드시 필요하지는 않다. 그렇지만, 이 포지션에 지원하는 사람들 대부분이 MBA를 마쳤기 때문에 아무래도 그쪽이 유리하다. 하지만 결국, 가장 중요한 것은 제품을 깊이 이해할 수 있는가와 제품을 만드는 일 자체가 재미있는가이다.
그 외 필요한 스킬은?
무엇보다 커뮤니케이션 스킬이 중요하다. 세상에 커뮤니케이션이 중요하지 않은 일은 없겠지만, PM에게는 특히나 더 중요한 것 같다. 엔지니어 조직이 독립적으로 있고, 그 조직에 직접 명령하는 방식이 아닌 영향(influence)을 주는 방식으로 일하려면, 똑똑한 그들이 이해할 수 있고 설득될 수 있어야 하기 때문이다.
소프트웨어 회사의 경우라면 기술적 배경지식(technical background)이 중요하다. 꼭 프로그래밍을 할 줄 알아야 하는 것은 아니지만, 컴퓨터 공학의 기본적인 내용, 프로그래밍 언어의 기본적인 내용을 아는 것은 필요하다고 생각한다. 나는 담당하는 제품이 개발툴이라서, 실제로 개발툴을 사용하는 방법은 코딩을 해보는 것이 최고인지라 가끔 코딩을 한다. 최근엔 iOS 개발툴인 Xcode를 이해하기 위해 아이폰으로 간단한 개발을 해보기도 했다.
첨언
PM의 정의는 회사마다 다르다. 어떤 회사에서는 PM을 Outbound Product Manager 및 Inbound Product Manager의 두 가지로 구별하기도 한다. 한편, Product Marketing Manager(PMM)의 역할은 사뭇 다르다. PMM은 제품 개발보다 마케팅에 더 초점을 맞춘다. 어떤 회사에서는 PM이 P&L (Profit and Loss)을 관리하기도 한다.
한편, 애자일(Agile) 프로세스가 요구되는 스타트업에서는 위에서 설명했던 것 같은 절차대로 하지는 않는다. 기능을 정의하는 즉시 구현을 시작하고, 구현된 결과를 보고 새로운 기능을 추가하거나 기존 기능을 변경한다.
참고 자료 :
데이터를 보다 효과적으로 전달하기
I Am A Product Manager (나는 프로덕트 매니저이다)
How to Write A Good PRD? (좋은 PRD를 쓰는 방법) by Silicon Valley Product Group
글 : 조성문
출처 : http://sungmooncho.com/2012/01/16/product-manager/