*서비스 기획 및 제품을 운영하면서 겪었던 일에 대한 이야기입니다.
Index
- 서론
- 그래도 정성적 데이터는 있잖아?
- 정성적 데이터의 정량화
서론
서비스 기획, PM, PO의 중요한 역량 중 하나로 데이터 기반 문제를 발견하고 지표를 개선하는 능력이 요구됩니다. 하지만 제품에 대한 데이터를 수집하는 일은 여간 쉬운 일이 아닙니다. 물론 데이터 인프라가 잘 구축된 곳이라면 그리 어렵지 않겠지만, 그렇지 않은 곳에서는 어려움이 많습니다.
저는 주로 데이터 인프라가 잘 구축되지 않은 환경에서 일을 해왔습니다. 그렇다고 환경 탓만 할 수는 없는 법입니다. 제품에 대한 오너십이 주어졌고, 스프린트는 계속 돌아가고 있었으니까요.
처음 떠올린 방법은 데이터를 수집할 수 있는 환경을 구성하는 것이었습니다. 하지만 저희는 B2B 구축형으로 솔루션을 납품하고 있었고, 이는 거의 불가능에 가까웠습니다. 주 고객들은 보안을 매우 중요시 여겼고, 폐쇄망에서 제품을 사용하길 원했습니다. 즉, 외부 기업에서 데이터를 수집하는 것을 좋아하지 않았습니다.
이러한 상황에서 정량적 데이터가 없는 회사에서 문제점을 발견하고 어떻게 개선했는지에 대해 회고해 보려고 합니다.
그래도 정성적 데이터는 구할 수 있잖아?
우선, 기존의 정성적 데이터를 최대한 활용했습니다. VOC 데이터 수집, 프로젝트 RFP 분석, 고객 인터뷰, 설문조사, 내부 직원들의 피드백 등을 통해 문제점을 파악했습니다. 이와 함께, 내부적으로는 유사한 문제를 경험한 사례를 분석하여 인사이트를 얻었습니다.
다음으로, 가능한 작은 범위 내에서라도 정량적 데이터를 수집할 수 있는 방법을 모색했습니다. 예를 들어, 로그 데이터를 활용하거나, 제품 사용 빈도를 추적하는 간단한 도구를 도입했습니다. 이 과정에서 고객의 보안 요구사항을 충족시키면서도 데이터를 수집할 수 있는 방법을 찾아냈습니다.
- VOC 데이터 수집
- 프로젝트 RFP
- 설문조사
- 고객 인터뷰
- 내부 직원들의 피드백
VOC 데이터가 가장 구하기 쉬웠고, 다음으론 프로젝트 RFP(요구사항 정의서)였습니다.
고객과의 인터뷰는 회사의 동의가 필요하고 고객도 응해야 했으므로 구하기 어려운 데이터였습니다.
정성적 데이터의 정량화.
앞서 말한 것처럼, 가장 쉽게 접할 수 있는 정성적 데이터는 VOC(Voice of Customer) 수집이었습니다. 대부분의 VOC는 제품 이름, 제품 버전, 디바이스 환경, OS 환경, 이슈, 원하는 결과 등의 카테고리로 구성되어 있어 이를 기반으로 맥락을 파악할 수 있었습니다.
그 다음으로 구하기 쉬웠던 데이터는 프로젝트 RFP(Request for Proposal)였습니다. RFP는 주로 단순 기능 위주로 작성되기 때문에, 해당 프로젝트 담당 PM과의 인터뷰를 통해 요구사항의 맥락과 해결 방법을 파악하는 것이 필요했습니다. 담당자가 부재한 프로젝트의 경우, 최종 결과물을 분석하여 역으로 히스토리를 추적했습니다.
가장 구하기 어려운 정성적 데이터는 고객과의 인터뷰였습니다. 이는 고객이 시간을 내어줘야 하고, 회사 내부적으로도 지원을 받아야 가능한 일이었습니다.
이렇게 수집한 데이터는 주관을 최대한 배제하고 현상을 객관적으로 파악해 원인을 찾는 것이 중요했습니다. 이는 고객이 문제라고 생각한 것과 실제 원인이 다를 수 있기 때문입니다. 즉, 맥락 파악이 중요한 것입니다.
예시를 들어보겠습니다. 저는 콘텐츠 저작 툴을 운영하는 PO 였습니다.
저희 제품이 고도화되고 무거워지면서 점점 생산성이 떨어진다는 피드백을 받은 적이 있었습니다.
생산성 저하 요인으론 원하는 기능 부족, 정보 가독성 저하, 반복 작업, 데이터 로드 속도, 리소스 확보 등이 있었습니다.
너무 추상적인 개념이라 아래와 같은 정량화 과정이 필요하였습니다.
1. 정성적 데이터 정의:
- 스크롤 길이가 얼마나 길어야 정보 가독성이 저하되는지?
- 같은 행위를 몇 번 반복해야 피로감을 느끼는지?
- 데이터 로드 속도가 느리다는 것은 몇초 기준인지?
- 3D 리소스 확보에 얼마나 많은 협업이 절차가 일어나는지?
2. 정량화 과정(인터뷰, 논문, 내부 실험 기준)
- 정보 3개가 전체 화면 스크롤 70% 이상이 넘어가면 피로함을 느낀다.(정보 개수는 도메인 특성마다 다릅니다.)
- 같은 행위를 2.5 이상 반복하면 피로감을 느낀다.
- 데이터 로드 속도가 3초 이상 걸리면 느리다고 표현한다.
- 3D 리소스 확보에 1인 이상 협업 필요할 시 어렵게 느껴지며, 2번 이상의 수정 과정이 일어날 시 피로감을 느낀다.
3. 개선 목표 및 방법:
- 정보 구조, 플로우를 개선하여 데이터 로드 속도를 3초 이내로 제공한다.
- 정보 구조 및 화면 UI 를 개선하여 전체 화면 스크롤 70% 안에 정보 3개를 표현하도록 한다.
- 2.5번 이상 일어나는 반복 행위는 템플릿화 시켜 제공한다.
- 기본 에셋과 확장자를 늘려 리소스 공수에 들어가는 협업 포인트를 줄인다.
3. 개선 결과:
- 데이터 로딩 시간 10초에서 1초로 개선
- 한 태스크 안에서의 화면 전환 횟수 50% 감소
- 스크롤 길이 80% 줄어들어 정보 가시성 향상
이와 같은 과정을 통해 정성적 데이터를 정량화하고, 이를 바탕으로 문제를 해결해 나갔습니다. 이러한 접근 방식을 통해 데이터가 부족한 환경에서도 유의미한 개선을 이루어낼 수 있었습니다.
'Talk about > My work story' 카테고리의 다른 글
프로젝트 시연 준비도 기획이다. (0) | 2024.08.08 |
---|---|
긍정적인 말이 주는 선한 영향력 (0) | 2024.08.04 |
반찬가게에서 만난 UX (0) | 2021.12.21 |
댓글