오늘날의 애자일 환경에서 프로덕트 전략을 커뮤니케이션하는 것은 제품 라이프사이클의 고립된 단계로 생각해서는 안된다. 아래 이미지에서 볼 수 있듯이, 로드맵 작성에서 로드맵 공유, 계획 실행으로 깔끔하게 이동하는 것이 아니다. 프로세스는 반복적이며 커뮤니케이션은 모든 단계의 일부라고 생각할 수 있다.

성공적인 PM은 여러 가지 다른 제품의 피드백을 지속적으로 모니터링한다. 계획을 자주 변경할 수는 없으며, 전체적인 비전이 없는 투박한 프로덕트를 릴리지할 수도 있을 것이다. 혹은 너무 많은 사공으로 인해 중심을 잡기 힘들 때도 있을 것이다.

그렇다면 누구와, 언제, 그리고 무엇에 대해 이야기해야 할까? 여기서는 프로덕트 라이프사이클의 각 단계에서 이해관계자와 소통하는 방법을 다루고자 한다. 또한 로드맵에서 이해관계자의 동의를 확보하고 일반적인 커뮤니케이션의 함정을 방지하는 방법도 이야기해보고자 한다.

프로세스 전반에 걸쳐 이해 관계자와 소통

계획 (PLAN)

3장에서 언급했듯이, 프로덕트 전략의 방향을 파악하기 위해서는 경영진과 긴밀히 협력하는 것이 중요하다. 명확한 프로덕트 비전을 개발하고 회사에 가장 중요한 전략적 목표를 파악해야 한다. 회사의 측정 기준은 매출 증가, 고객 획득, 감소를 기준으로 할 수 있을 것이다.

로드맵을 고민해야 하는 부서와 이해 관계자가 비전과 전략적 목표에 대해 사전에 합의할 수만 있다면, 나중에 프로덕트 우선순위에 대한 혼란이 줄어들 것이다.

하이-레벨 로드맵을 사용하여 향후 계획 기간에 가장 중요하다고 판단한 몇 가지 주제에 대해 경영진에게 설명하여야 한다. 로드맵의 각 테마가 회사의 제품 비전에 부합하고 전략적 목표와 관련이 있는지 확인해보자.

계획 프로세스, 이 단계에서는 개별 기능의 우선 순위를 지정하거나 특정 마감일을 준수하지 않도록 해야한다. 날짜 없이 로드맵을 사용하는 것이 가장 효과적일 수 있으므로 커뮤니케이션은 전략적 수준을 유지할 수 있다. 경영진이 기능 요청 목록에 우선 순위를 매길 때 전략적인 비전을 놓치기가 너무 쉽다. 대신 잠재적인 기능이나 업데이트를 테마를 나타내는 버킷으로 구성하도록 하자. (필요에 따라 테마를 안팎으로 이동하지만 테마 자체는 그대로 유지)

우선순위 부여 (PRIORITIZE)

3장에서 논의한 바와 같이 전략적 목표에 합의하고 목표 달성에 도움이 될 일련의 테마를 식별한 후에는 해당 테마 내에서 특정 이니셔티브의 우선 순위를 지정할 수 있다. 엔지니어링, 영업, 마케팅, 고객지원 등에서 부서장들과의 열린 소통이 중요해지는 대목이다. 최우선 순위에 대해 논의하고 이러한 우선 순위가 여러분의 더 큰 주제와 전략적 목표에 어떻게 들어맞는지 함께 결정하자.

이해관계자와 협력하여 우선순위 결정

“PM으로써 Cross-Functional한 고민을 해왔을 것이다. 모든 사람들을 함께 논의할 수 있도록 조율해야 하고 그들에게 최우선 순위가 무엇인지 묻고, 우선순위를 정하고 점수를 정의할 수 있어야 한다.”

— Paul Ninefelt, Gentex PM

우선순위를 정의하는 프로세스에 이해관계자를 참여시킬 수 있다면 이해관계자가 같은 편에 설 가능성이 훨씬 높다. 체계적인 사고 과정을 사용하여 Effort vs. Value 모델과 같은 잠재적 이니셔티브를 평가할 수 있다. (3장 참조).

