제품 기획을 팀원들과 '함께' 하는 방법

디자인 스프린트 - 구글 벤처스

저번화(참고​)에서는 팀원들이 맘 놓고 발언할 수 있는 조직의 안정감에 대해 말했다. 이번에는 어떤 방식으로 팀원들을 제품 기획에 참여시킬 것인가에 대한 방법론으로, 구글 벤처스의 '디자인 스프린트' 책의 내용을 간략히 소개하고 한계에 대해서도 얘기해보고자 한다. (구글벤처스에서 책의 내용을 단계별로 5분 정도의 영상으로 만들어두었길래, 해당 부분마다 ‘참고’로 링크해두었다)

기획부터 프로토타입 검증까지, 5일간의 스프린트

디자인 스프린트는 아래와 같은 유익이 있다.

팀원 전체를 기획에 참여시킬 수 있다

5일만에 한 개 아이디어를 고객 검증까지 마칠 수 있다

설령 실패하더라도 백로그들을 많이 확보할 수 있다

그리고 아래의 순서로 5일동안 진행된다.

1. 초기 환경 셋팅

2. 목표 설정과 가설 정리 (월요일)

3. 솔루션 도출 (화요일)

4. 솔루션 선정 (수요일)

5. 프로토타이핑 (목요일)

6. 고객 검증과 피드백 (금요일)

하나하나 자세히 살펴보자.

1. 초기 환경 셋팅 (참고​)

가장 중요한 것은 스프린트를 누가 진행하고, 누가 결정할지를 정하는 것이다. PM이 진행도 하고 결정도 한다고 생각할 수 있지만 실제 그렇게 하기가 어렵고 (바쁘다) 책에서도 둘을 나누는 것을 권장한다. 보통 본 PM은 결정하고, 애자일 코치나 동료 PM에 진행을 부탁하는 것이 좋다.

그리고 풀어야할 문제, 참가자, 그리고 5일 동안의 시간과 독립된 장소를 확보한다. 이외의 준비물에는 포스트잇, 화이트보드, 펜 등이 있다. 5일 동안의 스프린트지만 당연히 PM은 사전 준비가 필요하다.

2. 목표설정과 가설정리 (참고​)

월요일의 목표는 스프린트 과정에서 1) 어떤 문제를 풀 것인가 2) 목표는 무엇인가 3) 우리가 알고 있어야하는 것은 무엇인가 를 정리하는 것이다. 먼저 해결하고 싶은 고객의 문제를 적어본다(ex. 특정 상품에 대한 진입이 너무 낮다). 그리고 이를 '해결했다'라고 판단할 수 있는 기준을 생각해본다. 정량적 수치는 물론이고, 결과를 평가하기 위한 핵심적인 질문을 적어두는 것도 좋다.

다음으로는 문제 범위를 포함한 User journey map을 그려본다. 어떤 고객이 우리 서비스에 진입해서, 어떻게 문제 지점에 도달하고, 판단하고, 행동을 마치는지 간단하게 다이어그램으로 화이트보드에 그려본다. 이는 문제 상황을 도식화하여 팀원들이 솔루션을 도출하는데 용이할 뿐더러, 비슷한 문제를 겪어본 전문가에게 조언을 구하기 위함이다. 도식화를 마친 뒤에는 분야의 전문가, 혹은 비슷한 문제를 풀어본 동료를 불러서 도식화를 설명하고 조언, 경험을 물어본다.

도식화, 전문가 인터뷰를 하는 동안 팀원들은 포스트잇에 “어떻게 하면 ~할 수 있을까”의 형식으로 솔루션에 대한 간단한 아이디어를 메모한다 (포스트잇 한 장에 한개씩) 인터뷰가 끝나고 진행자는 포스트잇을 모아 벽에 분류해둔다. 가능하면 User journey에 따라 구분해두는 것이 좋다. 오늘의 결과를 바탕으로 풀어야 할 문제 범위를 다시 짚어두고, 세션을 종료한다.

3. 솔루션 도출 (참고)

화요일의 목표는 최대한 많은 솔루션에 대한 재료를 공유하고, 팀원 각자의 아이디어를 쌓는 것이다.​ 먼저 모든 팀원이 회사에서 시도했던 것, 경쟁사, 다른 산업군을 조사하여 솔루션에 도움될만한 자료를 모으는 것으로 시작한다. 모은 자료는 각자가 돌아가며 3~5분 수준으로 공유하고, 화이트보드에 기록해둔다.

이제 팀원들에게 각자의 시간이 주어진다. 이 시간에는 3가지 활동을 하게 되는데, 진행자는 적절히 시간을 알람하며 다음 활동으로 넘어갈 수 있도록 돕는다

지금까지 화이트보드에 정리된 내용을 보며 자유롭게 끄적거려본다. 자기 나름 전체 정보를 파악하는 시간이다 (20분)

정리된 정보를 토대로 이번엔 솔루션에 대한 아이디어를 끄적거려본다 (20분)

A4용지를 8등분하여 8분간 빠르게 8개의 아이디어를 스케치해본다. 8개가 다 다를 필요는 없으며 다른 아이디어의 수정/추가 버전이어도 된다 (8분)

