별점 4.8이 가린 문제, 매일 앱을 부숴 보는 PM
평점 4.8의 앱에서 고객이 프로모션 코드를 제대로 적용하지 못하는 일이 반복됐습니다. 숫자는 좋은데 경험은 나쁘다는 모순이 이 글의 출발점입니다. 기획과 QA의 경계에서 '지표가 가리는 마찰'을 어떻게 드러낼지 고민하는 팀에 참고할 만한 사례입니다.
"Repeated use gives the team another form of evidence, and the right tools to act on it."Mind the Product
무슨 일인가
Vladimir Pronin이 소개한 'Crash the App'은 PM이 실제 기기에서 지름길 없이 고객처럼 과업을 수행하는 습관입니다. 처음엔 주 1회 30분짜리 팀 세션이었지만, 각 PM이 자기 영역을 매일 비동기로 돌며 발견한 내용을 바로 팀 백로그에 기록하는 방식으로 바뀌었습니다. 프로모션 코드 사례에서는 CMS와 프로모션 도구 두 곳에 같은 설정을 수작업으로 입력하던 것이 근본 원인이었고, 팀은 개별 장애를 고치는 대신 CMS가 단일 원천에서 값을 가져오도록 구조를 바꿨습니다. 그 뒤 관련 불만 유형이 눈에 띄게 줄었다고 합니다.
여러 시각
같은 Mind the Product의 최근 글은 '고객 현장을 직접 본다'는 원칙을 다른 규모로 보여 줍니다.
- Mind the Product (Forward Deployed PM) — 고객사에 파견되어 사용 현장을 지켜보는 역할입니다. 지원 티켓이나 인터뷰 대신 문제가 어떻게 드러나고 사람들이 어떻게 우회하는지 직접 보고, 어떤 요구를 플랫폼 기능으로 만들지 걸러 냅니다.
- Mind the Product (Crash the App) — 고객 현장이 아니라 자기 제품을 반복 사용한다는 점이 다릅니다. 비용은 낮지만, 내부자 편향을 피하려면 실기기·실과업 원칙이 필요합니다.
왜 중요한가
평점이나 NPS 같은 요약 지표는 소수의 치명적 마찰을 평균에 묻어 버립니다. 반복 사용은 우연한 불편을 패턴으로 바꿔 주고, 패턴이 보이면 증상 수정이 아니라 원인 제거로 논의가 옮겨 갑니다. 또 책임을 공동 행사에서 개인 PM에게 옮기면 발견에서 수정까지의 시간이 짧아집니다. 엔지니어도 비난이 아닌 시스템 이해가 목적임을 알면 우군이 된다는 점이 인상적입니다.
실무 적용
- 스프린트마다 핵심 여정(가입·결제·쿠폰 적용)을 실기기로 따라가는 15분 점검을 QA 체크리스트 앞단에 넣습니다.
- 발견 사항은 재현 단계와 스크린 녹화와 함께 곧바로 백로그에 올리고, 같은 유형이 반복되면 원인 분석 티켓으로 묶습니다.
- 같은 값을 두 시스템에 수동 입력하는 지점을 목록화해 단일 원천(Single Source of Truth)으로 정리합니다.
Kenny의 관점
프런트엔드를 만드는 사람으로서 이 글의 핵심은 '직접 써 보는 일'이 가장 싸고 빠른 검증이라는 점입니다. 쿠폰 입력창 하나가 매출과 신뢰를 흔드는 걸 많이 봤고, 그 원인은 화면이 아니라 뒤쪽 데이터 구조인 경우가 적지 않았습니다. 기획자는 QA 결과를 기다리지 않고 자기 기획의 결과물을 먼저 써 봐야 합니다. 저는 작은 팀일수록 매일 하는 짧은 사용 습관이 대규모 회고보다 낫다고 생각합니다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Mind the Product ↗