PM들은 종종 왜 특정 프로젝트가 다른 프로젝트보다 우선적으로 추진되는지에 대해 의문을 제기하는 이해관계자들은 어떻게 해야할지 고민을 할 수도 있을 것이다. 하지만 경험적으로, 제품 방향에 대한 혼란의 근본 원인은 이니셔티브의 우선 순위를 정하는 방법에 대한 투명성 부족인 경우들이 많다.

실행(EXECUTE)

전략적 목표를 반영하기 위해 이니셔티브의 우선순위를 정하고 로드맵에 무엇이 포함될 것인지에 대해 주요 이해관계자들 사이에 합의에 도달했다면 이제는 프로덕트 비전을 실행 가능한 단계로 전환해야 하며 지금 사용하는 로드맵이 더 상세해야 한다. 각 실행 과제들에 리소스를 할당하고, 과제들의 소유권을 다른 팀 구성원에게 할당하며, 릴리스 날짜를 지정한다.

개발 부서 내의 각 팀이 자신이 무엇을 하고 있는지 알고 프로젝트가 어떻게 전체적인 상황에 기여하는지 이해할 수 있어야 한다. 상위레벨의 논의에서 활용되는 로드맵보다 여러 개의 로드맵을 사용할 때는 색상 코드와 태그가 일치하는지 확인해보도록 하자.

출시(RELEASE)

계획이 결정되고 실행이 되면 조직의 모든 이해관계자들이 동일한 입장에 있는지 확인하는 것이 중요하다. 영업, 마케팅, 고객지원 등과의 미팅을 통해 이후 논의 내용에 대해서 설명하도록 하자.

고객지원팀에 내용을 저달 할 때는 구체적인 로드맵 보다는 상위 로드맵으로 설명, 마케팅팀인 경우엔 새로운 제품, 기능세트의 포지셔닝을 이해할 수 있도록 전달하고 영업팀의 경우 어떻게 프로덕트가 고객의 문제를 해결할 것인지 이해할 수 있도록 해야 한다.

큰 조직일 수록 이러한 부서의 모든 직원을 포함하는 것은 논리적으로 훨씬 어렵지만 각 부서에 정보를 반드시 전달해야 한다.

이메일로 공유하기 보다는 클라우드 서비스에 로드맵을 구축하고 저장함으로써 각 팀들이 언제든지 확인하고 계획을 상기시킬 수 있도록 하는 것이 중요하다. 이는 이해관계자들이 ‘몰랐었다’는 핑계를 최대한 줄여줄 수 있을 것이다.

로드맵에 이해관계자를 참여시키기 위한 전략

PM은 다양한 청중들에게 로드맵을 제시할 수 있어야 한다. 경영진인 경우 아마도 그들이 전략에 참여하도록 하거나 계획을 승인하는 것이 목표가 될 것이다. 만약 경영진이 아니라면 제품의 방향을 전달하고 합의를 형성하는 것이 목표가 될 것이다.

두 경우 모두 명확하고 설득력이 있어야 하며 많은 준비들이 필요하며 아래 몇 가지 팁을 참고해보도록 하자.

미리 준비하기 : 로드맵을 공유하기 위해서는 단순히 문서를 만드는 것 만으로는 충분하지 않다. 설득력을 가지기 위해 로드맵 안에 모든 주요과제들이 해당 일정에 진행될 필요가 있음을 정당화할 수 있도록 하자.

프레젠테이션 구성하기 : 로드맵을 구축하는 방법과 마찬가지로, 좋은 프레젠테이션은 전체적인 그림에서 시작하여 세부적인 내용으로 좁혀질 것이다. “왜, 어떻게, 무엇을” 프레임워크를 활용하자. 전략적 목표를 공유하는 “이유”부터 시작하여 “방법”과 “무엇”에 대한 보다 자세한 설명을 시작할 수 있도록 하자.

간결하게 하기 : 로드맵을 간결하게 전달할 수 없다면 애초에 충분히 명확한 제품 전략이 정의되지 않은 것일 수도 있다. 프레젠테이션의 요점을 명확하게 하고 중언부언 말이 많은 프레젠테이션 슬라이드를 피하고 발표 시 커뮤니케이션을 명확하고 직접적으로 하자.

반대 예상하기 : 일부 과제들이 다른 과제들보다 우선적으로 추진되는 이유와 그에 대한 우려에 대응할 준비가 필요하다. 이는 다시 마켓에 대한 엄격한 우선순위 프레임워크를 사용하는 것으로 돌아가야 할 수 있다. (본능에 기반한 것이 아니라) 명확한 데이터 중심적이라면 이해관계자에게 우선순위를 정당화하는 데 문제가 없을 것이다.

