어떻게 제품을 개선해야할까?
Product 개선 프레임워크 소개
서론
현재 제가 다니고 있는 회사의 PM 분들은 약 20~30분 정도 계신다. 그 분들의 PRD/기획서 등을 보면 각자 업무를 하는 방식이 정형화되어 있는 것이 보인다.
나 또한 다양한 라이프 사이클 단계에 있던 프로덕의 PM으로 일하면서 여러 시행착오를 통해 제품을 개선하고 관리하기 위한 프레임워크가 생기게 되어서 오늘 이 글을 통해서 소개해보려고 한다.
우선 프레임워크의 정의에 대해서 살펴보면
“프레임워크는 어떠한 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조를 의미한다.”
정의를 보면, 뭔가 PM의 업무와 매우 유사하다. PM/PO는 제품의 성공을 위해, 복잡하게 얽혀있는 문제를 해결하는 고민을 하는 사람이다.
이처럼 프레임워크는 어쩌면 PM에게 당연히 있어야할 방식일 수 있다. 때로는 너무 구조를 따라서 유연성을 잃어서는 안되겠지만 적어도 여러 번의 수정을 통해 안정적으로 변화한 프레임워크는 때로는 팀원들의 심리적 안정감을 느끼게 해줄 수도 있다.
볼때마다 바뀌는 문서양식을 보는 개발자, 디자이너는 피로할 수밖에 없다...
프레임 워크 소개
서론이 길었고, 현재 내가 작성한 프로덕 개선 프레임워크는 아래와 같은 방식으로 이루어져있다.
프레임워크의 전체 단계는 위와 같고 이 중에서 주요하게 설명이 필요한 것들만 아래와 같이 풀어서 정리해두었습니다.
1. 문제 발견 & 딥다이브
보통 특정 팀의 PM이 되면 어느정도 표면적으로 제품의 문제가 정의된 경우가 많다. 이 경우에는 가장 큰 문제를 정하고 바로 PRD를 작성하고 팀원들과 PRD에서 문제/가설/해결책/주요지표/실험 등을 모두 싱크를 맞추는 과정을 가집니다.
그 과정에서, 솔루션(기능)에 대한 논의가 주도적으로 이어질 수밖에 없고 문제에 대한 논의는 상대적으로 시간이 부족할 수 있다. 이렇게 기능 중심으로 얘기하고 개발하다보면 이후에 배포하고 나서, 우리가 이걸 왜했지? 이게 정말 필요한 기능이었나?라는 생각이 들때가 있다. 또한 문제를 해결하기 위한 기능만 넣는 것이 아니라 있으면 좋은 기능들을 막 넣는 경우가 생겨난다.
또한 논의하다보면 문제에 공감, 싱크가 안될 수 있는데 이렇게 되면 PM은 밤새 열심히 생각해온 솔루션(구체적으로 화면 기획까지 하는 경우도 있음)은 결국 논의도 되지 않고 회의가 산으로 가며 끝나는 경우가 많습니다.
(보통 이러면, 다음 미팅때 PM이 다시 준비해올게요 하고 끝난다...)
이런 경우를 발생하기 위해서 이 프레임워크에서는 문제 발견 & 딥다이브를 통해 우선적으로 싱크를 맞추는데 집중하고 팀원들과도 이에 대해서 많은 시간을 보냅니다.
이렇게 문제에 대해서 깊게 논의를 하고 파헤치다보면 자연스럽게 팀원들은 문제에 대해 공감하게 되고, 누구나 쉽게 아이디어를 낼 수 있습니다.
사실 PM이라고 해서 아이디어를 더 잘 내는 것은 아닌데, PRD를 작성하는 과정에서 PM이 아이디어를 낼 수밖에 없는 구조가 되면서 결국 더 다양한 아이디어가 나올 수 없는 상황이 발생합니다.
이렇게 문제에 대해서 모두 싱크가 되면 모든 의사결정과 새로운 스펙 추가는 오로지 “문제를 해결하는가”를 기준으로 할 수 있게 되면서 이후 프로세스에 속도를 붙일 수 있게 됩니다.
나같은 경우에는 노션을 문서화 도구로 사용하는데, 노션 데이터베이스로 "Problem"이라는 DB를 만들고 이렇게 논의나눈 문제들을 문서로 별도로 만든다.
2. 지표 선정
앞에서 우리가 어떤 문제를 해결하기로 결정하고 아이데이션을 하기 시작하면 정작 그 문제를 해결하는 것과 관계없는 아이디어가 나오거나, 이게 진짜 문제가 많아요? 하는 논의가 길어질 때가 있다.
그래서 문제가 정해지고 난 이후에는 이 문제를 해결했다고 측정할 수 있는 지표를 선정하는 시간을 가진다. 이 지표가 정해지면 이 후의 프로세스에서 우리의 의사결정 기준은 이 지표를 높일 수 있을까요?로 치환된다.
3. 가설 발산 & 수렴
다음은 가설을 발산하고 수렴하는 과정입니다. 문제와 지표가 명확해졌기 때문에, 팀원들 누구나 가설을 작성할 수 있도록 가설 모음 페이지를 노션에 만들어둡니다.(주로 노션 데이터 베이스로 hypothesis 테이블을 만들어둡니다.)
이 때 여러 가설들간의 비교를 위해 주로 템플릿을 만들어두고 최대한 그에 맞춰서 작성할 수 있도록 합니다.
템플릿 구성은 아래와 같이 세가지가 구성되어 있다.
4. 임팩트 측정 & Task 선정
이렇게 각 가설들에 대해서 논의가 끝나면 이제 실제로 각 가설들이 어느정도 Impact를 낼 수 있는지 측정하는 과정이 필요하다.
이는 사실 각 팀, 제품마다 다르고 경험적으로 선정하는 경우가 많다. 비슷한 실험을 했을 때 이 정도 올랐으니 유사하게 오를 것이다. 이 기능이 없었을 때 이탈율이 이정도이니까 이 기능을 넣으면 그 이탈이 전환으로 바뀔것이다와 같이 다양한 게스티메이션이 요구된다. 이건 제품에 대한 이해도가 높아지고, 팀이 이터레이션을 돌면서 정확해지는 것 같다.
이후에는 그 impact 기준으로 task를 선정한다.
5. 실험 & 이터레이션
이제 실험 단계이다. 보통 나는 간단한 task(A/B 테스트 수준의 작업)인 경우에는 실험 문서, 큰 프로덕의 경우에는 PRD를 작성하는데 이 두개 모두 작성해야하는 양식은 거의 비슷하다.
(why) 이 작업이 왜 필요한가? -> 1.문제 딥다이브에서 정해진 문제에 대한 설명 문서로 대체
(what) 어떤 기능을 만드나요? -> 3. 가설 문서의 Action(A를 B로 바꾸면)을 구체화
(metric) 어떻게 성공했음을 알 수 있나요? -> 2. 가설 문서에서 정의된 지표와 목표치로 대체
1번 과정인 문제 발견 & 딥다이브가 정해지면 사실 가설을 계속 세우고 반복하면서 점점 그동안 세운 가설들의 임팩트도 더 정확히 높여나갈 수 있고, 문제를 해결해나가고 있는지 확인할 수 있다.
프레임워크의 장단점
장점 : 사실 문제를 해결하는 것이 중요하기 때문에, 문제 싱크에 많은 시간을 보내고 팀원들도 문제에 공감한 채로 일을 할 수 있다. 목적조직에 적합한 방식이다. 누구나 쉽게 아이디어를 낼 수 있고 내 아이디어가 반영될 수 있는 경험을 할 수 있다.
단점 : 기능조직으로 이루어진 조직에서는 사실 문제에 공감하는 것이 크게 중요하지 않을 수 있다. 무엇보다 빠르게 실행이 중요하기 때문에 이 방법이 맞지 않을 수 있다. 문제가 복잡하게 얽혀있지 않거나 작은 경우에는 사실 한번에 PRD를 작성해버리는게 더 간단할 수 있다.
끝으로, 모든 문제를 해결하는 은탄환은 없다. 결국은 각자 상황에서 각자의 해결책을 찾아야한다. 이 프레임워크는 목적조직의 동기부여와 효과적인 문제 정의 방식, 모두가 아이디어를 낼 수 있는 문화를 만들고 싶은 팀에게는 적합한 방식인 것 같다.
간단하게 프레임워크를 소개하는 내용을 썼다. 현재 나도 계속 시행착오를 통해 프레임워크를 가다듬고 있는 단계이기 때문에 이 글도 아마 지속적으로 업데이트되지 않을까 싶다.
