조성문의 실리콘밸리 이야기

프로덕트 매니저(Product Manager)란?

with 32 comments

오라클에서 나의 직함은 Principal Product Manager이다. 내가 하는 일은 자바 개발자들을 위해 우리가 만든 각종 소프트웨어에 추가할 기능을 정의하는 것이다. 회사에 있으면서 “오라클의 프로덕트 매니저가 어떤 일을 하는 사람인가요?” 와 같은 질문을 종종 받는다. 한국뿐 아니라 미국에서 회사에 다니는 사람들도 종종 이런 질문을 한다. 그래서 여기서 간략하게 하는 일과 자격 조건 등을 설명해보고자 한다.

프로덕트 매니저(Product Manager, PM)는 무슨 일을 하는가?

PM의 가장 중요한 역할은 ‘상품 전략’을 관리하는 것이다. 아주 간략하게 도식화하면, 상품은 다음과 같은 과정을 거쳐 만들어진다.

간략한 상품 개발 프로세스. 실제로는 훨씬 복잡하다.

아이디어가 정교화되어 제품이 되고, 출시된 후 피드백을 받아 업그레이드하고, 출시된 제품을 통해 고객의 피드백을 받는 과정에서 프로덕트 매니저(PM)는 ‘상품 전략’을 세우고 관리하는 역할을 한다. 아이디어는 누구에게서든 나올 수 있다. PM은 이 아이디어가 시장의 필요에 맞는지, 그 시장의 마켓이 충분히 큰지, 경쟁 제품과 비교해서 우위가 있는지 등을 먼저 생각해봐야 하고, 그 결과물로 사람들을 설득할 수 있어야 한다.

한편, 제품(product)은 기능(feature)의 집합이다. 예를 들어 얼핏 보기엔 간단하게 보이는 아이폰 하나에는 셀 수도 없이 많은 기능이 들어가 있다. 예를 들어 앱 실행중에 ‘홈’ 버튼은 한 번 누르면 메뉴 화면으로 나가지만, 메뉴 화면에서 홈 버튼을 누르면 검색 화면으로 간다. ‘최근 통화 목록’에서 오른쪽 화살표를 눌렀을 때, 이미 연락처에 들어있는 번호라면 연락처를 보여주지만, 모르는 번호라면 ‘새로운 연락처 등록’이라는 메뉴가 뜬다. ‘어떤 화면에서 어떤 버튼을 눌렀을 때 무슨 일이 일어나는가’는 사실 UX 디자이너(User Experience Designer)가 정의하지만, 그 안에 어떤 기능이 들어가야 할 지 정의하는 것은 PM의 몫이다. 각 기능에 대해 설명하고, 우선 순위를 정하고, 이 기능들을 개발자 및 다른 조직과 공유하기 위해  필요한 것이 제품 요구 조건 문서 (Product Requirements Document, PRD)이다. PRD에는 다음과 같은 것들이 정의된다.

  1. Requirement (요구 조건)
  2. Problem (해결하려고 하는 문제점)
  3. Use Case (사용 예)
  4. Background (배경 이유)
  5. Dependencies (다른 요구 조건과의 연관성)
  6. Priority (우선 순위)
  7. Release Version Number (제품 버전)

문서는 파워포인트, 워드, 또는 엑셀로 만들기도 하는데, 아무래도 자주 업데이트하는 문서이다보니 전용 소프트웨어를 사용하는 것이 편리하다. Accompa, Access 360, Borland의 CaliberRM등 많은 소프트웨어가 나와 있다.

Accompa 실행 화면 (출처: Accompa.com)

요구 조건은 어떻게 찾아내는가?

요구 조건을 찾아내는 경로는 매우 다양한데, 대략 네 가지로 요약할 수 있다.

1. 고객 피드백

가장 중요한 경로이다. 사람들은 다양한 경로를 통해 그들이 원하는 것을 표현한다. 이를 잘 잡아내고, 잡음을 제거하고, 그 중 중요한 것을 추려내어 우선순위를 정하는 것은 프로덕트 매니저의 몫이다. ‘고객의 목소리를 어떻게 듣는가?’는 아래에서 다시 설명하겠다.

