비전&목표를 실현하는 효과적 방법, 프로덕트로드맵 (4)

 

프로덕트로드맵에 대한 해외 아티클들을 번역하고 편집하여 공유하려는 목적의 글입니다.

관련 챕터는 아래와 같습니다.

 

 

 


 

 

BUILDING YOUR ROADMAP

 

프로덕트비전을 정의하고 모든 이니셔티브의 우선순위를 모두 결정했다면 로드맵을 수립할 때이다. 로드맵을 그려가기 전 사용가능한 도구들을 파악하는 것도 중요하지만 PM들이 오늘날 로드맵을 어떻게 구축하고 있는지 또한 우선 살펴보도록 하겠다.

 

 

오늘날 PM 로드맵을 수립하는 방법

 

2015년에 프로덕트 로드맵에 대한 설문조사를 실행한 적이 있는데 수백명의 PM들에게 프로덕트 로드맵에 대한 관점, 목표, 과제에 대한 질문을 한 적이 있었다. 설문조사에 따르면  번째 로드맵의 주요 목적은 프로덕트 전략을 전달하는 이다. 그리고  번째 목표는 계획을 세우고 우선순위를 정하는 이었다. 하지만 PM들은 프로덕트 전략을 전달하고 우선순위를 정하는 데 어려움을 겪고 있다.

로드맵 관리의 가장 큰 문제는 업데이트에 걸리는 시간과 시각적으로 설득력을 가지기 어렵다는 것이다. 대부분의 로드맵은 매월, 또는 매주 업데이트 되고 경영진을 대상으로 하고 있다. 로드맵을 그릴 수 있는 다양한 도구들이 있지만 대부분 PM들은 프레젠테이션 S/W, 스프레드시트, 위키를 사용하여 관리를 하고 있는 것이 현실이다.

 

– 스프레드시트는 구성, 우선순위 지정에는 좋지만 비전을 전달하는 데 있어서는 효과적이지 않다.

– 프레젠테이션은 작성에 시간이 오래 걸리기도 하고 공유하기 어려운 정적인 문서이다.

– wiki와 다른 문서들은 분리되어 있기도 하고 지속적인 업데이트가 쉽지 않다.

– 로드맵을 구축하는 데 있어 단 하나의 출처가 있는 경우는 드물다.

 

 

PM들 중 13%만이 로드맵을 만들어내는 도구에 만족하고 있으며 15%는 제품 요구사항을 관리하는 도구에 대해 만족하고 있다고 설문에서 답하였다.

 

 

시각적인 로드맵의 중요성

 

프로덕트 전략을 기획했다면 이제 팀에게 제안할 로드맵을 제안할 준비가 되었다. 한 회사의 로드맵이 회사에 어떻게 도움이 될지를 확인하기 위해 작성된 스프레드시트를 검토하기 시작한다. 모든 사람들이 8포인트 폰트크기를 보며 천재적인 전략을 확인할 수 있을지 모른다. 하지만 사람들은 텍스트보다는 시각적인 정보에 더 잘 반응하고 이해를 쉽게 할 수 있을 것이다. 

PM으로서 주요 업무 중 하나는 프로덕트에 대한 전도사가 되는 것이다. 높은 수준의 시각적 프레젠테이션을 통해 전략을 보다 효율적으로 전달 할 수 있을 것이다.

여기서는 파워포인트, 로드맵 템플릿, 로드맵 소프트웨어, 무엇이 되었든 로드맵 문서를 작성하기 위한 몇 가지 제안사항을 소개해보고자 한다.

 

1. 적절한 컬러의 사용

컬러는 로드맵이 프로덕트의 비전, 전략적 목표와 어떻게 연결되는지를 나타내는 좋은 방법일 수 있다. 로드맵의 각 항목을 컬러코딩하여 사람들이 각 주요 과제와 해당 과제가 큰 그림에 어떻게 적합한지 연결하도록 지원한다.


2. 큰
글꼴 사용하기