마지막으로 지금까지의 활동을 모아서 30분간 1개, 혹은 2개 정도의 솔루션을 A4용지에 스케치한다. 솔루션은 2개를 넘어가지 않도록 한다 (30분) 글이든 그림이든 상관없지만, 반드시 제목과 해결 포인트를 명시하도록한다. 각자의 솔루션은 진행자가 모아서 ‘익명’으로 화이트보드에 붙여두고 오늘의 세션을 마친다.

4. 솔루션 선정 (참고​)

수요일의 목표는 솔루션을 채택하고 스토리보드화하는 것이다. 팀원들은 스티커를 들고 어제 벽에 붙여둔 솔루션들을 보며 맘에 드는 ‘부분’에 스티커를 붙이고, 포스트잇으로 솔루션 아래에 피드백을 써둔다 (스티커 수에 제한은 없다) 끝나면 진행자는 팀원들에게 각 솔루션, 피드백을 읽어주고, 마지막에는 솔루션을 제출한 사람이 부연 설명을 한다.

이제 솔루션을 진짜 결정하는 시간이다. 각 팀원은 1개, 최종 의사결정권자는 3개의 스티커를 가지고 솔루션에 최종 투표를 한다. 단, 이 때 진행자는 반드시 첫날 적었던 문제와 목표에 대해서 팀원들에게 상기시킨다. 투표 결과에 맞추어 솔루션을 우선순위 배치하며, 이번에 실행하지 못하는 솔루션은 자연스레 우선순위로 백로그가 된다.

디자이너를 중심으로 솔루션을 스토리보드화(프로토타입을 만들 수 있도록 flow를 정리)하고 오늘의 세션을 종료한다.

5. 프로토타이핑 (참고​)

목요일의 목표는 프로토타입을 빠르게 제작하는 것이다. 회사마다 프로토타이핑 방법은 다르므로 자유롭게 사용하면 된다. 보통 우리 회사에서는 protopie를 이용하는데, PPT를 사용하든, 인쇄물을 사용하든 상황에 맞게 작업하면 된다. 신규 런칭이 아닌 경우는 기존 서비스에 붙여서 APK를 뽑는게 편한 경우도 있다.

6. 고객 검증과 피드백 (참고​)

금요일의 목표는 고객에 솔루션을 검증하고, 진행 여부를 피드백하는 것이다. 고객 검증자체는 각 회사마다의 방법을 사용하거나, 이후 ‘린 고객개발’의 내용을 다뤄보려고 한다. 이 과정에서는 5명 정도의 고객을 선정하여 직접 솔루션을 사용하게 하고 관찰, 질문하는 수준의 UT가 이루어진다.

이제 솔루션이 고객에 유효하다고 판단되면 실제 개발을 진행하면된다. 혹은 솔루션이 틀렸다고 판단되면, 선정과정에서 제외되었던 다음 우선순위를 꺼내어 프로토타이핑-검증을 반복한다. 첫번째 사이클이 5일을 소요했다면, 두번째 사이클부터의 반복은 2일이 걸린다고 볼 수 있다.

디자인 스프린트, 어떤 한계가 있을까?

구글벤처스의 영상을 보면 디자인 스프린트의 과정은 굉장히 재밌고 ‘스타트업’ 같아 보인다. 그렇다는 것은 반대로 실무자 입장에서는 이상적으로 보일 수 있다는 얘기다. 당장 바빠 죽겠는데, 5일을 비워서 스타트업 놀음을 하는 것처럼 보이면 “그건 구글이니까 그런 거고...”라는 말을 듣기 십상이다.

이에 대한 해결방법은 처음부터 새로운 방법을 알아왔다면서 오리지널 버전을 적용하려 하지말고, 부분 적용하거나 압축 적용하는 것이다. ‘문제 및 가설정리’, ‘솔루션 도출’은 2~3시간 정도의 아이디어 회의 형태로 떼내어 해볼 수 있다. ‘고객 검증과 피드백’은 어떤 형태의 프로토타입을 고객에 검증하고 결과를 팀원에 공유하는 그 자체로 같이 고객에 대해 생각해보는 좋은 시작점이 된다. 작은 크기의 문제를 가지고 하루동안 디자인 스프린트 순서를 따르는 워크샵을 진행하면서, 짧게 짧게 전 과정을 팀원들에 익숙하게 해주는 방법도 의미가 있다. (하루안에 솔루션 결정까지 할 수 있도록 문제가 충분히 작아야한다. 겉핥기만 하면 오히려 팀원들이 이상적으로 느낀다)

이상적으로 보이는 것 외에도 디자인 스프린트 적용을 재고해야할 경우는, 프로토타이핑 하는 것보다 그냥 만들어서 테스트하는게 더 빠른 경우다. 예를 들어 충분한 유저 트래픽, A/B테스트 환경, 실험에 열린 마음을 가진 개발자들, 길지 않은 배포주기를 가진 스타트업이라면 굳이 프로토타이핑 하는 것 보다 2~3일만에 만들어서 테스트하는게 빠르다. 굳이 그런 환경을 갖춘 스타트업에 디자인 스프린트를 적용할 필요는 없을 것 같다 (물론, 기존 서비스를 벗어난 신규 서비스 런칭은 얘기가 좀 다른 것 같다) 다만, 우리나라에 그 정도 환경을 갖춘 스타트업은 별로 없고, 오히려 배포 주기내에 다음, 다다음 솔루션들을 미리 고객 검증하는게 유리한 경우가 대부분인 것 같다.