2. 경쟁 제품 분석

경쟁 제품을 보고 분석하는 것도 물론 당연히 중요한 절차이다. 경쟁 제품의 장점을 보고 따라할 수도 있고, 단점을 개선하여 제품을 만들 수도 있다. 그대로 베껴서는 안되지만, ‘창조적 모방’은 죄가 아니라고 생각한다. 예를 들어, 틱톡은 카카오톡과 비슷하게 생겼고, 기능도 비슷하지만, 사람들이 더 빠른 속도를 원한다는 점에 착안하여 개발했고, 지금 매우 빠른 속도로 카카오톡을 따라잡고 있다.

카카오톡 실행 화면

틱톡 실행 화면

3. 조직 내부 제안

제안은 어디서든 올 수 있다. 그리고 조직 내에서 그 제안이 오는 경우가 사실 많이 있다. 제품을 개발하는 엔지니어들과, 품질을 테스트하는 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

UserVoice를 이용하면 고객들이 그들이 원하는 아이디어를 제안하고, 다른 사람이 이미 비슷한 아이디어를 제안했다면 그것에 투표할 수 있는 웹사이트를 쉽게 만들 수 있다. 가격은 월 $15부터 시작한다. 따로 정리하지 않아도, 사람들이 원하는 아이디어는 자연스럽게 위로 올라오는데다, 그 아이디어에 내가 커멘트를 할 수 있고, 제안한 사람들에게 그 기능이 구현되었다는 것을 알리기도 쉽게 되어 있어서 편리하다.

유저보이스(Uservoice)의 화면. 출처:Crunchbase.com

2. 설문 조사 (SurveyMonkey)

회사에 들어온 지 얼마 되지 않아 약 20,000명을 대상으로 설문조사를 하고 결과를 분석하는 일을 한 적이 있다. 효과적인 설문조사 방법론에 대한 이야기는 여기선 생략하겠다. 온라인 설문조사 툴은 Vovici, Survey Methods, QuestionPro, LimeSurvey, Zoomerang, Qualtrics 등 여러 가지가 있는데, 이것 저것 써보고, 가격 비교를 해본 후 가장 만족스러웠던 것은 SurveyMonkey였다. 간단한 설문이라면 무료 계정으로도 충분히 쓸 만하고, 아니면 월 $17를 내면 된다. 설문조사가 끝난 후, SurveyMonkey가 제공해주는 분석 툴을 이용해도 되고, 결과를 엑셀로 export해서 직접 분석해도 된다. 설문을 할 때 가장 중요한 것은 패널의 질이다. 즉, 의도적인 경우가 아니라면 설문 조사에 응답하는 사람들이 어느 한 지역, 어느 한 언어, 어느 한 나이대, 또는 어느 한 전문 분야로 치우치지 않도록 주의해야 한다. 그렇지 않으면 결과 전체가 쓸모없게 될 수가 있다.

SurveyMonkey 화면

주관식 답변을 효과적으로 분석하는 것이 어려운 일 중 하나인데, 이런 경우는 Wordle과 같은 Word Cloud 툴을 사용하면 효과적으로 결과를 전달할 수 있다. Wordle은, 많이 등장하는 단어를 더 크게 보이게 해 준다.

Wordle을 써서 만든 결과

3. 웹 로그, 다운로드 및 Usage 분석

모든 웹 서버는 로그를 기록한다. 이 로그에는 누가, 몇 시에 들어왔고, 무엇을 요청했고, 무엇을 받아갔는지에 대한 정보가 있다. 이 웹 로그를 분석하면 아주 많은 정보를 얻어낼 수 있다. 직접 분석할 수도 있지만, 이 역시 툴을 이용하면 편한데, 이 분야의 독보적 1위 회사는 지금은 어도비(Adobe)에 인수된 Omniture이다. Omniture에서 제공하는 데이터를 분석해서 고객 인사이트를 많이 얻을 수 있다. 한편, 무료로 사용할 수 있는 구글 웹 분석툴(Google Analytics)도 매우 유용한 정보를 제공한다.

Google Analytics 화면

