주말 잘 보내셨나요? SOOD입니다.
고객 인터뷰를 열심히 하고도 정작 제품에는 무엇부터 반영해야 할지 몰라 힘드신가요?
명확한 기준을 세워, 불필요한 기능을 만드느라 시간과 돈을 낭비하지 않도록 고객의 목소리를 바탕으로 지금 당장 '무엇부터 만들고 실험해야 하는지를 정리했습니다.
1. 전체 구조
고객 인터뷰에서 얻은 인사이트를 실제 제품에 반영하기까지의 시스템 4단계입니다.
가) 가설 유형 구분
인터뷰 내용이 뒤섞이지 않도록 문제, 고객, 솔루션, 성장 가설로 분류합니다.
나) 증거(Evidence) 매핑
인터뷰에서 나온 고객의 실제 발언과 행동을 각 가설과 연결합니다.
다) 점수화(Scoring)
중요도, 리스크, 실행 비용 등을 고려하여 어떤 가설부터 검증할지 숫자를 반영하여 계산합니다.
라) 백로그 분리
당장 만들 것과 먼저 실험해 볼 것으로 일을 나누어 배치합니다.
2. 1단계 - 가설 유형 먼저 나누기
인터뷰를 끝내고 바로 "이 기능 개선하자!"로 넘어가면, 정작 중요한 문제는 확인하지 못하고 UI만 고치게 됩니다. 먼저 우리가 검증하려는 가설을 다음 4가지로 분류하는 것이 우선입니다.
가) 문제(Problem) 가설: "고객이 실제로 이런 불편함을 겪고 있는가?"
예시: "1인 창업자는 단순히 일정을 기록하는 것보다, '오늘 당장 뭐부터 해야 할지' 우선순위를 결정할 때 더 큰 스트레스를 받는다."
나) 고객(Segment) 가설: "우리의 진짜 핵심 타깃은 누구인가?"
예시: "우리 서비스를 돈 내고 쓸 핵심 고객은 일반 직장인이 아니라 프리랜서 디자이너다."
다) 솔루션(Feature/UX) 가설: "우리가 만든 기능이 문제를 해결해 주는가?"
예시: "달력 형태로 일정을 보여주는 것보다, 포스트잇처럼 옮기는 '칸반 보드' 형태가 일정 스트레스를 더 줄여줄 것이다."
라) 성장(Growth) 가설: "고객이 어떤 경로로 우리 서비스를 알게 되고 결제하는가?"
예시: "인스타그램 광고보다는 세무사와의 파트너십 채널이 우리 서비스의 주요 유입 경로가 될 것이다."
3. 2단계 - 인터뷰 데이터 매핑 (실제 고객 사례 연결하기)
각 가설 옆에 "어떤 고객이 어떤 상황에서 어떤 행동을 보였는지" 자료를 기록하는 과정입니다. 이때 3가지 기준입니다.
가) 반복 빈도
10명 중 몇 명이나 같은 맥락의 이야기를 했는가?
나) 감정 강도
말할 때 얼마나 짜증을 냈거나 흥분했는가? 실제로 돈이나 시간을 들여 해결하려는 행동을 보였는가?
다) 구체성
상황을 설명할 때 시간, 장소, 현재 쓰고 있는 다른 툴의 이름을 구체적으로 언급했는가?
4. 3단계 - 스타트업 맞춤형 점수화
대기업에서 쓰는 복잡한 프레임워크 대신, 초기 스타트업의 생존에 직결되는 5가지 축으로 우선순위 점수를 계산합니다.
가) Impact (임팩트)
이 가설이 맞는다면 서비스 성공에 얼마나 큰 영향을 주는가? (1~5점)
나) Risk (리스크)
만약 이 가설이 틀렸을 때 사업이 실패하거나 큰 타격을 입는가? (1~5점)
다) Evidence (증거)
인터뷰나 데이터로 증명된 수준이 얼마나 탄탄한가? (1~5점)
라) Learning value (학습 가치)
이 가설을 테스트하면 다른 의문점들도 도미노처럼 함께 해결되는가? (1~5점)
마) Effort (공수/노력)
만드는 데 시간과 비용이 얼마나 드는가? (1~5점, 높을수록 만들기 어렵고 오래 걸림)
\[우선순위 점수 공식\]
여기서 주의할 점!
단순 디자인 개선(B)은 만드는 노력(Effort)이 '1점'으로 매우 낮기 때문에 최종 점수가 5점이라는 높은 수치로 뻥튀기됩니다. 만약 단순히 점수가 높다고 B를 먼저 실행한다면 리소스 낭비입니다.
스타트업은 리스크와 학습 가치가 높은 A 가설(6.33점)을 최우선으로 선택하여 제품의 핵심 생존 가치부터 검증해야 합니다.
5. 4단계 - '학습 백로그'와 '빌드 백로그'를 분리하기
인터뷰 내용을 듣자마자 개발 기능 목록(백로그)에 집어넣으면 안 됩니다. 업무 항목을 두 개로 나누세요.
가) Learning Backlog (학습/실험 백로그): 돈과 시간을 쓰기 전에 "먼저 맞는지 확인하는 작업" 리스트입니다.
예시: 진짜 우선순위 결정에 고통을 느끼는지 알아보기 위해 '종이 프로토타입(가짜 화면)'으로 추가 인터뷰 진행하기, 가격 테스트용 랜딩페이지 만들기.
나) Build Backlog (실제 제품 개발 백로그): 검증이 끝나서 "진짜로 코딩하고 디자인해서 출시할 작업" 리스트입니다.
예시: 칸반 보드 기능 개발, 결제 모듈 연동, 서버 용량 증설
우선순위 점수가 높은 가설은 무작정 개발(Build)부터 하는 것이 아니라, 먼저 학습 백로그(Learning) 상단에 올려서 쉽고 빠르게 실험을 거친 뒤, 확신이 들면 개발 백로그로 넘기는 흐름으로 관리해야 리소스 낭비가 없습니다.
6. 인터뷰 후 24시간 이내에 마쳐야 하는 팀 표준
인터뷰 기억이 사라지기 전에 팀원들과 빠르게 의사결정을 내리는 표준 루틴입니다.
가) 인터뷰 요약
가장 핵심적인 고객 발언 5개만 뽑아서 슬랙이나 노션에 공유합니다.
나) 가설 태깅
그 발언들이 문제/고객/솔루션/성장 중 어떤 가설에 해당하는지 분리합니다.
다) 점수화
얼마나 자주(빈도), 세게(감정 강도) 말했는지 보고 Evidence 점수를 줍니다.
라) 종합 우선순위 계산
팀원들과 함께 임팩트, 리스크, 공수를 논의해 최종 점수를 도출합니다.
마) 백로그 업데이트
점수가 높은 상위 3개 가설을 학습(Learning) 백로그 맨 위로 이동시킵니다.
7. 1인 기업 / 초기 스타트업을 위한 축소 버전
팀원이 없거나 리소스가 극도로 부족할 때는 복잡한 공식 대신 딱 3가지만 체크하세요.
가) PMF(제품-시장 적합성) 직결성
이게 틀리면 우리 사업이 망하는가? (임팩트+리스크 통합)
나) 근거 강도
인터뷰할 때 고객이 얼마나 리얼하게 고통을 호소했는가? (증거)
다) 테스트 용이성 (실행 속도)
진짜 쉽고 빠르게 실험해 볼 수 있는가? (높을수록 좋음)
이 정도만 체계적으로 적용해도, "인터뷰 때 고객이 말한 모든 요구사항을 제품에 다 넣으려다 배가 산으로 가는 혼란"을 확실하게 막을 수 있습니다.