구체적 사례 제시하기 : 구체적인 사례는 설득력 있는 무기에서 가장 강력한 도구 중 일부이다. 고객에게 어떤 혜택을 주거나 문제를 해결할 수 있는지를 설명할 수 있으며 해당 기능이 고객의 만족도를 높일지 등에 대해서 유저 리서치를 인용하거나 데이터 분석의 결과를 공유하도록 하자.

청중 파악하기 : 청중을 아는 것은 모든 종류의 의사소통의 핵심 원칙이며 로드맵도 예외가 아니다. 경영진에게 전략적 목표를 제시하는 등 상향식 커뮤니케이션은 개발자에게 구체적인 계획을 제시하는 등 하향식 커뮤니케이션과는 매우 다른 프로토콜을 따를 수 밖에 없다.

세부 정보 조정하기 : 경영진과 대면하는 로드맵에서는 높은 수준의 주제와 전략적 목표에 초점을 맞추고 마켓, 고객 데이터 및 신규 프로젝트에 대한 잠재적인 투자 수익에 대해 논의해야 한다. 그 외 조직에서는 로드맵을 이론적인 것에서 실행 가능한 로드맵으로 전환해야 하는데, 개발 로드맵의 경우엔 특정 작업, 요구사항 및 마감일을 전달할 수 있어야 한다.

적절한 언어 사용하기 : 로드맵에서 사용하는 언어는 해당 언어를 볼 사용자에게 적합해야 한다. 로드맵을 공유해야하는 청중이 다양한 도메인에 속한다면 일반인 용어를 사용하고 과제에 대해 구체적으로 설명이 필요할 것이다. 넓게 배포될 로드맵에서는 업계 외부에서 일반적으로 알려지지 않은 약어나 약어, 전문 용어나 유행어를 사용하지 말자.

상황 공유하기

로드맵은 일반적으로 회사의 높은 수준의 전략을 전달해야 하지만, 이해관계자와 만날 때는 구체적인 세부사항과 마감일에 대한 논의가 이루어질 수 밖에 없다.

임원들은 현재 프로젝트의 상태, 리소스 할당 방식 등에 따라 해당 프로젝트의 상태가 어떻게 될 것인지 알고 싶어할 것이고 이해관계자들은 새로운 기능이 출시되는데 까지 얼마나 걸릴지 등에 대한 구체적인 사항을 알고 싶어할 것이다. 하지만 로드맵은 궁극적으로 전략을 구체화하는데 도움이 될 내용들을 담고 있고 정확한 일정을 조율하는데 있어 중요한 발판이 될 수 있다.

로드맵에 각 주요 과제들의 “완료된 비율” 포함하기

세부 사항으로 깊게 들어가기 보단 각 주요과제들의 완료상태 정도를 로드맵에 포함해보자.

예를 들어, 청구 페이지의 재설계가 60% 완료되고 새 계정 관리 시스템의 시작이 30% 완료되었을 수 있는데, 로드맵에 이러한 정보를 제공하면 과제들이 서로 어떻게 의존하는지, 리소스를 이동하거나 프로젝트의 우선순위를 재조정하여 추진할 수 있는 방법에 대한 중요한 대화를 시작할 수 있을 것이다.

상태별로 주요 과제 필터링하기

또 다른 일반적인 접근 방식은 태그 지정 또는 컬러 코딩 시스템을 사용하여 로드맵을 복잡하게 만들지 않고 각 이니셔티브의 상태에 대한 정보를 계층화하는 것이다. 예를 들어 색상표 또는 태그를 통해 계획, 승인, 개발 중 및 완료된 이니셔티브를 서로 구분하도록 선택할 수 있습니다. 또한 이러한 변수를 따라 로드맵을 필터링하여 완료 상태에 따라 고유한 뷰를 작성하여 이해 관계자가 모든 것이 무엇인지 명확하게 파악할 수 있도록 할 수 있다.

이전 버전의 로드맵 보관하기

마지막으로, 수년 전의 로드맵뿐만 아니라 초기 버전의 로드맵도 저장해야 한다. 이전 로드맵의 아카이브를 작성하면 어떤 과제들이 완료되었는지, 지연되었는지, 연기되었는지, 또는 취소되었는지 쉽게 추적할 수 있다. 또한 이 데이터베이스를 사용하여 시간이 지남에 따라 전략이 어떻게 변경되었는지 분석할 수 있으며, 잘못될 경우 오프코스로 유도한 결정을 더 잘 식별하고 수정할 수 있습니다.