제품 사용(Usage) 분석 역시 매우 중요하다. 이를 통해 어떤 기능을 사람들이 주로 사용하는지를 알 수 있는데, 중요하거나 좋을 것 같다고 생각했던 기능이 의외로 거의 사용되지 않거나, 사람들이 좋아할 것이라고 생각해서 넣은 기능이 알고 보니 별로 쓸모가 없다든지 하는 것 등을 알 수 있다. 웹 사이트 분석할 때 히트맵(Heatmap)을 보기도 한다. 이를 통해 사람들의 눈이 어디로 가는지, 어디를 클릭하는지 등을 알 수 있다. CrazyEgg라는 툴이 유용하다. 월 $9부터 시작한다.

히트맵의 예. 출처: crazyegg.com

4. 직접 관찰 (Follow Me Home)

사람들이 제품을 사용하는 모습을 직접 관찰하는 것 만큼 많이 배울 수 있는 방법이 없다. 이를 적극적으로 잘 활용한 회사로는 회계 및 세금 소프트웨어 회사인 인튜잇(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)를 한다. 비싼 게 좋다는 건 누구나 안다. 하지만 성능과 가격을 끊임없이 재 보고, 자신이 생각하기에 최소의 비용으로 가장 좋은 성능을 살 수 있다고 생각할 때 그들은 지갑을 연다. 아래 예를 보자.

1) 삼성 HDTV, 46인치, LED, 240Hz, 테두리 없는 TV: $1500 at Amazon

VS.

2) 비지오 HDTV, 55인치, LED-backlit LCD, 240Hz: $1560 at Amazon

당신은 어떤 제품을 택할 것인가?  값은 60달러 더 비싸지만 화면이 더 큰 Vizio? 아니면 브랜드와 디자인을 생각해서 크기가 작더라도 삼성? 답은 사람들마다, 그 때의 필요에 따라 다를 것이다. 어떤 사람에게는 화면 크기가 더 중요하고 어떤 사람에게는 디자인이 더 중요하다. 이런 때에 아주 유용한 것이 컨조인트 분석이다. 파라미터를 약간씩 바꾸면서 위와 같은 질문을 반복적으로 하고 나면 사람들이 어떤 기능 또는 어떤 브랜드에 얼마만큼의 가치를 지불하기 원하는지를 알아낼 수 있다. 분석이 끝나면, 시뮬레이션도 할 수 있고, 세그멘테이션(segmentation)도 할 수 있다.

컨조인트(Conjoint) 분석으로 알아낼 수 있는 Part-worth 그래프. 각 기능에 대해 사람들이 느끼는 유용도(Utility) 함수를 찾아낼 수 있다. 출처: http://www.sawtoothsoftware.com/

그 이후의 절차는 무엇인가?

PRD가 1차적으로 완성되면 PM은 엔지니어 팀과 함께 항목을 하나하나 점검한다. 불분명한 내용은 없는지 보고, 구현가능 여부도 함께 검토한다. 이 과정이 끝나면 요구 조건을 동결(freeze)시킨다. 이 과정이 끝나면 이 문서는 PM과 엔지니어 사이의 일종의 ‘계약서’가 된다. 이제 이를 구현하는 것은 엔지니어의 몫이다. 이제부터는 PM의 역할은 줄어든다.

제품이 완성될 즈음에는 출시를 준비해야 한다. 이는 주로 마케팅 부서가 담당하지만, PM은 그 제품을 애초에 기획하고 정의했던 사람이므로, 전달해야 할 가장 중요한 메시지가 무엇인지 결정하는 것은 여전히 PM의 몫이다.

어떤 사람들이 프로덕트 매니저가 되는가?

내가 주변에서 관찰하는 가장 일반적인 프로필은 “컴퓨터과학(Computer Science) 학사+MBA” 이다. 실제로, LinkedIn에서 ‘product manager’로 검색해 보면 그런 프로필을 가진 사람들을 가장 흔하게 볼 수 있다.

구글의 Product Manager로 일하는 한 MBA 동기의 프로필. 버클리에서 컴퓨터 과학(Computer Science)을, UCLA에서 MBA를 전공했다.

