들어가기 앞서
제품팀은 늘 바쁘다. 인터뷰를 하고, 아이디어를 내고, 실험을 설계하고, 기능을 출시한다. 그런데 활동이 많다는 사실만으로는 올바른 제품을 만들고 있다는 확신을 얻기 어렵다. 고객을 자주 만나도 무엇을 배워야 할지 모르면 대화는 흩어지고, 데이터를 많이 모아도 어떤 문제에 집중할지 정하지 못하면 팀은 결국 가장 익숙한 해결책으로 돌아간다.
테레사 토레스의 『Continuous Discovery Habits』가 다루는 건 새로운 리서치 기법 하나가 아니다. 이 책은 제품팀의 질문 순서를 바꾼다. 곧장 “무엇을 만들까?”를 묻는 대신, 먼저 “어떤 결과를 만들려는가?”, “그 결과를 가로막는 고객의 기회는 무엇인가?”, “그중 지금 집중할 기회는 어느 것인가?”를 차례로 묻는다.
1~7장의 흐름은 한 줄로 이어진다.
원하는 결과를 정한다
↓
고객의 실제 경험을 듣는다
↓
니즈·고충·욕구를 기회 공간으로 구조화한다
↓
지금 집중할 하나의 타깃 기회를 고른다
↓
그다음에야 해결책을 탐색한다
Plain Text
복사
이 순서를 지키면 발견은 프로젝트 앞단의 일회성 단계가 아니라, 제품을 만드는 동안 계속 반복되는 의사결정 습관이 된다.
1장. 지속적인 발견이 필요한 이유
발견과 전달은 다른 일이다
제품팀의 일은 크게 두 갈래다. **발견(discovery)**은 무엇을 만들지 결정하는 일이고, **전달(delivery)**은 그것을 실제로 만들고 출시하는 일이다. 둘은 현실에서 겹치고 오가지만 요구하는 사고는 다르다.
많은 조직은 전달에는 익숙하다. 약속한 기능을 일정과 예산 안에서 출시했는지 꼼꼼히 본다. 반면 발견에는 상대적으로 적게 투자한다. 제때 만들었는지는 확인하면서도, 애초에 고객이 원하고 비즈니스에도 도움이 되는 것을 골랐는지는 늦게 묻는다. 그래서 팀은 훌륭하게 잘못된 것을 만들 수 있다.
Agile은 이 문제의 일부를 해결했다. 거대한 프로젝트를 짧은 주기로 나누고, 더 자주 피드백을 받으며, 변화에 대응하고, 불필요한 것을 덜 만들게 했다. 출시 주기도 연 단위에서 분기·월·주·일 단위로 짧아졌다. 하지만 전달 주기가 짧아진 것만으로는 무엇을 만들지 결정하는 방식까지 좋아지지 않았다. 사용성 테스트가 너무 늦게 이뤄지거나, 팀이 여전히 출시한 기능 수로 평가받거나, 고객이 원하지 않는 기능임을 배포 뒤에야 확인하는 일은 남았다.
디지털 제품은 완성되는 물건이 아니다. 시장이 바뀌고, 고객의 요구가 달라지고, 새로운 기술이 등장할 때마다 계속 진화한다. 그렇다면 무엇을 만들지 결정하는 발견도 한 번 하고 끝낼 수 없다.
제품 트리오가 함께 결정한다
책이 발견의 기본 단위로 삼는 것은 제품 트리오(product trio)다. 제품 관리자는 비즈니스 맥락을, 디자이너는 고객 경험과 시스템 설계를, 소프트웨어 엔지니어는 기술적 가능성과 안정성을 가져온다. 세 역할은 각자 산출물을 만들어 다음 사람에게 넘기는 것이 아니라, 무엇을 만들지 함께 결정한다.
‘트리오’가 꼭 세 명만 뜻하는 것은 아니다. 팀에 따라 데이터 분석가, 사용자 연구자, 제품 마케터, 고객 성공 담당자가 함께할 수 있다. 다만 참여자가 많아질수록 의사결정은 느려진다. 중요한 건 숫자보다 비즈니스·고객·기술 관점이 실제 결정에 함께 들어오는가다.
이 팀이 길러야 할 사고방식은 여섯 가지다.
•
결과 지향적: 출시한 코드보다 그 코드가 만든 변화를 본다.
•
고객 중심: 비즈니스 요구와 고객 가치를 같은 수준에서 다룬다.
•
협업적: 직군별 순차 전달 대신 팀으로 결정한다.
•
시각적: 생각을 말과 문서 안에만 두지 않고 그림과 지도로 꺼낸다.
•
실험적: 가정을 드러내고 증거로 수정한다.
•
지속적: 발견을 프로젝트 시작 단계가 아니라 상시 활동으로 만든다.
매주 고객을 만난다는 말의 진짜 뜻
책은 지속적인 발견을 이렇게 정의한다. 최소 매주, 제품을 만드는 팀이 직접 고객과 접촉하고, 원하는 결과를 추구하면서 작은 연구 활동을 수행하는 것이다.
핵심은 ‘매주 인터뷰 한 번’이라는 횟수 규칙이 아니다. 제품팀은 매일 결정을 내린다. 고객을 한 달에 한 번 만난다면 그사이 수많은 결정은 고객의 입력 없이 이뤄진다. 지속적인 발견은 고객의 경험을 팀의 일상적인 판단에 계속 공급하는 구조다.
2장. 발견의 공통 지도, 기회 솔루션 트리
비즈니스 가치와 고객 가치를 맞바꾸지 않는다
결과 중심으로 일한다고 해서 자동으로 고객 중심이 되는 것은 아니다. Wells Fargo는 고객 한 명이 가진 계좌 수를 늘린다는 명확한 결과를 추구했다. 하지만 불가능한 할당량과 강한 인센티브가 결합하자 직원들은 고객 동의 없이 계좌를 만드는 방식으로 숫자를 맞췄다. 결과는 있었지만 고객 가치는 사라졌다.
문제는 비즈니스 결과를 정한 것 자체가 아니었다. “어떤 수단으로든 계좌 수를 늘리자”라고 문제를 잘못 그린 데 있었다. “고객이 더 많은 계좌를 원하게 하려면 무엇이 달라져야 할까?”라고 물었다면 고객의 니즈를 해결하면서 비즈니스 가치를 만드는 다른 길을 찾을 수 있었을 것이다.
책은 고객의 니즈, 고충, 욕구를 한데 묶어 기회(opportunity)라고 부른다. ‘문제’라는 말만 쓰면 고장이나 불편을 고치는 일에 시야가 갇힌다. 아이스크림이나 놀이공원처럼 즐거움과 욕구를 채우는 제품도 있으므로, 제품팀이 개입해 고객의 삶을 더 낫게 만들 수 있는 모든 지점을 기회로 본다.
원하는 결과에서 가정 테스트까지
원하는 결과에 이르는 길은 정답이 하나인 문제가 아니다. 해결책이 많고, 문제를 어떻게 바라보느냐에 따라 좋은 답의 모양도 달라지는 비구조화된 문제다. 그래서 제품팀은 해결책을 내기 전에 기회 공간을 어떻게 그릴지부터 결정해야 한다.
책은 발견의 기본 구조를 네 층으로 정리한다.
1.
원하는 결과: 팀이 만들어야 할 비즈니스 가치
2.
기회 공간: 그 결과를 움직일 고객의 니즈·고충·욕구
3.
솔루션 공간: 선택한 기회를 해결할 여러 아이디어
4.
가정 테스트: 어떤 솔루션이 실제로 고객 가치와 비즈니스 가치를 만들지 평가하는 실험
이를 한눈에 보여주는 도구가 기회 솔루션 트리(Opportunity Solution Tree, OST)다.
기회 솔루션 트리: 원하는 결과에서 고객 기회, 후보 솔루션, 가정 테스트까지 발견의 경로를 연결한다.
OST는 아이디어를 예쁘게 정리하는 그림이 아니다. 팀이 지금 어떤 결과를 향하고 있고, 고객에 대해 무엇을 안다고 생각하며, 어떤 선택지를 검토하고 있고, 무엇을 테스트하는지를 한 화면에 드러내는 의사결정 지도다.
이 지도가 있으면 큰 기회를 작은 기회로 나눠 한 번에 하나씩 해결할 수 있다. 이해관계자에게도 결론만 통보하거나 인터뷰 원자료를 통째로 넘기는 대신, 어떤 선택지를 검토했고 왜 이 길을 택했는지 보여줄 수 있다.
‘할까 말까’ 대신 비교하고 대조한다
팀은 문제를 듣는 순간 해결책으로 뛰어들기 쉽다. 의견이 갈리면 “이 기능을 만들까 말까”를 두고 논쟁한다. 책은 이 질문을 경계한다. 단일 선택지만 놓고 결정하면 첫 아이디어에 갇히고, 그것을 뒷받침하는 증거만 찾기 쉽다.
대신 “지금 어느 고객 기회가 가장 중요한가?”, “이 기회를 해결할 다른 방법은 무엇인가?”라고 묻는다. 여러 기회와 여러 솔루션을 비교하고 대조하면 좁은 프레이밍, 확증편향, 아이디어에 대한 애착, 과신을 줄일 수 있다.
좋은 발견은 실패를 없애주지 않는다. 실패 가능성을 낮추고, 틀렸을 때 더 빨리 방향을 고치게 할 뿐이다. 대부분의 발견 결정은 되돌릴 수 있으므로 현재 아는 것으로 행동하되, 틀릴 준비를 함께 해야 한다.
문제 공간과 솔루션 공간도 순차 단계가 아니다. 솔루션을 테스트하다 실패하면 “다음 아이디어를 해보자”로 끝낼 것이 아니라, “우리는 고객을 무엇이라고 잘못 이해했나?”를 되물어 기회 공간을 고쳐야 한다. 반대로 고객을 새롭게 이해하면 이전에는 보이지 않던 솔루션이 열린다.
문제 공간과 솔루션 공간은 분리된 단계가 아니라 서로를 배우며 함께 진화한다.
3장. 산출물보다 결과에 집중하기
로드맵은 답을 미리 정하고, 결과는 탐색할 공간을 남긴다
기능 로드맵은 팀에 무엇을 만들지 알려준다. 편리하지만 그 해결책이 이미 옳다는 가정도 함께 전달한다. 반면 결과는 “어떤 변화를 만들어야 하는지는 알지만 최선의 해법은 아직 모른다”는 불확실성을 인정한다. 그래서 팀이 고객과 기술에 대한 지식을 활용해 여러 길을 탐색할 수 있다.
명확한 결과는 발견의 범위를 정한다. 어떤 고객을 만나고, 어떤 기회를 주목하고, 실험이 효과가 있었는지 무엇으로 판단할지가 결과에서 나온다. 반대로 결과가 없으면 인터뷰와 아이디어는 끝없이 넓어진다.
tails.com 팀은 장기 유지율을 높이려 했다. 처음에는 90일 유지율을 봤지만 실험의 효과를 확인하려면 너무 오래 기다려야 했다. 30일, 5일 유지율로 줄여도 장기 성과를 제대로 예측하지 못했다. 고객 인터뷰를 하자 이탈과 연결된 두 가지가 보였다. 고객이 맞춤 사료의 가치를 충분히 이해하지 못했고, 어떤 개는 사료를 좋아하지 않았다.
팀은 이를 ‘맞춤 사료의 가치를 이해하는 고객 수’와 ‘사료를 좋아하는 개의 수’라는 더 빠르고 직접적인 제품 성과로 바꿨다. 장기 유지율이라는 비즈니스 성과를 포기한 것이 아니라, 제품팀이 실제로 움직일 수 있고 장기 성과를 앞서 보여주는 지표를 찾은 것이다.
비즈니스 성과, 제품 성과, 트랙션 지표
책은 결과 지표를 세 층으로 나눈다.
•
비즈니스 성과는 유지율, 매출, 수익성처럼 사업의 진전을 나타낸다. 대개 늦게 움직이고 여러 부서의 영향을 함께 받는다.
•
제품 성과는 제품이 그 비즈니스 가치를 어떻게 움직이는지 보여준다. 제품 트리오의 통제 범위 안에 있고 비즈니스 성과를 앞서 예측할 수 있어야 한다.
•
트랙션 지표는 특정 기능이나 워크플로의 사용량을 잰다. 이미 특정 솔루션이 맞다고 가정하므로 발견의 폭을 좁힐 수 있다.
트랙션 지표가 언제나 나쁜 것은 아니다. 고객 수요가 확인된 성숙 기능을 최적화하거나, 발견 경험이 적은 팀이 좁은 범위에서 연습할 때는 유용하다. 다만 ‘transition calendar 사용률’을 목표로 주면 캘린더라는 솔루션을 미리 고정한다. ‘사료를 좋아하는 개의 수’라면 캘린더 외의 다양한 솔루션을 탐색할 여지가 남는다.
결과는 위에서 내려오는 숫자가 아니다
좋은 결과는 제품 리더와 제품 트리오의 양방향 협상으로 정한다. 리더는 회사의 전략과 비즈니스 맥락을 설명하고, 트리오는 고객과 기술에 대한 지식을 바탕으로 무엇을 어느 기간 안에 움직일 수 있을지 답한다. 더 높은 목표를 원한다면 더 많은 자원·위험·집중이 필요하다는 사실도 함께 조정한다.
새로운 결과를 맡은 팀에 처음부터 정밀한 수치 목표를 요구하면, 아직 무엇이 지표를 움직이는지도 모르는 상태에서 약속부터 하게 된다. 이때는 먼저 학습 목표로 시작해 어떤 전략이 효과가 있는지 찾고, 길이 보이면 도전적인 성과 목표로 옮기는 편이 낫다.
한 팀에 여러 결과를 동시에 주거나, 분기마다 결과를 바꾸거나, 트리오 구성원마다 따로 목표를 주는 방식은 공통 초점을 무너뜨린다. 기능 이름을 결과처럼 바꾸거나, 하나의 지표를 위해 고객 만족도 같은 건강 지표를 희생하는 것도 같은 함정이다.
4장. 고객을 만나기 전에, 알고 있다고 믿는 것을 그린다
경험 맵은 사실이 아니라 가설의 지도다
결과를 정하고 나면 팀은 고객을 만나고 싶어진다. 책은 그 전에 한 단계를 둔다. 제품 트리오가 고객 경험에 대해 현재 알고 있다고 생각하는 것을 먼저 그려보는 것이다.
처음부터 셋이 함께 그리면 목소리가 큰 사람이나 더 오래 고민한 사람의 관점으로 수렴하기 쉽다. 그래서 각자 경험 맵을 만든 뒤 비교한다. 제품 관리자는 고객 문의와 비즈니스 맥락을, 디자이너는 혼란과 감정을, 엔지니어는 단계 사이의 기술적 의존성을 떠올릴 수 있다. 어느 하나가 정답이 아니라, 차이를 발견하는 것이 목적이다.
팀은 각 지도의 승자를 고르지 않는다. 서로 다른 노드와 연결을 하나의 공유 경험 맵으로 합치며 “왜 여기서 흐름이 갈라졌다고 봤는가?”, “이 단계가 빠진 이유는 무엇인가?”를 묻는다. 그 과정에서 팀이 가진 가정과 지식의 빈틈이 드러난다.
화면 흐름이 아니라 고객이 겪는 시간을 그린다
경험 맵의 범위는 원하는 결과에서 출발한다. 스트리밍 제품이라면 ‘우리 서비스 사용’만 그리면 지나치게 좁고, ‘고객의 모든 여가’는 너무 넓을 수 있다. ‘고객이 비디오로 즐거움을 찾고 소비하는 과정’처럼 결과에 영향을 주면서도 탐색할 여지가 있는 범위를 잡는다.
지도에는 고객이 겪는 사건·행동·순간을 노드로, 그 관계를 링크로 표시한다. 행복 경로만 그리지 않고 검색 실패, 다른 서비스로 이동, 재시도, 이탈과 반복도 담는다. 각 순간에 고객이 무엇을 생각하고 느끼고 행동하는지도 더한다.
그림은 아름다울 필요가 없다. 그림의 힘은 막연한 생각을 검토 가능한 형태로 바꾸는 데 있다. 말로는 같은 의견처럼 들려도 막상 그려보면 서로 다른 장면을 떠올렸다는 사실이 보인다.
그리고 이 지도는 진실이 아니다. 인터뷰 전 팀의 최선의 가설이다. 다음 장의 고객 이야기는 이 가설을 확인하기 위한 자리가 아니라, 틀린 부분을 찾아 계속 수정하기 위한 입력이다.
5장. 고객에게 답을 묻지 말고, 실제 이야기를 듣는다
사람은 원하는 솔루션도, 행동의 이유도 정확히 말하기 어렵다
고객에게 “무엇을 만들어드릴까요?”라고 묻는 것은 발견이 아니다. 고객은 아직 존재하지 않는 솔루션을 상상하기 어렵고, 자신의 실제 행동을 움직인 이유도 나중에 그럴듯하게 설명하는 경향이 있다.
시각적 음성사서함이 나오기 전 사용자는 그 기능을 요청할 수 없었다. 하지만 메시지를 처음부터 순서대로 듣고 하나씩 보관하거나 삭제해야 하는 불편은 이야기할 수 있었다. 팀이 찾아야 하는 것은 고객이 떠올린 기능이 아니라 그 기능 아래의 미충족 기회다.
청바지 구매 사례도 같은 점을 보여준다. 사람은 핏이 가장 중요하다고 말했지만, 최근 실제 구매에서는 익숙한 브랜드, 세일 가격, 온라인 구매의 편리함이 더 크게 작용했다. 일반적인 선호를 묻는 질문과 실제 행동을 들여다보는 질문은 다른 답을 만든다.
그래서 책은 의견 대신 최근의 구체적인 경험을 묻는다. “평소에는 어떻게 하나요?”보다 “마지막으로 그 일을 했던 때를 처음부터 들려주세요”가 낫다.
연구 질문과 인터뷰 질문을 나눈다
연구 질문은 팀이 무엇을 배우려는지 정한다. 인터뷰 질문은 그 배움을 얻기 위해 고객에게 무엇을 물을지 정한다. 둘을 구분하지 않으면 알고 싶은 모든 것을 직접 질문하는 긴 목록이 만들어지고, 고객의 실제 이야기보다 팀의 관심사가 대화를 지배한다.
인터뷰에서는 시간의 흐름을 따라간다.
•
처음에 무슨 일이 있었는가?
•
그다음에는 무엇을 했는가?
•
그 직전에는 어떤 상황이었는가?
•
어디에 있었고, 누구와 함께였는가?
•
무엇이 어렵거나 도움이 됐는가?
참가자가 “저는 보통…”이라는 일반론으로 옮겨가면 방금 말한 구체적 사례로 부드럽게 돌아온다. 기능 요청이 나오면 “그 기능이 있다면 무엇이 달라질까요?”를 물어 밑에 있는 니즈·고충·욕구를 찾는다.
인터뷰는 끝난 뒤가 아니라 진행하면서 종합한다
연구 프로젝트에는 ‘인터뷰를 다 마친 뒤 분석하는 날’이 있다. 하지만 매주 인터뷰한다면 모든 인터뷰가 끝나는 날은 오지 않는다. 그래서 각 인터뷰를 마칠 때마다 한 장의 인터뷰 스냅샷으로 바로 종합한다.
인터뷰 스냅샷: 한 고객의 이야기에서 기억할 말, 기본 정보, 인사이트와 기회를 한 장에 종합한다.
스냅샷에는 고객을 기억하게 할 사진이나 간단한 정보, 기억에 남는 말, 핵심 인사이트, 발견한 기회, 경험의 흐름을 담는다. 긴 녹화본이나 메모를 조직에 넘기는 대신 팀이 무엇을 배웠는지 다시 꺼내 쓸 수 있는 형태로 남긴다.
매주 만나려면 모집도 습관이 되어야 한다
기회 공간과 시장은 계속 변한다. 한 번 충분히 인터뷰했다고 멈추면 지도는 다시 낡는다. 책은 최소 매주 한 명을 만나라고 권한다. 매주 유지하는 습관이 큰 연구 프로젝트를 멈췄다가 다시 시작하는 것보다 쉽다.
그 병목은 대개 인터뷰 기술보다 참가자 모집이다. 이상적인 상태는 월요일이 됐을 때 별도 수작업 없이 그 주의 인터뷰가 일정에 잡혀 있는 것이다. 제품 안에서 참여자를 모집하거나, 고객 접점 조직이 특정 행동을 본 순간 추천하게 하거나, 만나기 어려운 고객을 위해 자문 위원회를 운영할 수 있다.
인터뷰도 제품 트리오가 함께한다. 같은 가족 시청 이야기를 들어도 제품 관리자는 콘텐츠 구성의 문제를, 디자이너는 검색 사용성을, 엔지니어는 가족별 추천의 기술 문제를 포착할 수 있다. 한 사람만 고객을 만나면 그 사람이 ‘고객의 목소리’를 독점하지만, 함께 들으면 한 번의 인터뷰에서 더 많은 신호를 얻고 함께 행동할 수 있다.
6장. 인터뷰에서 찾은 기회를 구조화한다
기회 백로그는 서로 다른 것을 한 줄에 세운다
인터뷰를 계속하면 니즈·고충·욕구가 빠르게 쌓인다. 이를 평면적인 기회 백로그에 넣으면 문제가 생긴다. “볼 것이 없다”처럼 큰 기회와 “리모컨으로 제목 입력이 어렵다”처럼 작은 기회, “좋아하는 프로그램의 에피소드가 끝났다”처럼 앞의 기회에 포함될 수 있는 항목을 같은 수준에서 비교하게 된다.
기회 솔루션 트리는 이 관계를 구조로 바꾼다. 부모-자식 관계는 큰 기회와 그 부분집합을, 형제 관계는 비슷한 수준이지만 독립적으로 해결할 수 있는 기회를 나타낸다. 큰 기회를 작은 기회로 나누면 난해한 문제를 한 번에 다 해결하지 않고도 작은 가치를 반복해서 전달할 수 있다.
“이 프로그램이 볼 만한가?”라는 큰 기회를 장르, 출연자, 유사 작품, 다른 시청자의 선택이라는 작은 질문으로 나눈다.
최상위 가지는 고객 경험의 서로 다른 순간이다
트리의 최상위 가지는 고객 경험의 서로 겹치지 않는 주요 순간으로 나누는 편이 좋다. 가지가 겹치면 한 번에 한 기회에 집중하기 어렵다.
스트리밍 서비스의 ‘시청 시간 증가’라는 결과를 예로 들면, 고객의 경험은 ‘할 일이 필요하다’, ‘무엇을 볼지 모르겠다’, ‘프로그램을 보고 있다’, ‘보던 프로그램이 끝났다’는 서로 다른 순간으로 나뉠 수 있다. 결과라는 비즈니스 언어가 고객이 실제로 겪는 시간의 언어로 바뀐다.
‘시청 시간 증가’라는 결과를 고객 경험의 네 순간으로 나누면 서로 겹치지 않는 최상위 기회 가지를 만들 수 있다.
5장에서 그린 고객별 이야기와 인터뷰 스냅샷이 이 작업의 원재료다. 여러 이야기의 주요 순간을 비교해 반복되는 패턴을 찾고, 비슷한 기회를 합치고, 형제 기회를 묶을 부모를 만든다.
트리에 항목을 넣기 전에는 세 가지를 확인한다.
1.
이것은 회사의 요구나 솔루션이 아니라 고객의 니즈·고충·욕구인가?
2.
한 번의 흥미로운 발언이 아니라 여러 인터뷰에서 관찰됐는가?
3.
이 기회를 해결하면 원하는 결과가 움직일 가능성이 있는가?
목표는 완벽한 분류 체계를 만드는 것이 아니다. 현재 가진 증거로 다음 결정을 내릴 만큼 충분한 구조를 만드는 것이다. 새 인터뷰가 기존 구조를 흔들면 트리를 다시 만들고, 해체하고, 재구성한다.
기회처럼 보이는 솔루션과 감정을 걷어낸다
“광고를 빨리 감고 싶다”는 고객의 말은 기회처럼 보이지만 사실 특정 솔루션이다. “광고가 싫다”라고 바꾸면 재미있는 광고, 더 짧은 광고, 광고 없는 구독처럼 여러 솔루션을 탐색할 수 있다.
“답답하다”, “압도된다” 같은 감정도 그 자체로는 너무 넓다. 감정은 기회를 찾으라는 신호다. 어떤 순간과 행동이 그 감정을 만들었는지 파고들어야 한다. 회사의 목표를 고객의 말처럼 적거나, 자식 하나만 이어지는 수직 구조를 만들거나, 여러 부모에 걸치는 너무 넓은 기회를 두는 것도 트리의 판단력을 약하게 만든다.
7장. 솔루션이 아니라 기회에 우선순위를 둔다
기능 목록을 정렬하면 빌드 함정으로 돌아간다
기회 공간을 만들었다고 바로 모든 기회를 해결할 수는 없다. 여러 기회를 동시에 잡으면 다시 큰 일괄 프로젝트가 되고, 각 기회에서 여러 솔루션을 비교할 여지도 사라진다. 책은 한 번에 하나의 타깃 기회에 집중하라고 말한다.
기능과 출시량으로 성공을 정의하는 조직은 빌드 함정에 빠진다. 다음 기능 하나가 성공을 가져올 것이라 기대하고, 출시하면 또 다음 기능을 찾는다. 하지만 제품 전략은 기능을 정렬하는 목록이 아니라 어떤 결과, 어떤 고객, 어떤 기회를 선택할지 결정하는 일이다.
모든 기회를 평가하지 않고, 형제끼리 비교한다
기회 솔루션 트리의 장점은 거대한 기회 공간을 한 번에 평가하지 않아도 된다는 데 있다. 먼저 최상위 형제 기회들을 비교해 하나를 고른다. 선택한 가지의 자식들만 다시 비교한다. 자식이 없는 리프 노드에 이를 때까지 반복한다.
트리로 우선순위를 정한다. 상위 기회들을 먼저 비교하고, 선택한 가지의 하위 기회로 내려가며 탐색 범위를 좁힌다.
리프 노드라고 해서 쉬운 기회라는 뜻은 아니다. 현재 팀의 이해에서 더 작은 하위 기회를 찾지 못했다는 뜻이다. 이 방식은 “이 기회를 할까 말까?”라는 고립된 판단을 “같은 수준의 기회 중 지금 어디에 집중할까?”라는 비교로 바꾼다.
네 개의 렌즈로 보고, 공식으로 만들지는 않는다
형제 기회들을 비교할 때는 네 가지를 본다.
•
기회 규모: 몇 명의 고객에게 얼마나 자주 일어나는가?
•
시장 요인: 필수 조건인가, 차별화 요소인가, 경쟁 환경과 외부 추세는 어떤가?
•
회사 요인: 비전·미션·전략·가치와 맞는가, 우리 조직과 팀이 특별히 잘할 수 있는가?
•
고객 요인: 고객에게 얼마나 중요하며, 기존 방식에 얼마나 만족하고 있는가?
책은 이 판단을 정교한 점수 공식으로 바꾸지 말라고 한다. 원하는 결과에 이르는 길은 여전히 비구조화된 문제다. 숫자 하나로 정답을 만든 척하기보다, 데이터에 근거해 상대적으로 비교하고 제품 트리오가 함께 토론해야 한다.
같은 기회도 회사에 따라 우선순위가 달라진다. 스트리밍 서비스는 케이블 해지 추세 속에서 실시간 스포츠를 중요한 기회로 볼 수 있다. Google과 Apple은 비전과 강점, 제약이 다르기 때문에 같은 고객 기회에도 서로 다른 판단을 내릴 수 있다. 전략은 모든 회사에 통하는 점수가 아니라 자기 맥락에서 내리는 선택이다.
타깃 기회는 되돌릴 수 있는 결정이다
타깃 기회를 고른다는 것은 그것을 반드시 끝까지 해결하겠다는 약속이 아니다. 며칠이나 몇 주 동안 더 탐색해보겠다는 양방향 문 결정이다. 솔루션이 예상보다 어렵거나, 인터뷰를 더 해보니 고객 중요도가 낮거나, 다른 기회가 결과에 더 크게 영향을 준다는 사실을 배우면 돌아갈 수 있다.
그래서 완벽한 데이터를 기다릴 필요가 없다. 한두 시간, 길어도 하루나 이틀로 판단 시간을 제한하고 현재 증거로 결정한다. 분석을 미루는 것, 네 렌즈 중 하나만 보는 것, 이미 마음속으로 정한 결론을 정당화하는 방식이 7장의 안티패턴이다.
7장이 끝날 때 제품팀의 손에는 솔루션이 아니라 하나의 리프 노드 타깃 기회가 남는다. 이제야 팀은 “이 기회를 해결할 다른 방법은 무엇인가?”를 묻고 여러 솔루션을 탐색할 준비가 된다.
마무리
지속적인 발견은 고객 인터뷰를 자주 하는 방법론이 아니다. 무엇을 만들지 결정하는 과정을 고객의 실제 경험과 원하는 결과에 계속 연결하는 운영 방식이다.
•
1장은 제품 트리오가 매주 고객 입력을 받는 발견의 리듬을 정의한다.
•
2장은 원하는 결과에서 기회, 솔루션, 가정 테스트까지 이어지는 공통 지도를 세운다.
•
3장은 그 지도의 뿌리인 결과를 팀이 통제하고 학습할 수 있게 정한다.
•
4장은 팀이 고객에 대해 안다고 믿는 것을 경험 맵으로 드러낸다.
•
5장은 최근의 구체적인 고객 이야기로 그 믿음을 검증한다.
•
6장은 이야기에서 찾은 기회를 트리로 구조화한다.
•
7장은 그 트리를 따라 지금 집중할 하나의 기회를 고른다.
이 흐름이 바꾸는 건 질문의 순서다.
•
기능 요청을 받았다 → 만들까 말까?
라는 질문에서 아래의 질문들로 옮겨간다.
•
우리가 만들 결과는 무엇인가?
•
그 결과를 움직일 고객 기회는 무엇인가?
•
지금 비교해야 할 형제 기회는 무엇인가?
•
어느 하나를 더 탐색할 것인가?
•
그 기회를 해결할 서로 다른 솔루션은 무엇인가?
이 순서를 지키면 팀은 첫 아이디어와 가장 큰 목소리에 덜 끌려간다. 완벽한 확신을 기다리지 않으면서도, 고객을 외면한 채 빠르게 만들기만 하는 함정에서도 벗어날 수 있다. 지속적인 발견이 주는 자신감은 “우리는 정답을 안다”는 확신이 아니다. 현재의 증거로 행동하고, 틀렸다는 신호가 오면 지도를 고쳐 다음 결정을 더 낫게 만들 수 있다는 자신감이다.