🐋 4시간으로 끝내는 스프린트 기획
PMF를 찾거나 특정 지표를 개선하는데 "스프린트"의 개념이 많이 적용되고 있다. 스프린트는 반복적인 개발 주기로 이터레이트(iterate)하며, 정해진 기간동안 팀원들은 단거리 전력질주(sprint)하듯 자신이 맡은 업무를 수행하는 것을 뜻한다. 오늘 글에서는 스프린트에서 기획을 효율적으로 진행할 수 있는 기획 프로세스에 대해 이야기해보고자 한다.
도움 받은 자료들
우선 우리는 더벤처스 스프린트에서 엄청난 도움을 받았다. 이 프로덕트를 만든 @이한길 심사역님은 천재시다. 아이디어를 빠르게 검증해볼 수 있는 좋은 시스템을 구축해주셔서 이를 기반으로 우리의 것을 직접 만들 수 있었다.
그리고 유명한 PMF 맛집 YC에서 다양한 리소스를 참고하였다. 우선 David Rusenko의 How To Find Product Market Fit에서 iteration의 큰 그림과 각 단계별로 유의해야 할 점을 상세하게 확인해볼 수 있다. 그리고 Michael Seibel의 Building Product에서 PMF를 찾기까지의 과정과 우리가 가져야 하는 마인드셋에 대해 자세하게 이야기해준다.
0단계: BASICS
기획을 진행하기 전에 다음 세 가지를 팀원들과 공유하고 기억해야 한다.
- 서비스 장기 목표
- 서비스 타겟군
- OMTM
기획의 목적은 단기적으로는 OMTM을 개선하기 위함이고, 중장기적으로는 장기 목표를 달성하고자 함이다. 또한 이 모든 개선과 목표 달성의 배경에는 우리를 필요로 하는 서비스 타겟군이 있다. 이 타겟군을 위한 기획을 해야 한다. 따라서 이 세 가지는 항상, 꼭 기억하고 기획 진행 시 지속적으로 확인할 필요가 있다.
우리 팀의 것을 예시로 보이자면 미라클나잇의 서비스 장기 목표는 "세계 최고 수준의 수면 경험을 제공한다"이고, 타겟군은 "고효율 수면에 높은 관심이 있는 갓생러들"이고 OMTM은 "NDS"라는 만족도 조사 지표이다.
1단계: 데이터 공유
30분 소요
우선 지금까지 누적된 데이터의 상태를 본다. 우리가 설정한 KPI들이 성장/유지/하락하고 있는지 확인하고, 놓치고 있었던 유의미한 인사이트들을 공유한다. 이전에 진행한 User Test/Interview에서 참고하여 분석된 정성 데이터도 함께 확인한다. 여기서 포인트는 우리 서비스의 현황을 최대한 객관적으로 파악해야 한다는 것이다.
2단계: How Might We 작업
30분 소요
우선 현재 서비스에서 문제가 되는 부분을 정의하거나 추가적으로 핵심적으로 제공하고 싶은 가치에 대해 작성한다. 그리고 작성한 내용을 "어떻게 하면 ~할 수 있을까"로 변형한다.
여기서 나는 처음 들었던 의문이 말만 바꾸는 작업인데 왜 굳이 이런 형태로 바꿔야 하는가?였다. 하지만 이 과정이 중요한 이유는 문제를 전환하여 기회와 솔루션이 될 수 있는 인사이트가 도출된다는 것이다. 또한 팀원들이 각자 다른 부분에서 문제를 정의할 수 있지만 그 문제를 기회로 만드는 과정에서 대다수가 Overlap 될 수 있다. 따라서 새로운 시각에서 문제를 볼 수 있다는 점에서 꼭 거쳐야 하는 단계라고 생각한다.
예시) 문제: "사용자가 수면 후 결과페이지를 확인해야 어제 수면에 대한 긍정 경험을 체감할 수 있지만 사용자 중 일부는 아침에 비몽사몽해서 결과페이지를 확인하지 못한다". HWM: "어떻게 하면 아침에 비몽사몽하는 사용자가 결과 페이지를 확인하도록 할 수 있을까?"
여기서 한 가지 중요한 포인트를 집어보자면, 팀원들과 함께 작성하지 말고 꼭 따로 작성한 후에 공유하는 것을 추천한다. 서비스가 아직 초기단계라면 사실 비슷한 문제들에 대해 언급할 가능성이 높다. 하지만 각자 선택하는 단어들이나 바라보는 시야에 차이가 분명 존재하기에 그러한 모든 의견을 객관적으로 보기 위해 독립적으로 작성하는 것이 좋다.
아래는 우리 팀이 7차 스프린트에서 작성한 How Might We 테이블이다.
3단계: 주제 분류 및 투표
30분 소요
How Might We 문장들을 가지고 FigZam 포스팃에 나열한다. 그리고 같은 내용의 HMW는 하나로 묶는다. 그렇게 중복을 제외한 문장들을 나열한 후 큰 주제에 따라 분류한다. (플랫폼이 꼭 FigZam일 필요는 없지만 개인적으로 이 단계를 수행하기 가장 Interactive한 온라인 플랫폼이라고 생각한다)
그리고 대망의 투표 시간을 가진다. 각 사람은 투표권 2개를 가지고 본인이 생각하는 가장 유망하다고 생각하는 질문에 투표한다. 아래는 우리 팀이 7차 스프린트에서 진행한 투표 내용이다.
가장 많은 투표를 받은 메모가 우선순위가 높은 기회이다. 가장 투표를 많이 받은 메모 3가지를 나열하고 최종 결정권자가 이번 스프린트의 주제를 정한다.
4단계: 가설 수립
10분 소요
선정된 주제를 기반으로 검증하고자 하는 가설을 수립한다. 이때 가설은 최대한 상세할수록 좋다. 우리가 세웠던 가설을 예시로 공유해보자면 "유저들이 수면한 데이터를 다시 열람할 수 있게 하면 NDS 만족도가 올라갈 것이다"였다.
5단계: 성공 지표 정의
10분 소요
위에서 수립한 가설을 확인하기 위해 얼마의 모수가 어느 기간 안에 OMTM의 수치가 어디까지 올라가면 성공인지도 명확하게 작성하는 것이 좋다. 예시로 우리 팀의 7차 스프린트 성공 지표는 1000명이 2주 동안 들어와서 NDS 수치가 그 전보다 3% 올라가면 성공이였다.
그리고 한 번 정한 가설과 테스트 방식은 바꾸지 않는 것이 좋다. 최대한 Harsh하게 Condition을 만들고 최악의 상황에서 가설을 테스트하는 것을 추천한다. 그렇지 않으면 애매한 성공이나 실패가 계속 반복된다. 명확한 성공과 실패는 얼마나 높은 기준으로 가설을 테스트하는지에 따라 대부분 결정된다고 생각한다.
6단계: 레퍼런스 조사 및 공유
30분 소요
우리가 정한 가설을 테스트하기 위해 도움이 될만한 다른 제품/서비스를 빠르게 검색해보면서 레퍼런스들을 조사해본다. 우리는 각자의 공간에서, 따로 레퍼런스를 찾는다. 여기서 우리들의 한 가지 포인트는 바로 동종 산업의 서비스보다 아예 다른 영역의 서비스를 많이 본다는 것이다. 동종 산업의 서비스는 대체적으로 비슷한 맥락과 형태를 띄우는 경우가 많다. 그래서 새로운, 획기적인 아이디어는 이렇게 다른 곳에서 나오는 것 같다.
이렇게 조사한 레퍼런스를 공유하고 설명한다. 서비스를 소개하고 싶다면 정지된 화면에서 설명하는 것 보다 핸드폰으로 화면녹화를 해서 녹화 화면을 공유해주는 것이 이해에 빠르다. 추가로, 공유하다보면 말이 길어진다. 한 사람 당 말하는 시간을 타이머로 정해두고 하는 것을 추천한다.
7단계: 솔루션 스케치 및 공유
40분 소요
공유된 레퍼런스와 나의 아이디어를 토대로 솔루션을 빠르게 스케치해본다. 그림으로 그려서 만들고 돌아가면서 발표한다.
이 부분이 처음엔 디자이너분들의 영역인줄만 알았다. 하지만 개발자, 기획자 모두 각자의 생각대로 솔루션의 형태를 그리니 정말 다양한 결과들이 나왔다. 그림 실력은 중요하지 않다. 우리의 솔루션을 더 잘 전달할 수 있는 방법에 대해 열심히 표현해주면 된다. 아래는 우리 팀원이 스케치한 솔루션이다. (조금 많이 귀엽다)
모든 공유가 끝나면 정말 웃기게도 자연스레 어떤 솔루션이 채택되어야 하는지 모두 감이 잡힌다. 이 과정은 한 번도 의문이 생긴 적이 없어서 방법론이 없다. 다양한 형태의 솔루션을 보게 되면 각각에 대한 단점과 장점을 파악하게 된다. 최종 솔루션은 이러한 단점이 최소화되고 장점이 극대화되는 것으로 선택하면 된다.
여기서 몇 가지 인트를 강조하자면, 스프린트는 아무리 길어도 2주가 넘으면 안된다. 따라서 솔루션을 스케치할 때 이를 고려햐여 2주 안에 개발 가능한 정도로 조절하여 스케치해야 한다. 또한 모든 가설 검정은 MVP의 특성을 띄게 된다. 최소한의 노력으로 빠르게 프로덕트를 만들어 테스트해야 하기 때문에 속도를 고려한 스케치를 해야 한다. 뾰족한 MVP는 쉽고 빠르게 만들 수 있어야 한다.
솔루션이 끝나면 디자이너분께 전달하여 디자이너분께서 UX 플로우를 설계(솔루션이 어떤 시점에 나오면 좋을지)와 GUI 디자인 작업을 하게 된다.
이것은 조심하자
- 결국 선택은 결정권자의 몫이다. 팀원들과 다양한 의견을 나누며 더 좋은 인사이트를 찾아갈 수는 있겠지만 그것이 서비스 단에 나오고 테스트를 하게 되면 결과에 대한 모든 책임은 결국 결정권자가 지게 된다. 결정권자가 그 책임을 충분히 질 수 있는, 그런 자신이 생기는 기획이라면 당연히 추진해야 한다. 하지만 그렇지 않다면 팀원들에게 그 상황에 대해 충분히 이야기하고 공유하는 것이 좋다. 그리고 그 결정도 그에 맞춰 내리는 것이 좋다.
- 진행 방식이 마치 하나의 관례처럼 자리 잡으면 안된다. 이러한 기획 없이도 명확한 문제는 충분히 정의하고 도출할 수 있다. 중요한 것은 필요할 때 적절히 잘 사용하는 것이 중요하다. 우리 팀도 이 기획 프로세스를 사용하는 스프린트가 있고, 그렇지 않은 스프린트가 있다. 언제 필요한지, 그렇지 않은지 알려면 그만큼 스프린트를 진행해보는 수 밖에 없다. 많이 해봐야 그 정도를 결정내릴 수 있다.
- 0단계에서 설명한 세 가지를 꼭 기억해야 한다. 우리가 기획한 솔루션이 서비스의 장기 목표를 달성하는 방향과 Align되어야 한다. VOC를 기반으로 기획을 하다보면 OMTM을 개선하는 단기적인 방향으로 치우칠 수 있다. 고객의 만족도는 단기적으로 높아질 수 있지만, 장기적으로는 잘못된 방향으로 갈 수 있다. 예를 들어, 앞서 언급한 듯 우리 팀은 세계 최고 수준의 수면 경험을 제공하는 것이 목적이다. 하지만 OMTM인 NDS 만족도를 높이기 위해 수면 경험을 오히려 해치는 기능들을 기획한 적이 있다. 그럼 결국 서비스는 정체성이 불분명해져 어떤 문제를 푸는 솔루션인지 고객들도 헷갈려할 것이다. 따라서 모든 기획은 장기 목표와 Align 되어야 한다.
기획 프로세스가 내부적으로 수립되지 않았을 시점에 일주일에 33시간 동안 회의만 한 적도 있었다. ICE Factor부터 시작해 우리가 흔히 아는 애자일/그로스해킹 척도들을 사용해가며 회의가 돌고 돌았다. 그래서 4시간 만에 끝낼 수 있는 기획 프로세스는 우리에게 엄청난 효율을 가져다 주었다. 우리 팀의 스프린트 기획 프로세스가 이 글을 읽는 메이커인 여러분에게도 큰 도움이 되었으면 좋겠다. 모두 빠른 테스트와 실행으로 유니콘이 되어 날아올랐으면 좋겠다.✈️
