product-strategy

누구나 리서치 하는 시대, UX리서처의 생존법 (새 탭에서 열림)

AI와 비전문가도 리서치를 수행할 수 있는 시대에 UX 리서처의 진정한 역할은 단순히 데이터를 수집하는 기술적 숙련도를 넘어, 제품의 방향성을 설정하고 팀의 시야를 하나로 모으는 'UX 리더십'에 있습니다. 리서처는 제품 개발의 각 단계에서 사용자의 본질적인 문제를 정의하고, 복잡한 비즈니스 맥락 속에서 팀이 길을 잃지 않도록 돕는 나침반 역할을 수행해야 합니다. ## 아이디어 단계: 사용자 중심의 '퍼즐 테두리' 맞추기 - 기획 초기 단계에서 팀의 관점을 '우리가 무엇을 만들 수 있는가'에서 '유저의 어떤 문제를 해결할 것인가'로 전환시킵니다. - 비즈니스 지표(재방문율, 체류시간 등)에만 매몰될 경우 발생할 수 있는 UX 저해 요소들을 사용자 관점의 가치 정의를 통해 방어합니다. - **사례(AI 시그널):** 단순한 정보 요약 기능을 넘어, 유저가 시장 변화의 이유를 빠르게 파악하여 투자 판단을 돕는다는 '북극성(핵심 가치)'을 설정해 제품의 윤곽을 잡았습니다. ## 개선 단계: 사용자 목표 중심의 구조화와 기준 수립 - 흩어져 있는 피드백과 문제점들을 나열하기보다, 사용자가 해당 기능을 통해 달성하려는 최종 '목표'를 먼저 정의합니다. - 목표 달성을 가로막는 방해 요인을 파악하고, 팀 전체가 동의할 수 있는 '서비스를 잘 쓴다는 것'에 대한 합의된 기준을 만듭니다. - **사례(증시 캘린더):** 단순한 일정 나열을 넘어 '인지-이해-준비'라는 3단계 사용자 여정을 설정함으로써, UI 수정을 넘어 투자자가 시장을 스스로 판단하게 돕는 도구로 제품을 고도화했습니다. ## 성장 및 정체 단계: 제품의 정체성과 환경적 맥락 재정의 - 제품의 성장이 정체되었을 때, 기능적 결함이 아닌 '제품의 정체성'과 '사용 환경(맥락)'의 불일치를 분석합니다. - 데이터, 인터뷰, 시장 트렌드를 입체적으로 결합하여 제품이 시장 내에서 차지해야 할 최적의 위치를 다시 찾습니다. - **사례(토스증권 PC):** 모바일의 '심플함'이 깊이 있는 분석이 필요한 PC 환경에서는 오히려 한계가 될 수 있음을 발견하고, PC라는 맥락에 맞는 새로운 가치와 제품의 지향점을 재정립했습니다. ## 리서처를 위한 실용적 제언 UX 리서처는 인터뷰를 잘하는 '기술적 장인'에 머물기보다, 제품과 산업 전체를 조망하는 넓은 시야를 갖추어야 합니다. 특히 팀원들의 흩어진 생각을 구조화하고, 의사결정의 근거가 되는 기준을 마련하여 **실질적으로 팀을 움직이게 만드는 'UX 리더십'**을 발휘하는 것이 AI 시대 리서처의 핵심 경쟁력입니다.

우리가 진짜 문제를 풀고 있었을까? — POPM 과정이 남긴 질문 - tech.kakao.com (새 탭에서 열림)

카카오의 POPM 교육 과정은 단순한 지식 전달을 넘어, 파편화된 실무 개념을 구조적으로 정리하고 이를 반복 가능한 '문제 해결 루프'로 연결하는 데 집중했습니다. 제품 전략이 팀의 일상적인 실행 지침이 되도록 돕는 이 과정은, 단순한 기능 배포가 아닌 '진짜 문제를 해결하고 있는가'라는 본질적인 질문을 실무에 던지게 합니다. 이를 통해 참가자들은 가설 검증과 지표 분석을 바탕으로 한 데이터 중심의 의사결정 체계를 실무에 직접 이식하는 성과를 거두었습니다. **전략적 사고와 지표의 재발견** * 전략을 거창한 구호가 아닌, 실무 현장에서 팀원들이 판단을 내릴 수 있게 돕는 '판단 기준'으로 재정의하고 MECE, MVP 등의 개념을 맥락에 맞게 재구성했습니다. * 지표를 단순한 데이터가 아니라 제품의 문제를 드러내는 '언어'로 인식하며, 퍼널·리텐션·코호트·LTV 등의 지표가 문제 정의와 어떻게 연결되는지 체득했습니다. * '내가 해석하는 지표가 우리 제품의 본질과 맞는가'라는 관점의 전환을 통해 데이터 해석의 정교함을 높였습니다. **실험 설계와 UX의 본질적 접근** * 실험의 성공 여부보다 '실패한 실험을 해석하는 루틴'을 중시하며, MASS 조건(측정 가능성, 기인 가능성, 민감도, 단기 확인)을 통한 구체적인 실험 체크리스트를 활용합니다. * UX 디자인을 단순한 심미적 요소가 아닌 '사용자 맥락에 기반한 설계'로 정의하고, 카카오 내부 서비스의 실제 사례를 통해 적합한 설계를 스스로 질문하게 유도했습니다. * 작게 시작하는 실험의 중요성을 강조하여 실무에서 즉시 가설을 검증해 볼 수 있는 자신감을 배양했습니다. **실무로 이어지는 실행 구조 설계** * '문제 정의 → 가설 → 지표 → 검증 → 회고'로 이어지는 루틴을 확립하여, 릴리스가 끝이 아닌 학습과 다음 우선순위 설정의 시작이 되도록 변화시켰습니다. * 과제 시작 전 '문제 정의, 기대 행동, 확인 지표'를 명문화하는 템플릿을 도입하고, 사용자 스토리 방식을 통해 팀 전체가 업무의 목적을 공유하도록 했습니다. * 주간 또는 격주 단위로 지표 확인 및 인사이트 공유 시간을 고정하여, 실행이 일시적인 이벤트가 아닌 조직의 습관으로 자리 잡게 했습니다. 프로덕트 매니저는 단순히 기능을 배포하는 것에 만족하지 말고, 배포 이후의 지표 변화가 당초 정의한 문제를 실제로 해결했는지 확인하는 '루프 기반 실행' 구조를 조직 내에 안착시켜야 합니다. "지금 우리가 하고 있는 이 일이 정말 문제 해결을 위한 실행인가?"라는 질문을 끊임없이 던지는 것이 제품 성장의 핵심입니다.