제품 디스커버리

제품을 만드는 일은 오랫동안 주문을 받아 처리하는 일에 가까웠습니다. 영업이 고객에게서 들은 요청을 적어 오고, 대표가 경쟁사에서 본 기능을 적어 오고, 개발팀은 그렇게 모인 목록을 위에서부터 만들었습니다. 무엇을 만들지는 이미 정해진 것으로 취급됐고 남은 질문은 언제까지 만드느냐뿐이었습니다.

그러다 보니 회의는 늘 같은 자리에서 멈췄습니다. 누군가 "이거 정말 쓸까요" 하고 물으면 "고객이 요청한 겁니다" 라는 답이 돌아옵니다. 몇 명이 요청했는지, 그 사람들이 원한 것이 정말 이 기능인지는 아무도 확인하지 않았습니다. 확인할 방법이 정해져 있지 않았으니 질문을 던진 쪽이 멋쩍어지고 그대로 넘어갔습니다. 요청 목록은 분기마다 예순 건씩 쌓였고, 그중 무엇이 실제 수요이고 무엇이 한 사람의 인상인지를 가려내는 일은 아무의 업무도 아니었습니다.

문제는 다 만든 다음에야 드러났습니다. 넉 달을 들여 내놓은 기능을 한 달 동안 쓴 계정이 스물세 개였다는 식입니다. 그런데 이 시점에는 누구를 탓하기도 어렵습니다. 개발팀은 요청받은 것을 기한 안에 만들었고, 영업은 실제로 들은 말을 전했고, 기획은 적힌 대로 문서를 썼습니다. 각자 자기 몫을 제대로 했는데 결과만 없습니다.

빠져 있던 것은 만들기 전에 만들 값어치를 따지는 자리였습니다. 그 자리가 없으면 아이디어는 검증을 거치지 않고 곧장 일정표로 들어가고, 틀렸다는 사실은 가장 비싼 방법으로, 그러니까 다 만들어 내보낸 뒤에 확인됩니다. 넉 달치 인건비를 다 쓴 다음에야 답을 얻는 셈입니다. 같은 답을 2주 만에 얻을 방법이 없었던 것도 아닙니다. 고객 일곱 명에게 화면 그림을 보여 주는 일은 그때도 할 수 있었지만, 그 일을 누가 언제 하는지가 일정표 어디에도 적혀 있지 않았습니다.

제품 디스커버리는 그 자리를 일정 안에 집어넣은 것입니다. 만드는 일과 별개로 확인하는 일에도 사람과 시간을 배정하고, 통과한 것만 만드는 쪽으로 넘깁니다. 틀린 방향을 접는 비용을 넉 달에서 2주로 내리는 것이 이 활동이 노리는 전부입니다.

제품 디스커버리 아래 묶인 용어는 네 갈래입니다. 이 활동을 어떤 리듬으로 돌리는지(방법), 알아낸 것을 무엇으로 정리하는지(도구), 무엇을 글로 남기는지(산출물), 어디까지 확인해야 끝난 것으로 보는지(관점)입니다.

갈래를 보기 전에 한 바퀴가 어떻게 도는지부터 짚습니다. 실무에서 도는 순서는 대개 다섯 단계입니다.

1. 이번에 움직이려는 숫자를 하나 정합니다. 가입 후 첫 주에 다시 들어오는 비율 같은 것입니다. 목표가 없으면 아래 네 단계가 전부 취향 다툼이 됩니다.
2. 고객을 만납니다. 사용자 리서치로 직접 쓰는 모습을 보고 묻거나, 이미 쌓인 문의와 불만을 모아 둔 고객의 소리를 읽습니다. 보통 예닐곱 명을 만나면 같은 말이 반복되기 시작하고, 그 지점부터는 사람을 더 늘려도 새로 나오는 것이 거의 없습니다.
3. 들은 것 중에서 이번에 풀 문제를 하나 고릅니다. 다섯 명이 말한 불편과 한 명이 말한 불편은 무게가 다르고, 무게가 같더라도 1번에서 정한 숫자와 이어지지 않는 것은 접습니다. 이 단계에서 열 개 중 아홉 개를 버린다고 보면 맞습니다.
4. 그 문제를 어떻게 풀지 추측을 적습니다. 이 단계의 결과물은 답이 아니라 확인할 수 있게 적은 추측입니다.
5. 가장 싼 방법으로 그 추측을 확인합니다. 화면만 그린 프로토타입을 다섯 명에게 보여 주거나, 아직 없는 기능의 버튼만 먼저 달아 두고 누르는 사람 수를 셉니다.