시각 자료 활용하기

사람들은 듣는 것의 극히 일부만 기억하기 때문에 시청자들의 관심을 유지하고 주요 요점을 기억에 남기기 위해서는 시각적인 도움이 매우 중요하다. 시각자료는 새로운 정보를 제시하는 것이 아니라 구두로 말하는 것을 보완하고 명확하게 해야 한다.

필수적인 단어 사용 : 과제들을 설명하기 위해 짧은 제목과 설명을 적고, 크고 쉽게 읽을 수 있는지 확인해보자. 텍스트를 더 많이 추가할수록 읽을 가능성이 적을 수 밖에 없다.

색상표 통합 : 색상표를 사용하여 이니셔티브가 서로 어떻게 관련되어 있는지, 더 큰 전략적 목표와 어떻게 관련되어 있는지 보여줄 수 있다. 사람들이 색상이 무엇을 나타내는지 쉽게 볼 수 있도록 범례를 포함하고, 컬러를 활용해 명확하게 구분하자.

공통 커뮤니케이션의 함정

사업부서의 수익성을 위한 기능 요청

최근의 판매 전망이나 최근 손실된 판매에 근거하여 제품 결정을 내리는 것은 필요해보일 수 있지만, 이것은 전략적인 접근법이 아니다. 잠재적인 고객은 비즈니스 목표, 제품 비전 또는 시장에서의 회사의 포지셔닝을 알지 못한다. 고객이 요청하는 모든 것 또한 구현할 수 없을 것이고 이러한 전략은 프로덕트의 핵심기능을 희석시키고 포지셔닝을 애매하게 만들 것이다. 세일즈를 통한, 사업부문의 전략에만 집중하는 것은 근시안적인 접근 방법이다. 성공적 기업은 전략적으로 생각하고 장기적으로 계획한다.

판매부서를 통해 기능을 요청받을 때 또 다른 문제는 고객의 니즈라고 할지라도 고객이 핵심 문제의 근본을 파악하지 못하는 기능을 요청하는 경우가 많다는 점이다. 문제는 다양한 방법으로 해결할 수 있고 PM은 관리자로서 테이블에 올려 논의할 수 있는 내용일 것이다. 영업은 잠재적인 제품 아이디어를 위한 중요한 채널 중 하나이며, 중요하지만 우선 순위 결정 프로세스에서 의사결정을 하는 유일한 대화가 되어서는 안 될 것이다.

목적을 이해하지 못하고 진행되는 개발

또 다른 공통적인 의사소통의 함정은 개발 측면에서 회사의 전략적 방향을 이해하지 못하는 경우들 또한 흔히 볼 수 있다. 다시말해, 일반적으로 개발자들이 왜 지금 이것을 만들고 있는지 이해하지 못한다는 말을 듣는다.

PM으로써 개발자가 전체적인 상황을 파악하고 자체 개발 사일로에 갇혀 있지 않도록 하는 것이 PM의 의무 중 하나이다. 단기 개발 로드맵을 만들면 이러한 커뮤니케이션 격차를 극복하는 데 도움이 될 수 있을 것이다.

영업팀과 고객관리팀에 불필요한 정보의 공유

마지막으로, 영업팀 및 기타 고객관리팀과 로드맵 세부 정보를 과도하게 공유하지 않도록 하는 것 또한 중요하다. 영업부서가 잠재적 고객에게 기능을 공개하였으나 해당 기능이 연기되거나 취소되면 심각한 커뮤니케이션 이슈가 발생할 수도 있고, 그 결과 고객들은 불만을 품고 떠날 수도 있을 것이다. 유망한 미래에 대해 이야기하고 싶을 수는 있겠지만 고객과의 약속을 지키지 못하는 경우 더 큰 리스크가 존재하게 될 것이다.

특히 고객과 상호작용하는 팀에게 로드맵을 제시할 경우엔 특정 날짜를 생략하는 것이 필요할 수 있다. 아직 논의 중인 주요과제들인 경우 로드맵에서는 제외하는 것이 좋을 것이다.

Reference

Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty 1st Edition, Kindle Edition

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

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