product-management

3 개의 포스트

끊김 없는 사용 경험을 위하여 : 카카오톡 선물함 속 교환권을 배달의민족 주문으로 연결한 여정 (새 탭에서 열림)

배달의민족 선물하기 팀은 사용자가 카카오톡으로 받은 브랜드 교환권을 배달의민족 앱에서 직접 등록하고 주문에 사용할 수 있도록 하는 '외부 교환권 연동 서비스'를 기획하고 구현했습니다. 이 프로젝트는 플랫폼 간의 기술적·비즈니스적 장벽을 허물어 사용자의 파편화된 구매 경험을 하나로 잇고, 외부의 잠재적 주문 수요를 배달의민족 생태계 안으로 흡수하는 것을 핵심 목표로 삼았습니다. 결과적으로 기술적 복잡성과 다자간의 이해관계를 극복하며 '끊김 없는 연결'이라는 사용자 중심의 가치를 실현해냈습니다. **사용자 불편 해소와 비즈니스 성장의 결합** - 카카오톡 선물을 사용하기 위해 브랜드 자사 앱을 새로 설치하거나 매장을 직접 방문해야 했던 고객의 페인포인트(Pain Point)를 해결했습니다. - 외부 플랫폼에 머물던 교환권 수요를 배달의민족 앱 내 주문으로 전환함으로써 신규 고객 유입과 락인(Lock-in) 효과를 도모했습니다. - 단순히 기능을 추가하는 것을 넘어, 플랫폼 경계를 확장하여 배달의민족을 모든 주문 경험의 통합 창구로 만들고자 했습니다. **플랫폼 간 장벽을 넘는 ‘연결’의 본질 정의** - 여러 조직이 참여하는 대규모 프로젝트에서 "플랫폼 간 장벽을 넘어 사용자에게 끊김 없는 연결을 제공한다"는 본질적인 목표를 설정하여 의사결정의 기준으로 삼았습니다. - 기술적 제약이나 비즈니스 수익성 등 이해관계가 충돌할 때마다 프로젝트의 본질을 자문하며 사용자 중심 사고를 유지했습니다. - 고립된 플랫폼 생태계를 연결함으로써 사용자에게 경험의 단절이 없는 새로운 가치를 제공하는 선례를 남겼습니다. **다자간 협업을 위한 맞춤형 소통 기술** - 카카오(플랫폼사), 브랜드사, 쿠폰 연동사 등 서로 다른 KPI를 가진 파트너들과 공통의 목표인 ‘고객 경험 개선’을 공유하며 협력을 이끌어냈습니다. - 백엔드 개발자에게는 API 응답 속도와 에러 핸들링을, 비즈니스 담당자에게는 제휴 조건과 정산 프로세스를 중심으로 설명하는 ‘맞춤형 언어’를 사용했습니다. - ‘등록·사용’(배민)과 ‘조회·승인’(연동사)처럼 서로 다른 도메인 용어와 로직을 꼼꼼히 동기화하여 시스템 간의 간극을 메웠습니다. **주도적인 문제 해결과 기술적 조율** - 단순히 요구사항을 전달하는 가교 역할을 넘어, 양사 기술팀이 합리적인 타협점을 찾을 수 있도록 API 스펙과 에러 대응 정책을 주도적으로 조율했습니다. - 다양한 외부 연동사의 시스템을 수용하면서도 배달의민족 내에서의 사용 경험을 표준화하기 위한 기술적 스펙을 정의했습니다. - 복잡한 의존 관계를 가진 작업들 사이에서 우선순위를 설정하고 일정을 관리하며 프로젝트의 항해사 역할을 수행했습니다. 이 프로젝트는 기술적 구현만큼이나 플랫폼 간의 심리적·비즈니스적 거리를 좁히는 과정이 중요함을 보여줍니다. 복잡한 시스템 연동을 앞두고 있다면, 기술 스펙에 매몰되기보다 '사용자에게 어떤 연결된 가치를 줄 것인가'라는 본질을 먼저 정의하고, 파트너의 언어로 소통하며 주도적으로 표준을 만들어가는 접근 방식이 필요합니다.