한편, Job Requirement를 보면 대부분 MBA가 요구되거나(required) 선호된다고(preferred) 되어 있다. 예를 들어, 어도비(Adobe)의 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)의 역할은 마케팅에 보다 집중한다는 점에서 사뭇 다르다. 어떤 회사에서는 PM이 손익 (Profit and Loss, P&L)을 관리하기도 한다.

한편, 애자일(Agile) 프로세스가 요구되는 스타트업에서는 위에서 설명했던 것 같은 절차대로 하지는 않는다.  기능을 정의하는 즉시 구현을 시작하고, 구현된 결과를 보고 새로운 기능을 추가하거나 기존 기능을 변경한다.

참고 자료

Written by Sungmoon

January 16, 2012 at 11:07 pm

32 Responses

Subscribe to comments with RSS.

  1. MBA에서 배웠던 거 가장 잘 써먹고 있는 일인인듯…..Keep going, man!

    Joon Hyuk Park

    January 16, 2012 at 11:33 pm

  2. 지금 저에게 아주 중요한 도움이 되는글이었습니다.
    감사합니다.

    dajoa

    January 16, 2012 at 11:56 pm

  3. 내용 정말 잘 보았습니다!
    한가지 PRD 이면 Product “Requirements” document가 아닐까요?

    blue

    January 17, 2012 at 12:07 am

    • 피드백 감사합니다. 오타가 있었더라구요. 수정했습니다.

      Sungmoon

      January 17, 2012 at 8:35 pm

  4. 감사합니다.

    tertoen

    January 17, 2012 at 12:45 am

  5. 일하는 과정에서 새로운 Approach를 배울수 있네요. 너무 감사합니다. R&D와 Marketing의 교량역할을 명쾌하게 How to로 분석해 주신것 같습니다.

    Ryan Park

    January 17, 2012 at 1:48 am

  6. 내용 잘 봤습니다. 감사합니다!

    Hansol Hong

    January 17, 2012 at 2:03 am

  7. 모두가 같은 생각으로 각기 다른 모습으로 뜻이 같아 진다면 ^^*참행복해 지겠쬬 !!

    YongJin Kim

    January 17, 2012 at 2:29 am

  8. 좋은 글 정말 감사합니다!
    궁금했던 부분들에 대해서 많이 알게 되었네요 ^^

    Wannabeman

    January 17, 2012 at 2:42 am

  9. 대학 학부생 시절 한때 PM이 되고 싶었던 적이 있는 CS전공 출신으로써 좋은 글이자 예전 꿈을 다시금 환기하게 되는 계기가 되었네요. :)

    BULGARI

    January 17, 2012 at 5:13 am

    • 아 그랬나요? 엔지니어에서 PM으로 넘어가는 경우가 참 많으니까 재미있어 보이면 한 번 시도해 보세요.

      Sungmoon

      January 17, 2012 at 8:36 pm

  10. 지금의 저에게 꼭 필요한 글이었습니다 ^^ 감사합니다. 잘 배우고 가요 :)

    dojinkim (@nuguriDJ)

    January 17, 2012 at 5:30 am

  11. 고맙습니다^^
    PM을 계속해서 꿈꾸고 있긴하지만 어려운 분야라고 계속 난해해하고만 있는데 조금 힘이 되네요!

    YosHi (@dir4you)

    January 17, 2012 at 9:17 am

  12. 글을 남기는 건 처음이네요, 평소에 블로그의 좋은 글들 항상 잘 보고 있습니다^^
    저도 한 회사의 PM으로, 회사마다 PM의 정의와 역할은 정말 다르다는 걸 다시 한 번 느낍니다
    PM의 역할을 동일하게 정의하는 회사라도 제품의 특성이나 business model에 따라서 업무 focus는 달라 질 수 있을 것 같네요
    고객의 목소리를 듣는 tool과 방법들에 대해 많은 영감을 얻었습니다, 감사합니다~

    Jay Park

    January 17, 2012 at 2:04 pm

    • 이렇게 글 남겨주셔서 감사합니다. 말씀하신대로 PM의 정의가 회사마다 많이 틀려서 PM이 대체 뭔지 알기가 참 힘들더라구요. 기술적 지식이 필요한 정도도 회사마다 다르구요. 도움이 되었다니 기쁘네요.

      Sungmoon

      January 17, 2012 at 8:38 pm

  13. 내용 잘 봤습니다. 저랑 업무 관련성은 없지만 내용이 좋아 계속 보게 되네요. 감사합니다.

    김범구

    January 17, 2012 at 3:17 pm

  14. 공부 제대로 하고 갑니다. 감사합니다. ^^

    Eungjin Cho

    January 17, 2012 at 6:31 pm

  15. 긴 글을 두 단어로 요약 하면

    ‘프로덕트 매니저’ 가 되는 군요. ^^;

    잘 읽었습니다.

    유재영

    January 17, 2012 at 7:27 pm

  16. 잘 읽고 갑니다^^

    Jungsoo Amelia Lim

    January 17, 2012 at 8:06 pm

  17. 좋은 공부가 되었습니다.
    언급하신 서비스들 대부분이 처음 접하는 것들이네요. ㅎㅎ
    조금씩 사용해 봐야겠어요. ^^

    Ks Yi

    January 18, 2012 at 7:00 am

  18. 역시나 알찬 포스팅입니다! Product Manager라는 포지션에 대해 대충 이런저런 일을 하겠지..라고는 생각을 하고 있었는데, 이번 포스팅을 통해서 PM의 모든 것이라고 볼 수 있을지 모르겠지만 핵심적인 부분에 대해서는 명쾌하게 알 수 있을 것 같습니다. 정말 감사드립니다. : )

    Kyujin Lee

    January 19, 2012 at 7:32 am

  19. 우연히 블로그를 찾고 가끔 들어와 많이 배우고 갔는데 글 남기는건 처음이네요. 전 IBM에서 일 합니다. PM은 아니지만 관심이 있었는데 역시 알차고 좋은 내용이네요. 일뿐아니라 생활하실때도 주위를 둘러보시고 생각을 많이 하시는 분으로 보입니다. 앞으로도 종종 들르겠습니다. 감사합니다.

    Jongrak Kim

    March 22, 2012 at 10:33 am

  20. [...] S : Product Manager 의 업무에 대해 더욱 궁금하신 분들은 조성문님의 글 “Product Manager 란?”을 참고해주세요. Share this:트위터Facebook이것이 좋아요:좋아하기Be the first to [...]

  21. 안녕하세요. 저는 내년부터 독일에 있는 게임회사에서 Junior Product Manager로 일하게 됩니다. 프로덕트 매니저에 대한 개념이 잘 서지 않았는데, 좋은 정보 얻고 갑니다. 감사합니다.

    jclear228

    October 6, 2013 at 7:19 pm

  22. 프로덕트 매니저라는것은 기술직 사람이 단계를 밟아 올라가게 되는것인가요? 저도 프로덕트 매니저, 그러니까 경제,경영을 장래로 삼고있는데 최근 프로덕트 매니저가 흥미가 가서요. 근데 제가 기술직이아니라 사무직으로 입사를 할것인데, PM이라는 것은 기술직 사람만이 올라서는 지위인지 궁금합니다.

    October 30, 2013 at 6:20 am

    • 아닙니다. 좋은 PM이 되기 위한 자질은 참 다양하고, 소프트웨어 제품을 만들 때 소프트웨어에 대한 깊은 이해가 있으면 당연히 도움이 되겠지만 꼭 필요한 건 아닙니다.

      Sungmoon

      October 30, 2013 at 11:15 pm

      • 좋은 PM이 되기 위해서는 정확히 어떤 자질을 갖춰야 하나요??

        October 31, 2013 at 4:26 am

  23. My cousin suggested I could similar to this internet site. They seemed to be fully perfect. This kind of post actually designed our day. You simply can’t consider exactly how a whole lot time period I needed put in because of this information and facts! Thank you!

  24. 좋은 글 잘 봤습니다. ^^

    Lee Myung Sung

    April 7, 2014 at 6:11 pm

  25. […] 새로 배워야 할 것도 없었다. 그래서 바로 전에 썼던 블로그, “프로덕트 매니저(Product Manager)란?“의 내용을 이용해서 책을 한 번 만들어보기로 […]


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s