방법은 이 다섯 단계를 어떤 리듬으로 반복하는지를 가르는 갈래입니다. 둘이 있고 기준은 무엇과 나란히 도느냐입니다.

1. 듀얼 트랙 애자일 — 탐색과 개발을 두 갈래로 동시에 돌립니다. 이번 주기에 개발팀이 지난번에 통과한 것을 만드는 동안, 같은 팀의 다른 몇 명이 다음 주기에 만들 후보를 확인합니다. 탐색이 개발 앞을 한 칸씩 걸어가는 모양이라 개발팀이 손을 놓고 기다리는 구간이 생기지 않습니다.
2. 지속적 디스커버리 — 고객을 만나는 일을 프로젝트가 아니라 습관으로 만듭니다. 분기마다 몰아서 스무 명을 만나는 대신 매주 한두 명을 꾸준히 만납니다. 몰아서 하면 자료가 쌓이는 동안 시장이 이미 움직여 있고, 다음 몰아치기 전까지 석 달 동안은 다시 감으로 판단하게 됩니다. 매주 만나면 지난주에 세운 추측을 이번 주에 바로 확인할 수 있어서, 틀린 방향이 일정표까지 올라가기 전에 걸러집니다.

도구는 알아낸 것을 한 장에 펼쳐 놓는 갈래이고 하나뿐입니다. 기회 솔루션 트리는 맨 위에 목표를 두고, 그 아래에 목표를 막고 있는 기회를 늘어놓고, 기회마다 해법 후보를 달고, 해법마다 그것을 확인할 실험을 답니다. 이렇게 그리면 논의가 어느 층에서 엇갈리고 있는지가 눈에 보입니다. 한 사람은 기회를 말하는데 다른 사람은 해법을 말하는 상황이 회의에서 가장 흔하게 헛도는 자리입니다. 재방문을 늘리자는 목표 아래에 알림이 부족하다는 기회와 처음에 쓸 거리가 없다는 기회가 나란히 걸려 있고, 두 번째 기회 밑에만 해법이 세 개 달려 있다면 이번 분기에 무엇을 확인할지가 그림만 보고도 정해집니다. 층이 나뉘어 있으니 해법 하나가 죽어도 그 위의 기회는 남고, 다른 해법을 그 자리에 다시 답니다.

산출물은 탐색의 결과를 남에게 넘길 수 있는 글로 만드는 갈래이고 둘이 있습니다. 앞은 문제 쪽, 뒤는 해법 쪽입니다.

1. 문제 정의 — 누구의 어떤 문제를 왜 지금 푸는지를 한 문단으로 못 박습니다. 이 문단이 없으면 넉 달 뒤에 기능이 원래 겨냥하던 문제와 다른 것을 풀고 있어도 아무도 알아채지 못합니다.
2. 가설 — 해법이 그 문제를 풀 것이라는 추측을, 참인지 거짓인지 가릴 수 있는 형태로 적습니다. "예시 문서를 띄우면 첫 문서를 만드는 비율이 34퍼센트에서 40퍼센트로 오른다" 처럼 숫자와 기준을 함께 적어야 2주 뒤에 결과를 두고 다투지 않습니다.

관점은 무엇을 다 확인해야 끝난 것으로 볼지를 정하는 갈래이고 하나뿐입니다. 네 가지 리스크는 확인할 것을 넷으로 나눕니다. 사람들이 이걸 원하는가(가치), 쓸 줄 아는가(사용성), 만들 수 있는가(실현 가능성), 회사가 감당할 만한가(사업 타당성)입니다. 넷 중 하나만 확인하고 넘어가는 일이 잦은데, 대개 사용성만 보고 가치를 건너뜁니다. 화면을 다듬는 일은 눈에 보이고 필요 자체를 의심하는 일은 불편하기 때문입니다. 쓰기 편한데 아무도 원하지 않는 기능은 쓰기 불편한 기능보다 더 고치기 어렵습니다. 고칠 곳이 없기 때문입니다.

네 갈래는 따로 놀지 않습니다. 방법이 한 바퀴의 주기를 정하고, 도구가 그 안에서 논의를 층으로 갈라 주고, 산출물이 합의된 것을 글로 못 박고, 관점이 무엇을 빠뜨렸는지 확인합니다. 다만 이 한 바퀴가 늘 값을 하는 것은 아닙니다. 되돌리기 쉬운 작은 변경이나 이미 답이 분명한 일에까지 가설을 세우고 사람을 만나면, 2주면 끝날 일이 6주가 되고 팀은 확인만 하다 아무것도 내놓지 못합니다.

