사용자 페르소나

연구 기반 페르소나는 내부 가정이 아닌 실제 사용자 데이터를 필요로 합니다. 연구 입력 자료는 다음과 같습니다: 사용자 인터뷰 (통찰력 포화에 도달하기 위해 주요 페르소나당 최소 12~15회 세션 — 인터뷰는 그들의 업무, 목표, 불만, 현재 워크플로우를 탐색합니다); 지원 티켓 분석 (어떤 사용자 세그먼트가 어떤 유형의 티켓을 생성하는지 파악하면 설문조사보다 더 잘 문제점을 드러냅니다); 제품 사용 데이터 (기능 사용 패턴에 따른 행동 클러스터링은 제품 내에서 뚜렷한 사용자 원형을 식별합니다); 그리고 CRM의 고객 속성 데이터 (회사 규모, 산업, 직책 분포). Product Ops는 이러한 입력 자료를 2~4개의 주요 페르소나로 종합합니다 (4개 이상은 일반적으로 의사 결정을 더 어렵게 만드는 페르소나 확산을 의미합니다). 각 페르소나에는 다음이 포함됩니다: 설명적인 이름과 역할 ("Alex, Series B SaaS의 일선 지원 리더"), 주요 업무 목표, 현재 도구에 대한 주요 불만, "정보를 찾는 곳" (watering holes), 그리고 기술적 숙련도 수준.

페르소나는 Notion 문서에 존재함으로써가 아니라 의사 결정에 적극적으로 활용될 때 가치를 얻습니다. 효과적인 통합 관행: 사용자 스토리 연결 (모든 사용자 스토리는 자신이 대상으로 하는 페르소나를 명시적으로 언급합니다: "지원 리더 Alex로서, 저는 ...을 원합니다"); 디자인 검토 질문 (모든 디자인 비평에서: "Alex는 이것을 직관적이라고 생각할까? 그녀의 실제 워크플로우에서 이 시나리오를 만날까?"); 우선순위 대화 (질문: "이것은 누구를 위한 것인가 — Alex인가 Sam (IT Admin 페르소나)인가? 어떤 세그먼트가 더 높은 기회를 나타내는가?"); 상담원 교육 (페르소나 모델로 훈련된 지원 상담원은 고객의 역할 맥락을 이해하여 일반적인 제품 지원보다 더 공감적이고 맥락에 맞는 응답을 가능하게 합니다); GTM 메시징 개발 (마케팅 캠페인은 일반적인 ICP 설명보다는 특정 페르소나의 문제점과 "정보를 찾는 곳"에 맞춰집니다). Product Ops는 연간 페르소나 검토를 촉진합니다 — 제품이 발전하고 새로운 고객 세그먼트가 타겟팅됨에 따라 사용자 연구가 변경되므로, 페르소나가 조직의 신화로 굳어지지 않도록 보장합니다.

가장 흔한 페르소나 설계 실수 중 하나는 페르소나를 직책에 직접 매핑하는 것입니다 — "지원 담당 부사장" 대 "지원 상담원". 문제는 다음과 같습니다: 동일한 직책을 가진 두 사람 (둘 다 "지원 관리자")이라도 회사 규모, 단계 및 지원 철학에 따라 완전히 다른 업무, 목표 및 제품 요구 사항을 가질 수 있습니다. 반대로, "지원 리더"와 "고객 운영 책임자"는 동일한 목표와 요구 사항을 가질 수 있습니다. 페르소나는 조직도상의 직책이 아니라 목표와 업무를 중심으로 구축되어야 합니다. 테스트 질문: "다른 직책을 가졌지만 동일한 방식으로 일하고 생각하는 두 사람이 이 페르소나에서 자신을 알아볼 수 있을까?" 만약 그렇다면, 그 페르소나는 직책 기반이 아닌 역할 기반이며, 이는 더 견고합니다. Product Ops는 5~10명의 고객에게 페르소나 설명을 읽게 하고 "이것이 당신과 비슷하게 들리나요? 그렇지 않다면 무엇이 다른가요?"라고 물어 각 페르소나를 검증합니다 — 이 피드백을 사용하여 각 페르소나가 대표하는 사람들에게 즉시 인식될 때까지 다듬습니다.