Discovery와 Delivery는 무엇일까?
제품을 사용자에게 전달하기 위한 방법에는 크게 2가지가 있다. 새로운 가치를 발굴하는 과정인 Discovery와 이미 발굴한 가치를 사용자에게 전달하는 Delivery가 그것이다. 두 가지를 한 번에 진행하기는 어렵기도 하고, 완전 초기 단계의 스타트업이나 리소스가 많지 않은 팀에서는 적합하지 않을 수 있다. 특히 대부분의 경우에는 이미 운영이 되고 있기 때문에 Delivery를 주로 하게 된다. 다만 완전 초기의 팀 또는 스타트업의 경우나 서비스의 규모가 어느 정도 도달했거나, 성장성에 한계점이 도달했다면 서비스를 운영하는 일뿐만 아니라 서비스의 확장성을 고려하여 신규 가치 발굴을 모두 준비해야 하기 때문에 모두 고민해볼 수 있어야 한다.
이번 글은 가치를 사용자에게 전달하는 Discovery와 Delivery에 대해 적어본 글이다. 글의 순서는 아래와 같다.
|
1. Discovery는 무엇일까? 2. Discovery는 어떻게 진행할 수 있을까? 3. Delivery는 무엇일까? 4. Delivery는 어떻게 진행할 수 있을까? |
Discovery는 무엇일까?
Discovery는 새로운 기능이나 새로운 제품을 탐색하고 발굴하는 활동이다. 아예 존재하지 않았던 가치(Value Proposition)를 사용자에게 보여주고, 그 가치의 PMF를 검증하고, 실제로 구현해야 하는 과정이기 때문에 Delivery 활동에 비해 시간이 오래 걸리고, 많은 에너지를 소모할 수 있다. 또한 탐색하고 발굴한 모든 신규 가치가 사용자에게 부합하지는 않기 때문에 시간과 에너지, 리소스를 소모했음에도 불구하고 원하는 결과가 나오지 않을 수 있다. 원하는 결과가 나오지 않았다 하더라도 낙담하거나 무력해하지 말아야 한다. 사용자가 정말 원하는 가치를 발굴해낸다면 앞서 소모했던 시간과 에너지, 리소스를 모두 보상받을 수 있을 만큼 큰 임팩트를 느낄 수 있다.
Discovery는 Design Sprint라는 프레임워크를 사용하거나 User JourneyMap을 통해 백로그 과제를 발굴하게 된다. 물론 이 2가지 방법 외에도 여러 가지 방법이 있을 수 있지만, 내가 주로 사용하는 방법이 앞서 말한 2가지 방법이기 때문에 이 프레임워크에 대해서 설명하는 것이 좋을 것 같다.
Discovery는 어떻게 진행할 수 있을까?
Design Sprint
Design Sprint는 Google Ventures에서 개발된 5단계의 디자인/개발 프레임워크다. 각 단계를 하루씩 할당해서 스프린트 팀이 5일 안에 문제 발굴부터 해결 방법, 해결 방법을 구현한 프로토타입 구축, 프로토타입 테스트까지 진행한다. 5일이라는 짧은 시간 동안 제품에 대한 주요 이슈 및 비즈니스 질문에 대한 해결책을 확보하는데 주력한다.
1일차 : 과제 정의 및 타깃 선택
스프린트 방향성 설정
스프린트의 방향성은 장기적인 목표를 수립하는 과정이며 아래의 주요 질문들에 대답할 수 있어야 한다. 아래 나열한 주요 질문들을 적어보고, 이 질문에 대한 답을 찾기 위한 과정으로 스프린트가 진행되어야 한다.
|
1. 이번 스프린트에서 우리가 답하고 싶은 질문들은 무엇인가? 2. 장기 목표를 달성하기 위해 실현되어야 할 것은 무엇인가? 3. 미래로 날아가 우리 계획이 실패했다면 그 실패 원인은 무엇일까? |
지도 그리기
지도는 고객 중심으로 그려져야 하며 사용자가 우리 제품을 발견하고, 사용하는 전반적인 과정을 나열한다. 지도를 그리는 특징은 아래와 같다.
|
1. 핵심 행위자 설정 2. 결말 수립 3. 단어 및 화살표를 사용하며, 5 ~ 15단계로 간단하게 그리기 |
전문가 의견 수렴
스프린트의 방향성과 지도를 그렸다면, 이제 전문가들을 불러서 그들의 의견을 들어보는 시간을 가지면 좋다. 전문가들은 우리가 생각하지 못했던 부분들을 찾아내어 개선할 수 있도록 알려줄 수 있고, 우리가 설정한 방향성과 지도를 실현 가능한 요인들을 덧붙여 줄 수 있기 때문이다. 전문가 의견 수렴은 아래의 단계를 거친다.
|
1. 스프린트 소개 2. 전문가가 스프린트의 목표 / 질문 / 지도를 살펴보게 하기 3. 전문가의 의견을 듣기 전문가에게 질문하기4. 전문가의 피드백을 토대로 지도 및 목표를 업데이트하기 |
”우리가 어떻게 하면 ~ 할 수 있을까?”
이렇게 전문가의 의견까지 들어보았다면 지금까지 나온 내용을 토대로 “우리가 어떻게 하면 ~ 할 수 있을까?(How Might We, HMW) 과정을 진행해보자. 팀원 각자가 메모지를 가지고 질문과 각 지도에 나와있는 주요 포인트들에 대해서 “우리가 어떻게 하면 ~ 할 수 있을까?”로 시작하는 질문들을 작성한다. 이렇게 작성한 메모들을 모아서 정리하자. 이렇게 정리된 메모는 타깃을 설정하거나 다음 단계에서 솔루션을 고민하는 과정에서 사용될 수 있다. 타깃 설정 1일차의 모든 과정을 진행했다면 이제 마지막으로 타깃을 설정할 차례다. 우리 회사의 가장 중요한 고객이 누구인지, 고객이 우리 제품에서 겪는 경험에서 가장 중요한 순간이 어디인지를 고민하여 타깃을 선정하자.
2일차 : 솔루션 도출
2일차는 1일차 과정에서 나온 내용들을 토대로 솔루션을 고민해보는 시간이다. 이 과정에서는 우리 제품뿐만 아니라 다른 제품이나 회사에서 아이디어를 차용해서 가져와도 좋다. 또한 회사에서 논의되었던 기존 아이디어들을 다시 끌고 들어와도 좋다. 우리가 1일차에 고민했던 질문들, 우리가 선정한 타깃, 문제라고 생각했던 과제를 어떻게 해결할 수 있을지 고민한 후, 여러 가지 아이디어들을 조합하고 발전시켜 하나의 아이디어 스케치로 만들어보자. 이 과정에는 아이디어를 스케치하는 것뿐만 아니라 크레이지 에이트(가장 효과적인 아이디어를 8분 만에 8가지로 변형하여 스케치하는 활동)와 최종적인 솔루션을 스케치하는 과정을 포함한다. 솔루션 스케치가 완료되었다면 모든 팀원이 스케치에 대해서 비판하고, 토론한 후 결정하는 과정을 거쳐야 한다. 이렇게 결정된 솔루션 스케치는 다음 단계에서 스토리보드로 발전하고, 이후 프로토타입까지 발전할 수 있다.
3일차 : 스토리보드 구성
2일차에 결정한 솔루션 스케치를 토대로 스토리보드를 구성해야 한다. 스토리보드는 프로토타입을 만들기 위한 단계별 설계도다. 이때 새로운 아이디어가 떠오르더라도 잠시 뒤로 미룰 수 있는 용기가 필요하다. 스토리보드 단계는 수렴하는 단계로서 추가적인 발산 없이 기존에 나왔던 아이디어로만 진행해야 하며, 수렴하는 과정에서 최대한 세부사항을 포함할 수 있도록 고민해야 한다. 스토리보드는 너무 길지 않게 15분 이내로 시연이 끝날 수 있도록 준비해야 한다.
4일차 : 프로토타입 구축
스토리보드를 토대로 프로토타입을 구성한다. 프로토타입은 실제 개발까지 가지 않아도 좋다. 다만 인터뷰 대상자가 실제 제품처럼 느낄 수 있도록 잘 설계되어야 하고, 잘 만들어져야 한다.
5일차 : 인터뷰 / 테스트
4일차에 만든 프로토타입을 토대로 사용자들을 대상으로 시연 및 인터뷰를 진행한다. 이 과정에서 사용자가 프로토타입을 사용해보는 과정에서 최대한 개입하지 않아야 한다. 다만 그들이 사용하는 과정을 보고 막히거나 질문을 하는 부분이나 우리가 의도하지 않았던 방식으로 제품을 사용하는지를 철저하게 파악할 수 있어야 한다. 그 부분들이 우리가 실제 제품으로 구현할 때 반영되거나 개선되어야 할 부분이기 때문이다. 사용자가 제품을 충분히 잘 사용하고, 이에 만족한다면 스프린트를 통해서 나온 가치는 충분히 검증되었다고 볼 수 있다. 이제 해당 가치를 실제 제품으로 구현하면 된다.
고객을 인터뷰하는 방법은 ‘고객 인터뷰하기‘ 아티클에서 자세한 내용을 확인할 수 있다.
User JourneyMap
User JourneyMap은 사용자가 우리 제품이나 우리가 사용자에게 제공하는 가치를 경험하게 되는 순간들을 그려보고, 더 나은 경험을 제공하거나 사용자가 불편함을 느낄 수 있는 부분을 찾아내어 새로운 가치를 전달할 수 있도록 만드는 작업이다. Delivery라고 생각할 수 있지만, Delivery는 이미 도출된 백로그를 사용자에게 전달하기 위한 과정이고, User JourneyMap은 백로그를 탐색하고 발굴하기 위한 과정이기 때문에 Discovery 활동으로 설정했다. 앞서 Design Sprint 1일차에서 나온 Map과 형태는 유사하다. 다만, 이미 사용자에게 가치를 전달하는 과정을 기반으로 수행되기 때문에 Design Sprint보다는 조금 더 수월하고, 빠르고, 리소스를 덜 소모하면서 새로운 가치를 탐색할 수 있다. 보통 서비스를 운영하는 과정에서 새로운 기능을 제공함으로써 사용자를 더 많이 유입시키고, 더 오래 머물게 하기 위해 자주 사용하고 있다.
|
1. 사용자가 서비스를 발견하고, 사용하고, 가치를 느끼게 되는 순간을 User JourneyMap으로 그려낸다. 2. 각 Map에서 사용자가 어려움을 느낄 수 있는 지점이나, 새로운 가치를 전달할 수 있는 지점을 찾아내어 아이디어를 도출한다. 3. 도출한 아이디어를 프로토타입으로 만들고 테스트를 진행한다. 4. 테스트 결과가 성공적이라면, 해당 기능을 만들어 제품에 적용시킨다. |
Delivery는 무엇일까?
사실 Delivery는 사실 기획 – 디자인 – 개발 – QA – 배포의 일련의 과정을 의미한다. 다만 Discovery 활동과 구분하기 위해서 별도로 분리해 보았다. Delivery 활동은 User Interview, VoC, 사용자 리뷰, 운영 과정에서 나온 백로그와 같은 것들을 실행하기 위한 작업을 말한다. Discovery와 달리 아예 존재하지 않았던 가치를 사용자에게 전달하는 것이 아니고, 팀이 기존에 알고 있었거나, 사용자로부터 나온 의견을 실제로 구현하여 적용하는 활동을 말한다. 문제 및 과제를 정의하거나 탐색할 필요 없이 이미 나온 백로그를 개발과 디자인으로 구현하는 과정이다. 그래서 Discovery에 비해서 시간이나 리소스를 많이 소모할 필요가 없고, PMF를 검증하지 않아도 어느 정도 효과를 예상해볼 수 있다는 장점이 있다. 다만 해당 가치가 전달되었을 때 실 경험자가 적거나, 요구사항이 적을 경우 느낄 수 있는 임팩트가 생각보다 크지 않을 수 있다.
Delivery는 어떻게 진행할 수 있을까?
Delivery는 일련의 제품 개발 프로세스와 동일하다. 백로그에서 나온 내용을 사용자에게 잘 전달하기 위해서 기획을 진행하고, 사용자에게 잘 전달하기 위한 UI/UX 기획 / 디자인을 진행하며, 이렇게 나온 디자인 및 세부 기능을 개발을 통해 구현하는 과정이다. 구현이 되고 나면 기획 및 디자인대로 잘 구현이 되었는지, 개발 과정에서 버그는 없는지 QA를 진행하고, 이상이 없는 경우 배포를 통해서 사용자에게 가치를 전달하게 된다.
결론
사실 굳이 Discovery와 Delivery를 구분하여 생각할 필요는 없을 수 있다. 결국 Discovery를 통해서 나온 새로운 가치는 Delivery의 형태로 구현되어야 하고, Delivery 과정에서 새로운 가치가 발견될 수 있기 때문이다. 다만 이러한 업무가 기획자나 PM이 다른 메이커(디자인, 개발 등)에 비해서 더 중점을 두고 고민을 해야 하는 작업임은 분명하다. 우리는 제품의 방향성을 수립하고, 팀이 올바른 제품을 만들어 사용자에게 가치를 전달할 수 있도록 해야 하는 역할이기 때문이다. 우리는 우리의 제품을 끊임없이 들여다보고 새로운 가치를 더해서 제품 수명 주기를 늘리고, 사용자의 불편함이나 개선점은 지속적으로 해결해서 사용자가 더 오래 서비스에 머물고, 그들의 비용을 기꺼이 지불할 수 있도록 해야 한다.
June님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