"그건 아직 가설이에요. 이번 주에 고객 다섯 명 만나 보고 정합시다."

지금 논의가 근거 없는 추측 단계이니 더 다투지 말고 확인부터 하자는 제동입니다.

"디스커버리 트랙에서 두 주 돌려 보고, 통과하면 다음 주기 백로그에 넣을게요."

만드는 일정과 별개로 탐색이 먼저 돌고 있고 거기서 통과한 것만 개발로 넘어간다는 뜻입니다.

"이건 사용성 문제가 아니라 가치 문제 같아요. 화면을 고쳐도 안 쓸 겁니다."

쓰기 불편해서 안 쓰는 것이 아니라 필요 자체가 없다는 진단이라, 화면을 다듬는 방향으로 시간을 더 쓰지 말자는 말입니다.

페이지덱에서는 문서 승인 기능을 두고 이 절차가 한 바퀴 돌았습니다. 수아가 기업 고객 네 곳에서 같은 요청을 받아 왔고, 목록 맨 위에 올릴 만큼 강한 요청이었습니다.

지현은 만들기 전에 두 주를 썼습니다. 요청한 네 곳을 포함해 일곱 팀을 만나 실제로 어떤 상황에서 곤란했는지를 물었습니다. 반복해서 나온 말은 승인이 아니었습니다. 누가 언제 무엇을 고쳤는지 모른 채 최종본이 바뀌어 있는 상황이 무서운 것이었고, 승인은 그 상황을 막으려고 떠올린 방법일 뿐이었습니다.

민서가 두 가지 화면을 그렸습니다. 하나는 요청받은 대로 결재선을 두는 안, 하나는 중요한 문서가 바뀔 때 관련된 사람에게 알리고 바뀐 부분을 나란히 보여 주는 안이었습니다. 같은 일곱 팀에 보여 주자 여섯 팀이 두 번째를 골랐습니다. 태오는 두 번째가 결재선을 만드는 것보다 개발이 절반쯤 든다고 답했습니다. 요청은 그대로 받았지만 만든 것은 다른 기능이었고, 그 판단에 쓴 시간은 두 주였습니다. 결재선을 그대로 만들었다면 넉 달이 들었을 테고, 네 곳이 원한 것이 아니었다는 사실은 그 넉 달이 끝난 뒤에야 알게 됐을 것입니다.

개발에 들어가기 전에 한 번 거치는 단계라고 여기는 경우가 가장 많습니다. 기획하고 만들고 내보낸다는 그림이 워낙 익숙해서, 탐색도 그 그림의 맨 앞 칸에 놓인 것처럼 보입니다. 실제로는 만드는 동안에도 계속 돌아갑니다. 만들기 시작한 뒤에야 알게 되는 것이 늘 나오기 때문입니다. 세 번째 주에 고객이 쓰는 파일 형식이 예상과 다르다는 사실이 드러나면 그때 방향을 트는 편이 싸게 먹힙니다. 단계로 못 박아 두면 그 자리에서 "디스커버리는 끝났다" 는 말이 나오고, 이미 절반을 만들었으니 멈출 수 없다는 이유로 나머지 절반을 마저 만들게 됩니다.

고객에게 물어보면 답이 나온다고 여기는 것도 흔합니다. 탐색의 대표적인 장면이 인터뷰라서 묻는 일과 알아내는 일이 같아 보입니다. 하지만 고객은 자기가 겪은 불편은 정확히 말하는 대신 해법은 잘 고르지 못합니다. 앞의 승인 기능 요청이 그 예입니다. 네 곳 모두 승인을 달라고 말했지만 실제로 막혀 있던 것은 변경 이력이었습니다. 말을 그대로 받아 적으면 요청 목록만 길어지고, 그 목록대로 만들어도 다 만든 뒤에 쓰는 사람이 없는 상태로 돌아갑니다. 물어서 얻는 것은 해법이 아니라 상황이고, 해법은 MVP처럼 작게 내놓은 것에 사람들이 어떻게 반응하는지로 확인합니다. 그래서 인터뷰에서는 원하는 기능을 묻는 대신 지난번에 그 일을 어떻게 처리했는지를 묻습니다. 앞으로 쓰겠다는 대답은 자주 빗나가지만 지난주에 실제로 한 행동은 빗나가지 않습니다.