Product Operation Framework
프로덕트를 만드는 과정을 한 눈에 훑어보기
데이터를 기반으로 프로덕트를 만들어가는 방법을 정리해보고 있습니다.
관련글
0. 프로덕트는 어떤 목적과 흐름으로 만들어 가야 할까?
1. Product Operation Framework
연간 계획에도 레벨이 필요하지 않을까?
우리는 서비스를 운영하면서, 매해 '연간계획' 혹은 '로드맵'을 작성합니다.
특히 대기업의 경우, 마치 매년 똑같은 바퀴를 돌듯 작년 대비 올해는 무엇을 할 것인지에 대해서 개선안을 반복적으로 작성하는 경우도 많죠. 큰 흐름에 대한 고민보다는 실무단의 프로젝트나 기능 단위의 고민에서 그치는 경우가 많았던 것 같습니다 (물론 이런 경우 대부분 리더십의 부재라고 생각합니다.)
저도 처음에는 매해 똑같은 연간계획 포멧을 불러와 올해에 필요하다고 생각되는 아이템들의 목록을 빼곡히 정리하는 데에만 몰두했었는데, 어느 순간, 프로덕트의 생애주기나 환경에 따라 계획의 계층이나 레벨이 달라져야 할 것 같다는 생각이 들었어요.
예를 들어, 작년과 올해에 목표가 '신규 가입자 유치 증대'라는 동일한 목표를 유지한다면, 단순히 올해 추진할 아이템을 고민하면 되겠지만, '피봇팅'이 올해의 목표라면 단순히 올 한 해의 계획보다는 장기적인 계획이 필요한 단계일 수 있는 것이죠. 이제와서 보니 너무나도 당연한 이야기이긴 합니다...
그래서 프로덕트를 운영함에 있어서 우리는 어떤 단계에 있고, 그 단계에서 어떤 주요 산출물을 만들어 가야 하는가에 대한 정의가 있으면 좋겠다는 생각을 했습니다. 물론 상황에 따라 항상 같은 프로세스는 아닐겁니다. 하지만, 백지에서 논의를 시작하기 보다는, 하나의 정리된 안이 있다면 그걸 변형해서 적용하는 것은 그리 어렵지 않을 거라 생각했어요.
우선 프로덕트 운영을 크게 4개의 Stage로 나눠보자
프로덕트가 성장하는 단계에 따라서, 우리는 다른 형태의 계획을 세워야만 합니다.
초기에는 러프하지만 더 큰 그림을 그려야 하고, 계획이 진행될수록 디테일한 밑그림을 그려가야만 할겁니다.
그래서 사업 계획을 세우는 초기부터, 스크럼을 진행하는 프로젝트 단계까지를 아래와 같이 4개의 레벨로 구분하고, 각 단계에 맞는 방법론들과 데이터 분석 방안을 정리해보기로 했습니다.
첫번째는 비즈니스의 콘셉트를 정의하는 Business Definition
다음은 전략을 구상하는 Roadmap
그리고, 하나의 기능 혹은 프로덕트를 완성해 가는 Feature
마지막으로 프로덕트를 만들어가는 최소단위인 Project
각각의 단계가 1회 혹은 여러번 반복되며, 상위 Stage를 구성하게 되는 구조입니다.
프레임워크를 시각적으로 정리함으로써 단계별 목표와 산출물에 대한 이해가 쉬워지고, 연차와 경험의 차이가 있더라도 동일한 눈높이에서 논의가 가능하게 됩니다.
누구나 머릿속에 다양한 프로세스들이나 구조가 있기 때문에, 어떤 기준이 있지 않으면 논의가 진행되기 어렵습니다. 어떤 사람에게는 로드맵이라는 단어가 '백로그'와 같은 의미로 인식되어 있기도 하고, 또 다른 사람에게는 '연간 계획'과 같은 의미로 사용되기도 하죠.
이렇게 시각적으로 구체화를 시켜놓고나면, 각 단어의 의미도 어느정도 예상이 가능해지고, 시각적으로도 이해가 쉬워집니다. 연차나 직군에 관계없이 우리가 지금 어떤 단계에 와있으며, 어떤 단계로 나아가기 위해서 무엇을 논의해야 하는지에 대해서 전제를 가지고 논의를 진행할 수 있게 되기 때문에, 생각의 전제를 효율적으로 맞춰 나갈 수 있다는 장점이 있는 것 같습니다.
만약 내용이 틀리더라도, 전체에 대한 그림이 있다면 생각에 차이를 이해하기가 훨씬 쉬워질 것 같습니다.
당신이 생각하는 프로덕트 운영의 프레임은 어떤 모습인가요?
다음 글부터는 프레임워크를 바탕으로 단계별 정의와 활용할 수 있는 방법론들을 정리해 나갈 생각입니다.
여러분들의 다양한 의견을 기다리고 있습니다.
부족한 부분이나 잘못된 부분에 대한 많은 의견 부탁 드립니다.
