하지만 명심해야 할 점은 기존 당신의 프로덕트를 사용하는 고객들은 이미 당신의 제품을 구매해서 사용하고 있는 고객이기 때문에 편향에 빠질 수도 있다. 당신의 프로덕트를 사용하지 않는 고객들 역시 잊지 말도록 하자. 그리고 더 중요하게 보아야 할 점은 고객이 요구하는 내용들을 정확히 측정하고 구축하지 않는다는 점이다. 고객의 요청이 비전과 반드시 일치하지 않는 경우들도 존재한다. 이러한 부분들은 반드시 챙겨서 보아야 할 지점이다.

영업팀의 피드백, 목표가 프로덕트의 목표와 일치하거나 일치하지 않을 수 있으므로 영업팀에서 로드맵을 주도하도록 하면 어려움을 겪을 수 있다.

경쟁환경

프로덕트를 만드는 사람들의 목표는 시장에서 유니크하고 가치있는 프로덕트를 만드는 것이다. 하지만 경쟁사의 제품을 검토하는 것만으로도 환경에 대한 많은 것들을 배울 수가 있다. 하지만 경쟁사의 기능을 복제함으로써 'me too'프로덕트를 출시하게 되는 것에는 주의를 해야 할 것이다. 경쟁사의 프로덕트 자체보다 경쟁사에 대해서 고객들이 이야기 하고 있는 그 핵심에 집중하는 것이 더 도움이 될 수 있다. 무엇이 문제인지, 그리고 또 어떤 니즈와 원츠가 있는지를 고려해보도록 하자. 물론 현재 운영하고 있는 자신의 프로덕트가 있다면 이 또한 정기적으로 검토하는데 시간을 할애해보면 어떨까 싶다.

판매와 고객서비스

한 회사의 판매 담당자는 최종적으로 제품을 구매하는 고객을 대응하는 최전방에서 근무하는 사람이다. 해당 담당자는 최종적으로 프로덕트 로드맵을 구축하고 업데이트하는 최선의 방법에 대한 또 다른 귀중한 정보를 얻을 수 있는 소중한 사람이 될 수 있다. 현재 제품을 제 가격에 판매가 어렵다는 사실을 판매 담당자가 알고 있다면 그 이유를 알아야만 한다. 고객서비스 담당자 역시 최전선에서 실제 사용자 피드백을 수집할 수 있는데, 이들은 제품의 가장 일반적인 문제, 고객이 가장 자주 전화를 걸어 문의하는 기능들을 잘 알고 있다.

판매 담당자 혹은 고객서비스 담당자를 점심 식사에 초대하여 이야기하거나 짧은 온라인서베이를 통해 그동안의 경험에 대한 전략적인 질문을 해보도록 하자. 이들을 통해 실제 세상의 질문과 불만들을 들어볼 수 있을 것이다. (앞단에서 각 담당자의 이야기들을 들어보는 것은 조직을 넘어서 모두의 흥미와 관심을 끌어낼 수도 있을 것이다)

분석가 리서치

가트너나 포레스터와 같은 분석회사의 업계 보고서를 검토하고 어떤 유형의 프로덕트가 어떤 장/단이 있는지를 파악해볼 수도 있다. 이러한 보고서들에서 유용한 정보는 수집한 설문조사 생성데이터들일 것이다. 현재 프로덕트의 고객의 조사를 하는 것은 상대적으로 쉽고 이미 정보를 가질 수 있지만(그리고 왜곡된 그림을 얻을 수도 있음), 유사한 업계의 다른 회사들의 데이터를 얻는 것은 쉽지 않은 일이다. 그리고 비용도 많이 들 수 있다.

분석과 지표

데이터는 당신의 의견보다 훨씬 설득력이 있을 수 있다. 그리고 경영진, 이해관계자, 로드맵 담당자들은 데이터에 더 많은 관심들을 가지게 될 것이다. 프로덕트 로드맵을 가장 잘 구축하는데 도움이 될만한 비즈니스 인텔리전스 소스는 이미 준비가 되어 있을 것이다. 자체 분석을 통해 의사결정을 내릴 수 있어야 한다. 이 데이터는 고객이 제품에 대한 언급을 했던 텍스트, 비디오, 혹은 이를 분석한 분석데이터 등이 될 수도 있다. 이는 추측이 아니라 증거로서 활용될 수 있을 것이다.

이니셔티브를 테마로 구성해보기