사람들은 전략을 이해하는 데 시간이 제한적이므로 프로젝터나 온라인 미팅에서 가능한 한 큰 글꼴로 명확히 메시지를 전달하도록 하자. 로드맵을 프레젠테이션과 같이 생각한다면 경쟁에서 앞서나갈 수 있을 것이다.

 

3. 높은 수준을 유지하기

회사의 전략이 비전에 어떻게 적합한지 이야기를 하고 있다는 것을 기억하도록 하자. 그 이야기를 세부사항으로 파고들기보다는 크고 대담하게 이야기할 수 있어야 한다. 가능한 한 로드맵을 쉽게 파악할 수 있도록 이니셔티브의 논리적 그룹을 구성하는 것도 방법이다.

 

 

협업 로드맵

 

로드맵의 공유는 파워포인트일 수도, 동료와 함께 실시간으로 작업한 솔루션일 수도 있다. 로드맵 구축은 서로 다른 우선순위의 조화로운 조합이어야 한다. 처음부터 공동작업을 수행하는 방법은 각 이해관계자가 각자의 영역에서 자신의 이니셔티브를 주도하면서 참여할 수 있도록 하는 것이다. 

대형 소프트웨어를 만드는 회사의 PM이라고 가정을 해보았을 때, 모든 UI 기획을 보여주는 로드맵이 있을 수도 있고, 모든 API 프로젝트에, 혹은 전반적 소프트웨어 전략을 설명하는 로드맵에 초점을 맞출 수도 있다. 

PM으로서 이러한 모든 이니셔티브에 관심을 가져야 한다. 하지만 모든 분야의 전문가가 될 수는 없으므로 우선순위를 정하는 데 초점을 맞추도록 하자. PM 해야할 이다. 

큰 그림을 이해하기 위해 이런 개별 로드맵을 하나의 포트폴리오 계획으로 정리하고, 경영진에서 쉽게 이해할 수 있도록 그림을 추출하여 제안해야 한다.

 

로드맵 업데이트 빈도

 

제품 로드맵은 회사의 장기적인 제품 비전을 반영하는 높은 수준의 전략 문서이다. 그리고 로드맵 방향을 조정해야 할 경우 로드맵을 자주 업데이트할 수 있어야 한다.

빠르게 변화하는 세상에서, 몇 년 후에 무슨 일이 일어날지 예측할 수 없기 때문에 시장 변화, 고객 요구 사항, 이해관계자 요구 및 기타 영향에 신속하게 적응해야 할 것이다. 따라서 로드맵은 실제 문서여야 하며 변경을 허용해야 한다. 로드맵을 얼마나 자주 변경하느냐는 로드맵에 얼마나 많은 세부 정보를 포함하느냐에 따라 달라질 것이다. 예를 들어, 로드맵이 장기(12개월 이상)이고 상위 전략 수준이라면 자주 변경되지 않을 수 있지만, 상세 기능이 포함된 단기 로드맵은 자주 변경이 필요할 것이다.

프로덕트 로드맵 설문 조사에 따르면 대부분의 PM 매월 또는 매주 로드맵을 변경하고 있다고 한다. (물론 분기별 변경빈도도 꽤 높은 편으로 나타났다)

 

 

 

 

가지 인기 있는 로드맵 스타일

 

로드맵을 작성하는 첫 번째 단계는 적절한 스타일을 선택하는 것이다. Roadmap 스타일 순열은 끝이 없지만, 가장 일반적으로 다음 세 가지 스타일이 인기가 있다.

 

1) 타임라인 베이스 로드맵

2) 타임라인이 제외된 로드맵

3) 칸반 보드형태의 로드맵

 

정도로 나누어 볼 수 있다. 각각의 장/단점 역시 설명해보도록 하겠다.

 

1) 타임라인 베이스 로드맵

 

 

 

모든 PM들은 “무엇을 하고 있으며 언제 완료됩니까?”라는 질문을 들어본 적이 있을 것이다. CEO가 이 질문을 하면 타임라인 기반 로드맵이 좋은 도구가 될 수 있으며 이 질문에 답변하는 데 도움이 될 수 있다.

