중렙 서비스 기획자로 진화하고 싶다면 필독!

 

 

로드맵 그리기:
중렙 서비스 기획자가 되기 위한 관문

 

담당하고 있는 서비스나 기능에 대한 이해도가 높아지면, 자연스레 ‘로드맵’을 정하게 되는 때가 온다. 그것은 연차나 포지션에 따라 ‘프로덕트의 방향성’이라는 거창한 이름이기도, ‘기능의 Next 컨셉’이라는 보다 한 단계 낮은 이름이기도 하다.

때로는 자의일 수도, 때로는 타의일 수도 있지만, 언젠가 한번쯤은 거쳐야 하는 것이고 로드맵을 잘 잡는 것은 중렙 기획자가 되기 위한 중요한 덕목이기도 하다. 필자도 담당하고 있는 서비스의 방향성을 생각해보아야 할 때가 왔다. 이번 기회에 로드맵의 정석을 공부하고자 한다.

 

 

 

 

로드맵이란 무엇이고, 왜 필요한가?

 

프로덕트 로드맵(Product Roadmap)에 대한 정의부터 시작하려고 한다. 요즘 큰 반향을 일으키고 있는 ChatGPT 님께 물어봤다 ^^

 

제품 로드맵은 시간 경과에 따른 제품의 비전, 방향 및 우선 순위를 개략적으로 설명하는 고급 시각적 요약입니다. 이 문서는 제품의 목표와 계획에 대한 명확한 뷰를 제공하고, 제품이 제공할 것으로 예상되는 사항에 대해 부서, 이해 관계자 및 고객을 조정하는 데 도움이 되는 전략적 문서입니다.

 

그렇다. 한마디로 ‘프로덕트 로드맵’이라는 것은 프로덕트와 관련된 이해관계자에게 우리 프로덕트의 비전과 방향을 개략적으로 설명하는 문서라고 할 수 있다.

그리고 이것이 바로 로드맵이 필요한 이유이기도 하다. 프로덕트를 만들어나가다보면, 사업부나 개발파트 등… 여러 관계자들에게 우리가 생각하는 프로덕트의 방향성에 대해 ‘설명’하고 ‘설득’ 시켜야 하는 일이 생긴다. 그때 필요한 것이 바로 이 ‘프로덕트 로드맵’이다. 잘 만든 프로덕트 로드맵은 일의 1)우선순위를 정하고, 2)리소스 분배를 효율적으로 하게 하고, 3)제품 전략을 뒷받침하는 결정을 내리는 데에 도움이 된다.

 

 

 

 

프로덕트 로드맵을 세우는 4단계

 

자, 이제 프로덕트 로드맵이 무엇인지 알았으니 어떻게 세워야 하는지를 알아보자. 크게 아래의 4단계를 거치게 된다.

 

1. Vision 확립하기 2. Product Goal 확립하기 3. 하나의 Theme으로 묶기 4. 우선순위 정하기

 

 

1. Vision 확립하기

 

이제 막 프로덕트 로드맵에 대해 배웠는데 Vision이라니, 싶지만 Vision은 간단하다. (정의는 간단하지만 세우는 것은 어렵다.) Vision이란 우리 서비스가 고객 또는 사회에게 주어야 하는 가치, 추구하는 미션을 말한다. 예를 들어 Google의 비전은 전세계의 정보를 체계화해 모두가 편리하게 이용할 수 있도록 하는 것이다. 이러한 비전을 실현하기 위해 전세계 모든 정보에 접근할 수 있는 검색 엔진을 운영하고 있다.

프로덕트에 Vision이 있으면, 우리의 로드맵에 어떤 과제를 담아야 하는지가 더욱 명확해진다. 우리가 만든 프로덕트 로드맵의 Why가 Vision에 근거하는지를 생각해보면, 비전에 부합하는 과제를 좀 더 우선순위 높게 진행할 수 있기 때문이다.

 

 

2. Product Goal을 정하기

 

프로덕트의 Vision이 정해졌다면, 이제는 Vision을 실현하기 위한 Product Goal을 선정할 차례다. Product Goal은, 우리가 정한 Vision과 프로덕트의 전략을 실제로 이행가능한 계획으로 만들어주는 목표라고 할 수 있다. 학문적으로 접근하면 ‘조작적 정의’와 비슷하다고 할 수 있다. 좀처럼 측정하기 어려운 추상적인 Vision을, 실제로 달성할 수 있는 목표로 만드는 것이다.

아래에 Product Goal 예시들을 보면 좀 더 이해하기 쉽다.

 

Competitive Differentiation Customer Delight Technical Improvements Sustain Product Features Improve Customer Satisfaction Increase Lifetime Value Upsell New Services Reduce Churn Expand Geographically Mobile Adoption

 

Product Goal을 정하고 나면, Goal을 달성하기 위한 여러가지 과제가 튀어나올 것이다. 예를 들어 “프로덕트에서 이탈하는 고객을 줄인다”라는 Product Goal이 선정되면, ‘가입 단계 줄이기’, ‘푸시 알림을 통한 CRM’ 등, 이탈률을 줄일 수 있는 여러가지 세부 과제들이 줄지어 나오게 된다. 심지어 이런 과제들은 Backlog에 엄청나게 쌓여있는 경우도 있다.

 

 

 

 

바로 이때 필요한 것이 Theme으로 묶는 3단계 작업이다.

 

 

3. 많은 과제들을 하나의 Theme으로 묶기

 