회사의 비전을 설득력있는 방식으로 전달하기 위해 프로덕트 로드맵을 구축하는 것은 어려운 일이다. 하지만 이니셔티브를 테마로 그룹화하면 고객, 그리고 이해관계자들에게 가치를 설명하는 방식으로 로드맵을 구성해볼 수 있다. 테마는 여러분이 제안하는 것의 배경에 있는 이야기를 뒷받침해줄 수 있는 로드맵을 구성하는데 도움이 될 수 있다.

프로덕트 로드맵에 개별 기능, 태스크를 나열하는 대신 보다 크게 생각하고 '테마'로 분류하여 로드맵에 명확하게 설명하고 방어할 수 있는 우선순위 계층 구조로 배열해보도록 하자.

이상적인 테마는 고객의 가치, 즉 고객이 무엇을 얻게 될지 고객이 달성하도록 도울 수 있는 일을 설명할 수 있어야 한다. 아래 그림에서 '고객의 첫 구매 완료 시간 단축'은 하나의 예가 될 수 있으며 이를 지원하는 이니셔티브 (새로운 기능, 기능향상, 버그수정 등)를 테마로 분류해볼 수 있다.

테마는 로드맵을 더 높은 단계, 오랜 기간동안 유지할 수 있게끔한다. 이렇게 하면 전체 로드맵에 영향을 미치지 않고도 기능들을 쉽게 넣었다 뺐다가를 할 수 있다.

테마는 목표 중심적이야하고 목표에 대해서 경영진들의 의견을 일치하게끔 할 수 있다면 이렇게 만들어가는 것이 더 쉬울 수 있다. 이를 위한 프로세스 상에서 목표달성 여부를 정의하는 지표와 KPI에 대해 논의하는 것이 중요하다.

테마 작성 방법

프로덕트의 전략적 목표는 로드맵 테마를 구분하는 좋은 방법일 수 있다. 달성하고자 하는 수준 높은 이니셔티브를 선택해볼 수 있다. 이러한 이니셔티브들은 프로덕트 레벨에 속하거나 조직에 맞게 구분될 수 있다. 테마는 기간이 짧거나 여러 릴리즈에 걸쳐 있을 수도 있다. 상황에 따라서는 테마에 여러개의 epic들이 포함될 수도 있다.

* 테마 사용 시 주의사항: 판매를 담당하는 영업팀과 같은 경우 테마가 포함되는 내용에 대해 빠르게 대응해줄 수 있으므로 관련해서 미리 이야기를 나누어보아도 좋다.

PM으로써 중요한 일 중 하나는 의사소통일 수 있다. 경영진 및 기타 이해관계자를 회사의 비전과 ㅎ마께 참여시킬 수 있어야 한다. 프로덕트 로드맵 템플릿, 온라인 로드맵 스프레드시트, 혹은 제품 로드맵 소프트웨어를 사용하든 상관없이 테마는 제품 계획을 단순화 하고 더 많은 것들을 만들 수가 있을 것이다.

우선순위 결정 테크닉

회사의 리소스는 한정되어 있다. 새로운 기능이나 향상과 같은 미래지향적 이니셔티브의 우선순위를 정하고 불만 사항이나 기타 데이터를 기반으로 사용자 환경을 조정하는 것과 같은, 보다 방어적인 프로젝트를 위해 이러한 리소스를 할당하는 것은 중요한 일이다. 그럼, 로드맵에서 어떻게 우선순위를 정해야 할까? 어떤 기준을 보고 결정해야 할까? 회사의 프로덕트를 관리하면서 아마도 정말 많은 곳에서 기능 및 수정, 업데이트 요청이 들어오게 될 것이다. 하지만 충성도 있는 고객의 요청이라고, 경영진의 요청이라고 모든 것을 우선순위를 높일 수는 없는데, 프로덕트를 업데이트 하는 방법과 시기 및 이유는 보다 전략적으로 생각하고 결정해야 한다.

우선순위를 위한 제안

로드맵에 포함될 만한 이니셔티브를 생각해볼 수 있는 제안사항은 아래와 같다.

- 팀 활동으로 접근하기: 우선순위는 팀에 대한 참여를 유도하며 다양한 관점으로 접근이 필요하다

- 우선순위 지정항목수 제한하기: 세부 정보 보다는 가장 큰 항목에 초점 맞추는 것이 필요하다.

- 이니셔티브를 전략적 테마로 분류/그룹핑하기: 고객에 대한 '만족도 향상'은 그룹화하기 좋은 방법이다.