위 그림 13에 나와 있는 타임라인 기반 로드맵은 시간의 맥락에서 서로 상대적인 과제들을 보여주고 있다. 특정 과제에 얼마나 오랫동안 집중하고 언제 완료할 계획인지 시각적으로 알려준다.

 

2) 타임라인이 제외된 로드맵

 

 

 

 

로드맵에 날짜가 있을 수 있지만, 제품 관리 관점에서 날짜를 너무 구체적이지 않고 높은 수준으로 유지하는 것이 좋은 관행인 경우도 꽤나 존재한다. 예를 들어, 정확한 시작 및 종료 날짜를 지정하지 않고 몇 개월 동안 과제들을 표시하는 것이다. 구체적인 일정이 적혀있을 수록 구체적인 날짜 및 기능 제공에 대한 기대치를 설정해야 한다.타임라인 기반 로드맵은 당면한 여러 작업 간에 제품 일정을 시각화하는 데 유용하지만 타임라인 기반 로드맵의 일반 로드맵의 함정은 전략적 우선 순위를 강조하기보다는 마감일에 집중하는 이다.

“목적지 보다는 여정”이라는 말을 명심하면 로드맵에서 날짜 제한을 제거할 수 있으므로 프로세스 모델링, 즉 최종 목표를 달성하는 방법에 더 집중할 수 있다. 시간 표시 막대 기반 로드맵과 날짜가 없는 로드맵 사이에는 많은 공통점이 있지만, 여기서 중요한 차별화 요소는 그림 14에서 볼 수 있듯이 과제들을 날짜와 연관시키지 않는다는 것이다.

유사한 과제들을 같은 스윔레인(swimlane)에 함께 그룹화하면 주요 과제들을 더 잘 강조할 수 있다. 위의 로드맵 예제에서 막대로 표시된 각 과제들의 길이는 전략적 중요성 또는 대략적인 노력 수준을 나타낼 수 있다. 먼저 수행해야 하는 작업을 기준으로 프로세스를 모델링하고 다른 모든 작업과 함께 과제들을 배치할 수 있다.

 

3) 칸반 보드형태의 로드맵

 

 

 

 

Kanban은 로드맵, 우선순위 및 진행 상황을 보여주는 데 자주 사용되고 있다. Kanban 진행 중인 작업량(WIP:Work In Progress) 팀의 용량에 맞추어 팀에게  유연한 계획 옵션, 빠른 결과, 명확한 포커스  개발 주기 전반에 걸쳐 투명성을 제공합니다.

Kanban의 주요 장점은 진행 중인 작업량을 제한하는 이다. WIP 제한은 집중력, 인력 또는 기술 집합의 부족으로 인해 팀 프로세스에서 병목 현상과 백업을 강조할 수 있기 때문이기도 하다.

그림 15와 같은 칸반 스타일 로드맵의 경우, 각 개발 단계의 상태와 우선순위를 이해 관계자에게 쉽게 보여줄 수 있다. 예) 승인됨, 검증됨, 준비 완료, 진행 중, 준비 중 등

 

 

Roadmap Examples

 

이제 서로 다른 로드맵 스타일에 대해 이야기하고 다양한 아이디어를 불러일으킬 수 있는 몇 가지 구체적인 로드맵 사례를 살펴보도록 하겠다. 경영진을 위해 작성하는 로드맵은 엔지니어링을 위해 작성하는 로드맵과 매우 다를 것이다. 예를 들어, 경영진은 보다 긴 시간 범위와 보다 높은 수준의 과제들을 보다 중요하게 보고 싶어할 것이고, 엔지니어링 팀은 보다 짧은 시간 내에 보다 세부적인 수준으로 과제들을 파악하기 원할 수 있다.

 

Example Product Management Roadmaps

 

