제품 로드맵에 집착하고 계신가요?
Inspired Summary
해당 글은 Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group) by Marty Cagan을 읽고 요약한 글입니다.
제품 조직에서 발생하는 대부분의 실패와 낭비가 전형적인 로드맵 때문입니다.
Yet, typical roadmaps are the root cause of most waste and failed efforts in product organizations.
"결과물이 아닌 성과에 집중하세요. 훌륭한 팀은 사업적 성과를 만들어 내는 것이 주요 업무이며, 전형적인 제품 로드맵은 단순 결과물에 지나지 않는다는 것을 기억하세요."
"Focus on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results."
전형적인 로드맵 (typical roadmap)
- 프로덕트 로드맵은 수행해야할 프로젝트와 기능에 대한 우선순위 목록
- 일반적으로 회사들은 분기별로 나눠 프로덕트 로드맵을 구성함
- 많은 회사들은 경영진으로부터 내려온 이해관계자 기반의 프로덕트 로드맵(stakeholder-driven roadmap)에 기반하여 업무를 진행
- 버그나 최적화를 다루지 않으며, 보통 이니셔티브(initiatives)라는 이름으로 기능, 프로젝트 단위의 여러 팀의 협업을 요구하며, 보통 만기일이나 납기일이 포함되어 있음
전형적인 로드맵은 왜 자주 사용되는가?
- 제한된 자원으로 인해 하고자 하는 모든 것을 할 수 없기 때문에, 일반적으로 경영진이 이를 판단하는 것이 효율적이라고 생각하기 때문
경영진의 니즈
1. 가장 가치가 큰 것들부터 수행하기를 바람
2. 계획에 기반하여 마케팅 프로그램, 영업 인력 구성, 파트너십 등에 대한 일정을 미리 예측하고자 함
전형적인 로드맵에 대한 두 가지 불편한 진실
1. 계획의 절반 이상이 틀어질 것
- 제품이나 기능을 개발하지 말아야 할 이유는 너무나도 많음
- (1) 가치(value) 부재: 고객들은 우리가 생각한 만큼 만족스럽지 않아서 해당 제품을 사지 않는 경우 → 계획이 틀어지는 가장 많은 이유
- (2) 사용성(usability) 부족: 고객들이 원하는 바를 이루고자 할 때, 많은 어려움이 발생하여 사용하기를 꺼리는 경우
- (3) 실현가능성(feasibility) 부족: 내부적으로 시장에 내놓기 위한 시간과 비용이 부족한 경우
- (4) 사업 실행가능성(business viability) 부족: 심각한 법적, 재무적, 사업적 제약 사항으로 인해 출시가 불가한 경우
2. 반복 검증(iteration)은 선택이 아닌 필수
- 수익화 검증의 시기(time-to-money): 가치, 사용성, 실현가능성, 사업 실행가능성을 충족하는 것처럼 보이는 아이디어라도, 여러 번의 검증을 통해 확실한 사업적 가치가 있는지 확인해야 함
전형적인 로드맵 개미지옥
1. 경영진으로부터 할당된 로드맵으로 기반하여 움직이는 제품팀들은 끊임없는 시간동안 지친 채로 업무 (plod through the roadmap)를 하게 되며
2. 제품을 출시했을 때, 반응이 좋지 않으면 해당 로드맵을 제안한 이해관계자들을 탓하게 되고
3. 로드맵 담당자는 ‘문제를 해결할 수 있길 바라며’ 새로운 로드맵을 만들어냄
4. 경영진이 인내심이 거덜나지 않는 한(그럴 가능성은 거의 전무, “a big if”), 이 무한 개미지옥은 계속됨
전형적인 로드맵이 위험한 이유
- 로드맵을 공표하는 순간, 사람들은 로드맵 내에 있는 목록들 하나하나를 회사에 대한 공헌 혹은 성과라고 인식함
- ‘문제를 해결하는 것’이 아닌 ‘만드는 것’에 집중이 됨 → 실질적인 사업적 성과를 내는 데에 집중하는 것이 아니라, 계획서에 적힌 것을 수행하는 것을 우선적으로 생각하게 되면서, 주객전도의 상황이 발생
무엇이 필요한가?
- 두 가지 불편한 진실(최소한 절반 이상의 계획 사항들이 틀어질 것, 반복 검증(iteration)은 선택이 아닌 필수)를 부정하지 않고, 진지하게 받아들여야 함
- 아이디어들이 가지고 있는 위험들을 재빠르게 다루고 인식함
- 효과적인 해결책을 만들어내고 검증하는 데에 민첩함
⇒ 이 세 가지 사항들이 제품 발견(product discovery)의 핵심 역량(core competency)이라고 볼 수 있음 = 제품에 대한 완전한 의무 (high-integrity commitment)
참고: https://www.svpg.com/managing-commitments-in-an-agile-team/
Comment
제품 로드맵을 강조하게 되면, 문제 해결이 아닌 '제작'자체에 집중이 되는 역효과가 큼
제품을 만들 때는, 고객과의 인접성과 가설에 대한 반복 검증이 필수 조건