- 우선순위 전 각 이니셔티브에 대한 고객가치 이해하기: 고객 가치는 의견보다 수집된 증거에 기반해야 할 것이다.

- 각 항목에 대한 대략적인 비용에 대한 측정에서 시작하기: 비용 또한 중요한 기준이 될 수 있다.

아래는 프로덕트 로드맵에서 제한된 리소스를 가지고 경쟁해야 하는 기능, 개선사항, 수정사항 및 기타 항목 중 많은 변수를 수량화 하는 방법들이다.

가치 vs. 복잡성

이 모델에서 비즈니스 가치와 구현해야할 상대적인 복잡성을 거ㅣ준으로 모든 기회를 평가해야 한다. PM의 대화를 바탕으로한 일반적인 접근 방식이라고 할 수 있는데, 많은 PM들은 매일 이러한 평가를 받게 된다. 아래 그림과 같이 매트릭스는 단순하다. 가장 높은 가치와 가장 낮은 노력을 가진 이니셔티브는 로드맵에서 낮은 성과에 해당될 것이다. 고객 영향을 위한 변수 추가를 포함, 사용자 고유의 목적으로 이 매트릭스를 수정해볼 수도 있겠다.

가중치 점수

가중치 점수를 활용하면 가치 vs. 복잡성 모델을 사용하면서 보다 객관적인 결과를 얻을 수도 있다.

아래 그림처럼 가중치 점수 방식을 활용하여 주요 기능의 순위를 정의하면 PM은 프로덕트 로드맵에 포함될 내용에 대해 보다 생산적인 논의를 진행할 수 있을 것이다. 궁극적으로 프로덕트의 결정에 들어가는 수 많은 입력요소들이 있지만 점수를 부여하는 모델은 팀이 객관적 대화를 하는데 도움이 될 수 있을 것이다.

카노모델

카노모델을 사용하면 기능이 고객에게 제공하는 즐거움 vs. 기능을 개선하기 위해 수행하는 잠재적인 투자를 렌즈를 통해 살펴볼 수 있다. 아래 그림에 나와있는 것 처럼 제품을 판매하기 위해 제품에 필요한 몇 가지 기본 기능들이 있고, 이러한 기능에 계속 투자한다고 고객 만족도가 크게 향상되지는 않는다. 투자함에 따라 만족도가 비례적으로 증가하는 몇 가지 기능이 있는데, 이를 한 눈에 볼 수 있도록 제공해준다. 정말 고객의 만족도를 높이기 위해서는 정말 흥미를 끌 수 있는 차별화된 요소의 기능이 필요해질 것이다.

기능 구매하기

이 모델은 고객 또는 이해관계자와 함께 일련의 잠재적 기능의 우선순위를 정하는데 사용할 수 있는 활동이다. 접근은 간단하지만 재미있는 방법이다. 잠재적인 기능을 나열하고 각 기능에 대해 '가격'을 할당하는 방법이다. 정해진 양의 현금을 나눠준 다움 참가자들에게 그 기능을 구입하도록 요청하는 방법이다. 어떤 사람들은 모든 돈을 그들이 열정을 가지고 있는 특정 기능에 쏟을 것이고 다른 사람들은 그들의 돈을 주변에 뿌릴 지도 모른다. 그 결과 기능들에 대한 우선순위가 정해지게 된다.

기회의 점수화

이는 결과중심 혁신에서 나온 분석의 한 유형인데, 자세한 설명 없이 중요도 vs.고객 만족에 따라 기회를 측정하고 순위를 정할 수 있다.

이를 위해 고객에게 각 기능의 중요성에 대한 점수를 준 다음 해당 기능에 대한 현재 만족도를 주도록 요청을 한다. 여기서 중요한 기회는 중요도는 높은데 만족도가 낮다고 표기된 영역이 될 것이다.

어피니티 그룹핑

아래 그림에도 설명된 어피니티 그룹핑은 재미있는 우선순위 작업이 될 수 있다. 아이디어는 간단한데, 모든 사람이 포스트잇 메모로 기회에 대한 브레인스토밍을 한 후, 유사한 항목을 그룹화한다. 이후 각 그룹의 이름을 지정하고 이를 통해 모든 사람들이 투표하거나 우선순위를 정하도록 한다.

스토리 매핑