PM에게 로드맵은 망치가 목수에게 있는 것과 같으므로 먼저 제품 관리자를 위한  가지 일반적인 로드맵 사례를 설명하도록 하겠다. 이러한 프로덕트 로드맵은 경영진 이해관계자가 마주하고 있는 경우가 많기 때문에 시간이 길어질 수 있으며 세부 사항이 더 적은 주요 과제들을 보여줄 것입니다. 그들은 종종 전략적 과제들을 중요시 할 것이다. 왜냐하면 이것이 경영진들과 이해관계자들의 가치일 수 있기 때문이다.

 

 

Single Product Roadmap

 

 

 

 

특정 제품 하나를 담당하는 PM이라면, 이 로드맵 유형을 보면 될 것이다. 그림 16에 나와 있는 예제 로드맵은 동시에 진행되는 다른 모든 과제들의 상태를 전달하는 타임라인 기반 로드맵이다.

대형 소프트웨어 회사의 PM이라고 가정해보면 고객이 로드맵을 분류하는 한 가지 방법은 각 기능 영역에 대한 서로 다른 과제들을 서로다른 행에 그룹핑 하는 것이다. 예를 들어 소프트웨어용 모바일 애플리케이션뿐만 아니라 웹 애플리케이션도 있는 경우 로드맵을 두 가지 구분으로 분할 할 수 있을 것이다. 모든 업무 그룹에 걸쳐 각각의 개별 과제들은 종종 회사의 전체 전략적 목표와 다시 연관되기 위해 컬러로 구분한다.

 

 

Multiple Product Roadmap

 

 

 

 

또 다른 일반적인 사례는 회사의 포트폴리오에서 서로 다른 제품 또는 과제들을 조정하기 위한 다양한 프로덕트의 로드맵이 담긴 하나의 로드맵이다. 여러 제품을 시각화하는 로드맵은 여러 제품 또는 제품 범주를 책임지는 단일 PM을 가진 조직을 위한 훌륭한 커뮤니케이션 도구가 될 것이다. 예를 들어, 여러 핵심과제들이 동시에 발생하는 스타트업은 이 모든 것을 하나의 로드맵에 통합할 가능성이 높을 것이다. 이 로드맵은 이해 관계자들과 쉽게 공유하고 소통할 수 있다. 

 

 

Agile/Sprint Roadmap

 

 

 

 

개발 팀에는 밀린 일을 추적할 수 있는 프로젝트 관리 소프트웨어가 있지만 애자일 팀에는 여전히 제품의 방향을 보여주는 로드맵이 필요하다. 민첩한 기업은 장기 비전과 단기 실행 사이에서 로드맵이 적절한 균형을 맞춰야 한다. 상황에 맞추어 신속하게 로드맵을 변경할 수 있어야 한다.

그림 18에 표시된 사례를 보면 스프린트를 타임라인에 보여주고 있는 로드맵이다. 컬러는 팀이나 상태를 나타낼 수 있다. 여러 스프린트에 걸쳐 있는 기능의 경우 마일스톤을 사용하여 각 릴리스를 시각화하는 것도 방법이다.

 

Example Technology Roadmaps

 

프로덕트 관리 외에도, 로드맵의 또 다른 일반적인 용도는 전략적 기술 과제들을 위한 이다. 이러한 로드맵은 종종 내부 이해관계자 청중, 파트너 또는 엔터프라이즈 고객을 위한 것이다.

 

 

Technology Roadmap

 

 

 

 

기술 로드맵을 사용하여 여러 소프트웨어 시스템을 마이그레이션하거나 소프트웨어 업데이트를 롤아웃하는 등 해당 연도의 전략적 과제들을 계획할 수 있다. 기술 로드맵의 대상자는 종종 내부 시스템 솔루션을 제공하기 위해 IT 팀을 찾는 이해 관계자일 것이다.

또한 기술 로드맵은 조직의 통합 및 기타 기술에 의존하는 파트너 및 공급업체와 공유할 수 있다. 그림 19에 표시된 예에서, 로드맵은 사람, 기술 보안이라는  가지 범주로 나뉜다. 색상은 과제들의 상태를 나타낸다. 로드맵은 내년과 같은 시간 범위를 가질 수도 있고, 시간 범위를 전달하지 않는 것이 중요한 경우 날짜가 없을 수도 있다.

 

 

