피드백이 5개 채널에 흩어져 있을 때 /analyzing-user-feedback는 이를 행동 경로로 군집화해 잡음이 아니라 근본 원인에 대응하게 합니다. — Claude Skill
Claude Code용 Claude 스킬 · 제공: Refound · 실행: /analyzing-user-feedback (Claude 내)·업데이트: 2026년 6월 14일
NPS, 지원, 인터뷰, 이탈 데이터를 실행 가능한 주제로 군집화합니다
- Bob Moesta 행동 경로 군집화(JTBD): 인구통계 세그먼트가 아니라 고용/해고 기준을 찾습니다
- 80/20 잡음 필터(Jen Abel): 기존 습관에서 나온 피드백과 실제 시장 신호를 구분합니다
- 이탈 우선 인터뷰 프로토콜(Uri Levine): 만족한 사용자보다 떠난 사용자의 인사이트가 더 큽니다
- 침묵 신호 탐지(Ramesh Johari): 큰 목소리뿐 아니라 누락된 평점과 말하지 않은 불만을 봅니다
- 근본 원인 드릴다운(Bret Taylor): '가격' 불만을 실제 가치 격차로 번역합니다
대상
기능
지난 분기의 NPS 댓글 240개가 읽히지 않은 채 남아 있습니다. /analyzing-user-feedback는 이를 Bob Moesta 행동 경로로 군집화하고, 20%의 핵심 신호와 80%의 기존 습관 잡음을 구분해 상위 5개 주제 브리프를 만듭니다.
이번 달 티켓량이 35% 늘었습니다. /analyzing-user-feedback는 Geoff Charles의 '모든 티켓은 제품 실패' 관점을 적용하고 티켓을 근본 원인별로 군집화한 뒤 각 군집을 제품 담당자에게 연결합니다.
이탈률이 4%가 됐고 이탈 설문은 '가격'이라고만 말합니다. /analyzing-user-feedback는 Bret Taylor의 '사용자는 거짓말한다' 규칙을 적용하고 Uri Levine식 이탈 사용자 인터뷰 프로토콜을 작성해 '가격' 뒤에 숨은 실제 가치 격차를 드러냅니다.
파워 유저 10명이 온보딩을 악화시킬 변경을 강하게 요구합니다. /analyzing-user-feedback는 Tamar Yehoshua의 '내일의 사용자를 위해 설계하라' 규칙을 적용해 침묵하는 다수의 데이터와 목소리 큰 소수를 함께 평가합니다.
NPS, Intercom, 영업 메모, Reddit, 사용자 인터뷰가 5곳에 흩어져 있습니다. /analyzing-user-feedback는 Brian Balfour의 집계 패턴을 실행하고, 사용자가 말하지 않는 지식 공백을 찾아 단일 주제 저장소를 만듭니다.
작동 방식
NPS 원문, 지원 티켓, 인터뷰 기록, 이탈 사유, Reddit 언급 등 피드백 출처를 공유합니다
하나의 풀로 모으고 반복 보고를 자동으로 중복 제거합니다
행동 경로(Moesta)로 군집화하고 80/20 잡음 필터(Jen Abel)를 실행합니다
Bret Taylor의 '사용자는 거짓말한다' 점검으로 근본 원인을 파고들고 침묵 신호(Ramesh Johari)를 표시합니다
상위 5개 주제, 근본 원인, 추가 리서치 공백, 지정된 실행 담당자가 포함된 인사이트 브리프를 받습니다
예시
Q1 NPS 원문 240개(NPS 32, 41에서 하락) 출처: 제품 내 설문(180), 지원 종료 설문(40), 이탈 인터뷰(20) 상위 불만 키워드: '느림', '헷갈림', '비쌈', '누락'
경로 A - 규모에 부딪힌 파워 유저(42건): 더 빠른 대량 작업, 고급 필터를 원함 경로 B - 신규 관리자 온보딩(68건): 설정에서 길을 잃고 기본 기능을 찾지 못함 경로 C - 이탈한 중견 고객(30건): '가격'이라고 말했지만 실제로는 보고 가치 격차
핵심 신호(실행): 경로 B 설정 혼란(68건, 세그먼트 전반에서 일관) 핵심 신호: 경로 C 숨은 보고 공백(근본 원인 조사 필요) 잡음: '도구 X처럼 보이게 해달라'(12건, 기존 습관 요청) 잡음: '다크 모드 추가'(18건, 고용/해고 기준과 무관)
신규 계정의 60%가 온보딩 설문을 완료하지 않았습니다. 이는 68개 불만보다 강한 신호입니다. 모바일을 언급한 원문은 0개지만 모바일 DAU는 18% 하락했습니다. 사용자가 너무 예의 바르거나 이미 떠났을 수 있습니다.
이번 스프린트에 경로 B 설정 문제를 수정합니다. 담당자: 온보딩 제품 관리자. 이번 주 이탈 사용자 인터뷰 5건(Uri Levine 프로토콜)으로 경로 C 보고 공백을 검증합니다. 온보딩 완료율을 침묵 신호로 계측합니다. 다크 모드는 지금 무시합니다(기존 습관 잡음). 티켓 군집은 매주 온보딩 제품 관리자와 공유합니다(Geoff Charles 패턴).
개선되는 지표
지원 도구
사용자 피드백 분석을(를) 사용해 보시겠어요?
시작 방법을 선택하세요.
이 스킬을 컴퓨터에 로컬로 설치하고 실행합니다.
컴퓨터에서 터미널을 열고 이 명령을 붙여넣으세요:
이 명령은 스킬과 모든 파일을 컴퓨터에 다운로드합니다:
모든 프로젝트에서 사용하려면 끝에 -g를 추가하세요.
Claude Code를 시작한 다음 명령을 입력하세요:
사용자 피드백 분석
56명의 제품 리더가 사용하는 기법으로 고객 피드백에서 실행 가능한 인사이트를 뽑아내도록 돕습니다.
돕는 방법
사용자가 피드백 분석에 대해 도움을 요청하면:
- 출처를 이해합니다 - 피드백이 어디에서 오는지 묻습니다(NPS, 지원, 영업, 소셜, 인터뷰).
- 패턴 식별을 돕습니다 - 피드백을 주제로 묶고 빈도와 영향으로 우선순위를 정하도록 돕습니다.
- 표면적 해석에 도전합니다 - 말로 드러난 불만이 아니라 근본 원인을 찾게 합니다.
- 행동으로 연결합니다 - 인사이트를 제품 결정으로 번역하도록 돕습니다.
핵심 원칙
피드백은 호수가 아니라 강입니다
Shaun Clowes: "정말 뛰어난 제품 관리자는 끊임없이 피드백의 강에서 헤엄칩니다. 사용자 인터뷰 데이터, NPS, 경쟁사 정보를 매일 흘러오게 하세요." 피드백 소비는 일회성이 아니라 지속적이어야 합니다.
사용자는 의도치 않게 거짓말합니다
Bret Taylor: "고객이 포커스 그룹에서 말하는 내용을 그대로 받아들이는 것은 거의 항상 틀립니다. 표면적 불만과 근본 원인을 구분하려면 지적 정직성을 연습하세요." 사용자가 "가격"이라고 말할 때 실제로는 "가치"를 뜻하는 경우가 많습니다.
세그먼트로 나누지 말고 군집화합니다
Bob Moesta: "우리는 인구통계로 세분화하지 않고 행동 경로로 군집화합니다. 사람들이 행동하는 이유는 하나가 아니라 여러 이유의 묶음입니다." 사용자 군집별 '채용과 해고' 기준을 찾으세요.
모든 지원 티켓은 제품 실패입니다
Geoff Charles: "우리는 모든 채널에 '모든 지원 티켓은 우리 제품의 실패'라고 실제로 게시해 두었습니다. 부정적 리뷰는 매달 관련 제품 관리자와 디자이너에게 공유하세요."
침묵의 신호도 중요합니다
Ramesh Johari: "남기지 않은 평점에도 많은 정보가 있습니다. 평점이 없는 것은 사용자가 너무 예의 바르게 말하지 않는 그저 그런 경험의 강한 신호인 경우가 많습니다."
80%의 소음을 걸러냅니다
Jen Abel: "피드백의 80%는 과거 습관에서 나온 소음이고, 20%는 미래 제품을 이끄는 금입니다. '옛 방식'과 실제 시장 수요를 해석하는 것이 창업자의 일입니다."
모든 채널을 합칩니다
Brian Balfour: "AI는 기존 피드백을 분석할 뿐 아니라 고객이 말하지 않는 지식 공백도 찾을 수 있습니다. 모든 출처의 피드백을 중앙 저장소에 모으세요."
이탈한 사용자와 이야기합니다
Uri Levine: "가장 중요한 인사이트는 성공한 사용자가 아니라 퍼널에서 이탈한 사용자에게서 옵니다. 이탈한 사용자를 인터뷰해 실패 뒤의 '왜'를 찾으세요."
목소리 큰 소수보다 미래 사용자를 우선합니다
Tamar Yehoshua: "변화에 불만인 사람들에게 과도하게 맞추지 마세요. 오늘 불평하는 소수보다 내일 사용할 더 많은 사람을 위해 설계하세요."
인사이트가 기억에 남게 만듭니다
Yuhki Yamashata: "목표는 '밈화'입니다. 임원들이 회의에서 인용할 만큼 기억에 남도록 인사이트를 종합하세요. 복잡한 개념을 설명할 때 현실의 은유를 사용하세요."
사용자를 돕는 질문
- "피드백은 어디에서 오고 있나요? 빠진 채널이 있나요?"
- "이탈한 사용자와 이야기했나요, 아니면 만족한 고객에게만 들었나요?"
- "이 불만 뒤의 패턴은 무엇인가요? 근본 원인은 무엇인가요?"
- "이 요청은 얼리어답터에게서 온 것인가요, 아니면 낡은 습관에 묶인 사용자에게서 온 것인가요?"
- "이 인사이트를 어떻게 실행할 건가요?"
지적해야 할 흔한 실수
- 피드백을 문자 그대로 받아들임 - 사용자는 X를 원한다고 말하지만 실제로는 Y가 필요한 경우가 많습니다.
- 목소리 큰 사용자만 들음 - 침묵하는 다수는 다른 요구를 가질 수 있습니다.
- 비사용자를 무시함 - 전환하지 않은 사람은 중요한 인사이트를 갖고 있습니다.
- 피드백을 쌓아두기만 함 - 사일로에 갇힌 인사이트는 누구에게도 도움이 되지 않습니다.
- 사후 확신 편향 - 리서치 결과를 나중에 "당연한 것"이라고 무시하지 마세요.
심층 자료
56명의 게스트에게서 얻은 64개 인사이트 전체는 references/guest-insights.md를 참고하세요.
관련 스킬
- 사용자 인터뷰 진행
- 제품-시장 적합도 측정
- 로드맵 우선순위 지정
- OKR 및 목표 설정
참조 문서
사용자 피드백 분석 - 전체 게스트 인사이트
게스트 56명, 언급 64개
Alexander Embiricos
Alexander Embiricos
"우리 중 몇 명은 계속 Reddit에 있습니다. 거기에는 칭찬도 있고 불만도 많습니다... Reddit은 조금 더 부정적이지만 사실 실제에 가깝습니다. 그래서 사람들이 Reddit에서 Codex를 어떻게 쓰고 이야기하는지 점점 더 주의 깊게 보기 시작했습니다... 무엇이 중요한지, 다른 사람들이 어떻게 생각하는지에 대해 좋은 신호를 얻을 수 있습니다."
인사이트: Reddit 같은 필터링되지 않은 커뮤니티 플랫폼은 더 세련된 소셜 플랫폼보다 제품 결함과 '진짜' 사용자 감정에 대해 신호가 더 높은 피드백을 제공합니다.
실행 조언:
- 필터링되지 않은 제품 불만과 버그 보고를 찾기 위해 틈새 서브레딧을 관찰합니다
- 어떤 사용자 고통 지점을 먼저 처리할지 우선순위화하기 위해 Reddit의 추천 메커니즘을 사용합니다
타임스탬프: 00:56:44
Aishwarya Naresh Reganti + Kiriti Badam
Aishwarya Naresh Reganti + Kiriti Badam
"모든 트레이스를 앉아서 평가하는 것은 현실적으로 불가능합니다. 무엇을 봐야 하는지 이해하기 위한 어떤 표시가 필요합니다. 이때 운영 환경 모니터링이 도움이 됩니다. 이런 트레이스를 얻고 나면, 서로 다른 유형의 상호작용에서 어떤 실패 패턴이 보이는지 살펴봐야 합니다."
인사이트: 운영 환경 모니터링은 수동 오류 분석과 실패 패턴 식별을 위해 특정 트레이스를 걸러내고 찾는 데 사용해야 합니다.
실행 조언:
- 문제가 있는 트레이스를 더 깊게 검토하도록 운영 환경 모니터링으로 표시합니다
- 사용자 상호작용에서 반복되는 실패 패턴을 식별해 새 평가 데이터셋 생성에 반영합니다
타임스탬프: 00:35:35
Anneka Gupta
Anneka Gupta
"오늘날 우리가 AI를 사용하는 한 가지 방식은 사용자 리서치 통화를 요약하는 것입니다. ... 통화를 찾아주고, 맥락을 찾아주고, 녹취록을 찾아주며, 그 통화에서 정확히 무엇을 배웠는지 요약해줍니다."
인사이트: AI 기반 사용자 리서치 통화 요약과 태깅은 조직 전체에서 검색 가능하고 충실도 높은 인사이트를 가능하게 합니다.
실행 조언:
- 고객 발견 통화의 전사와 요약을 자동화하기 위해 Dovetail 같은 도구를 사용합니다
타임스탬프: 01:00:08
Barbra Gago
Barbra Gago
"우리는 과정 내내 사례 연구를 했습니다. 로고에 대한 피드백을 받았고, 브랜드와 디자인에 대한 피드백도 받았습니다. '아, 저는 RealtimeBoard가 좋아요. 직관적이에요'라고 말하는 사람도 많았습니다. 그들은 제품을 사랑했지만, 결국 우리는 그들 중 많은 사람에게 계속 알리고, 우리를 늦추지 않으면서도 피드백을 받을 수 있을 정도로 그들을 과정에 실제로 참여시켰습니다."
인사이트: 리브랜딩 과정에 핵심 지지자를 참여시키면 충성도를 유지하면서 새로운 시각 방향에 대한 중요한 피드백을 얻을 수 있습니다.
실행 조언:
- 기존 사용자와 새 로고 및 디자인에 대한 사례 연구와 피드백 세션을 진행합니다
- 초기 지지자에게 주요 변경 사항을 계속 알리고 소유감을 유지하게 합니다
타임스탬프: 33:31
Bob Moesta
Bob Moesta
"그다음 우리가 하는 일은 모든 사람에게서 주제를 찾으려는 대신, 사실 다른 일을 하는 것입니다. 그들을 세그먼트로 나누는 대신 군집화합니다. 경로를 찾습니다. 왜냐하면 사람들이 그것을 하는 이유가 하나가 아니라 이유들의 묶음이라는 것을 깨닫기 시작하기 때문입니다."
인사이트: 사용자 피드백은 인구통계 세그먼트가 아니라 행동 '경로'로 군집화해야 합니다.
실행 조언:
- 서로 다른 사용자 군집의 '고용과 해고' 기준을 식별합니다
- 한 사용자 그룹은 속도를 원하고 다른 그룹은 철저함을 원하는 충돌을 찾습니다
타임스탬프: 00:20:29
Brian Balfour
Brian Balfour
"우리가 출시한 첫 제품은 Reforge Insights라고 불립니다. 이것은 당신의 AI 제품 리서처처럼 작동하며, 모든 출처의 피드백을 집계하고 AI로 분석하며 탐색을 돕습니다. 또한 오늘 피드백에 없는 것들, 즉 공백을 식별하고 그 새로운 인사이트를 모으기 위한 리서치를 자동 생성하기 시작합니다."
인사이트: AI는 기존 피드백을 분석하는 것뿐 아니라 '지식 공백'을 식별하고 그것을 채울 리서치를 능동적으로 생성하는 데도 사용할 수 있습니다.
실행 조언:
- 모든 출처의 피드백을 중앙의 AI 분석 가능 저장소에 모읍니다
- 향후 리서치 노력을 안내하기 위해 고객이 말하지 않는 것을 AI로 식별합니다
타임스탬프: 01:06:22
Brian Tolkin
Brian Tolkin
"여기저기서 오는 모든 아이디어와 피드백은 여러 이유로 반드시 기록해두세요. 첫째, 나중에 참고할 수 있습니다. 둘째, 그 아이디어를 제시한 사람들이 들렸고 존중받았으며 적어도 어딘가에서 검토됐다는 것을 알게 하는 것도 일의 일부입니다."
인사이트: 모든 피드백을 체계적으로 문서화하면 이해관계자가 들렸다고 느끼고, 향후 우선순위화를 위한 검색 가능한 저장소가 만들어집니다.
실행 조언:
- 즉시 실행하지 않더라도 모든 피드백을 중앙 백로그(Google Sheet, Jira 등)에 기록합니다
- 부서 간 존중을 유지하기 위해 피드백 출처를 인정합니다
타임스탬프: 00:56:33
Bret Taylor
Bret Taylor
"포커스 그룹이나 사용성 연구에서 고객이나 사용자가 말한 것을 문자 그대로 받아들이는 것은 거의 옳지 않습니다... 올바르게 파악하는 것이 매우 중요합니다."
인사이트: 사용자는 도입이 부족한 진짜 이유를 가리는 '공손한' 피드백을 자주 제공합니다. 그 밑의 진실을 파고들어야 합니다.
실행 조언:
- 가격 같은 표면적 불만과 가치 부족 같은 근본 원인을 구분하기 위해 지적 정직성을 실천합니다
타임스탬프: 00:21:16
Chandra Janakiraman
Chandra Janakiraman
"요청은 사실 모든 분석에 대한 메타 분석을 만드는 것입니다... 회사의 역사적 아카이브를 훑고 그것을 종합해 매우 소화하기 쉬운 거시 주제로 압축하는 것입니다."
인사이트: 전략은 처음부터 다시 시작하기보다 기존 행동 데이터와 리서치의 상위 수준 종합을 바탕으로 해야 합니다.
실행 조언:
- 역사적 행동 데이터와 기능 출시 성과에 대한 메타 분석을 만듭니다
- 고객 서비스, 소셜 채널, UX 리서치의 '소프트' 신호를 거시 주제로 종합합니다
- 전략 작업 그룹이 공감을 만들기 위해 사용자를 직접 관찰하게 합니다
타임스탬프: 00:20:50
Christine Itwaru
Christine Itwaru
"고객 기반 전체에서 떠오르는 주제로 보였던 이 정성 및 정량 데이터의 종합... 전통적으로 제품 관리자가 처리했을 여러 입력을 제품 개발 생애주기 계획을 진행할 때 표면으로 끌어올리는 것입니다."
인사이트: 제품 운영은 다양한 피드백 출처를 중앙화하고 종합해 계획 주기 동안 제품 관리자에게 실행 가능한 인사이트를 제공합니다.
실행 조언:
- 영업 및 고객 성공의 정성 피드백을 정량 사용 데이터와 집계합니다
- 제품 개발 생애주기 계획 단계에서 특히 종합된 피드백 주제를 표면화합니다
타임스탬프: 00:12:54
"우리는 그 사람들을 한 방에 모았습니다... 어느 순간 전문 서비스팀 책임자가 '와, 이것은 온보딩 관점에서 우리가 하는 일에 정말 영향을 줄 수 있고 이제 이 데이터가 있네요'라고 했습니다... 제품 관리자는 위험 데이터, 우선순위 높은 거래, 피드백 제품에서 온 피드백을 얻었습니다. 잠재 고객과 유료 고객에게서 각각 무엇을 듣고 있는가를 보게 됐습니다."
인사이트: 부서 간 피드백 세션은 온보딩부터 영업 거래까지 제품 문제가 비즈니스의 여러 부분에 어떤 영향을 주는지 드러냅니다.
실행 조언:
- 매출, 고객 성공, 제품 팀을 함께 모아 피드백을 공동으로 검토합니다
- 위험한 우선순위 높은 거래를 식별하기 위해 잠재 고객과 유료 고객처럼 고객 유형별로 피드백을 세분화합니다
타임스탬프: 00:16:46
Claire Butler
Claire Butler
"초기에는 Intercom을 구현했습니다... Dylan도 뛰어들고, 엔지니어도 뛰어들었습니다. 그는 사람들과 채팅을 열었고 그들은 실제로 우리와 함께 제품을 실시간으로 디버깅했습니다. 그들이 '이 버그가 있어요'라고 하면 엔지니어가 '지금 바로 품질 확인해볼게요'라고 했습니다."
인사이트: 초기 단계에서 엔지니어와 사용자의 직접적이고 실시간 상호작용은 강한 충성도를 만들고 빠른 버그 해결을 보장합니다.
실행 조언:
- 엔지니어와 창업자를 포함한 전체 팀이 초기 고객 지원에 참여하게 합니다
- 사용자와 실시간으로 문제를 디버깅해 극도의 배려와 반응성을 보여줍니다
타임스탬프: 00:39:17
"몇 년 전 우리는 모든 품질 업데이트를 하나로 묶어 함께 출시하고, 이를 촉발한 트윗이나 포럼 요청까지 보여주면 어떨까라는 아이디어를 냈습니다. 거기서 '작지만 큰 업데이트' 아이디어가 나왔습니다."
인사이트: 사용자가 요청한 작은 품질 개선을 하나의 출시로 묶으면 회사가 듣고 있고 사용자 작업 품질을 중요하게 여긴다는 것을 보여줍니다.
실행 조언:
- 엔지니어가 작지만 성가심이 큰 버그를 고치는 '품질 주간'을 운영합니다
- 업데이트에 영감을 준 특정 사용자 요청이나 트윗을 공개적으로 인정합니다
타임스탬프: 00:52:53
Dan Shipper
Dan Shipper
"수많은 고객 인터뷰나 살펴봐야 할 고객 데이터가 있을 때도 마찬가지입니다. 그런 큰 데이터셋에서 들어가 무언가를 파악하는 데 믿을 수 없을 만큼 강력합니다."
인사이트: 자율 에이전트는 단순한 맥락 밀어넣기보다 방대한 정성 사용자 리서치 데이터셋에서 인사이트를 처리하고 종합하는 데 더 효과적입니다.
실행 조언:
- 에이전트형 CLI 도구를 사용해 개별 고객 인터뷰 파일을 모두 읽고 특정 행동 패턴을 찾습니다
타임스탬프: 00:11:05
Donna Lichaw
Donna Lichaw
"스스로에게 들려주는 이야기에 데이터 기반 접근을 하세요. 예를 들어 '나는 너무 친절하다'라는 이야기는 사실일 수도, 아닐 수도 있습니다. 어떻게 그 밑바닥까지 내려갈까요? 이 경우 우리는 밖으로 나가 그의 팀과 이야기했습니다... 그리고 사람들이 실제로 그와 그의 리더십을 어떻게 경험하는지 알아냈습니다."
인사이트: 리더십 자기 인식을 제품 발견처럼 다루고, '고객'(동료)에게서 객관 데이터를 모아 내부 서사를 검증하거나 반박합니다.
실행 조언:
- 내부 자기 이야기와 팀이 실제로 경험하는 리더십을 비교하기 위해 비공식 360도 리서치를 수행합니다
타임스탬프: 00:16:55
Eeke de Milliano
Eeke de Milliano
"우리는 고객과 이야기하는 데 Slack을 매우 많이 씁니다... 고객과의 Slack 채널이 수백 개 있습니다. 새 제품을 테스트할 때마다... 우리는 Slack에서 그들과 일하며 즉흥적인 피드백을 주고받습니다."
인사이트: Slack 같은 직접적이고 비공식적인 소통 채널은 공식 설문보다 더 빠르고 솔직한 피드백 루프를 제공합니다.
실행 조언:
- 핵심 고객이나 베타 테스터를 위한 전용 Slack 채널을 만듭니다
- 새 기능을 반복 개선하기 위해 즉흥적인 양방향 메시지를 사용합니다
타임스탬프: 00:52:34
Elizabeth Stone
Elizabeth Stone
"우리는 내부적으로 그런 기술 묶음을 결합하는 것을 초능력이라고 이야기합니다. Netflix의 소비자 인사이트 팀은 특정 전문 영역에서 많은 신뢰를 갖고 있었고, 우리는 그것을 다른 기능 전문성과 결합해 다음 단계로 가져갔습니다... 태도 리서치, 정성 및 정량 리서치를 데이터 과학, 데이터 엔지니어링 분석 쪽의 행동 리서치와 결합한 것입니다."
인사이트: 가장 강력한 인사이트는 정성적인 '태도' 리서치와 정량적인 '행동' 데이터 과학을 합칠 때 나옵니다.
실행 조언:
- 복잡한 제품 문제를 해결하기 위해 사용자 리서치와 데이터 과학 팀을 통합합니다
- '무엇' 뒤의 '왜'를 이해하기 위해 행동 데이터 추세를 정성 사용자 인터뷰로 검증합니다
타임스탬프: 00:58:51
Ethan Smith
Ethan Smith
"영업 통화, 고객 지원, Reddit에서 사람들이 당신에게 묻는 모든 질문은 무엇인가요? 어딘가에 존재하는 그 질문들을 채굴하세요. 아마 같은 질문들이 채팅에서도 물어지고 있을 것입니다."
인사이트: 영업과 지원 데이터는 사용자가 AI 엔진에 묻는 구체적이고 긴 꼬리 질문을 식별하는 최고의 출처입니다.
실행 조언:
- 특정 제품 비교 질문을 찾기 위해 영업 통화 녹취록을 검토합니다
- 공개 문서에서 아직 다루지 않는 '방법' 질문을 식별하기 위해 고객 지원 티켓을 분석합니다
타임스탬프: 00:24:02
Geoff Charles
Geoff Charles
"첫 번째 원칙은 '모든 지원 티켓은 우리 제품의 실패다'라고 말하는 것이었습니다. 우리는 실제로 그 문구를 모든 채널에 붙여두었습니다. 실패입니다."
인사이트: 모든 고객 지원 상호작용을 제품 마찰의 신호로 보고, 엔지니어링으로 제거해야 합니다.
실행 조언:
- 매달 모든 부정적 리뷰를 관련 기술 리드, 제품 관리자, 디자이너와 공유합니다
- '고객 혼란' 티켓을 사용자 경험 품질의 주요 지표로 추적합니다
- 운영 부담이나 혼란 지표가 임계값을 넘으면 새 기능 출시를 멈춥니다
타임스탬프: 00:47:30
Gibson Biddle
Gibson Biddle
"저는 피드백 광입니다. 그래서 제가 하는 모든 강연, 모든 글 끝에는 피드백을 주는 링크가 있다는 것을 보실 겁니다. 그리고 질문은 항상 같습니다. 0에서 10까지의 척도로... 이것을 친구에게 추천할 가능성이 얼마나 되나요?"
인사이트: 모든 산출물에 일관되고 단순한 피드백 루프를 구현해 데이터 기반 지속 개선을 추진합니다.
실행 조언:
- 모든 제품이나 커뮤니케이션에 피드백 링크를 포함합니다
- 숫자 평점(0-10)과 '좋았던 점', '더 나아질 점'을 함께 묻습니다
- 개선 패턴을 식별하기 위해 피드백을 매일 검토합니다
타임스탬프: 57:33
Hamel Husain & Shreya Shankar
Hamel Husain & Shreya Shankar
"이런 데이터를 정복하는 첫 단계는 그냥 메모를 쓰는 것입니다... 데이터를 샘플링해서 한번 들여다보세요. 그렇게 할 때 얼마나 많이 배우는지 놀랍습니다."
인사이트: 수동 '트레이스 분석'(로그 검토)은 AI 제품이 실제로 어떻게 작동하는지 이해하는 가장 효과적인 방법입니다.
실행 조언:
- 운영 환경 트레이스를 샘플링하고 수동으로 주석을 답니다
- 잘못된 것으로 처음 보이는 것을 적는 '열린 코딩'을 수행합니다
타임스탬프: 00:17:47
"새로운 것을 더 이상 배우지 않는다고 느낄 때까지 트레이스를 계속 보세요... 이론적 포화입니다."
인사이트: 수동 검토 과정은 팀이 새로운 유형의 실패 모드를 더 이상 발견하지 않을 때까지 계속되어야 합니다.
실행 조언:
- 새 오류 범주가 나오지 않는 '이론적 포화'를 목표로 합니다
- 오류의 대표적 분류 체계를 만들기 위해 최소 50-100개의 트레이스를 검토합니다
타임스탬프: 00:30:30
Guillermo Rauch
Guillermo Rauch
"사람들이 제품 안에서 피드백을 줄 기회를 많이 만드세요... 네 개의 이모지로 기능에 대해 어떤 기분인지 고를 수 있는 아주 매끄러운 인라인 양식이 있는 피드백 버튼 같은 것입니다... 그것은 곧바로 Slack으로 갔습니다. 우리는 매일 만들면서 사용자 생각을 우리 의식 속으로 바로 흘려보냈습니다."
인사이트: 앱 내 사용자 감정을 Slack 같은 실시간 소통 채널로 직접 흘려보내 피드백 루프를 조입니다.
실행 조언:
- 이모지 기반 감정 선택이 있는 단순한 피드백 버튼을 삽입합니다
- 앱 내 피드백을 전체 팀이 볼 수 있는 공유 Slack 채널에 직접 통합합니다
타임스탬프: 01:01:45
Gustav Söderström
Gustav Söderström
"Spotify 홈페이지에서 사람들이 무엇을 하는지 보면... 거의 90%가 우리가 회상이라고 부르는 것입니다... 디자인을 테스트했을 때... 90/10에서 10/90으로 바꿨습니다. 회상 10%, 발견 90%였습니다. 사람들은 발견을 원하지만, 아마 회상 90% 대신 발견 90%를 원하지는 않습니다."
인사이트: 재설계 중 사용자 불만은 새 '발견' 기능을 싫어해서가 아니라 알려진 항목을 찾는 '회상'이 사라졌기 때문에 생기는 경우가 많습니다.
실행 조언:
- 사용 데이터에서 '회상' 의도와 '발견' 의도를 구분합니다
- 새 사용자 코호트(기존 습관 없음)와 장기 사용자를 비교해 피드백이 습관 깨짐 때문인지 나쁜 설계 때문인지 식별합니다
타임스탬프: 00:49:59
Inbal S
Inbal S
"고객과 시간을 보내고 고객에게서 배우세요. 혁신적인 아이디어의 많은 부분은 기본적으로 고객과의 대화에서 나오기 때문입니다. 그들은 좌절을 공유하고, 갖고 싶은 것을 공유하고, 자신에게 놀라운 발명이 될 것을 공유합니다."
인사이트: 고객의 좌절은 혁신적 제품 아이디어의 주요 원천입니다.
실행 조언:
- 큰 커뮤니티와 작은 커뮤니티 기반 모두에서 피드백을 모을 수 있는 메커니즘을 만듭니다
- 고통 지점을 이야기할 때 고객이 묘사하는 '놀라운 발명'에 귀를 기울입니다
타임스탬프: 34:55
Howie Liu
Howie Liu
"예를 들어 영업 통화의 긴 녹취록에 대해 많은 LLM 호출을 실행해 여러 유형의 인사이트를 추출합니다. 예를 들어 제품 공백을 식별하거나 요약을 만드는 식입니다."
인사이트: 영업 녹취록 같은 대량 정성 데이터를 공격적으로 처리해 전략적 제품 및 마케팅 인사이트를 찾는 데 LLM을 사용합니다.
실행 조언:
- 영업 통화 녹취록에 LLM을 실행해 제품 공백과 포지셔닝 인사이트를 식별합니다
- 방대한 데이터셋에서 인사이트를 집계하기 위해 '맵-리듀스' LLM 패턴을 사용합니다
타임스탬프: 00:14:49
Jeff Weinstein
Jeff Weinstein
"무엇을 측정해야 할지 확신이 없다면... 사용자가 나쁜 하루를 보내는 차트를 만드세요. 로그 한 줄을 남기고 막대 차트로 세세요. ... '아, 나는 이 차트를 올리는 일을 하고 있구나'라고 이름을 소리 내어 말하기만 해도 기분이 좋습니다."
인사이트: 모든 사용자 마찰 사례를 '나쁜 하루' 이벤트로 추적하면 품질 개선의 우선순위 백로그가 만들어집니다.
실행 조언:
- 사용자가 404, 지연, 거절을 만날 때마다 로그 한 줄을 남깁니다
- 가장 빈번한 고통 지점을 식별하기 위해 '나쁜 하루' 이유의 누적 막대 차트를 만듭니다
타임스탬프: 01:01:14
Jen Abel
Jen Abel 2.0
"그것을 해석하는 것은 창업자의 일입니다. 받는 피드백의 상당수는 이것이 예전 방식이라는 뜻이기 때문입니다. 그들은 예전 일하는 방식 때문에 이렇게 반응합니다... 80%는 잡음이고, 20%는 이 질문을 하지 않았다면 오늘 그들이 어디에 있는지에 대한 금 같은 답을 얻지 못했을 부분입니다."
인사이트: 창업자는 디자인 파트너의 사용자 피드백을 걸러내고, '예전 방식'에 기반한 요청과 실제 시장 필요를 드러내는 인사이트를 구분해야 합니다.
실행 조언:
- 피드백에 80/20 규칙을 적용합니다: 80%는 기존 습관 기반 잡음이고, 20%는 미래 제품을 안내하는 '금'입니다
타임스탬프: 00:30:37
Judd Antin
Judd Antin
"답을 이미 알고 있다면 모든 것이 명백합니다. 이것은 사후확신 편향에 관한 것입니다... 우리는 결국 선택적으로 기억하고, 실제로는 몰랐는데도 이미 알고 있었던 것처럼 느끼게 만드는 방식으로 그 주변에 서사를 구성합니다."
인사이트: 팀은 사후확신 편향과 서사 오류에 자주 빠져, 리서치 인사이트를 나중에 '당연한 것'으로 치부합니다.
실행 조언:
- A/B 테스트가 제공하지 못하는 데이터 뒤의 '어떻게와 왜'를 설명하기 위해 리서치를 사용합니다
- 충돌하는 증거를 무시하는 단순하고 편리한 과거 사건 이야기를 만들지 않도록 주의합니다
타임스탬프: 00:43:16
Julie Zhuo
Julie Zhuo 2.0
"대화형 분석은 완전히 다릅니다... 실제로 사용자 의도가 무엇인지 분리해내기가 더 어렵습니다... 사용자 의도를 버킷으로 나누려면 아마 LLM이나 머신러닝 모델을 사용해야 할 것입니다."
인사이트: AI 시대의 사용자 피드백은 종종 구조화되지 않은 대화이므로, 의도를 종합하려면 새로운 머신러닝 기반 방법론이 필요합니다.
실행 조언:
- 대화 데이터에서 사용자 의도를 버킷화하고 종합하기 위해 LLM을 사용합니다
타임스탬프: 00:30:16
Kristen Berman
Kristen Berman
"우리는 사람들이 하겠다고 말하는 것과 실제로 하는 것을 이해하려고 합니다. 그렇게 하면 예산 기능이 실제로 바꾸려는 행동을 바꾸는 데 효과가 있을지 모두가 의심해야 한다는 점이 매우 분명해집니다."
인사이트: 사용자 요청은 실제 행동 변화로 이어지지 않는 경우가 많습니다. 제품팀은 말로 표현된 선호보다 관찰된 행동을 우선해야 합니다.
실행 조언:
- 요청된 기능이 목표 행동에 필요한 마찰을 실제로 줄이는지 확인하기 위해 행동 진단을 수행합니다
타임스탬프: 09:03
Laura Schaffer
Laura Schaffer
"저는 고객의 목소리 보고서를 공유하기 시작했습니다. 인사이트를 공유하고, 적어 내려가고, 그냥 공유하기 시작했습니다. 그것이 다이제스트가 되었고 결국 사람들은 '저에게도 공유해주실 수 있나요? 저도 목록에 넣어주실 수 있나요?'라고 말했습니다."
인사이트: 고객 인사이트를 내부에 배포하면 주제 전문가로 자리 잡고 리더십의 신뢰를 만들 수 있습니다.
실행 조언:
- 회사와 공유할 정기적인 '고객의 목소리' 다이제스트를 만듭니다
- 분기별 세션을 열어 제품 조직에 고객 인사이트를 발표합니다
- 여러 부서의 피드백을 모아 고객 고통 지점에 대한 전체적인 관점을 제공합니다
타임스탬프: 00:13:55
Maggie Crowley
Maggie Crowley
"데이터 기반이 되는 것에 정말 흥분하는 사람들은 제게 종종 제품 사고의 경고 신호입니다... 그들은 정성 데이터의 희생 위에서 정량 데이터를 과도하게 강조하고 좋은 판단을 쓰지 않습니다."
인사이트: 대시보드에 과도하게 의존하면 인간 사용자와 그 동기에 대한 이해 부족을 가릴 수 있습니다.
실행 조언:
- '왜'를 이해하기 위해 정량 대시보드와 직접 사용자 인터뷰를 균형 있게 사용합니다
- 대시보드보다 나은 인사이트를 얻기 위해 사용자 10명과 이야기합니다
- 방대한 데이터 정당화가 필요 없는 '분명히 더 나은' 개선을 식별하는 데 판단을 사용합니다
타임스탬프: 00:58:39
Marty Cagan
Marty Cagan
"사용자 리서치를 할 때 우리는 그들이 그것을 좋아하지 않는 모든 이유를 찾습니다. 사실 Elon Musk의 말처럼, 사용자 리서치를 할 때는 사람들이 왜 당신의 제품을 쓰지 않을지 모든 이유를 찾는 데 집중해야 합니다."
인사이트: 평가 리서치의 주요 목표는 검증을 찾는 것이 아니라 마찰과 거절 이유를 식별하는 것입니다.
실행 조언:
- 고객이 제품을 쓰지 않을 이유를 찾는 데 사용자 리서치를 집중합니다
- 해결책의 결함을 드러내기 위해 평가 리서치를 사용합니다
타임스탬프: 00:32:45
"두 번째는 데이터 전문가가 되어야 한다는 점입니다. 제품이 어떻게 사용되는가? 시간이 지나며 어떻게 변하는가? 영업 분석은 무엇인가? 사용자 분석은 무엇인가? 제품이 실제로 어떻게 쓰이는지 알아야 합니다."
인사이트: 제품 관리자는 사용자 행동 데이터와 영업 분석을 깊고 직접적으로 이해해야 합니다.
실행 조언:
- 시간이 지나며 제품이 어떻게 사용되는지 이해하기 위해 사용자 분석을 연구합니다
- 제품 사용의 비즈니스 영향을 이해하기 위해 영업 데이터를 분석합니다
타임스탬프: 00:40:41
"또 하나는 데이터 전문가가 되어야 한다는 것입니다. 우리 제품이 어떻게 사용되고 있는가? 그 사용은 시간이 지나며 어떻게 바뀌고 있는가? 어떻게 구매되고 있는가? 이것이 큽니다."
인사이트: 제품 관리자는 제품 사용과 구매 추세에 대한 깊은 정량 전문성을 유지해야 합니다.
실행 조언:
- 팀에서 제품 사용 데이터의 주요 전문가가 됩니다
- 제품 결정을 알리기 위해 사용 패턴이 시간이 지나며 어떻게 바뀌는지 추적합니다
타임스탬프: 00:24:09
Matt MacInnis
Matt MacInnis
"제품 임원인 제게 고객의 에스컬레이션을 받는 것보다 더 큰 선물은 없습니다... 에스컬레이션은 선물입니다... 그것은 회사 안의 다른 사람들을 몰아붙여 진짜 근본 원인에 도달하게 하는 데 특히 능숙한 사람들입니다."
인사이트: 고객 에스컬레이션은 제품이나 프로세스의 시스템적 실패를 식별하는 최고의 데이터 원천입니다.
실행 조언:
- 모든 에스컬레이션을 선물로 보고 깊은 근본 원인 분석의 기회로 삼습니다
- 오류를 소프트웨어, 그다음 시스템, 그다음 그 시스템을 만든 프로세스까지 추적합니다
타임스탬프: 01:13:09
Melissa Perri + Denise Tilles
Melissa Perri + Denise Tilles
"사람들이 조회할 수 있도록 지금까지 수행된 모든 인터뷰나 고객 리서치를 집계하는 것도 중요합니다. 그러면 우리가 이미 무엇을 알고 있는지 보기 시작할 수 있고, 밖에 나가 같은 리서치를 잔뜩 중복하지 않게 됩니다."
인사이트: 리서치 결과를 조회 가능한 데이터베이스로 중앙화하면 조직 전반의 중복 발견 작업을 막을 수 있습니다.
실행 조언:
- Dovetail 같은 도구를 사용해 정성 리서치를 집계합니다
- 팀원이 과거 인터뷰 결과를 조회할 수 있는 '발견 데이터베이스'를 만듭니다
타임스탬프: 00:16:22
"우리가 이야기하는 또 다른 부분은 영업과 지원에서 정성 인사이트를 얻는 것입니다... 우리가 하려는 것은 그것을 개별 시스템에서 꺼내 많은 사람이 그 정성 인사이트를 가져가 배우기 시작할 수 있는 곳으로 옮기는 것입니다."
인사이트: 가치 있는 제품 인사이트는 Salesforce나 지원 티켓 같은 사일로에 갇혀 있는 경우가 많으며, 제품팀을 위해 종합되어야 합니다.
실행 조언:
- Salesforce와 지원 티켓에서 고객 피드백을 추출해 중앙 시스템으로 옮깁니다
- 이탈 이유와 기능 요청을 체계적으로 추적하기 위해 영업팀과 피드백 루프를 구축합니다
타임스탬프: 00:17:30
Melanie Perkins
Melanie Perkins
"우리는 커뮤니티에서 매년 백만 건이 넘는 요청을 받고, 그것을 집계하고 분해한 다음 모든 제품팀에 전달하는 훌륭한 팀이 있습니다. 그리고 그것들은 실제로 닫힙니다."
인사이트: 대량 사용자 피드백의 수집과 분류를 체계화해 제품 로드맵을 이끕니다.
실행 조언:
- 가장 '뜨겁게 요청된' 기능을 식별하기 위해 커뮤니티 요청을 집계하고 분류합니다
- 제품팀이 해결할 특정 커뮤니티 요청을 배정받는 '루프 닫기' 프로세스를 만듭니다
타임스탬프: 00:38:17
Nick Turley
Nick Turley
"저는 그것들을 자세히 살펴봅니다. 저도 그런 사용 사례를 알고 있었던 것이 아니기 때문입니다. 그것들은 매우, 매우 창발적이고, 저는 댓글을 읽고 처리합니다. 배울 것이 너무 많기 때문입니다. ... 매우, 매우 유용하다고 느낍니다. 사람들이 자신들이 가진 다양한 사용 사례에 대해 서로 이야기하는 모습을 보는 것도 재미있습니다."
인사이트: TikTok 같은 소셜 미디어 플랫폼은 범용 AI의 예측하지 못한 창발적 사용 사례를 발견하는 데 매우 귀중합니다.
실행 조언:
- 바이럴 소셜 게시물의 댓글을 읽어 새로운 사용자 적용 사례를 찾습니다
- 대규모 사용자 데이터에서 상위 추세를 식별하기 위해 대화 분류기를 사용합니다
타임스탬프: 00:48:55
Nicole Forsgren
Nicole Forsgren
"사람에게서 오는 데이터와 시스템에서 오는 데이터는 정말 중요한 보완재입니다. 시스템에서는 절대 얻지 못할 특정 인사이트를 사람에게서 얻을 수 있기 때문입니다. 예를 들어 변경 리드타임을 보겠습니다. 커밋에서 배포까지의 시간입니다. 속도는 괜찮아 보일 수 있지만, 사람들은 그것을 해내려면 절대적인 영웅적 노력이 필요하다고 말할 수 있습니다. 말도 안 되는 Rube Goldberg 기계 같은 것이죠. 시스템은 절대 그것을 말해주지 않습니다."
인사이트: 시스템 원격 측정은 성능을 유지하는 데 필요한 '인간 비용'이나 '영웅적 노력'을 놓치는 경우가 많으므로 정성 피드백이 필수입니다.
실행 조언:
- 자동화 시스템이 포착할 수 없는 인사이트를 발견하기 위해 개발자를 최소 1년에 한 번 설문합니다
- 시스템 데이터와 사용자 설문이 불일치하는 지점을 찾습니다. 설문이 현실을 더 정확히 반영하는 경우가 많습니다
타임스탬프: 00:37:27
Nikhyl Singhal
Nikhyl Singhal
"피드백을 끌어내고 듣는 일을 잘해야 합니다. 항상 당신을 보지 않는 사람, 항상 보는 사람, 동료에게서 그것을 삼각측량해야 합니다. 하지만 제공자가 보복이나 우려를 걱정하지 않아도 되는 안전한 환경을 만들어야 합니다."
인사이트: '실제 진실' 피드백을 얻으려면 다양한 출처에서 적극적으로 끌어내고 제공자를 위한 심리적 안전을 만들어야 합니다.
실행 조언:
- 피드백을 내면화했다는 것을 보여주기 위해 제공자가 말한 것보다 더 잘 정리해 되돌려 말합니다
- 피드백 문화를 장려하기 위해 받은 건설적 피드백을 공개적으로 공유하고 출처를 인정합니다
- 숨은 성장 영역을 찾기 위해 이전에 무시했던 이상치인 피드백의 '버린 더미'를 봅니다
타임스탬프: 00:31:43
Nikita Bier
Nikita Bier
"앱 안에 하루 24시간 실시간 채팅 고객 지원을 넣으세요... 사용자가 말 그대로 겪고 있는 문제를 알려주기 때문에 피드백을 얻고 사용자 리서치를 하는 최고의 수단입니다."
인사이트: 실시간 지원 채널은 전통적인 리서치 방법보다 더 높은 품질과 더 즉각적인 제품 신호를 제공합니다.
실행 조언:
- 초기 출시 단계에는 앱 안에 실시간 채팅을 삽입합니다
- 흥미로운 지원 피드백을 제품 개발 채널로 직접 보내는 전용 프로세스를 둡니다
타임스탬프: 00:32:18
Nilan Peiris
Nilan Peiris
"댓글을 읽어보면, 지금은 당연히 그 위에 온갖 멋진 모델들이 올라가 있지만, 고객들은 계속 같은 말을 했습니다. '더 빠르게, 더 싸게, 더 쉽게 쓰게 해달라.' ... 고객들은 꽤 분명했습니다. 우리가 전도자라고 부르는 사람들은 훨씬 더... 더 저렴한 경험을 가진 사람들이었고, 그것에 대해 이야기한 사람들은 빠른 경험을 가진 사람들이었습니다."
인사이트: NPS 댓글의 정성 피드백은 사용자 전도를 이끄는 핵심 제품 축을 식별하는 가장 효과적인 방법입니다.
실행 조언:
- 무엇이 흥분을 만드는지 이해하기 위해 '전도자' 사용자(9-10점)의 구체적 댓글을 읽습니다
- 피드백을 가격, 속도, 사용 편의성 같은 상위 축으로 집계합니다
- 무엇이 중요한지에 대한 공동 확신을 만들기 위해 원시 고객 댓글을 회사 전체와 공유합니다
타임스탬프: 00:12:51
Oji Udezue
Oji Udezue
"고객 청취는 다릅니다. 그것은 사실 발견이 아닙니다. 어차피 계속 발생하는 고객 신호를 긁어모으는 것입니다. 사람들은 소셜에서 이야기하고, 앱스토어와 G2 Crowd에서 이야기합니다. 계측된 이탈 설문이 있다면 사람들은 이야기하고 있습니다. NPS가 있다면 사람들은 점수만 주는 것이 아니라 원문 응답도 넣습니다."
인사이트: 제품팀은 능동적 발견과 '고객 청취', 즉 지원, 영업, 소셜 미디어에서 오는 기존 신호의 체계적 처리를 구분해야 합니다.
실행 조언:
- Zendesk, Salesforce(성사/실패 메모), 앱스토어 리뷰에서 오는 신호를 분류해 빈도 분포를 봅니다
- '청취'의 마찰을 줄이기 위해 제품 관리자와 디자이너에게 고객 신호가 자동으로 표면화되는 시스템을 구성합니다
타임스탬프: 00:32:49
Patrick Campbell
Patrick Campbell
"10개 회사 중 단 하나만 분기별로 고객 리서치나 개발을 실제로 합니다. 이것은 지속적인 것이어야 하고, 월간, 주간 형태여야 합니다."
인사이트: 정기적인 고객 리서치는 더 높은 NPS, 더 나은 유지율, 더 효율적인 성장 퍼널과 상관관계가 있는 거대한 경쟁 우위입니다.
실행 조언:
- 매월 영업 목적이 아닌 고객 대화 10건을 약속합니다
- 길고 복잡한 설문보다 짧고 표적화된 설문(30-45초)을 보냅니다
- 단순 기능 요청을 받아들이기보다 고객 인식과 세계관을 이해하는 데 리서치를 사용합니다
타임스탬프: 00:41:44
Ramesh Johari
Ramesh Johari
"평점 시스템 문헌에는 침묵의 소리라는 훌륭한 개념이 있습니다. 남겨지지 않은 평점에도 많은 정보가 있다는 생각입니다... 이것은 판매자의 이후 성과를 훨씬 더 잘 예측했습니다. 그러니 응답이 없다는 데에도 많은 정보가 있습니다."
인사이트: 평점의 부재는 사용자가 말하기에는 너무 공손한 보통 또는 나쁜 경험의 강한 신호인 경우가 많습니다.
실행 조언:
- 참가자 성과를 더 정확히 파악하기 위해 '무응답'을 품질 지표에 포함합니다
타임스탬프: 01:07:44
Robby Stein
Robby Stein
"사람들에게 '왜 스토리에 게시하지 않나요? 무엇이 막고 있나요?'라고 물었을 때... 공통점은 청중 문제였습니다. 누군가가 자신을 보는 사람들에 대해 문제가 있었습니다."
인사이트: 사용자 피드백 전반의 공통 심리적 장벽을 식별하면 'Close Friends' 같은 주요 새 기능을 만들 수 있습니다.
실행 조언:
- 핵심 제품 공백을 식별하기 위해 사람들이 기능을 쓰지 않는 이유의 공통점을 찾습니다
- 공유 앱에서 '청중 문제'나 사회적 마찰을 드러내기 위해 정성 리서치를 사용합니다
타임스탬프: 01:01:16
Sachin Monga
Sachin Monga
"우리는 그것을 작가와 함께 만들고, 독자와 함께 만든다고 부릅니다... 작가들을 함께 데려가는 방식으로 합니다... 이제 우리는 제품 실험실이라는 것을 만들었습니다... 최첨단에 관심이 있다는 것을 아는 작가 백 명 정도의 초대 전용 작은 그룹입니다."
인사이트: 일반 출시 전에 빠른 피드백을 받고 기능을 공동 제작하기 위해 파워 유저로 구성된 전용 '제품 실험실'을 만듭니다.
실행 조언:
- 위험이 높거나 근본적인 변경을 테스트하기 위해 일부 사용자와 작은 파일럿을 운영합니다
- 더 넓은 대시보드에 반영되기 전에 해당 그룹의 직접 피드백으로 기능 설계를 반복 개선합니다
타임스탬프: 00:33:18
Sean Ellis
Sean Ellis
"제가 좋아하는 질문 중 하나는... '당신이 얻는 주요 이점은 무엇인가요?'입니다. 저는 처음에는 사람들이 얻는 다양한 이점을 크라우드소싱하기 위해 열린 질문으로 사용합니다. 하지만 그다음 또 다른 설문을 실행해 그것을 객관식 질문으로 바꾸고, 네 가지 뚜렷한 이점 문장 중 하나를 고르게 합니다. 그리고 그 다음 설문에서 이어지는 질문은 '그 이점이 왜 당신에게 중요한가요?'입니다."
인사이트: 두 단계 설문 과정(열린 질문 후 객관식)은 핵심 가치 제안을 정량화하고 맥락화하는 데 도움이 됩니다.
실행 조언:
- 먼저 열린 질문으로 이점을 크라우드소싱합니다
- 객관식 후속 질문으로 이점 우선순위를 강제합니다
- 사용자의 맥락과 고통 지점을 이해하기 위해 '왜 이것이 중요한가요?'라고 묻습니다
타임스탬프: 00:14:59
"왜 가입했지만 소프트웨어를 다운로드하지 않았는지 그냥 물어보면 어떨까요? ... 우리는 '아직 제품을 사용할 기회가 없으신 것 같아 연락드립니다. 무슨 일이 있었나요?'라고 물었습니다. 고객 지원에서 온 것처럼 보였습니다. 그리고 받은 답은... '너무 좋아서 사실일 리 없다고 생각했습니다. 이것이 무료라는 것을 믿지 않았습니다'였습니다."
인사이트: 퍼널 마찰 지점에 대해 사용자에게 직접 물으면 활성화를 막는 뜻밖의 심리적 장벽이 드러날 수 있습니다.
실행 조언:
- 특정 퍼널 단계에서 이탈한 사용자에게 '고객 지원'에서 온 것처럼 보이는 개인적인 이메일을 보냅니다
- 다운로드나 설치 같은 특정 행동을 완료하지 않은 이유를 열린 질문으로 묻습니다
타임스탬프: 00:58:26
Shaun Clowes
Shaun Clowes
"그는 이 개념을 피드백 강이라고 부르곤 했고, 기본적으로 정말 똑똑한 제품 관리자는 계속 피드백 강에서 헤엄친다고 말했습니다. 그들은 자신을 피드백 강으로 둘러싸려고 하고, 저는 그것을 정말 깊이 믿습니다."
인사이트: 뛰어난 제품 관리자는 다양한 고객 및 시장 피드백 흐름에 지속적으로 몰입하는 시스템을 만듭니다.
실행 조언:
- 사용자 인터뷰 데이터, NPS, 경쟁사 정보를 매일 자신에게 '흘러오게' 하는 자동 스트림을 설정합니다
타임스탬프: 00:17:26
"우리는 LLM을 사용해 그런 요청을 받아 그것이 무엇에 관한 것인지 요약하고, 그것과 비슷한 다른 요청을 찾습니다. 정말 설득력 있고 실제적인 방식으로, 의미론적인 방식으로요. 단어가 정확히 같은지가 아니라, 이것들이 같은 개념인가를 봅니다. 그래야 우리에게 들어오는 모든 수요를 가로질러 '가장 인기 있는 아이디어는 이것이고 점점 더 인기를 얻고 있다'고 말할 수 있습니다."
인사이트: LLM을 활용한 의미 분석은 키워드 매칭보다 대량 고객 피드백을 더 정확하게 군집화하고 우선순위화할 수 있게 합니다.
실행 조언:
- 실제 수요 추세를 식별하기 위해 고객 요청 유입에 LLM 기반 의미 군집화를 수행합니다
타임스탬프: 00:18:20
Shweta Shriva
Shweta Shriva
"인간의 뇌는, 또는 인간 운전자는 무의식적으로 그런 경사에서 내리막을 갈 때 속도를 늦추도록 훈련되어 있습니다. 자율주행 차량은 안전하다면 반드시 그럴 필요는 없습니다... 하지만 우리는 이것이 더 자연스러운 주행 경험이고 탑승자도 경험 측면에서 그것을 기대한다는 것을 배웠습니다. 그래서 그 행동을 수정했습니다."
인사이트: 사용자 피드백은 순수하게 논리적이거나 기술적인 최적화와 충돌하는 무의식적 인간 기대를 드러낼 수 있습니다.
실행 조언:
- 기술적으로 '맞는' 행동이 사용자에게 '부자연스럽게' 느껴지는 공백을 식별합니다
- 사용자 무의식 습관과 기대에 맞도록 시스템 행동을 수정합니다
타임스탬프: 15:31
Tomer Cohen
Tomer Cohen 2.0
"우리 리서치 에이전트는 기본적으로 회원 페르소나로 학습되어 있습니다... 세계 지식만 쓰는 것이 아니라 과거에 우리가 수행한 모든 리서치와 들어오는 모든 지원 티켓을 사용합니다. 그래서 LinkedIn의 그 페르소나를 이해하는 데 꽤 좋습니다."
인사이트: AI 에이전트는 수년간의 과거 리서치와 고객 지원 데이터를 종합해 특정 사용자 페르소나가 새 기능에 어떻게 반응할지 즉각적인 피드백을 제공할 수 있습니다.
실행 조언:
- 내부 페르소나와 과거 사용자 리서치로 리서치 에이전트를 학습시킵니다
- 설계 단계에서 '고객의 목소리'를 제공하기 위해 지원 티켓을 AI 모델에 공급합니다
타임스탬프: 00:22:05
Tim Holley
Tim Holley
"우리는 특정 판매자들이 보고 있는 수요를 감당하지 못할까 걱정했습니다. 그래서 옛날식으로, 직접은 아니지만 그들에게 전화해서 '어떻게 지내세요? 무엇을 도와드릴까요?'라고 물었습니다."
인사이트: 변동성이 크거나 고성장인 기간에는 사용자에게 직접 '옛날식'으로 연락하면 데이터만으로는 포착할 수 없는 중요한 정성 인사이트를 얻을 수 있습니다.
실행 조언:
- 위기나 고성장 기간에는 파워 유저에게 직접 전화해 즉각적인 필요를 이해합니다
- 숨은 고통 지점을 드러내기 위해 '무엇을 도와드릴까요?' 같은 열린 질문을 합니다
타임스탬프: 00:15:20
Uri Levine
Uri Levine
"개선하려면 실패한 사람들, 성공하지 못한 사람들, 등록하지 않은 사람들, 또는 등록했지만 사용하지 않은 사람들, 사용했지만 돌아오지 않은 사람들과 이야기해야 합니다. 그들은 우리가 정말 알아야 하는 것을 알고 있기 때문입니다."
인사이트: 제품 개선에 가장 중요한 인사이트는 성공한 사용자가 아니라 퍼널에서 떨어져 나간 사용자에게서 나옵니다.
실행 조언:
- 실패 뒤의 '왜'를 찾기 위해 이탈했거나 등록을 완료하지 못한 사용자를 인터뷰합니다
타임스탬프: 01:12:17
Vijay
Vijay
"이것이 만들어낸 것은 모든 엔지니어와 디자이너가 게이트키퍼도, 접근 절차도, 사전 집계도 없이 직접적인 고객 접점의 원시 피드를 소비할 수 있는 문화였습니다."
인사이트: 원시적이고 편집되지 않은 사용자 고통 지점을 공유 팀 채널로 직접 흘려보내 고객 피드백을 민주화합니다.
실행 조언:
- 영업과 고객 성공팀의 고객 '공백'을 Slack 피드로 직접 보냅니다
- 엔지니어가 특정 피드백 지점 뒤의 '다섯 번 왜'를 묻기 위해 고객에게 직접 연락하도록 장려합니다
- 팀에 맥락을 제공하기 위해 ARR, 고객 성공 관리자 이름 같은 계정 데이터로 피드백 피드를 보강합니다
타임스탬프: 30:43
Yuhki Yamashata
Yuhki Yamashata
"우리는 Concerning Tweets라는 새 비공개 채널을 만들었습니다. Dylan이 우리를 넣을 수 있는 작은 그룹이었습니다. 이것들은 결코 바이럴이 되는 트윗이 아닙니다. 좋아요 하나, 때로는 좋아요 0개가 있는 것들입니다. 하지만 그는 그 안에 진실의 핵심이 있다고 느끼고, 우리는 그곳에서 무슨 일이 벌어지는지 보고 우리가 집중해야 할 훨씬 더 큰 무언가가 없는지 확인합니다."
인사이트: 고품질 제품 개발에는 한 자릿수 좋아요 트윗 같은 약한 신호 피드백을 더 큰 문제의 '광산 속 카나리아'로 관찰하는 일이 필요합니다.
실행 조언:
- '우려되는' 저빈도 피드백 전용 채널을 만듭니다
- 소셜 미디어의 목소리 큰 소수와 지원 티켓 및 영업에서 오는 더 넓은 데이터를 균형 있게 봅니다
- 개별 불만을 시스템적 사각지대의 잠재 신호로 취급합니다
타임스탬프: 00:25:31
Dylan Field
Dylan Field
"저는 Figma에 대한 정보를 계속 흡수하려고 모든 곳을 봅니다. Twitter/X만이 아니라, 지금 뭐라고 부르든, 인터넷 어디든, 지원 채널 등 모든 곳입니다. 그리고 항상 이해하려고 합니다. 질문도 많이 하고 근본 문제에 도달하려 하며 사람들이 어디에서 오는지, 실제로 무엇을 해결하려 하는지 이해하려고 합니다. 때로 사람들은 'X가 필요합니다'라고 말하지만, 실제로는 Y나 Z를 원합니다."
인사이트: 사용자 피드백을 진정으로 이해하려면 모든 채널을 보고, 명시된 요청과 근본 필요를 구분하기 위해 파고드는 질문을 해야 합니다.
실행 조언:
- 넓은 피드백을 흡수하기 위해 소셜 미디어와 지원 포럼 같은 비전통 채널을 관찰합니다
- 사용자가 요청한 'X' 뒤의 'Y나 Z' 문제를 드러내기 위해 후속 질문을 합니다
타임스탬프: 12:00
Josh Miller
Josh Miller
"멤버십... 우리는 그들과 깊고 진정성 있으며 지속적인 관계를 가져야 합니다. 1일차에는 따옴표로 말해 '고객 성공'일 수 있습니다. ... 37일차에는 '버그가 있습니다'일 수 있습니다. ... 58일차에는 '모바일 앱을 곧 출시합니다. 모바일에서 무엇을 원하시나요?'일 수 있습니다. 다른 회사들은 그것을 서로 다른 조직과 분야로 봅니다. 우리는 반대편에 우리가 섬기는 사람들이 많이 있다고 봅니다."
인사이트: 고객 지원, 고객 성공, 사용자 리서치를 하나의 '멤버십' 기능으로 통합해 사용자와 전체적이고 장기적인 관계를 유지합니다.
실행 조언:
- 첫 접점부터 장기 유지까지 사용자 관계를 '풀스택'으로 소유합니다
- 맥락을 유지하기 위해 버그 보고와 기능 발견에 같은 팀을 사용합니다
타임스탬프: 00:47:36
Megan Cook
Megan Cook
"먼저, 제가 언급했듯이 우리는 그 설문이 있었고 정말 풍부한 피드백을 받았습니다. 그래서 단순히 평점만 받는 것이 아닙니다. 사람들이 왜 그 평점을 줬는지 말해줍니다. 그것은 무엇이 핵심적으로 점수를 낮추는지 정확히 좁히는 데 정말 도움이 됩니다."
인사이트: 정량 만족도 점수를 끌어내리는 구체적 사용성 문제를 식별하기 위해 정성 설문 피드백을 깊이 분석합니다.
실행 조언:
- 실행 가능한 사용성 공백을 찾기 위해 CSAT나 NPS 평점 뒤의 '왜'에 집중합니다
- 품질 개선에 대한 감정적 몰입을 만들기 위해 생생한 고객 피드백(영상이나 인용)을 팀과 공유합니다
- 사용성 개선을 획득과 확장 같은 비즈니스 지표에 연결합니다
타임스탬프: 00:39:05
Tamar Yehoshua
Tamar Yehoshua
"제가 많은 제품 관리자가 저지르는 실수로 보는 것 중 하나는 출시하는 제품에 불만을 가질 사람들에게 과도하게 치우친다는 점입니다... 내일 그것을 사용할 더 많은 사람을 위해 설계해야 합니다. UI를 다시 해야 하고 Who Moved My Cheese 같은 상황이 되면 사람들은 불만을 가질 것입니다. 하지만 모든 새 사람들은 '이건 훨씬 쉽다'라고 할 것입니다."
인사이트: 제품 관리자는 현재 사용자의 목소리 큰 소수 불만보다 미래 규모의 필요를 우선해야 합니다.
실행 조언:
- 변경 이유를 설명할 때 '마케팅 말투'가 아니라 투명하고 진정성 있게 설명합니다
- 기능을 종료할 때 사용자가 들렸다고 느끼도록 선택권이나 전환 기간을 제공합니다
타임스탬프: 00:46:04