지속적 디스커버리

고객을 만나는 일은 오랫동안 프로젝트였습니다. 새 분야에 들어가거나 큰 개편을 앞두면 두어 달 예산을 잡아 스무 명 남짓을 인터뷰하고, 결과를 문서로 묶어 공유하고, 그다음 여섯 달은 그 문서를 근거로 삼았습니다.

문제는 문서가 나오는 순간부터 낡기 시작한다는 데 있었습니다. 인터뷰를 마치고 정리하는 데 3주가 걸리는 동안 경쟁 제품이 하나 나오고, 문서가 공유될 즈음에는 사용자가 이미 다른 습관을 들인 경우가 생깁니다. 게다가 다음 조사까지 남은 석 달 동안 새로 생긴 질문에는 답할 방법이 없습니다. 팀은 결국 그 기간을 감으로 건넙니다.

페이지덱에서도 이 간격이 그대로 드러났습니다. 분기 초에 지현이 스무 명을 만나 정리한 문서가 있었는데, 두 달 뒤 회의에서 "문서 만들다 만 사람들이 왜 이탈하는지" 라는 질문이 나오자 아무도 답하지 못했습니다. 그 질문은 인터뷰 때 묻지 않은 것이었고, 다음 조사는 넉 달 뒤였습니다. 그날 회의는 각자의 짐작을 한 시간 주고받다 끝났습니다.

지속적 디스커버리는 조사의 규모를 줄이는 대신 횟수를 늘려 이 간격을 없앱니다. 한 번에 스무 명을 만나고 석 달을 비우는 대신 매주 한두 명을 만나면, 이번 주에 생긴 질문을 다음 주에 물어볼 수 있습니다. 근거가 쌓이는 속도가 질문이 생기는 속도를 따라가는 것이 이 방식의 핵심입니다.

고객을 만나는 일을 매주 같은 자리에 고정하고, 거기서 나온 것을 그 주의 판단에 바로 넣습니다. 도는 순서는 다섯 단계입니다.

1. 주간 고정 시간을 잡습니다. 매주 화요일 오후 두 시처럼 캘린더에 미리 박아 두고, 그 주에 만날 사람이 없어도 시간은 비워 둡니다. 여유가 생길 때 하기로 하면 바쁜 주에 가장 먼저 밀립니다.
2. 사람이 끊기지 않게 모집 경로를 만들어 둡니다. 제품 안에 참여 신청 링크를 두거나 최근 가입자에게 자동으로 메일이 나가게 해 두면 대기 명단이 유지됩니다. 매주 사람을 새로 구하러 다니면 두어 달 만에 멈춥니다.
3. 기획·디자인·개발이 함께 듣습니다. 고객 인터뷰를 한 사람이 듣고 옮겨 적으면 옮기는 과정에서 대부분이 사라집니다. 페이지덱에서는 지현이 묻고 민서가 기록하고 태오가 옆에서 듣습니다.
4. 들은 것을 그날 기회 솔루션 트리에 붙입니다. 목표 아래에 기회를, 기회 아래에 해법 후보를 다는 그림입니다. 주마다 붙이면 같은 불편이 몇 번 나왔는지가 눈에 보이고, 한 명이 말한 것과 여섯 명이 말한 것이 구분됩니다.
5. 다음 주에 확인할 추측을 하나 고릅니다. 이 단계의 결과물이 가설입니다. 화면만 그린 프로토타입을 다음 주 인터뷰에서 보여 주면, 만든 다음이 아니라 만들기 전에 틀린 방향이 걸러집니다.

절차를 도는 내내 사용자 리서치의 기본은 그대로 적용됩니다. 원하는 답을 유도하지 않고, 앞으로 어떻게 하겠냐고 묻는 대신 지난번에 실제로 어떻게 했는지를 묻습니다.