IT Architecture Roadmap

 

 

 

 

많은 소프트웨어 회사에서 소프트웨어 설계자는 회사 제품의 중추 역할을 하는 견고한 기반을 구축해야 하는 과제를 안고 있다. 일반적인 아키텍처 로드맵 구성 요소는 API, UI, 스토리지 타사 서비스 통합 등이 있을 수 있다.

그림 20의 예에서 로드맵은 프로젝트 상태(계획 설계, 구현 테스트, 최적화) 따라 컬러로 구분되었다. 

 

 

Enterprise IT Roadmap

 

 

 

 

대기업이 진행 중인 모든 중요한 과제들을 놓치는 것은 드문 일이 아니다. 엔터프라이즈 IT 로드맵을 통해 전략적 과제들을 시각화할 수 있다. 엔터프라이즈 IT 로드맵의 대상 고객은 대개 내부 대면 시스템, 보안 및 기타 솔루션을 제공하기 위해 IT 팀을 찾는 내부 이해 관계자일 것이다. 그림 21의 예에서, 로드맵은 전략적 중요성에 따라 필요한 역량을 개략적으로 설명하고 있다. 예를 들어 보안 규정 준수 과제, 재해 복구(DR) 운영 지원 태스크별로 그룹화할 수 있다. 이러한 전략적 로드맵의 기간은 종종 12-18개월로 꽤나 긴 경우가 많다.

 

Example Marketing Roadmaps 

 

마케팅 전략은 로드맵에서 흔히 볼 수 있는 또 다른 범주이다. 마케팅 로드맵 활용 사례로는 마케팅 계획, 제품 출시 계획, 콘텐츠 달력, 마케팅 프로그램 기반 로드맵 등이 있다.

 

 

Marketing Plan Roadmap

 

 

 

 

마케팅 계획은 당신의 마케팅 전략과 노력을 요약하는 청사진이다. 예를 들어, 마케팅 계획은 회사의 포지셔닝 메시징, 디지털 마케팅 프로그램 또는 영업 전략을 개략적으로 설명할 수 있다. 로드맵에서 마케팅 계획을 시각화하면 모든 마케팅 과제들에 대한 체계적인 개요를 얻을 수 있다. 이 예에서 로드맵은 과제들 유형별로 구성되며 담당자들에 의해 컬러로 그룹핑된다. 마일스톤은 특정 목표를 나타낸다.

 

 

Product Launch Roadmap

 

 

 

 

새 프로덕트를 출시할 때는 모든 과제들이 일치하고 모든 팀 구성원이 자신이 추진하는 과제들을 완료해야 하는 시기를 알고 있어야 한다. 프로덕트 출시 로드맵은 프로덕트 마케팅에 의해 관리되어 서로 다른 팀 간의 노력을 조율하는 경우가 많다. 프로덕트 출시 계획은 시간에 따라 결과물을 명확하게 전달하는 타임라인 기반 로드맵입니다. 이 예제 로드맵은 과제들 유형(: 브랜드 채널 관리)별로 구성됩니다. 타임라인은 6개월이며, 색상은 과제들의 단계를 나타내고 있다.

 

 

Digital Marketing Roadmap

 

 

 

 

마지막 로드맵 예는 디지털 마케팅 로드맵이다. 아마도 개별 캠페인의 세부 사항보다 훨씬 더 중요한 것은 올바른 마케팅 조합이다. 디지털 마케팅 로드맵을 통해 프로그램 관리자는 다양한 마케팅 채널에서의 노력을 보다 효율적으로 조정할 수 있다. 그림 24에 표시된 디지털 마케팅 로드맵은 컨텐츠 마케팅 과제, 이메일 마케팅 캠페인 소셜 미디어 전략등을 시각화하고 있다. 각각의 노력은 마케팅 퍼널 단계에 따라 분류될 것이다.

 

Reference

 

 

해당 글은 글쓰는몽글C 님과 모비인사이드의 파트너쉽으로 제공되는 기사입니다.