Backlog에 쌓여있는 여러 과제들을 유심히 살펴보면, 결국 하나의 주제로 묶을 수 있다. 예를 들어 ‘푸시 알림 메시지 개선’이라는 주제 아래에는 ‘UX Writing 개선 작업’, ‘푸시 알림 API 성능 개선’, ‘운영도구 개선’ 등의 세부 과제들이 들어갈 수 있다.

 

 

 

 

이때 중요한 것은 Theme 자체는 고객이 느낄 수 있는 가치에 초점을 맞춰야 한다. 위의 예시에서 Theme을 정의하려면, ‘푸시 알림 개선’이 아니라 ‘사용자는 푸시 알림을 통해 필요한 정보를 적시에 받아볼 수 있다.’ 정도가 될 수 있겠다.

이렇게 Theme을 이용하는 것은 로드맵에 하나의 스토리를 불어넣을 수 있다. 단순히 무언가를 개선하겠다는 것이 아니라, 개선사항을 통해 사용자가 어떤 가치를 얻게 될 수 있는지를 설명할 수 있게 된다.

 

 

 

 

4. 우선 순위 정하기

 

이제 가장 어려운 것이 남았다. 무엇이 우리 Vision을 실행하기에 더 중요한지 경중을 따져야 하는 순간이다. 회사란 무릇, 항상 제한된 리소스 때문에 더 중요한 것을 선택해야 한다. 그리고 서비스 기획자는 늘 이런 선택의 기로에 서게 된다. 이때 사용할 수 있는 유용한 모델을 소개해본다.

 

 

A. 카노 모델 (Kano Model)

 

카노 모델은 카노 노리아키에 의해 1980년대에 연구된 제품 개발을 논하는 상품기획이론이다. 이 모델에서는 제품의 품질을 결정하는 세 가지 요소를 제시한다.

 

매력적 품질요소(Attractive Quality Element): 충족되는 경우 만족을 주지만 충족이 안 되더라도 크게 불만없는 품질요소를 말한다. 고객이 미처 기대하지 못했던 것 혹은 기대를 초과하는 만족을 주는 품질요소가 될 수 있다. 이러한 요소의 존재는 고객들은 모르거나 기대하지 않았기 때문에, 충족이 되지 않더라도 불만을 느끼지 않는다. 일차원적 품질요소(One-Dimensional Quality Element): 충족이 되면 만족하고 충족되지 않으면 고객들의 불만을 일으키는 품질요소이다. 가장 일반적인 품질인식요소이다. 당위적 품질요소(Must-Be Quality Element): 반드시 있어야만 만족하는 품질요소이다.

 

우리가 생각했던 과제와 Theme이 세 가지 중 어디에 속하는지에 아는 것 만으로도 우리는 어느 정도의 우선순위를 가질 수 있다. 예를 들어 프로덕트에 다수의 사용자가 체감할 만한 버그가 있는 경우, 이는 당위적 품질 요소에 해당하면 빠른 시일 내에 개선되는 것이 좋을 것이다.

 

 

B. Story Mapping

 

스토리 매핑 기법은, 고객이 프로덕트를 사용하는 단계에 제품의 기능을 맵핑하면서 어떤 기능이 가장 중요한지 판단하는 시각적인 기법이다.

예를 들어 고객이 어떤 프로덕트를 사용할 때 A, B, C, D라는 기능을 사용한다고 가정해보자. 정해진 배포일자까지 개발할 수 있는 기능에 한계가 있을 때, 사용자가 프로덕트를 사용하는 데에 문제가 없으려면 어떤 요소가 먼저 제공되어야 하는지를 반단할 수 있다.

 

 

 

 

 

좀 더 자세한 방법론에 대해서는 아래 아티클을 참고하기 바란다.

• Mapping User Stories in Agile

 

 

로드맵의 예시

 

제품의 우선순위까지 정했다면, 이제는 진짜 로드맵을 시각화해볼 차례가 왔다. 로드맵은 크게 ‘타임라인이 있는’ 로드맵과 ‘타임라인이 없는’ 로드맵으로 나눌 수 있지만, 결과적으로는 시간의 흐름에 따라 어떤 가치를 먼저 제공하고 이를 위해 어떤 과제를 먼저 진행해야 하는 지를 보여준다는 점에는 큰 차이가 없다.

아래 예시가 가장 정석적인 예시라고 볼 수 있다. 특정 기간 동안 각 파트에서 전반적으로 어떤 일을 하는지를 정리한다.

 

 

 

 

주니어 기획자 및 PM이라면 단건 과제를 진행하는 경우가 많다. 이 때에는 아래와 같이 각 과제를 진행하는 파트 별로 나누어서 로드맵을 그릴 수 있다.

예를 들어 디자인 파트, 서버 파트, 기획 파트, 앱 개발 파트와 같이 나누고, 프로젝트의 일정을 협의하고 진척 상황을 관리할 수 있다.

 

 

 

 

로드맵에 대한 대원칙: 살아있기~

 

로드맵에 있어 가장 중요한 원칙 중 하나는 “실시간으로 의견이 반영되는 문서(living document)여야 한다”는 점이다. 어느 날 갑자기 삘받아서 정해놓고 wiki 어딘가에 짱박힌 채로 사문화되어서는 안된다는 말이다. 실시간이 아니더라도 주기적으로 프로덕트의 로드맵에 대해 다양한 부서의 의견이 정리되고 반영되는 시간이 있어야 한다.

 

 

 

 

쪼렙 서비스 기획자님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.