사용자에게 직접 닿을 수 있는 제품에 맞습니다. 개인이 가입해서 쓰는 서비스라면 제품 안에서 바로 참여자를 모을 수 있어 주 단위 리듬이 유지됩니다. 반대로 기업 고객만 있는 제품은 한 명을 만나는 데 세일즈 담당자를 거쳐 고객사 일정을 잡아야 해서 주 단위가 서지 않습니다. 그런 팀은 만나는 간격을 격주나 월로 늘리고, 대신 이미 쌓여 있는 고객의 소리와 지원 문의 기록을 매주 읽는 것으로 자리를 채웁니다.

세 가지 한계를 함께 봅니다.

1. 같은 사람만 만나게 되기 쉽습니다. 참여 신청을 하는 사람은 대개 제품을 열심히 쓰는 쪽이라, 몇 달 지나면 이탈한 사람의 이유는 한 번도 듣지 못한 채 열성 사용자의 요구만 쌓입니다. 분기에 한 번은 이탈한 계정에 따로 연락합니다.
2. 듣는 것과 정하는 것은 다릅니다. 매주 고객을 만나도 무엇을 만들지는 팀이 정합니다. 이 방식은 판단의 재료를 대는 장치이지 판단을 대신하는 장치가 아닙니다.
3. 값을 못 하는 구간이 있습니다. 되돌리기 쉬운 작은 변경이나 이미 답이 분명한 일에까지 매주 확인 절차를 붙이면, 2주면 끝날 일이 6주가 됩니다.

"이번 주 인터뷰에서 두 명이 같은 말을 했어요. 트리에 기회로 하나 달아 둘게요."

들은 것을 그 주에 바로 정리해 다음 판단의 재료로 올린다는 말입니다.

"다음 주 화요일 인터뷰에 이 프로토타입 가져가서 반응 보고 올게요."

만들기 전에 확인하는 자리가 이미 잡혀 있다는 뜻입니다.

"저희는 리서치를 따로 안 잡아요. 매주 하고 있어서요."

조사가 프로젝트가 아니라 상시 활동이라는 답입니다.

페이지덱은 화요일 오후를 인터뷰 시간으로 고정했습니다. 지현이 두 명을 잡아 두고, 민서와 태오가 번갈아 들어옵니다. 끝나면 30분 안에 셋이 남아 그날 들은 것 중 트리에 붙일 것을 정합니다. 여기서 오래 이야기하지 않는 것이 규칙입니다. 결론을 내는 자리가 아니라 재료를 쌓는 자리이기 때문입니다.

넉 달쯤 지나자 회의 모양이 달라졌습니다. 규원이 왜 이 기능이냐고 물으면 지현이 지난 6주 동안 같은 불편을 말한 사람이 아홉 명이라고 답합니다. 반대로 아무도 말하지 않은 기능은 만들자는 말이 나와도 다음 인터뷰에서 물어보는 것으로 미뤄집니다.

고객이 원하는 것을 매주 물어 그대로 만드는 방식이라는 오해가 가장 흔합니다. 고객을 자주 만난다는 점만 보면 그렇게 읽힙니다. 실제로는 고객에게 해법을 묻지 않고 겪은 일을 묻습니다. 사용자는 자기가 무엇에 막혔는지는 정확히 말하지만 그것을 어떻게 풀지는 대개 지금 아는 화면 안에서만 떠올립니다. 요청을 그대로 받아 만들기 시작하면 서로 안 맞는 기능이 늘어나고, 정작 아홉 명이 공통으로 겪던 불편은 그대로 남습니다.

리서처나 기획자 한 사람이 맡는 일이라는 오해도 자주 봅니다. 전담자가 있으면 효율적으로 보이기 때문입니다. 하지만 전담자를 두면 듣는 사람과 만드는 사람이 갈라지고, 그 사이는 다시 문서로 이어집니다. 문서로 옮기는 순간 말투와 망설임과 화면 앞에서 멈칫한 3초가 빠집니다. 개발자가 인터뷰를 한 번 들으면 문서 열 장을 읽은 것보다 네 가지 리스크 중 실현 가능성 판단이 빨라집니다.