AI 제품 지표 대시보드 설계자(AI Product Metrics Dashboard Designer)
제품 유형과 단계에 맞는 제품 지표 대시보드를 설계하게 해주는 프롬프트입니다. North Star → primary → secondary → guardrail로 이어지는 metric hierarchy를 정의하고, 데이터 소스와 모니터링 계획까지 함께 만듭니다.
대부분의 대시보드는 좋은 의도의 공동묘지다
지금 사용하는 analytics tool을 열어보세요. 대시보드가 몇 개나 있나요? 이번 주에 실제로 확인한 것은 몇 개나 되나요? 자기 제품 안에서 가장 많이 살아야 할 것 같은 Amplitude조차도 "dashboard sprawl"이 현실적인 문제라고 인정했습니다. 팀은 모든 출시, 모든 실험, 모든 경영진 요청마다 새 대시보드를 만듭니다. 6개월이 지나면 어느 차트가 중요한지 아무도 기억하지 못합니다.
문제는 도구가 아닙니다. 무엇을 측정할지에 대한 사고, 혹은 그 사고의 부재입니다.
Metric Hierarchy 문제
Amazon에는 유명한 원칙이 있습니다. 모든 팀은 자신이 책임지는 단 하나의 "input metric"을 가진다는 것입니다. 차트 40개짜리 대시보드가 아니라, 그 숫자가 움직이면 팀이 이기고 있다는 뜻이 되는 단 하나의 수치입니다. 나머지는 모두 보조 지표이거나 guardrail입니다.
대부분의 제품팀은 정반대로 행동합니다. 추적하기 쉬우니 전부 추적합니다. Mixpanel의 2024년 설문에 따르면 평균적인 제품팀은 대시보드 전반에서 47개의 지표를 추적하지만, 그중 비즈니스 의미를 설명할 수 있는 것은 8개뿐이었습니다. noise-to-signal 비율이 6:1인 셈입니다.
결과는 의사결정 마비입니다. 대시보드에 12개 지표가 있고, 3개는 올라가고, 4개는 내려가고, 5개는 그대로라면 무엇을 해야 할까요? 대개는 아무것도 하지 않습니다. 다음 sprint review까지 기다리며 그림이 좀 더 명확해지길 바랄 뿐입니다. Netflix의 전 VP of Product였던 Gibson Biddle은 "metric that matters" 개념을 여러 차례 설명했습니다. North Star가 팀의 일상적인 의사결정과 어떻게 연결되는지 설명할 수 없다면, 당신의 측정 체계는 장식에 가깝습니다.
또 하나의 함정은 vanity metric입니다. 전체 가입자 수, 페이지뷰, 정의되지 않은 "engagement" 같은 숫자들입니다. 이런 수치는 대시보드에서는 그럴듯하지만 retention이나 revenue와 연결되지 않습니다. 제품 세계의 "코드 라인 수" 같은 지표입니다.
이 프롬프트가 돕는 방식
이 프롬프트는 가장 먼저 와야 할 질문, 즉 "당신 제품의 North Star metric은 무엇이고 왜 그런가"에서 출발해 대시보드를 처음부터 설계합니다. North Star에서 primary metrics(직접 영향을 주는 3-4개 지표), secondary metrics(선행 지표), guardrail metrics(최적화하면서 망가뜨리면 안 되는 것)로 내려가는 hierarchy를 만듭니다.
각 지표마다 데이터 소스, 측정 주기, alert threshold, owner까지 지정합니다. 이것은 추상적인 프레임워크가 아니라, 월요일 아침 데이터 엔지니어링 팀에 바로 건넬 수 있는 실행 청사진입니다.
언제 사용할까
- 새 제품이나 기능의 지표 체계를 처음 만들면서 hierarchy를 처음부터 제대로 잡고 싶을 때
- 기존 대시보드가 지나치게 커져서 정말 중요한 것만 남기고 가지치기해야 할 때
- 이사회 미팅이나 투자자 업데이트를 준비하며 metric framework를 설명해야 할 때
- product-market fit에 도달해 discovery metric에서 growth metric으로 중심을 옮겨야 할 때
- 새 PM이 합류해서 무엇을 왜 봐야 하는지 빠르게 온보딩해야 할 때
좋은 결과물의 모습
강한 output은 모든 지표가 인과관계 사슬을 따라 North Star로 연결되는 명확한 hierarchy를 보여줍니다. 그리고 "so what?" 주석이 붙어 있어야 합니다. 단순히 "7-day retention을 추적한다"가 아니라, "현재 코호트 규모 기준으로 5% 개선이 연 매출 X와 연결되므로 7-day retention이 주요 성장 레버다"처럼 설명해야 합니다. 또한 모니터링 계획에는 누가 어떤 지표를 얼마나 자주 보고, threshold를 넘기면 어떤 액션을 취하는지가 분명히 적혀 있어야 합니다.
참고 자료
- The Metric That Matters — Gibson Biddle
- 2024 Product Analytics Benchmark Report — Mixpanel
- Working Backwards: Insights from Inside Amazon — Colin Bryar & Bill Carr
Sources
- The Metric That Matters — Gibson Biddle
- 2024 Product Analytics Benchmark Report — Mixpanel
- Working Backwards: Insights from Inside Amazon — Colin Bryar & Bill Carr
Prompt details
Ready to try the prompt?
Open the live prompt detail page for the full workflow.