POPM 과정은 어떻게 하나의 ‘제품’이 되었나 - tech.kakao.com (새 탭에서 열림)

카카오의 POPM 교육은 단순한 지식 전달 과정을 넘어, PO와 PM이 공통의 언어로 협업하고 문제를 해결할 수 있도록 돕는 하나의 '제품'으로 설계되었습니다. 교육 과정을 제품 개발 프로세스와 동일하게 '구조화'와 '반복 실험'의 관점에서 접근했으며, 수강생의 피드백을 데이터로 치환하여 지속적으로 기능을 개선하듯 커리큘럼을 고도화했습니다. 결과적으로 이 과정은 전략이 실제 실행으로 이어지도록 만드는 조직 차원의 구조적 프레임워크를 구축하는 성과를 거두었습니다. **POPM 교육의 탄생 배경과 목적** * PO와 PM의 역할이 모호하고 비가시적인 업무가 많아 발생하는 의사결정의 혼선을 줄이기 위해 시작되었습니다. * 문제 정의, 지표 해석, 실험 설계 등 실무에서 반복되는 질문들에 대해 조직이 공유할 수 있는 공통 언어를 수립하는 것이 핵심 목표입니다. * PO의 전략적 고민과 PM의 실행이 단절되지 않고 하나의 목표로 이어질 수 있는 구조적 기틀을 마련하고자 했습니다. **제품 개발 프로세스를 닮은 교육 설계** * 파일럿 과정(1기)의 8개 세션을 시작으로, 매 기수마다 '사용자 피드백'을 반영하여 구조를 최적화했습니다. * 3기부터는 '전략 → 지표 → 실험 → 디자인 → 실행'의 5개 핵심 세션으로 고정하여 흐름을 단순화하고 몰입도를 높였습니다. * 교육 설계자는 PM의 관점에서 교육을 하나의 제품으로, 각 세션을 기능으로, 각 기수를 소프트웨어 버전으로 정의하여 반복 개선을 수행했습니다. **데이터 기반의 기회 점수 도출과 리디자인** * 수강생 대상의 사전/사후 설문을 통해 각 세션의 '중요도'와 '만족도' 매트릭스를 분석했습니다. * 중요도는 높으나 만족도가 낮은 영역(예: 데이터/지표 세션)을 '기회 영역'으로 정의하고, 이를 제품 기능의 우선순위처럼 취급하여 최우선적으로 개선했습니다. * 단순한 내용 수정을 넘어 슬라이드 재구성, 실습 난이도 조정, 워크시트 포맷 변경 등 구조적인 해결책을 적용하여 기회 점수를 관리했습니다. **설계자가 얻은 구조적 인사이트** * 교육은 사람의 변화보다 '구조의 누적'에 집중해야 하며, 시스템이 바뀌지 않으면 동일한 시행착오가 반복된다는 점을 확인했습니다. * 지식의 전달보다 '질문의 리듬'을 설계하는 것이 중요하며, 슬라이드 하나에도 질문과 예시, 흐름을 유기적으로 배치하여 수강생의 사고를 유도했습니다. * 실습의 목적은 정답 작성이 아니라 '생각의 구조화'에 있으며, 실습 과정이 실제 팀의 업무 루틴으로 자연스럽게 이어지도록 설계했습니다. 조직 내 교육이나 프로세스를 설계할 때 이를 하나의 고정된 커리큘럼이 아닌, 지속적으로 개선 가능한 '제품'으로 바라보는 시각이 필요합니다. 수강생을 사용자로 정의하고 그들의 불편함을 데이터로 측정하여 구조를 개선해 나간다면, 교육은 단순한 학습을 넘어 조직의 실행력을 높이는 강력한 도구가 될 수 있습니다.

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

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