출시 전 사용자 조사 대부분은 연극이며, 최악의 부분은 양쪽 모두 자신의 대사를 알고 있다는 것입니다. "이런 걸 쓰실 것 같나요"라고 물으면, 통화 상대방 — 친절하게 대하는 중이고, 아무런 이해관계도 없으며, 존재하지 않는 제품을 상상하고 있는 사람 — 은 그렇다고 답합니다. 여러분은 이것을 검증으로 기록합니다. 하지만 아닙니다. 낯선 사람이 가상의 상황에 대해 예의를 차리는 것일 뿐입니다.
저는 예전에 이런 인터뷰를 종교처럼 진행했습니다. 모든 제품 전략 책이 그렇게 하라고 말하기 때문입니다. 코드 한 줄 쓰기 전에 사용자 50명과 대화하라. 페인 포인트를 찾아라. 솔루션 이전에 문제를 검증하라. 규율 있게 들리고, 화이트보드에 적어놓으면 그럴싸해 보입니다. 하지만 열 번의 디스커버리 콜에서 실제로 나오는 결과물은, 여러분이 듣고 싶어 할 것 같은 말을 하는 열 명의 사람들이며, 그마저도 통화가 시작되고서야 생각하기 시작한 문제에 대한 자기 자신의 막연한 기억을 거친 것입니다. 아무도 일부러 거짓말을 하는 게 아닙니다. 단지 아직 그 정보를 갖고 있지 않을 뿐입니다 — 그 물건이 존재하기 전까지는 그 정보 자체가 존재하지 않기 때문입니다.
인터뷰로는 얻을 수 없는 것
빌드하기 전에 실제로 알아야 할 것은 태도가 아니라 행동입니다. 이 사람이 이 앱을 두 번째로 열어볼 것인지, 돈을 지불할 것인지, 세 번째 화면에서 막혀 그만둘 것인지. 이런 것들은 대화에서는 전혀 드러나지 않습니다. 세션 리플레이, 이탈률 차트, 지원 티켓에서 드러납니다. 사용자는 완전히 진심으로 온보딩이 "이해가 된다"고 말하고서 40초 만에 포기할 수 있습니다. 자기 보고와 행동은 서로 다른 것을 측정하는 서로 다른 도구이기 때문입니다.
경제적 논리도 어차피 인터뷰를 먼저 하도록 강요해왔습니다. 무언가를 만드는 데 8주와 엔지니어 3명이 필요하다면, 출시 후에야 그것이 틀렸다는 것을 알게 되는 여유를 부릴 수 없습니다 — 그래서 위험을 저렴한 대화에 미리 부담시켜 값비싼 실수를 잡아내길 바라는 것입니다. 그 거래는 빌드가 병목이었을 때는 타당했습니다. 이제는 아닙니다. 작동하는 프로토타입 — 실제 인증, 실제 데이터베이스, 실제로 클릭해볼 수 있는 UI — 은 이제 적절한 도구(제 도구 포함)만 있으면 하루 오후 만에 만들 수 있는 것입니다. 첫 버전의 비용이 이 정도까지 떨어지면, 인터뷰는 더 이상 저렴한 위험 감소 수단이 아니라 오히려 값비싼 단계가 됩니다. 주말 만에 끝낼 수 있는 빌드를 피하려고 몇 주의 시간을 쓰고 있는 셈입니다.
제가 대신 하는 것
아이디어의 가장 작은 실제 버전을 만들고, 그 문제를 실제로 겪고 있는 사람 3~5명 앞에 두고, 묻지 말고 관찰하세요. "어떻게 생각하세요"가 아니라 — 커서가 어디서 머뭇거렸는지, 아무 반응도 없는 것을 무엇을 클릭했는지, 제품이 전혀 지원하지 않는 무엇을 시도했는지. 마지막이 진짜 금맥입니다. 유도 없이 시도한 그것은 가상의 인터뷰에서 그들이 말했을 그 어떤 것보다 더 진실한 신호입니다. 표명된 선호가 아니라 드러난 선호이기 때문입니다.
이것은 전통적인 리서치 퍼널을 뒤집으며, 무엇이 바뀌는지 명확히 짚어볼 가치가 있습니다:
| 인터뷰 우선 | 빌드 우선 | |
|---|---|---|
| 측정하는 것 | 표명된 의도 ("아마 쓸 것 같아요") | 드러난 행동 (이번 주에 세 번 열어봤다, 혹은 열어보지 않았다) |
| 틀렸을 때의 비용 | 회당 비용은 낮지만, 수십 번의 인터뷰 동안 몇 달간 틀릴 수 있음 | 한 번의 빌드 사이클, 이후 데이터가 빠르게 바로잡아줌 |
| 가장 좋은 질문 | "오늘 이 작업을 하면서 답답한 점이 뭔가요?" | "여기서 X를 시도했던 가장 최근 순간을 보여주세요" |
| 무엇을 찾아내는 데 효과적인가 | 문제가 애초에 존재하는지 여부 | 당신의 특정 해결책이 실제로 통하는지 여부 |
| 실패 양상 | 모두가 예의는 갖추지만 누구도 솔직하지 않아서, 엉뚱한 것을 자신 있게 만들게 된다 | 신뢰를 얻기도 전에 완성도 낮은 것을 출시하게 되고, 그로 인해 첫인상이 나빠진다 |
두 항목이 서로 상쇄되지 않는다는 점에 주목하라 — 각각 다른 질문에 답하고 있을 뿐이다. 인터뷰는 문제가 실재한다는 것을 확인하는 데는 꽤 쓸 만하다. 하지만 당신의 특정 해결책이 옳은지 말해주는 데는 형편없는데, 그 해결책이 아직 존재하지 않아서 누구도 그것에 대해 솔직하게 반응할 수 없기 때문이다. 이것이 "사용자와 대화하라"는 조언 대부분이 얼버무리고 넘어가는 구분점이다: 문제 발굴에는 대체로 좋은 조언이지만, 솔루션 검증에는 대체로 나쁜 조언인데, 사람들은 이 둘 모두에 똑같이 적용해버린다.
내가 아는 한 창업자는 미용실을 겨냥한 예약 관리 도구를 위해 열네 번의 인터뷰를 진행했다. 열세 명이 중복 예약 문제가 실제로 존재하고 고통스럽다고 답했다. 그녀는 그것을 만들었다. 하지만 채택률은 제자리걸음이었다. 알고 보니 미용실 사장들은 추상적으로는 중복 예약을 싫어했지만, 이미 포기하고 싶지 않은 어설픈 개인적 우회 방법을 만들어 놓은 상태였다 — 이는 아무도 언급하지 않은 사실이었는데, 대체 수단을 직접 보여주고 그것을 거부하는 모습을 지켜보지 않는 한, 누구도 자신의 대처법을 굳이 설명할 생각을 하지 않기 때문이다.
비판자들이 옳은 지점
이것이 모든 경우에 적용되는 것은 아니며, 그렇다고 우긴다면 과대 포장하는 셈이다. 만약 구축 자체를 되돌리는 비용이 정말로 크다면 — 하드웨어라든지, 규제 대상 의료 워크플로우라든지, 변경 하나하나에 컴플라이언스 검토가 따라붙는 무언가라면 — 인터뷰 우선 계산법은 다시 뒤집힌다. 구축을 먼저 하는 것을 저렴하게 만들어주는 비용 비대칭성 자체가 그런 곳에서는 성립하지 않기 때문이다. 오후 한나절이면 버릴 수 있는 프로토타입과, 이미 금형을 뜬 장치는 완전히 다른 종류의 물건이다.
리서치가 제 몫을 하는 또 다른 곳은 영업 주기가 긴 엔터프라이즈 세일즈다. 구매자가 조달 위원회이고 영업 주기가 넉 달이라면, "일단 출시하고 지켜보는" 식으로는 계약 체결까지 갈 수 없다 — 구축에 앞서 그것이 보안 검토를 통과할 수 있는지부터 알아야 한다. 6개월 만에 거래가 무산되는 비용은 어떤 인터뷰 비용보다 훨씬 크기 때문이다. 그리고 순수한 문제 발굴 — 미래의 제품을 상상해 달라고 요청하는 것이 아니라, 누군가 실제 업무를 처리하는 모습을 옆에서 지켜보는 것 — 은 이른 시기에 저비용으로 이루어질 경우 실제로 저평가되어 있고 실제로 유용하다. 사람들과 대화하는 것 자체를 반대하는 게 아니다. 정중한 가상의 대화를 증거로 취급하는 것을 반대하는 것이다 — 완성도 낮은 실제 결과물을 같은 사람 앞에 10분만 놓아두어도 진실을 알려줄 수 있는데도 말이다.