스토리 매핑은 사용자 스토리를 구성하고 우선순위를 지정하여 MVP 문서화할 수 있는 좋은 방법 중 하나이다. 아래 그림과 같이 작업중심의 스토리카드를 먼저 만들고 이를 워크플로우로 그룹화하는 것이다. 이후 카드를 우선순위에 따라 정렬한다. 각 그룹에 대한 마지막 단계는 모든 스토리에 선을 그어 릴리즈/스프린트로 나누는 것이다.

기능 바구니(Bucket of Features)

새로운 기능, 향상된 기능, 사용성 문제 등에 대한 노력의 균형은 대부분 제품 및 조직의 목표에 따라 달라진다. 새로운 제품은 새로운 기능에 초점을 맞출 수 있고, 성숙한 제품은 새로운 시장에 대한 경험을 개선하는데 초점을 맞출 수 있다.

테마 작성 외에도 기능 바구니 모델을 활용하여 바구니에 백분율, 또는 가음과 같은 기타 가중지를 할당할 수도 있다.

- 핵심기능 향상

- 고객이 요청한 새로운 기능

- 버그 수정 및 UI개선

- 새로운 혁신적 기능 (고객 불만사항)

- 내부 이니셔티브

우선순위 전략의 '노력의 수준'에 주의하기

이전 섹션에서는 새로운 기능, 이니셔티브에 필요한 노력 수준에서 다양한 요소를 고려하는 중요성에 대한 논의였으며, 이를 통해 전반적 로드맵을 파악할 수 있었다. 사전 로드맵 단계에서는 새로운 이니셔티브를 추가하는데 필요한 '노력 수준'을 팀, 비즈니스 및 고객에게 필요한 모든 비용으로 폭넓게 생각할 수도 있다. 여기에는 구현 시간, 필요한 전문지식 수준, 금전적 비용 및 아마도 가장 중요한 다른 것을 구현할 수 없는 기회비용이 포함된다.

각 기능의 추가, 버그 수정에 대한 가치는 비즈니스 뿐 아니라 프로덕트에 대한 가치로 평가해야 한다. 하지만 모든 가능한 이니셔티브와 비교하여 구현비용 또한 고려해야 한다. 단순히 '이 기능 구현에는 오래걸리지 않아요'가 유용한 기능처럼 보일지라도 로드맵에 추가하기엔 충분한 정보는 아니다. 문맥과 전체 그림이 필요하다. 이 기능을 추가하면 로드맵에 포함되는 다른 기능들이 어떤 의미가 있는지 이해해야만 한다.

로드맵 우선순위 지정의 계획단계에서 '대규모 사업', '중간 노력', '단순 작업' 등의 범위로 그룹화 하는 것이 필요할 수 있다. 또는 앞에서 언급한 보다 표준적인 항목으로 '작은', '중간', 또는 '큰' 바구니(bucket)으로 그룹화할 수도 있다. 이후에는 한 걸음 뒤로 물러나 서로간의 관계에 있어 가능한 모든 이니셔티브를 볼 수도 있을 것이다. 그럼 높은 수준의 관점을 가지고 어떤 이니셔티브를 포함시키고 제외할 것인지 등, 우선순위를 지정하는 방법에 대한 현명한 의사결정을 내릴 수 있을 것이다.

'아니요'라고 말하기

훌륭한 PM들은 '아니요'라고 말한다. (응?) 회사 안팎의 이해관계자들은 지속적으로 많은 기능들을 요구할 것이며, 때로는 이러한 기능들이 합법적이고 논리적일 수도 있지만, 종종 제품의 비전과 회사의 목표에는 역행하는 또 다른 결과를 낳기도 한다.

쉽게 성공하는 것처럼 보이는 기능 요청을 받기도 할텐데, 이러한 기능들은 결국 이후 관리가 필요해지는 '프로덕트 부채' (보통 '기획부채'라고도 일컫는..)를 증가시킨다. 즉 각 기능에는 개발 뿐 아니라 QA, 운영, 문서화 및 기타 조직의 여러 영역에 대한 추가적인 작업이 필요하게 될 수 있다.

프로덕트 로드맵에 해당 기능을 포함시켜야 하는 정당한 이유는 명확한 기준을 통해 결정되어야 할 것이며 가장 중요한 기준은 프로덕트, 혹은 회사의 전략적 목표에 부합한다는 점일 것이다.

Reference

https://www.amazon.com/Product-Roadmaps-Relaunched-Direction-Uncertainty-ebook-dp-B076VX53K1/dp/B076VX53K1/ref=mt_other?_encoding=UTF8&me=&qid=

https://assets.productplan.com/content/Product-Roadmap-Guide-by-ProductPlan.pdf