| 구분 | 상세 |
| 저자 | 마티 케이건 |
| 출판사 | 제이펍 |
| 출간일 | 2018/12/28(금) |
| 후기 | ★★★☆ (7.0/10.0) |
목차
들어가며
"이 책을 읽지 않았다면 PM이라고 하지 마라!"라는 이야기가 있어 어떤 책인지 궁금했다.
하지만 책에서 말하는 PM은 제품 관리자(Product Manager)였고 내가 생각한 PM은 프로젝트 매니저(Project Manager)였다.
전자는 제품 발견부터 기획, 개발, 광고·홍보, 법무 검토, 고객 응대까지 사업 일체를 담당하는 총책임자다. 후자는 앞서 나열한 부문들이 원활하게 굴러갈 수 있도록 일감, 일정, 연관 이슈를 관리하는 실무자다. 전자가 후자의 상위 개념인 셈이다.
그래서 당장 내게 꼭 맞는 책은 아니었지만, 보다 큰 그림을 그리며 성장하고자 하는 마음으로 읽어봤다.
총평
효과적으로 일하는 방법에 대한 고찰.
이 책의 핵심 주제는 팀의 마인드, 구성원, 업무 방식이다.
마인드 부분은 팀이 주어진 일을 처리하는 데 그치지는 대신, 적극적으로 개선 및 혁신에 대해 고민해야 한다는 내용이다. 생각지도 못한 접근을 통해 '인스파이어드' 될 생각에 설렜는데 다소 원론적이다 😂
구성원, 업무 방식 부분 역시 현업 종사자라면 익히 예측 가능하다. 시간이 흐르고 근무 형태, 환경이 변화함에 따라 출간 당시엔 파격적이었던 주장도 당연한 소리가 되어버린 듯하다.
그렇다고 사회 초년생이 대세로 자리 잡은 체계, 문화를 파악하기에 유용하느냐 하면 그렇지도 않다. 독자가 중니어~시니어라는 전제 하에 쓰인 책이라, 기초적인 개념을 자세히 다루고 있지 않기 때문이다.
예를 들어 "개발자가 스프린트 계획 미팅에서 아이디어를 처음 접하게 하지 말라."라고 이야기하면서 스프린트가 뭔진 알려주지 않는다.
요약하자면 2023년 기준, 현업 종사자가 업무 수행에 관한 개념들을 차근차근 돌아보고 체계적으로 정리하기 좋은 책.
물론 나의 식견이 부족해 책의 진가를 알아보지 못했을 수 있으니 아래의 핵심 요약을 보고 호기심이 동한다면 직접 읽어보시길 권한다.
핵심 요약
1. 최고의 기술 기업에서 배운 것
저자는 전통적인 '폭포수 모델'의 약점을 꼬집으며 비교적 최근 대두된 '에자일', '린'에서 배울 점이 있다고 강조한다. 에자일과 린은 폭포수 모델과 달리 ① 작업 초반부터 위험에 대응하고 ② 제품을 순차적·일방적으로 정의하기보다 상호 협의 하에 설계하여 나가며 ③ 기능 구현보다 문제 해결에 초점을 맞추기 때문이다.
저자의 설명에 살을 붙여 세 가지 개념을 비교, 정리해보았다.
| 구분 | 설명 | 장점 | 단점 | 권장 환경 |
| 폭포수 (Waterfall) |
기획 → 디자인 → 개발 → 테스트 → 런칭 순으로 작업을 진행한다. |
이전 단계가 끝나야 다음 단계가 진행되기 때문에 진척 사항을 빠르게 확인할 수 있다. | 이전 단계에 변동 사항이 발생할 경우, 변경해야 하는 부분이 많아 유연하게 대처하기 어렵다. | 사용자의 문제점, 솔루션을 명확히 알고있다. |
| 에자일 (Agile) |
폭포수처럼 순차적인 과정을 거치지만, 주기가 짧다. A, B, C 기능이 포함된 제품을 개발한다고 가정해보자. 에자일 방법론에서는 A 기능에 대한 기획 → 디자인 → 개발 → 테스트를 진행한 후, B 기능에 대한 작업을 똑같이 수행한다. 이렇게 A, B, C 기능에 대한 테스트까지 모두 완료되면 런칭 후 고객 피드백을 받는다. 에자일에서의 제품 개선은 고객과의 협업을 통해 이루어지는 셈이다. |
작업이 프로토타입에 살을 붙이는 형태로 진행되어 도중에 수정하기 용이하다. | 고객에게 정말 필요한 것을 만들고 있는지 가늠하기 어렵다. | 사용자의 문제점은 명확히 알고있지만, 솔루션을 모른다. |
| 린 (Lean) |
"낭비를 줄인다."라는 철학 아래 개발 → 측정 → 배움 단계를 밟는다. MVP(Minimum Viable Product)를 빠르게 선보이고 고객 피드백을 수렴하여 개선하는 식이다. 즉, 제품이 없는 상태에서 광고를 개제한다거나 커뮤니티에 설문을 돌리는 것도 가능하다. 고객과 만나기 전부터 불필요해보이는 것들을 최소화하므로 전적으로 고객을 지향하는 방법론이다. |
상동 | 가설에 대한 빠른 검증이 필요하므로 지속적인 배포 채널, 체계적인 데이터 수집 방법, 검증 기술이 필요하다. | 사용자의 문제점이 모호하며 솔루션도 모르겠다. |
[표 1] 프로젝트 방법론 비교
2. 사람
저자는 뛰어난 '제품팀'이야말로 성공의 핵심이라고 이야기한다. 제품팀이란 서로 다른 전문 지식을 보유하고 있고 각자의 일에 책임을 지는 사람들로 구성된 집단이다.
2-1. 훌륭한 제품팀의 원칙
제품팀은 ① 용병팀이 될 수도 있고 ② 미션팀이 될 수도 있다. 용병팀은 지시한 것만 만들지만, 미션팀은 비전을 믿고 고객의 문제를 해결하기 위해 최선을 다한다. 우리가 지향해야 하는 제품팀은 미션팀이다.
- 구성원: 제품팀에는 최소 제품 관리자 1명, 제품 디자이너 1명, 엔지니어 2명이 필요하다. 경우에 따라 더 많은 엔지니어가 합류하기도 하고 마케팅 매니저, 테스트 자동화 엔지니어, 사용자 경험 연구원, 데이터 분석가 등이 포함될 수 있다. 구성이나 규모보다 중요한 것은 제품을 만드는 데 필요한 역량을 갖추는 것이다.
- 제품 관리자: 고객, 데이터, 비즈니스, 시장·산업을 깊이 이해하고 제품팀 전반을 관리한다.
- 제품 디자이너: 제품 발견, 총체적인 사용자 경험 디자인, 프로토타이핑, 사용자 테스트, 시각 디자인을 전담한다.
- 엔지니어: 제품 발견, 솔루션 구현, 오류 해결 분야에서 활약하며 제품 관리에 대한 지식, 역량을 제품팀에 제공한다.
- 제품 마케팅 매니저: 제품 발견 단계와 제품 실행 단계에서 포지셔닝 전략, 고객 대상 메시지, 시장 공략 계획 등을 팀에 제공한다. 영업 채널과 긴밀하게 협업하며 제품팀의 역량, 한계, 경쟁 이슈 등에 관해 일러주기도 한다.
- 사용자 연구원: 정성적인 연구1를 통해 제품 발견을 지원한다.
- 데이터 분석가: 정량적인 연구2의 전문가. 테스트를 계획하고, 데이터를 모아 분석하며, 데이터 수집 과정에서 발생할 수 있는 개인정보보호에 관한 리스크 등을 관리한다.
- 테스트 자동화 엔지니어: 제품을 검증하기 위한 자동화 테스트 코드를 작성한다.
- 협업: 제품팀에는 관리자가 없다. 각 구성원은 수평적으로 활동하고 필요시 힘을 모으며 결과에 책임을 진다.
- 지속성: 제품팀은 오래 지속되어야 한다. 그래야 서로 효과적으로 일하는 방법을 배울 수 있기 때문이다.
- 업무 범위: 제품팀은 높은 자율성을 지닌다.
2-2. 제품 총괄(VP product)의 핵심 역량
- 팀 개발: 채용, 훈련, 지속적인 코칭을 통해 뛰어난 제품 관리자와 제품 디자이너팀을 개발한다.
- 제품 비전과 전략 설정: 강력한 비전을 통해 회사가 안정적으로 유지, 성장할 수 있도록 한다.
- 실행: 제품 기획, 고객 발견, 제품 발견, 제품 개발 프로세스에 대한 최신 지식을 익히고 전파한다.
- 제품 문화: 지속적이고 빠른 학습의 중요성을 강조한다. 학습 과정에서는 실수가 생길 수 있으며 재빠른 개선이 더욱 중요하다는 사실을 이해한다.
- 기타: 풍부한 경험, 핵심 인원 간 화합을 유도할 수 있는 커뮤니케이션 스킬 등.
3. 제품
저자는 결과물이 아닌 성과에 집중해야 한다고 거듭 이야기한다. 그런 의미에서 '우선순위가 정해진 기능과 프로젝트의 목록'에 해당하는 로드맵은 실패하기 십상이다. 따라서 제품팀은 로드맵보다 ① 제품 비전과 제품 전략, ② 사업 목표에 주목하는 게 바람직하다.
3-1. 제품 비전과 제품 전략
조직이 무엇을 달성하기 위해 노력하는지, 그 비전을 완수하기 위한 계획은 무엇인지에 대한 큰 그림을 그릴 수 있어야 한다.
- 제품 비전: 2~5년 간 제품팀이 만들고자 하는 미래. 구성원에게 영감과 동기를 준다. 백서, 스토리보드, 프로토타입 등을 통해 수립 가능하다. 다음은 제품 비전의 주요 원칙이다.
- '왜'에서 시작하라.
- 솔루션이 아니라 문제와 사랑에 빠져라.
- 비전을 크게 생각하라.
- 자신을 파괴하는 데 두려움이 없어야 한다.
- 적절하고 유의미한 트렌드를 선택, 활용하라.
- 공이 있던 곳이 아니라, 공이 향하는 곳으로 움직여라.
- 비전은 완고하게 정하되, 세세한 부분은 유연하게 하라.
- 모든 제품 비전은 믿음이라는 것을 깨달아라.
- 계속, 집요하게 비전을 전파하라.
- 제품 전략: 제품 비전을 실현하기 위한 과정에서 이루어지는 계획 또는 출시. 구성원의 초점을 명확히 한다. 다음은 제품 전략의 주요 원칙이다.
- 한 번에 한 가지 시장/고객에 집중하라.
- 제품 전략은 사업 전략과 연계되어야 한다.
- 제품 전략은 영업 및 시장 진출 전략과 연계되어야 한다.
- 경쟁사가 아닌 고객에 집착하라.
- 제품 전략을 조직 전체와 이야기하라.
3-2. 제품 원칙
제품 비전, 제품 전략을 보완하는 수단. 스스로 만들고자 하는 제품의 특성.
4. 프로세스
위대한 제품을 발견하려면 고객에게 자신의 아이디어를 일찍, 자주 보여주어야 한다. 또 위대한 제품을 실행하려면 최고의 기술을 활용하고 엔지니어의 조언에 귀 기울여야 한다.
4-1. 제품 발견의 원칙: 제품 발견의 목적은 다음 네 가지 중요한 위험에 대응하는 것이다.
- 가치 위험: 고객이 과연 이 제품을 구매하거나 사용할 것인가?
- 사용성 위험: 사용자가 이 제품의 사용 방법을 이해할 수 있는가?
- 실현 가능성 위험: 우리가 만들 수 있는 것인가?
- 사업 유효성 위험: 우리 사어에 효과가 있는 솔루션인가?
4-2. 제품 발견 기법
| 대분류 | 소분류 | 설명 |
| 제품 발견 구조화 기법 | 기회 평가 기법 | 목표5, 핵심 성과6, 고객 문제7, 목표 시장8에 대해 답하는 것. |
| 고객 편지 기법 | 제품에 감동한 고객이 감사의 편지를 보내왔다고 했을 때, 제품의 어떤 면이 고객의 삶을 어떻게 변화시켰는지 생각해보는 것. 거꾸로 일하기의 일종. | |
| 스타트업 캔버스 기법 | 완전히 새로운 제품을 제작해야 하는 상황에서 제품의 가치, 수익화 전략, 판매 및 유통 채널, 비용 구조, 진척 상황에 대한 측정 방법, 사업을 지속하는데 충분한 시장 규모 등을 종하적으로 고려하는 것. | |
| 제품 발견 계획 기법 | 스토리 맵 기법 | 두 가지 축으로 구성된 맵을 그리는 기법. 가로축에는 주요 사용자의 활동이 시간순으로 왼쪽부터 늘어놓고 세로축에는 각 활동에 대한 구체적인 과업을 배치한다. 이때, 과업은 핵심적인 것을 상단에 두고 선택적인 것을 하단에 둔다. |
| 고객 발견 프로그램 기법 | 참고 고객9을 확보하고 제품 발견의 파트너로 삼는 것. 제품을 시장에 내놓기 전, 참조 고객에게 먼저 제공하여 의견을 듣는 등 다양한 방식으로 돈독한 관계를 이어갈 수 있다. | |
| 아이디어 발상 기법 | 고객 인터뷰 | "우리 고객은 내가 목표로 했던 고객이 맞는가?", "고객은 내가 생각했던 문제를 실제로 겪고 있는가?", "지금 고객은 어떻게 문제를 해결하고 있는가?", "고객의 마음을 얻기 위해 무엇이 필요한가?"를 편안한 분위기에서 장기적으로 묻고 답하는 것. 꼭 직접 참여하자. |
| 안내인 테스트 기법 | 고객 입장에서 고객이 하고자 하는 과업을 직접 수행하는 것. | |
| 핵 데이 | 제품팀 구성원이 자체적으로 팀을 구성해 주어진 목표를 완수하기 위한 아이디어를 실행하는 것. | |
| 프로토타이핑 기법 | 실현 가능성 프로토타입 | 엔지니어의 코드나 알고리즘. 제품 발견 기간 동안 기술적인 실현 가능성, 위험에 대응하기 위한 프로토타입. |
| 사용자 프로토타입 | 사용자가 참여하는 모의 시험. 와이어프레임처럼 보이는 프로토타입부터10 실제 제품과 비슷할 만큼 완성도 있는 프로토타입까지11 다양하게 쓰인다. | |
| 라이브 데이터 프로토타입 | 실제 데이터를 수집하여 가설을 증명하거나, 제품을 제작하는 데 필요한 최소한의 증거를 마련하는 것. 실제 제품의 아주 일부 정도만 구현하는 식이다. | |
| 혼합 프로토타입 | 서로 다른 프로토타입을 부분적으로 조합한 것. |
[표 2] 제품 발견 기법 비교
5. 문화
좋은 제품팀의 특징, 해당 팀이 유지되기 위한 조건을 살펴보는 부분.
5-1. 좋은 제품팀 vs. 나쁜 제품팀
좋은 제품팀은 ① 훌륭한 제품을 만드는 데 필요한 능력을 갖춘 이들이 모여 있는 집단이다. 이들은 ② 강력한 제품 비전을 구심점 삼아 ③ 고객이 보내온 의견, 고객 행동 데이터, 문제 해결을 위한 기술 등을 끊임없이 탐색하며 ④ 고객뿐 아니라, 다양한 이해 관계자를 이해하며 우호적인 관계와 적절한 솔루션을 이끌어내기 위해 힘쓴다.
아울러 좋은 제품팀은 가치 있는 아이디어를 발굴해 내기 위한 ⑤ 여러 제품 발견 기법들을 능숙하게 사용하고 ⑥ 아이디어 평가 과정에서 발생하는 건전한 토론을 즐긴다. 이런 의견 교류는 각자의 자리에서 문서를 통해 진행하기보다, ⑦ 함께 둘러앉아 주고받는 경우가 많다.
⑧ 이렇듯 좋은 제품팀은 끊임없이 새로운 아이디어를 선보이고 도전하는 한편 브랜드 가치를 지키기 위해 힘쓰지만, ⑨ 자신만만하게 내놓은 아이디어가 효과가 없을 수 있다는 점을 인정할 줄 안다. ⑩ 그 때문에 올바른 기법, 재빠른 검증, 깊이 있는 분석을 중요히 여긴다.
5-2. 혁신, 속도를 잃는 10가지 이유
| 혁신, 속도 O | 혁신, 속도 X |
|
|
[표 3] 혁신, 속도를 잃는 10가지 이유
마치며
완독부터 서평 작성까지 장장 보름이 넘게 걸렸다. 블로그에 서평을 남기기 시작한 이래 최장 기록인 듯?!
처음엔 단순히 적지 않은 분량, 딱딱한 번역체 때문에 오랫동안 고통받았다고 생각했다. 그러나 책을 덮으며 돌이켜보건대 그간 내가 자신 있게 알고 있다 여긴 부분이 실은 온전히 소화되지 못한 상태로 남아 있었기에 진정으로 이해하기까지 긴 시간이 걸린 건 아닐까 싶다.
그런 의미에서 (2023년 기준) 독자에게 신선한 충격을 주거나 놀라운 영감을 불러일으키진 않지만, 읽을 가치는 충분한 책. 또 시간이 흐른 뒤 시니어가 되어 들여다보면 또 다른 감상이 생길 것만 같은 책이다.
나중에 또 만나자! 👋
참고 자료
애자일과 린, 그리고 워터폴
더 나은 소프트웨어 개발 문화 만들기 | 본 글은 애자일 관련 4번째 글이며, 첫 번째 작성하였던 아래 글에서부터 이어진다. 애자일에 대해서 다소 생소하다면, 앞 글을 먼저 읽어 보기 바란다.
brunch.co.kr
고객 여정이란? - ServiceNow
고객이 벤더를 결정하고, 솔루션에 동의하고, 구매 계약을 체결하는 단계입니다. 구현이 시작되고 고객이 팀을 구성하기 시작합니다. 솔루션 제공업체는 KPI, 성공 기준, 일정을 설명하면서 고객
www.servicenow.com
아키텍처(Architecture)란?
안녕하세요 린생입니다. 개발을 이제 막 시작한 입문 개발자인 제가 갑자기 Architecture(아키텍처)라는 것이 궁금해졌습니다. 다들 "Architecture(아키텍처)가 뭐야?" 라고 하면 잘 설명을 할 수 있나요
linsaeng.tistory.com
- 발생적인 문제에 관한 접근법. "고객은 왜 불편해하는가?" [본문으로]
- 평가적인 문제에 관한 접근법. "고객은 얼마나 불편해하는가?" [본문으로]
- Customer Journey. 고객이 제품과 상호작용하며 발생하는 경험의 총체. 브랜드 인식 (고객이 입소문, 광고, 검색 등을 통해 서비스에 대해 알게 되는 단계) → 관심 증대 (고객이 제품에 관심을 갖고 구매를 고려하는 단계) → 구매 결정 (고객이 구매를 결정하는 단계. 고객 경험에 따라 구매를 철회할 수도 있어 유의해야 한다.) → 제품 경험 (고객이 제품을 사용하기 시작하는 단계. 튜토리얼, FAQ 같은 셀프서비스를 제공하여 고객이 문제를 쉽게 해결할 수 있도록 해야 한다.) → 충성도 함양 (고객이 제품에 만족하고 긍정적인 소문을 퍼뜨리는 단계. 꾸준히 만족스러운 경험을 선사하기 위해 노력해야 한다.) 단계로 이루어져 있으며 순환 모델로 묘사되기도 한다. [본문으로]
- Architecture. 제품의 작동 원리. 하나의 제품이 어떻게 이루어져 있고 동작하는지에 대한 명세. [본문으로]
- 우리의 사업 목표는 무엇인가? [본문으로]
- 성공 여부를 어떻게 판단할 수 있는가? [본문으로]
- 고객을 위해 어떤 문제를 해결해야 하는가? [본문으로]
- 우리가 집중하고 있는 고객은 누구인가? [본문으로]
- 제품을 '내돈내산'한 고객 중, 제품에 몹시 만족해 가족이나 친구에게까지 권할 의사가 있는 고객. [본문으로]
- 낮은 충성도의 사용자 프로토타입 [본문으로]
- 높은 충성도의 사용자 프로토타입 [본문으로]