Product Management 프레임워크
목표, 전략, 실행의 틀
백그라운드
어느날 Product 전략이나 로드맵을 작성해야하는 미션이 생기면, 무엇을/어떻게/어디서부터 정리하는 건지 막막하다. 해본적도 없고 참고할 문서를 찾기도 쉽지 않으며, 회사마다 상황과 맥락이 너무도 다르기때문에, 한두번 경험해보았어도 여전히 까다롭다. 최근에 스타트업 컨설팅을 진행하면서, Product 전략과 로드맵에 대한 자료들을서치하고 정리할 기회가 생겼다. 전략이나 로드맵이 어느날 하늘에서 뚝 떨어지는게 아니다보니, 관련된 내용을 차근차근 정리하고 구조화해보았다. 1) Product Management 전반의 Framework를 다시 세워보게 되었고, 그중에서도 2) Product 전략과 로드맵에 대한 구조화 방법들을 탐색하게 되었다. 이번 글에서는 Product Management Framework에 대한 개요를 정의하고, 이어서 Product 전략과 로드맵에 대해서는 각각 별도로 정리하였다(그외 영역에 대해서는 후순위로 정리할 예정)
먼저, Framework가 왜 필요한가?
프레임워크라는 용어를 한번 쯤은 들어봤을것이다(소프트웨어 개발자들은 익숙한) 네이버에 검색해보면 "어떤 일에 대한 판단이나 결정 따위를 위한 틀"이라고 하는데, 쉽게 말하면 "뼈대""구조"라고 할수 있겠다.
모델/방법론과는 차이가 있지만, 넓은 범위로 구조화된 틀을 활용하는 방법들을 통칭해 프레임워크라고 정의해보자. 프레임워크는 Product Management와 관련해서도 여러가지 예를 들수 있다. 사업모델을 정의할때는 Business Model Canvas , 경쟁우위를 비교할때는 SWOT / 3C, 애자일 방법론을 도입할때는 Scrum / Kanban, 우선순위를 정할때는 MosCow/Ice 등등..
프레임워크는 아래와 같은 Benefit을 준다
새로운 관점/생각의틀을 제공한다: 잘 모르는 분야, 정리가 필요한 대상에 대한 관점/생각의 틀을 제공한다. 예를들어 우선순위를 정할때 무슨기준으로 어떻게 정리 할수 있지? 라고 할때 MosCow / Ice 등은 훌륭한 "렌즈"를 제공한다. 제대로된 렌즈를 끼면 세부내용을 체계적으로 이해하고 정리 할 수 있다.
효율적이다: 프레임워크는 구조화된 "틀"이기 때문에, 틀에 넣어 빠르게 생각을 정리할 수 있다. 그리고 보통은 하나의 주제에 여러가지 대체가능한 프레임워크가 있기 때문에 비교해가면서 상황에 맞게 선택하거나 응용할 수 있다.
설득력을 높인다: 알려진 프레임워크들은 여러 사람에게 검증된 틀이기 때문에 대체로 완성도가 높고 논리적이다. 그리고 관련 정보와 사례를 쉽게 찾아볼수 있어서 접근성과 이해가능성이 높다.
Product Management Framework
경험과 스터디를 바탕으로 정리해본 Product Management의 Framework이다. Product Management 체계를 처음 설정하고 고민하거나, 현재 내가 속한 Product 조직의 현황을 진단할때 활용할수 있겠다. 짧게 부연설명을 하자면, Product Management Framework에는 크게 목표/전략/실행이라는 세가지 축이 있고, 세 축의 각 항목들은 유기적으로 작동한다. 세 축에 대해 간단히 설명하면 아래와 같다.
1) 목표
회사와 Product가 달성하고자 하는 수준이다. 조직이 OKR을 적용하고 있다면, 우리 제품을 통해 이루고자 하는 목적(Objective)과 그것을 측정하는 핵심적인 결과(Key Result)로 구성할 수 있겠다.
1년이상의 중장기적인 목표는 [Product Stategy]와 맞춰나가며, 1년이내 목표는 [Product Roadmap]과 유기적으로 설계된다. 월/분기 단위로 목표 결과를 리뷰하고 앞으로의 계획을 설정한다. 이는 Product 로드맵에 반영된다.
2) 전략
목표를 달성하기 위한 "설계"이다. 무엇에 집중하고 무엇은 하지 않고, 어떤 차별화와 해자를 만들어 성과(고객 창출, 매출 등)를 만들것인지에 대한 설계/시나리오이다.
목표달성을 위해 전략과 로드맵을 계속 만들어나가되, Product를 통해 궁극적으로 이루고자 하는 비전과 미션은 변하지 않아야할 기준점이 되어야한다.
3) 실행
Product 원칙과 프로세스를 지키면서, Product 로드맵과 백로그 계획에 따라 Product를 검증하고 고객에게 Deliver하는 일이다.
목표 달성을 위해 실행할 Theme를 설정하고, 실험을 통해 지속적으로 검증한다. 검증을 통해 실제 제품으로 온전하게 만들어갈 "할일"은 백로그가 되어 실행된다.
그 중에서도, 왜 좋은 Product 전략/로드맵은 드문가?
1) 구조적 한계
첫번째 이유는 조직이 단기 목표달성에 집중하게 되는 경향이다. 아무래도 월/분기 등 단기적인 목표 달성을 위해 필요한 과업들을 실행하다보면, Product 전략과 로드맵을 충분히 고려하기 힘들다. 이러다보면 장기계획과 단기 실행이 뒤죽박죽이 되거나, 위키에 문서로만 존재하는 사장된 전략/로드맵이 된다.
또한 실행 체계와 유기적으로 연결되어야하는데, 이는 복잡하고 난이도 높은 Management 과업이다. 전략과 로드맵이 뜬구름 잡는 소설되지 않으려면 권한/역량/정보가 있는 사람이 주기적으로 목표-실행과 연결을 해야하는데, 이는 조직구조를 뛰어넘고 체계적인 인터페이스를 만들어야만 가능한 일이다.
2) 경험과 인사이트 부족
경험의 부족: Product Manager가 Product 전략과 로드맵에 대해 깊이 고민하고 경험하는건 드물다. 전략이나 로드맵은 대부분 경영자나 비즈니스 조직에서 정하는 경우가 많다. 혹은 최상위 Product Leader의 고유한 영역이다. 운좋게 이전에 경험이 있거나 혹은 타고난 탤런트가 뛰어난 PM이 있다면 괜찮지만, 일반적인 Product 조직에서는 그런 Product Manager가 존재하는 일은 매우 드물다.
인사이트의 부족: Product 전략과 로드맵을 어떻게 다루면 되는지 이해했다고 하더라도, 실제 유효한 구성을 하려면 충분한 인사이트가 제공되어야한다. 시장과 고객의 인사이트를 공할 수 있는 환경이되거나, 아니면 시니어 Product Manager들이 그러한 인사이트를 수집할 충분한 시간이 주어져야한다(아니면 엄청 스마트한 누군가가 있거나)
이러한 구조적인 한계와 경험/인사이트 부족의 문제를 극복하는데 도움이 되는 것중 하나는, Product Manager가 좋은 Framework를 활용하는 것이라고 생각한다(물론 가장 좋은 건 뛰어난 Product Manager를 채용하는 것이겠지만) 그리고 이를 가능하게 하려면, Product Manager가 전략과 로드맵을 설계하기 위한 충분한 시간/역량/권한/의지가 있어야 한다.
Product Manager가 참고할만한 전략과 로드맵 프레임워크
Product 전략과 로드맵에 대한 기본적인 이해와 참고할만한 프레임워크들을 아래 글에서 소개한다.
