다음 스프린트에서 어떤 걸 다뤄야 할지 막막합니다.
기회-솔루션 트리로, 넥스트 전략을 한 번에!
목차
1. 실험할 때, 이런 고민 해본 적 없나요?
2. 나무를 심어보자! 기회-솔루션 트리
3. 이런 실수, 다들 한 번쯤 해봤자나요?
4. 그래서 어떻게 하는 건데?
하나라도 해당되면, 재밌게 읽을 수 있어요!
1. PO, PM를 시작한 지 얼마 안 됐다.
2. 가설 검증에 진심이다.
3. 아이디어를 생각할 때, 2%가 부족하다.
실험할 때, 이런 고민 해본 적 없나요?
1. 실험에 진심이 되자!
현재 초기 창업 팀에서 기획자 겸 PO를 맡고 있다. 린 프로세스에 기반해 팀을 운영하고 있고, 매주마다 [문제 파악 - 팀 액션 - 실험 - 가설 검증 & 학습 - 회고]의 싸이클을 반복하고 있다. 이번 주에 특정 가설을 검증했다면, 다음 주에 새로운 가설을 검증해야 한다. 이처럼, 린하게 일한다는 것은 가설 검증을 끝없이 반복하는 것과 같다.
가설을 검증하는 이유는 팀이 추측이 아닌, 사실을 알아냄으로써 배우기 위함이다. 프로덕트가 갖고 있는 기능은 고객이 겪고 있는 문제를 해결할 때, 비로소 가치가 있다. 따라서, 기능을 구상하기에 앞서서 고객이 어떤 문제를 겪고 있는지 알아야 한다. 이를 위해 팀은 갖고 있는 기존 정보를 최대한 뜯어보고, 조합해 고객 문제를 생각한다. 하지만, 여기서 생각한 '고객의 문제'는 '추측'일뿐이지, '사실'이 아니다. 물론, 어떤 정보를 기반으로 했느냐에 따라서 '추측'이 '사실'일 확률은 높아진다. 그렇지만, 고객에게 직접 찾아가 물어보는 게 가장 명확한다.
2. 주니어 PO의 고민, 이런 거 나만 생각해?
실무자인 기획자와, 관리자인 PO로 일한다는 건 매우 다르다. 기획자는 '이번' 스프린트에서 진행하는 실험을 어떻게 기획하고 진행할지를 주로 생각한다. 실험을 진행하기 위해 무엇이 필요한지 생각하고, 가설의 참/거짓을 가장 잘 나타내는 지표가 무엇일지 생각한다. 이와 다르게, PO는 '다음' 스프린트에서 어떤 가설을 검증할지 고민한다. 아직 증명하지 못한 가설 사이의 우선순위를 매기고, 이를 통해 실험의 중장기적 로드맵을 구상한다. 또한, 실험 백로그를 관리해 다른 팀원이 현재의 실험에 집중할 수 있도록 도와야 한다. 한 마디로 말해, PO는 앞으로의 실험에 대한 Why와 What을 고민하고, 팀원이 현재의 실험에 대한 How를 찾을 수 있도록 돕는다. 이전 회사에서 기획자로 일할 때 몰랐지만, 현재 PO를 맡아보니 방향을 제시하고, 실험 백로그를 관리하는 게 생각보다 어려운 일임을 깨달았다. 팀에서 진행한 실험이 많아질수록, 아래 2가지 고민이 스물스물 생기기 시작했다.
(고민 1) 다음 주, 어떤 가설을 검증해야 하지?
(고민 2) 검증한 게 너무 많아...
아직도 부족한 게 많은 주니어 PO... (출처 : <독수리 오형제>)다음 주, 어떤 가설을 검증해야 하지?
실험을 위해선 생각보다 많은 리소스가 필요하다. 우선 실험 재료(ex. 프로토타입, MVP, 랜딩 페이지)를 만들고, 데이터를 수집할 환경도 구축해야 한다. 그리고, 수집한 데이터를 분석할 시간도 필요하다. 하지만, 팀이 증명해야 할 가설은 너무 많고, 끊임없이 생겨난다. 동시에 팀에게 주어진 리소스는 한정적이므로, 이 모든 가설을 검증하기란 현실적으로 불가능하다. 따라서, 수많은 가설 중에서도 '검증할 만한 가치'가 있는 게 무엇인지 판단하고, 리소스를 집중해야 한다.
PO는 수많은 가설 사이에 우선순위를 보다 빠르고 명확하게 내려서, 넥스트 전략을 제시해야 한다. 우선순위는 요소 사이의 순위를 매기는 것이며, 이때 순위를 판단하는 기준은 매우 다양하다. 그리고, 어떤 판단 기준을 적용하느냐에 따라서 순위가 계속 바뀔 수도 있다. 예를 들어보자. 순위 판단 기준을 'OKR의 임팩트'로 설정한다면, 가설을 검증했을 때의 인사이트가 OKR에 어떤 영향을 줄지 생각하고 우선순위를 매긴다. 반대로, 판단 기준을 'ICE'로 한다면, 가설을 검증하는 실험에서 ICE 점수를 생각해 우선순위를 매긴다. 우선순위를 판단하는 몇 가지 기법은 아래 링크에서 확인 가능하다!
검증한 게 너무 많아...
실험을 통해 많은 것을 학습하고, 이 학습한 모든 것이 곧 정보가 된다. 이 정보를 평생 간직하면 좋으려 만, 아쉽게도 우리 뇌가 기억할 수 있는 정보엔 한계가 있다. 뇌는 한정된 기억 저장소 용량을 관리하기 잘 관리하기 위해, 오래된 정보는 삭제하고 새로운 정보를 저장한다. 따라서, 실험이 쌓일수록 학습한 것이 많아지지만, 이러한 것들이 시간이 지나면 잊어버리게 된다. 힘들게 실험까지 했는데 학습한 걸 잊어버리는 것만큼, 억울한 일이 있을까?
이로 인해 발생하는 또 다른 문제는 팀원 사이의 동기화가 어긋날 수 있다는 점이다. 예를 들어보자. 몇 주 전 실험에서 'A'라는 가설을 검증했고, 이때 학습한 것을 바탕으로 이번 주에 'B' 가설을 검증하기로 했다. 'B'는 'A'에서 시작됐으므로, 'B'를 검증하기 위한 배경 및 목적을 알려면 당연히 'A'를 알아야 한다. 근데, 일부 팀원이 'A'를 정확히 기억하지 못한다면? PO의 역할은 동일한 맥락, 이른바 Why를 전달해 팀원 모두가 같은 그림을 그리게 만드는 것이며, 이를 위해 지금까지 진행한 모든 실험의 맥락을 직관적이고 쉽게 전달해야 한다.
나무를 심어보자! 기회-솔루션 트리
최근에 '기회-솔루션 트리(Opportunity-Solutioon Tree)'라는 프레임워크를 다루는 아티클을 접했는다. 기회-솔루션 트리는 프로덕트 팀이 넥스트 전략을 어떻게 해야 할지 고민 끝에 나온 프레임워크인데, 앞선 2가지 고민을 명쾌하게 해결해줬다. 꽤나 인사이트가 많아서 아티클의 내용을 일부 요약 및 각색해서 가져왔다! 역시 사람은 끊임없이 배워야 한다!
(고민 1) 다음 주, 어떤 가설을 검증해야 하지?
(답변) 목표 기반으로 우선순위를 매기고 검증할 가설을 선택한다.
(고민 2) 검증한 게 너무 많아...
(답변) 나무 구조로 팀이 어떤 실험을 했고, 각 실험의 맥락을 무엇인지 한눈에 보여준다.
고민이 한순간에 해결! (출처 : <개비스콘 광고>)1. 결과 - 기회 - 솔루션 - 실험
기회-솔루션 트리는 '결과(Desired Outcome)', '기회(Opportunity)', '솔루션(Solution)' 그리고 '실험(Experiment)'이란 계층으로 구성된다. 결과-기회-솔루션-실험의 순으로 내려가고, 각 계층은 서로 이어져있다. 예를 들어, '결과'는 '기회 A'와 '기회 B'로 이어지고, 이 중에서 '기회 A'는 '솔루션 a'와 '솔루션 b'로, 또 다시 '솔루션 a'은 '실험 1'과 '실험 2'로 이어지는 형식이다. 각 계층에 대한 설명은 아래와 같다.
1. 결과(Desired Outcome) : 팀이 궁극적으로 원하는 결과로, 특정 정량적 수치를 설정함
2. 기회(Opportunity) : 위 결과를 만들어 내는 현상
3. 솔루션(Solution) : 위 기회를 실현시키는 액션
4. 실험(Experiment) : 솔루션이 정말로 유효한지를 검증하는 실험
2. 목표와 액션 사이의 연결 고리, 기회!
기회-솔루션 트리는 목표 기반의 관리 방법과 유사하다. 핵심 지표(Key Metrix)를 달성하기 위해 어떤 일(Task)을 해야 할지 찾는 것처럼, 기회-솔루션 트리에선 원하는 결과(Desired Outcome)를 얻기 위해 어떤 솔루션(Solution)이 필요한지 탐색한다. 다만, 기존 방식과 차이점으로 이 2가지 요소(핵심지표 - 일 / 원하는 결과 - 솔루션)사이에 기회(Opportunity)라는 게 존재한다. 즉, 팀의 일은 '결과'가 아닌, '기회'를 달성하기 위해서 존재한다. 그리고, 이렇게 달성된 '기회'들이 모여서 '원하는 결과'가 이루어진다.
우린 기회로 묶인 깐부자나! (출처 : <넷플릭스, 오징어 게임>)이해를 돕기 위해 예시를 들어보자. 팀이 원하는 결과로 'WAU 150명'을 설정했다. 그러면, 이 결과를 달성하게 만드는 기회가 무엇이 있을까? '첫 방문 유저 증가'나 '재방문 유저 증가'가 있다. 이 중에서 '재방문 유저 증가'를 가능케 하기 위해 '알림 기능 추가'를 솔루션으로 생각할 수 있다. 그렇다면, 이제 '알림 기능 추가'가 정말 '재방문 유저 증가'를 가능케 하는지 실험을 스케치한다. 이 실험으로 'A/B 테스트', '알림 기능에 의한 유입 유저 분석' 등이 있을 수 있다.
이런 실수, 다들 한 번쯤 해봤자나요?
아이디에이션 단계에서 많은 사람들이 공통적으로 보이는 몇 가지 실수들이 있다. 나 또한, 처음 스타트업에 다닐 때 이러한 실수를 자주 범했고, 최근에도 팀을 리드하다가 비슷한 실수를 저지르고 아찔해한다. 기회-솔루션 트리를 사용해 생각해본다면, 이 실수를 어느 정도 줄일 수 있다.
실수를 뒤늦게 깨닫는 순간, 대략 정신이 멍해진다. (출처 : <돌아온 럭키짱>)(실수 1) 아이디어'만' 생각한다.
프로덕트 팀에서 Next 전략을 위해 "다음에 어떤 기능을 구현하지?"라는 질문을 던진다고 해보자. 그러면, 이 질문에 대한 답으로 "기능"이 나오는 게 당연하다. 여기서 많은 사람이 실수하는 게 이렇게 나온 '기능'을 바로 구현한다는 것이다. 기능과 같은 솔루션은 목적이 아닌 수단이다. 즉, 수단으로써의 솔루션은 특정 목적을 달성하기 위해 존재한다. 따라서, 앞선 질문을 한 후에 나온 아이디어를 보고, "이 기능이 어떤 기회로 이어질까? 그리고, 이렇게 이어진 기회는 결과로 다시 이어질까?"를 되물어야 한다.
(실수 2) '1'개 밖에 생각하지 않는다.
앞서 말했듯이 솔루션은 기회와 이어져야 한다. 이때, 이 기회와 이어져 있는 솔루션이 1개냐 혹은 2개 이상이냐에 따라 상황이 크게 달라진다. 만약 솔루션 아이디에이션 단계에서 1개밖에 나오지 않았다면, 이 솔루션의 평가는 독립적으로 진행된다. 즉, 'Wheter or not (이걸 해야 해? 말아야 해?)'의 영역이며, 자칫 솔루션을 과대평가할 수도 있다. 이러한 상황을 방지하기 위해 하나의 기회에 이어지는 솔루션을 최소 2개 이상 생각해야 한다. 인간은 비교의 동물이라는 말도 있지 않은가? 솔루션이 2개 이상이라면, 각 솔루션의 영향도를 서로 비교함으로써 좀 더 객관적인 평가가 가능해진다. 또한, 이 비교를 통해 솔루션 사이의 우선순위도 설정할 수 있다.
비교를 통해 합리적인 결정을 내리자! (출처 : <피지컬 갤러리>)1개의 솔루션 밖에 나오지 않았다면 다음의 방법을 써보자. 먼저, 갖고 있는 솔루션을 보고 "이 솔루션은 어떤 기회로 이어질까?"를 물어본다. 기회를 찾았으면, 다시 질문한다. "이 기회를 일으킬 수 있는 다른 솔루션은 무엇일까?" 이러한 방식을 통해 하나의 기회와 이어져 있는 여러 솔루션을 생각할 수 있다.
(실수 3) 아이디어의 '결'을 보지 않고 비교한다.
프로덕트 백로그를 보면, 아직 구현되지 않은 기능(=기회-솔루션 트리에서의 '솔루션')이 매우 많다. 동시에 팀이 가진 리소스는 한정됐으므로, 기능 사이에 우선순위를 매기고 가장 높은 순위의 기능에 리소스를 집중한다. 여기서 가장 많이 하는 실수로, 모든 기능을 같은 선상에 두고 순위를 내린다. '솔루션'은 기회-솔루션 트리에서 '기회'를 달성하기 위한 수단이다. 즉, 솔루션의 가치는 '기회'를 얼마나 잘 달성하느냐에 있다. 근데 각각의 솔루션마다 달성하는 기회는 같을 수도 혹은 다를 수도 있다.
좀 더 쉬운 예시를 들어보자. 기능 A는 문제 a를 해결하고, 기능 B는 문제 b를 해결한다고 해보자. 이제 기능 A와 기능 B를 비교해 우선순위를 매길 때, 어떤 기준을 적용해야 할까? "문제 a를 가장 잘 해결하는 것은 기능 A니깐, 기능 A가 더 우선순위가 높아!"라는 판단이 맞을까? 애초에 기능 B는 문제 b를 해결하기 위해 등장한 기능인데, 문제 a를 기준으로 두는 건 무의미하다. 이처럼, 같은 기회로 이어지는 기능끼리 비교해야 하며, 이를 위해 각각의 기능이 실현시키는 기회가 무엇인지 먼저 알아내야 한다.
(실수 4) 백로그에 아이디어를 쌓기만 한다.
프로덕트 백로그에 아직 구현하지 못한 기능이 너무도 많고, 자원은 한정됐다. 따라서, 기능 사이에 우선순위를 내리고, 가장 순위가 높은 기능부터 순차적으로 구현해야 한다. 근데 백로그의 모든 요소를 하나하나 비교해 순위를 매기는 게 쉬운 일이 아니다. 예를 들어서, 아직 구현되지 못한 기능이 10개라고 해보자. 우선순위를 판단하려면, 이 10개의 기능을 한 번에 모두 비교해야 하는데 이건 쉬운 일이 아니다.
백로그에 기능이 끝이 없네! (출처 : <만화의 길>)기회-솔루션 트리는 각각의 계층에서 우선순위를 내림으으로써, 우선순위 관리를 더 쉽고 체계적으로 할 수 있다. 상위 계층에 있는 '기회'끼리 우선순위를 내리고, 동일한 기회와 연결된 하위 계층 '솔루션'끼리 다시 우선순위를 내린다. 다시 위의 예시를 가져와보자. 10개의 기능이 어떤 기회를 일으키는지 생각해봤고, 3개의 기능은 '기회 A', 4개의 기능은 '기회 B', 마지막으로 4개의 기능은 '기회 C'와 이어진다고 해보자. 그러면 우선 '기회 A', '기회 B', '기회 C' 사이에 우선순위를 내린다. 이 후, '기회 A'와 연결된 3개의 기능 사이에 우선순위를 매긴다. 이 후, 다시 '기회 B'와 연결된 4개의 기능, '기회 C'와 연결된 4개의 기능 사이에 우선순위를 매긴다.
이전에 10개의 기능을 한 번에 비교했다면, 기회-솔루션 트리를 도입해본 결과 한 번에 3~4개의 기능만 비교하면 된다. 백로그의 정보를 2가지 계층으로 나눔으로써 한 번에 비교할 객체 수를 조절하고, 우선순위의 더 쉬운 판단이 능하다.
(실수 5) 회의를 하다 보면 계속 딴 길로 센다.
기회-솔루션 트리의 가장 큰 장점은 시각화다. 많은 회의와 업무를 하다 보면, 너무도 많은 정보에 휩쓸려 자칫 중심을 잃을 수도 있다. 예를 들어, 팀 회의를 여러 번 하다 보니깐 어느새 이야기가 첫 회의 때와 전혀 다른 방향으로 흘러갈 수도 있다. 기회-솔루션 트리은 전체적인 그림을 한눈에 봄으로써 중심을 잃지 않게 도와준다.
그래서 어떻게 하는 건데?
지금까지 기회-솔루션 트리가 어떤 것이고, 이걸 쓰면 뭐가 좋은지 알아봤다. 이제 어떻게 이걸 만드는지 살펴보자! 기회-솔루션 트리는 아래와 같은 프로세스를 통해 만든다.
1. 원하는 결과(Desired Outcome) 명확히 하기
2. 리서치를 통해 기회(Opportunity) 찾기
3. 모든 솔루션(Solution)을 기회와 연길 시키기
4. 실험(Experiment)하고 관리하기
5. 우선순위 내리고 넥스트 전략 짜기
step 1. 원하는 결과를 명확히 한다.
기회-솔루션 트리를 만들기 위해, 가장 먼저 팀이 추구하는 결과를 명확히 해야 한다. 이때, 결과는 정량적 수치에 기반한다. OKR의 Key Result가 쓰일 수도 있고, OKR을 쓰지 않는 곳이라면 리텐션, 수익, NPS 등의 정량적 수치를 사용할 수 있다. 만약 목표하는 지표가 여러 개라면, 각각의 지표마다 독립적인 트리를 만들면 좋다.
step 2. 리서치를 통해 기회를 찾는다.
결과를 설정했으면, 이제 이 결과를 가능케 하는 기회를 찾아야 한다. 지금까지 갖고 있는 모든 고객 데이터를 뒤져보고, 기회를 찾는다.
step 3. 모든 솔루션을 기회와 연결시키기
이렇게 기회를 모두 찾았으면, 이제 각 기회를 실현시키는 솔루션을 생각한다. 이때, 모든 솔루션은 1개의 기회와 연결돼야 하며, 연결된 기회는 그 솔루션의 타겟 기회가 된다. 만약 솔루션과 기회가 이어지지 않는다면, 이를 과감히 포기하거나 혹은 다른 기회를 생각한다.
step 4. 실험하고 관리하기
이제 그 솔루션이 기회를 정말로 실현시키는지 실험한다. 각 솔루션마다 여러 실험을 진행하며, 다양한 실험을 통해 솔루션의 유효성을 검증한다.
step 5. 우선순위를 내리고 넥스트 전략 짜기
기회-솔루션 트리가 완성되면, 이제 각 요소를 비교해 우선순위를 매기며 팀의 넥스트 전략을 만들어간다. 여기서 우선순위의 판단은 윗 계층에 끼치는 영향을 기준으로 한다. 모든 기회는 결과를 이루기 위해 존재하므로, 다양한 기회 사이에 우선순위는 '결과에 끼치는 영향'을 기준으로 내린다. 이렇게 기회의 우선순위가 결정되면, 이 기회를 가능케 하는 솔루션 사이의 우선 순위를 평가한다. 앞선 결과와 기회의 관계처럼, 솔루션의 우선순위 판단도 '기회에 끼치는 영향'을 기준으로 한다.
아티클
https://www.producttalk.org/2016/08/opportunity-solution-tree/
