1편 글
https://nevermind22.tistory.com/27
P.M Must Read 03 : THE GO PRODUCT ROADMAP vol.01
들어가기 전 처음 프로덕트 로드맵이란 단어를 접한건 프로덕트 전략에 대해 공부할 때 이다. 이때 너무나 많은 로드맵 방식이 있어 어떻게 접근해야 할지 몰라 주먹구구 식으로 접근한 적이 많
nevermind22.tistory.com
이상적인 프로덕트 목표를 찾는 올바른 방법은 제품전략으로부터 시작해 유저, 고객, 제품목표까지 세부적이고 구체적이며 측정가능한 목표로 나눌 수 있는지 스스로에게 물어보는 것 에서부터 시작한다. 새롭게 만들어진 목표가 프로덕트를 발전시킬 수 있는 의미 있는 가설을 가지고 있는지 확인해야 하며 이때 여러가지 목표를 세우는 것이 아닌 하나의 목표에 집중해야 한다. 이런 방식은 명확하고 일관되며 진행사항을 추적, 이를 달성했는지를 알 수 있다.
하지만 간과하지 말아야 할 것이 있다. 목표를 설정하는 것은 매우 중요하지만 실제 프로젝트 에서 이해관계자, 개발팀을 위해 내부 로드맵을 만든다면, 날짜, 데드라인과 같은 것들이 더욱 중요해 질 수 있다 (1행, DATE에 관련된 이야기)
예를 들어 새로운 게임을 런칭해야 하는 상황이다. 이런 게임은 보통 휴일에 플레이가 많이 되기 때문에 크리스마스 시즌과 같은 연휴에 런칭하는 것이 원하는 가치를 달성하는데 있어 가장 중요한 요소가 될 것이다. (데드라인은 꼭 들어가야 한다)
이를 반영하여 템플릿에 언제 아웃풋이 나와야 하는지를 설명할 수 있는 행이 있다.
만약 이 템플릿을 가지고 외부 고객을 만나야 하는 경우 간단히 해당 행을 제거해 미팅에 가져가면 된다 (내부 정보 유출 방지)
2번째 행은 새로운 서비스의 이름, 버전을 적으면 된다
예를들어 IOS 14, Window 10 과 같은 이름들이 아니라, 젤리빈(Android 4.1), 마시멜로(Android 6.0) 과 같은 이름들이 더 창의적일 것이다 (난 공대감성 좋은데..)
4번째 행의 경우 목표 달성을 위해 필요한 제품의 기능에 해당한다. 기능은 목표로 가기 위한 수단이지 그 자체가 목표가 되어서는 안된다. 이때 주의해야 할 것은 목표와 마찬가지로 기능 또한 많아서는 안된다 1개의 목표에 3개의 기능이 적당하며 5개를 넘어가면 안된다. 그렇기에 제품의 기능은 너무 디테일 해선 안된다. 프로덕트 로드맵은 고차원의 계획이며 앞서 말한 디테일한 기능들은 백로그에 적으면 된다. 에픽, 유저스토리는 로드맵에 포함되지 않습니다.
마지막 행은 metric이다. 이런 수치는 목표가 달성되었는지를 확인할 수 있다. 이런 metric은 프로덕트 목표를 확인가능하고 측정 가능하게 만들어준다. 그럼 이러한 수치들(KPI)은 어떻게 설정이 되는가. 서비스 런칭 이후 목표를 달성하기 위해 얼마나 시간이 걸리는 지를 확인해야 한다.
예를 들어 여러분의 목표가 5-10%의 유저를 새롭게 유치하는 거라면 이를 달성하기 위해 몇일, 혹은 몇 주가 걸릴 수 있다.
(해당하는 부분은 이후 KPI 설정과 관련하여 더 디테일 하게 다루고자 합니다, 지금의 설명으로는 저 스스로도 이해가 잘 안 되고 있네요.. 부족한 번역 읽어주셔서 감사합니다)
'기획 공부' 카테고리의 다른 글
P.M Must Read 03 : THE GO PRODUCT ROADMAP vol.01 (0) | 2024.03.03 |
---|---|
P.M Must Read 02 : How to Hire a Product Manager vol.02 (0) | 2024.02.25 |
P.M Must Read 02 : How to Hire a Product Manager vol.01 (1) | 2024.02.11 |
P.M Must Read 01 : ROMAN’S PRODUCT STRATEGY MODEL vol.02 (0) | 2024.02.05 |
P.M Must Read 01 : ROMAN’S PRODUCT STRATEGY MODEL vol.01 (2) | 2024.01.29 |