프로덕트 로드맵, 전략에서 로드맵까지
비전&목표를 실현하는 효과적 방법, 프로덕트 로드맵 (2)
프로덕트로드맵에 대한 해외 아티클들을 번역하고 편집하여 공유하려는 목적의 글입니다.
관련 챕터는 아래와 같습니다.
전략에서부터 로드맵까지 (현재 글)
로드맵 계획을 세우고 우선순위 정하기 (예정)
로드맵 만들기 (예정)
로드맵 커뮤니케이션하기 (예정)
요약 (예정)
Trying To Strategy To Roadmap
탑다운 전략기획
PM과의 여러 번에 걸친 대화를 통해 경영진들은 아래 그림과 같은 탑다운 전략 및 커뮤니케이션을 선호한다는 사실을 알게 되었다. 경영진은 제품의 비전, 목표에 연결된 미래의 먹거리에 대해 생산적인 논의를 하기를 원하며, 이러한 탑다운 형태의 토론과 계획을 통해 회사를 움직이는 프로덕트 로드맵을 작성할 가능성이 높아진다.
높은 수준의 프로덕트 비전을 공유함으로써 경영진, 마케팅, 지원, 엔지니어링 관리 및 나머지 조직 구성원을 이 전략에 참여시킬수 있으며 PM은 경영진에게 제안된 로드맵이 회사의 전략적 방향에 적합한지 여부에 대해서 매우 관심을 가질 수 밖에 없다. 이 과정에서 상세한 릴리즈 계획과 백로그를 도출할 수 있다.
프로덕트 전략 개발하기
프로덕트 로드맵은 가만히 앉아서 초안을 만들 수가 없다. 달성해야 할 목표, 이유, 누구를 위해 필요한지 등에 대한 전략과 계획을 수립해야 한다.
로드맵 계획 단계에서도 중요한 것은 명확하게 설명하고 방어할 수 있는 전략을 구상하는 것이다. 결국 임원을 포함한 다양한 이해 관계자의 동의가 필요하다. 즉 계획을 백업하기 위해서는 높은 수준의 비전과 증거, 혹은 다른 지원 데이터가 필요할 수 있다.
궁극적으로 프로덕트 로드맵으로 이어지는 전략을 개발할 때는 프로덕트 비전과 원칙, 즉 ‘이유(why)’를 파악하고 명확히 설명하는 것이 중요하다.
프로덕트가 존재하는 이유, 그리고 프로덕트 운영에 대한 접근 방식을 명확하게 설명할 수 있어야 한다. 이는 미션에 대한 언급, 신조, 혹은 원칙일 수 있다. 중요한 것은 사람들이 이 내용을 믿는 다는 것이며 이를 모든 로드맵의 맨 위에 고정시킴으로써 그 로드맵을 따르는 것이 다른 부서들의 원칙과 일치하는지 아닌지를 분명히 할 것이다.
– Airbnb PM디렉터, Ian AcAllister
로드맵 계획을 수립하기 전에 프로덕트의 미션을 결정한 다음, 이해당사자들이 이해할 수 있는 가벼운 설명이 필요하다. 여기에는 프로덕트 비전, 해결해야 할 문제들, 타겟 고객, 그리고 마켓에서의 가치 등이 포함된다. 이를 문서화하면 로드맵에 도움되는 많은 주요 항목을 정확하게 파악할 수 있다.
IKEA의 비전: IKEA의 비전은 많은 사람들을 위해 더 나은 일상을 만드는 것. 우리의 사업 아이디어는 가능한 많은 사람들이 구매할 수 있도록 저렴한 가격에 잘 디자인되고 기능적인 가정용 가구제품들을 공급함으로써 이러한 비전을 뒷받침 하는 것이다.
“At IKEA our vision is to create a better everyday life for the many people. Our business idea supports this vision by offering a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.”
임원들은 프로덕트 개발 및 업데이트 계획을 명확히 알고 있어야 하며, 이에 동의하고 있어야 한다. 개발팀의 경우 프로덕트에 대해 어떤 계획을 세웠는지, 그리고 그 이유에 대해서 이해하고 있어야 한다. 영업, 서비스, 마케팅 팀은 시장에 전략을 명확히 전달할 수 있도록 해당 이유를 명확히 알고 있어야 한다.
이러한 전략 우선(Strategy-first) 접근 방식은 몇 가지 이점이 있다.
– 이 접근 방식은 회사 내 모든 부서에 프로덕트 비전을 보다 쉽게 전달할 수 있으며, 이후 이어지는 세부적 대화를 하기 전에 이해당사자들이 동일한 의견을 가지고 있는지 확인할 수가 있다.
– 이 접근 방식을 통해 프로덕트 비전을 보다 쉽게 파악할 수 있으며, 프로덕트 로드맵 프로세스 전반에 걸쳐 꼭 해야 하는 우선순위와 비전과는 별개로 생각해야 하는 별도의 항목들을 명확히 구분할 수가 있다.
Google의 비전: 세계의 정보를 정리하고 보편적으로 접근 가능하고 유용하게 만드는 것
“To organize the world’s information and make it universally accessible and useful.”
프로덕트 목표(Goal) 정의
프로덕트 비전을 통해 프로덕트 목표를 도출하면 로드맵 상에 있는 시작점에 영향을 줄 수가 있다. 프로덕트 목표를 정립하는 것은 프로덕트 전략을 실행 가능한 계획으로 전환하는 데 도움이 되는 단계이다. 모든 조직의 프로덕트 목표는 다를 것이다. 프로덕트 목표를 통해 제품별, 회사 지향, 또는 더 일반적인 목표를 개발할 수 있다. 아래에 몇 가지 예가 있다.
경쟁력 차별화
고객 즐거움
기술 향상
제품 운영
고객 만족도 향상
실생활의 가치 향상
신규 서비스 업셀링
이탈률 감소
지리적 확장
모바일 적용
이러한 목표는 일반적이지만 이를 KPI로 연결지어 볼 수 있다. 이러한 목표들은 이해 관계자들에게 큰 영향을 미칠 수 있고, 이러한 목표는 매월 보다는 매년 변경될 수 있는 장기적인 목표로 볼 수 있다.
Agile에서의 로드맵 계획
언뜻 보기에는, Agile이라는 용어와 프로덕트 로드맵은 모순처럼 보일 수 있지만 실제로는 그렇지 않다. 대부분의 Agile 개발 조직에서 백로그는 단기적으로 제품기능을 정의하고 백로그를 통해 개발팀은 이후 스프린트에 대해서 가늠을 할 수 있다. 하지만 백로그를 로드맵이라고 할 수 없는 것처럼, 프로덕트 로드맵은 중/장기적으로 프로덕트가 지향하는 방향에 대한 전략적 관점을 정의한다. 이 로드맵은 조직의 비전 및 전략적 목표와 연계되어 있으며 종종 향후 12개월 이상 지속된다. Agile조직에서 로드맵은 엄격한 프로젝트 계획 보다는 지침을 제공해야 한다.
Backlog는 로드맵이 아니다
로드맵은 시장을 확장하고 경쟁을 해결하고 고객가치를 창출하는 큰 그림을 조직에게 전달할 수 있어야 한다. 이러한 그림을 Backlog로는 그려낼 수가 없다. 특히나 스프린트 측면으로 생각하지 않는 임원, 이해관계자들에게 전략을 전달하는 것은 쉽지 않다. Agile 조직도 전략적 관점을 필요로 하며 프로덕트 플랜에서는 개발자들과 프로덕트 로드맵을 공유하고 있다는 점이 중요하다. 로드맵은 주제의 관점에서 설명할 수 있으며 Backlog는 프로덕트를 제공하는 세부 기능과 작업을 나타낸다. 어떤 의미에서 Backlog는 회사의 프로덕트 로드맵에 설명된 비전을 어떻게 제공할지에 대한 설명서와 같은 것이다.
Agile 로드맵
로드맵은 민첩(Agile)해야 하며 픽스된 계획이라기 보단 살아있는 문서가 되어야 한다. 정기적으로 새로운 정보를 바탕으로 로드맵을 재검토하고 논의하여 우선순위를 다시 매길 수 있어야 한다. 이유는 로드맵이라는 것이 변경되지 않는 약속이 아니라는 것을 이해관계자들과 함께 기대치를 설정하는 것이 중요하다. 따라서 로드맵의 경우 날짜를 월별로 혹은 분기별로 유지하는 것이 더 나을 수 있다. PM은 모든 사람이 동일한 방향을 향해 갈 수 있도록 커뮤니케이션 해야 하며, 특히 최종 결정을 내리거나 예산을 통제하고 방향에 영향을 미치는 이해관계자는 더욱 그럴 수 있어야 한다. 따라서 Agile 로드맵의 경우 이해 당사자들이 이해할 수 있고 백로그를 파악할 수 있도록 시각적으로도 이해하기 쉬운 문서가 되어야 한다.
전형적인 로드맵 프로세스 과제
프로덕트 로드맵이 어려운 이유는 무엇일까? 프로덕트 팀과의 대화에서 PM은 경영진 및 기타 이해 관계자가 프로덕트 전략을 따르지 않아 불만이라는 공통적인 이야기를 듣곤 한다. PM은 큰 그림을 전달하고 싶어하지만 쉽지 않다.
로드맵의 가장 중요한 목적은 프로덕트 전략을 커뮤니케이션 하는 것위 그림에서 보이는 것처럼 대부분의 로드맵의 주요 목표는 프로덕트 전략을 전달하는 것이다. 두 번째 목표는 계획을 세우고 우선순위를 정하는 것이다. 효과적인 로드맵을 개발하기 위해 극복해야 하는 몇 가지 문제들에 대해서 조금 더 자세히 이야기해볼까 한다. 이러한 당면 과제와 솔루션은 로드맵 문서를 넘어 로드맵을 개발하는 데 사용하는 프로세스의 핵심을 다룬다.
#문제1: 너무나도 장기적인 계획의 수립
많은 PM들은 장기 계획 및 성과물이 포함된 로드맵을 작성하곤 한다. 때로는 수 년 후의 모습을 그려보기도 하는데, Agile 프로세스를 상상해보면 새로운 기술 뿐 아니라 시장의 요구, 기회도 프로덕트 개발이나 우선순위의 변화가 필요해지는 경우가 많다. 이것이 성공적인 프로덕트 로드맵이 계획, 우선순위를 빠르게 조정할 수 있는 유연성에 초점이 맞춰지고 설계되어야 하는 이유이다. 이는 또한 로드맵이 특정 릴리즈 일 보다는 제품의 높은 수준의 목표를 달성하기 위해 마일스톤과 성과물을 유연하게 유지해야 한다는 점을 모든 부서에 효과적으로 알리는 것이 매우 중요한 이유이기도 하다.
#문제2: 딱 한 시점의 우선순위 정의
로드맵을 개발하는 초기 단계에서 우선순위를 정하는 목표를 세우는 것은 PM의 책임이라고 할 수 있다. 또한 PM은 여러 상황 속 더 큰 컨텍스트 내에서 프로덕트 개발을 우선시해야 한다. 프로덕트 의사결정에 우선순위 프레임워크를 구축하면 고객에게 필요한 기능의 우선순위를 결정할 때 활용도가 높아질 수 있다. 마찬가지로 이 단계는 기대치를 관리하고 필요할 때 팀이 더 높은 우선순위로 신속하게 초점을 전환할 수 있도록 해준다. 이 내용에 대해서는 이후 3번째 챕터에서 좀 더 자세히 살펴보도록 하겠다.
로드맵을 지원하기 위해 사용하는 메트릭스(Metrics)
메트릭스(지표) 중심의 프로덕트 관리는 이제는 성공적인 제품을 만드는 기본이라고 할 수 있다. 하지만 이제 막 만들어진 제품과 같은 경우엔 데이터 자체가 거의 없기 때문에 메트릭스 자체를 활용하기 어려울 수 있다. 출시 초기에 데이터가 폭주할 수도 있지만 올바른 매트릭스 구조 자체가 없을 수 있다. 프로덕트 팀이 새로운 제품의 잠재적인 성공과 약점을 측정하는 데 필요한 올바른 기준은 무엇일까? 로드맵 계획에 메트릭스를 통합하려면 아래와 같은 팁을 확인해보자.
메트릭스의 빠른 정의
올바른 메트릭스를 초반에 정의하면 프로덕트의 의사결정 및 로드맵을 안내할 수 있는 더 나은 인사이트를 얻을 수 있다. 프로덕트 개발 중 가능한 빨리, 그리고 프로덕트 개발 전에 성공 메트릭스를 정의하는 것이 좋다. PM이 사용할 수 있는 새로운 분석툴들은 너무나도 다양하기 때문에 프로덕트 출시 전에 어디에 초점을 맞출지에 따라 명확한 메트릭스를 결정하는 것은 중요하다. 당연히 빠를 수록 좋다.
과학적 사고방식
올바른 측정기준과 프로덕트 목표를 빠르게 설정하기 위해서는 과학적인 사고가 필요하다. 사이언티스트들은 빠르게 가설을 설정하고 정의하고 측정, 검증한다. PM은 목표를 설정한 후 다음 목표에 대한 메트릭을 설정한다. 비록 간단하지만 이 과학적 사고방식은 새로운 제품을 성공적으로 만들어가는 가장 좋은 방법일 수 있다. 예를들어, 유료고객으로 전환한 트라이얼(평가판) 고객의 비율과 같이 전환 메트릭스을 측정하는 것은 중요하다고 할 수 있다. 앞으로 보고자 하는 대상에 대한 가설을 세우고 이에 대한 메트릭스를 측정하는 것은 앞으로 비즈니스모델에 대해 팀과 대화를 나누고 고객 데이터가 도착하기 시작하면 문제를 조기에 발견할 수 있기 때문이다.
올바른 것들을 측정하고 있나?
궁극적으로 선택한 메트릭스는 프로덕트 단계, 산업, 제품유형 및 회사의 규모에 따라 달라질 수 있다. 하지만 가장 중요한 건 최우선 목표 및 비즈니스 결과와 연결되는 가장 중요한 지표에 집중하는 것이다. 단순히 보기만 좋은 ‘허구의 메트릭스(vanity metrics)‘는 피하도록 하자. 예를들면 이러한 ‘허구의 메트릭스’에는 단순 웹사이트 페이지 뷰 혹은 페이스북 좋아요 수가 포함될 수 있다. 이러한 측정 기준들은 비즈니스 결과나 고객의 성공과는 직접적인 관련이 없다. 더 나은 선택은 활성화 사용자(active users), 고객 획득비용(Acquisition Cost), 평균 수익(average revenue)등 일 것이다. 이는 비즈니스에 직접적인 변화를 가져오는 지표이다.
프로덕트를 위한 샘플 메트릭스
성공 메트릭스가 아직 없다면 올바른 메트릭스를 찾는 방법은 무엇일까?
일반적으로 매출, 수익, 획득비용 및 리텐션과 같은 측정 기준도 좋은 출발점일 수 있다. 다음은 고객 및 비즈니스 관점에서 성공을 측정하는데 도움이 될 만한 몇 가지 메트릭스의 예이다. 여러 지표 중에 우선 몇 가지 중요한 지표들만 선택해서 집중하는 것이 필요하다. 이러한 지표들 중 몇 가지를 선택해서 기준선을 설정하자. 궁극적으로 비즈니스의 메트릭스를 세분화하고 팀과 협력하여 중요한 지표에 대한 합의를 도출하자. 이는 프로덕트 로드맵에 설정한 전략적 목표와 연계되는 실행가능한 지표이다. 목표와 메트릭스를 주기적으로 수정하자. 프로덕트가 성숙함에 따라 메트릭스도 변화하고 그에 따라 자연스럽게 지표는 증가하게 될 것이다.
* 고객 사이드에서의 성공이라고 할 수 있는 프로덕트 참여 메트릭스는 (비용, 수익관점이 아닌) 사용자의 비중, 특정 기능의 사용율, 리텐션, 해지율 등이 될 수 있겠다. 우선순위 설정에 대한 이야기는 #3에서..
Reference
Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty
해당 글은 글쓰는몽글C 님과 모비인사이드의 파트너쉽으로 제공되는 기사입니다.
