- 추천여부 : 추천!
- Why : 프로덕트 매니저의 교과서라는 명성~에 어느정도 걸맞다
- 요약평 : PM이 알아야 할 수많은 요소들을 얕게 파악할 수 있다
의식의 흐름
이 책이 매우 별로라는 분과 여러가지 이야기를 나눈 끝에 결론을 내렸다. (ㅎㅎ thx to B)
이 책은 IT 제품을 직접 만들며 어느정도 애자일이라는 방향성을 추구해야 의미를 가질 수 있다.
책에서 내내 말하는 것은 매우 이상적인 이야기이고, 이걸 다 할 수 있는 기업이 존재는 하나 싶다. 따라서 너무 동떨어진 형태의 기업에서 책을 쥔다면 이게 무슨 현실감 없는 소리인지 이게 전혀 먹히지 않는 상황에서는 어떻게 해야하는지에 대한 해결책을 얻을 수 없을 것 같다.
이 책은 방향성을 원하는 사람에게 이상적인 힌트를 주는 것 같다. 방향을 구체화하는 건 기업의 상황을 가장 잘 알고있는 본인이 되어야 할 것이다. 그리고 굉장~히 많은 개념이 나오지만 이에 대해 디테일한 설명은 얻기 어렵다. 다... 알아서 찾아보란 이야기인듯. ㅎ_ㅠ
이 책이 2009년에 초판이 나왔고 2018년에 개정증보판이 나왔는데, 소개하는 개념들 중 많은 것들이 나름 트렌디한 기업에서도 제대로 적용 못하고 있다. 공부해야할 것들을 리스트업하는 것도 꽤나 가치 있는 일 아닐까~~
아래에서는 공감가거나 의미있다고 느끼는 부분을 간단하게 메모하려고 한다.
CH6 실패한 제품의 근본 원인
- 워터폴 프로세스에 대하여 비판하는 부분이다.
- 아이디어 다음 순서로 '비즈니스 케이스'가 나오는데, 비즈니스 케이스는 '얼마만큼 돈을 벌 수 있는지', '얼마만큼 비용이 드는가'에 대하여 논할 수 있어야 한다. 그런데 이걸 아이디어 다음에 잡는 것이 가능한가? 제품팀으로서 정말 말도 안 되는 이야기라는 걸 공감한다.
- 우리의 아이디어의 절반 이상은 유효하지 않고, 아이디어가 만약 포텐셜이 있더라도 우리는 돈을 버는데 시간이 필요하다.
- 그리고 워터폴 모델에서는 엔지니어들이 너무 늦게 참여한다. 나는 이 부분에 너무 공감했는데... 기획서가 픽스되고 나서 개발자에게 요구사항만 리뷰하는 단계에서는 개발자들이 자신의 제품이라는 생각을 갖고 몰입하기가 쉽지 않다. 더 큰 문제는 기획서가 기술적인 요건을 고려하지 못할 경우 다시 기획 단계로 돌아가서 수정이 필요하다는 점이다. 시간을 너무 잡아먹는다. 그런데 워터폴로 일하는 회사들은 많고 기획 단계에서 관여하지 않기를 원하는 개발자들도 많다. 어려운 부분~
CH10 제품관리자
- 제품관리자는 무엇을 해야하는지에 대하여 논하는 파트이다.
- 저자는 하루가 120시간 쯤 되는 슈퍼 휴먼을 원하고 있다. 뭐 그치만... 저자가 논하는 역량은 다 일을 하는데 필요한 부분이고 맞는 말...이라고 생각한다. (단지 PM의 하루가 120시간이 아닐 뿐)
- 인상깊었던 부분은 제품관리자 vs. 제품소유자라는... PMvs.PO의 개념비교가 이미 매우 잘 정리되어 있던 것이다. 이걸 우리나라에서는 올해 처음 제대로 이야기했단 말이야? 개인적으로 PO 직무명을 안 좋아한다... JD를 보면 결국 PM을 원하는 건데 우리나라에서는 PO를 PM의 상위 개념으로 인식하고 있는 경우도 많은 것 같아서 아쉬움... 그냥 글로벌리 통용될 수 있도록 PM을 써주었으면 하는 바람이 있다.
CH 21 사례 소개 : 레아 힉맨, 어도비
- 어도비 CC의 사례를 소개한다.
- 시장의 흐름이 완전히 바뀔 때, 이전에 우위를 차지하고 있던 커다란 기업들이 기존 질서만을 지키다가 무너지는 경우가 왕왕 있다. 그렇지 않은 인상깊은 사례인 것 같다. 단순히 제품팀과 사용자 뿐만 아니라 회사 전체의 이해관계자를 설득하는 부분이 인상적이다.
CH 22 제품 로드맵의 문제
- 개인적으로 반성한 부분이다. 제품에 관하여 (1) 가치가 없거나 (2) 가치를 만들어내는데 추가적인 시간이 필요하다. 이건 누구에게나 적용되는 불편한 진실이지만 뛰어난 팀과 그렇지 않은 팀은 대응하는 방식이 다르다.
- 취약한 팀은 할당받은 로드맵을 따라 진행하고, 일이 잘 풀리지 않은 경우 그것을 요청한 이해관계자를 비난한다. 하지만 뛰어난 팀은 거부하기보다는 받아들이고 위험을 신속하게 파악하고 헤쳐나간다.
- 나는 취약한 팀에 가까웠던 것 같다. 내가 바라보기에 부족한 부분이 있었으면 이해관계자와 거시적인 시각을 공유하고, 방향성에 대해서 함께 다듬었어야 한다. 그리고 그걸 수용하고 보완했어야 하는건데 이해관계자를 비난했던 태도가 다소 있었던 것 같다. 이런 태도는 일을 되게 하는 데에는 전혀 도움이 되지 않는 듯.
CH 25 제품 비전의 원칙
- 내가 제품 비전을 도출하는 위치가 아니더라도 제품을 바라보는 태도로 적용하면 좋을 것 같다.
1. 왜에서 시작하라.
2. 솔루션이 아니라 문제와 사랑에 빠져라.
3. 비전을 크게 생각하는 것에 두려워하지 마라.
4. 현재의 자신을 파괴하는 데 두려워하지 마라.
5. 제품 비전은 영감을 불어넣는다.
6. 적절하고 유의미한 트렌드를 선택하고 포함하라.
7. 공이 있던 곳이 아니라 공이 향하는 곳으로 움직여라.
8. 비전은 완고하게 하되 세세한 부분은 유연하게 하라.
9. 모든 제품 비전은 믿음이라는 것을 깨달아라.
10. 계속, 집요하게 비전을 전파하라.
CH 33 제품 발견의 원칙
1. 우리가 무엇을 만들어야 하는지는 우리의 고객, 임원, 이해관계자들이 말해주지 않는다. (고객은 무엇이 가능한지 모른다.)
2. 무엇보다 중요한 것은 강력한 가치를 구축하는 것이다.
3. 기술 구현이 어렵고 중요한 만큼이나, 훌륭한 사용자 경험을 제공하는 것은 보통 그 이상으로 어렵고 성공에 더 중요한 요소이다.
4. 기능과 디자인과 기술은 본질적으로 함께 얽혀있다.
5. 우리는 아이디어 중 다수가 효과를 내지 못할 것이며, 검증된 아이디어도 몇 번의 이터레이션이 필요하다는 것을 알고 있다.
6. 우리는 실제 사용자와 고객을 대상으로 아이디어를 검증해야 한다.
7. 제품 발견의 목적은 아이디어를 가능한 한 더 빠르고 적은 비용이 드는 방법으로 검증해 내는 것이다.
8. 제품 발견 단계를 진행하며 아이디어의 실현 가능성에 대해 검증해야 한다.
9. 사업 유효성은 제품 발견단계에서 검증해야 한다.
10. 공유 학습을 해야 한다.
CH 66 속도를 잃는 10가지 이유
1. 기술 부채
2. 뛰어난 제품 관리자의 부재
3. 제품 실행 관리자의 부재
4. 느슨한 출시 주기
5. 제품 비전과 전략의 부재
6. 같은 장소에서 오래 가는 제품팀의 부재
7. 제품 발견 단계에서 충분히 이른 시점에 엔지니어를 참여시키지 않는다.
8. 제품 발견에서 제품 디자인의 역할을 활용하지 않고, 엔지니어가 제품을 구현할 때 같이 업무를 진행하도록 한다.
9. 우선순위의 변경
10. 합의의 문화
- 10가지 모두 공감... 그리고 저자는 리모트 근무를 무척 싫어한다 ㅋㅋㅋ 근데 개인적으로 오피스 근무를 할 때 업무 밀도가 높은 건 사실이다... 그리고 다른 직군과 협업하기도 훨씬 수월함 ㅠ
중간에 건너뛰었지만 매우 다양한 기법들을 소개한다. 다만 이걸 적용하기 위해서는 추가적인 리서치가 (많이) 필요할 듯.
개인적으로 PM 기본서 소리를 들을만 한 것 같은데... 또 지식의 깊이가 얕은 건 사실이고... 근데 지식이 전무한 사람이 이 책을 쉽게 읽을 수 있는가? 이것도 아닌 것 같다. 실무 경험을 어느 정도 했을 때, 경험과 비교해보며 이해해야 어느정도 와닿는 부분이 있지 않나 싶기도.
그치만 다시 읽어볼 만한 책이다. 그리고 뭔가 제품의 방향성을 꾸리는 위치에 있다면 (난 아니지만) 특히 목적조직의 PM을 하고 있는 사람에게는 충분히 도움이 될 듯.
'책을 한 달에 몇 권 읽는지 알아보자' 카테고리의 다른 글
| [실용서] (사용자를) 생각하게 하지마! (0) | 2022.10.23 |
|---|---|
| [실용서] 그로스해킹 (1) | 2022.10.08 |
| [실용서] 프로덕트 오너 (1) | 2022.09.25 |
| [에세이] 기록의 쓸모 (0) | 2022.07.15 |
| [실용서] UX/UI의 10가지 심리학 법칙 (0) | 2022.07.15 |
