PRD에 사용자가 없잖아요
주니어 PM 성장기 #14
PM으로 일한 지 만으로 3년 반을 바라보고 있을 때, C레벨에게 들은 말이다.
"우리 회사 PRD에는 사용자 관점이 부족해서 아쉬워요."
처음에는 좀 억울하다고 생각했다.
그러나, 회사에서 고인물이라는 소리를 종종 들었기에 마음을 고치고 과거에 작성했던 PRD를 다시 꺼내봤다.
피드백을 주신 분의 말이 맞았다.
입사 초기에 작성했던 PRD부터, 최근에 작성한 PRD까지 공통된 문제점이 보였다.
기능 명세가 상세해질수록 PRD에 사용자는 사라지고 '기능' 중심의 문서가 되어있었다.
최근 PRD를 사용자 관점으로 작성하는 방법을 고민하고 시도해 보며 몇 가지 원칙을 정리했다.
덕분에 완벽하지 않더라도 이전보다는 확실히 사용자 중심의 PRD를 작성할 수 있게 되었다.
1. 모든 PRD는 명확한 타깃으로부터 시작해야 한다.
프로덕트는 사용자의 문제를 제대로 해결해 주었을 때 높은 임팩트를 가져올 수 있다.
사용자의 문제를 제대로 해결해 주기 위해서는 '누구'의 문제를 해결해야 하는지부터 명확하게 정해야 한다.
예를 들어, '알림 기능'을 만든다고 하자.
알림은 앱의 보편적인 기능이기 때문에 '모든 사용자'를 타깃으로 잡는 실수를 범하기 쉽다.
모든 사용자를 대상으로 한다는 것은 아무도 타깃 하지 않는다는 것과 같은 말일 수 있다.
타깃은 아래처럼 사용자의 특성, 연령대, 심리적인 환경 등을 활용하여 명시해야 한다.
'하루에 3번 이상 앱을 사용하는 20~30대 직장인 중 업무 관련 정보를 놓치는 것을 걱정하는 사용자'
타깃이 구체적일수록 PRD의 모든 내용이 일관성을 가지게 된다.
화면 설계부터 예외 상황까지, 의사결정의 기준을 '우리가 정의한 타깃은 어떨까?'로 잡을 수 있기 때문이다.
2. 기능 명세는 줄이고, 유저 스토리를 사용자 중심적으로 작성해야 한다.
기존에도 PRD에 유저 스토리를 작성했었다.
그러나, 이전에 작성한 유저 스토리는 그 목적을 잊고 작성했다.
'유저가 A 버튼을 클릭하면, B가 실행된다'와 같이 기능 중심적으로만 작성했기 때문이다.
이런 방식에는 치명적인 한계가 있다.
기능 중심적인 유저 스토리는 '무엇을 만드는지'만 설명하고, '왜 만들어야 하는지'를 설명하지 못한다.
개발자가 '이 기능이 정말 필요한가요?'라고 질문하게 되고, 개발 리소스를 줄이기 위해 스펙을 조정할 때도 기준이 모호해진다.
더 나아가, 기능을 배포하더라도 사용자들이 예상과 다르게 반응하는 경우도 많아진다.
유저 스토리를 작성하는 목적은 사용자의 '동기'를 명확히 하는 것이다.
유저 스토리는 'As a (사용자), I want (원하는 것), So that (이유)'의 형태로 작성한다.
가장 중요한 부분은 'So that' 뒤에 오는 '이유'다.
이 부분이 명확해야만 기능의 우선순위, 구현 방식 등을 일관성 있게 결정할 수 있다.
예를 들어, 알림 기능의 유저 스토리를 작성할 때,
'사용자는 보아야 할 글의 알림을 확인할 수 있다.'가 아니라.
'(As a) 업무 관련 정보를 놓치는 것을 걱정하는 20-30대 직장인은, (I want) 본인에게 필요한 중요한 정보만 골라서 알림을 받고 싶다. (So that) 업무에 집중하면서도 필요한 정보는 놓치지 않을 수 있다.'로 작성해야 한다.
유저 스토리는 팀 전체가 같은 목표를 바라보게 하는 나침반 역할을 하기도 한다.
만약, 개발 과정에서 "알림 설정 옵션을 어떻게 구성할까요?"라는 질문이 생겼을 때,
유저 스토리에 따라 "사용자가 업무에 집중할 수 있도록 중요한 정보를 선택할 수 있는 옵션을 제공하자"는 명확한 기준을 제시할 수 있다.
3. 비즈니스 임팩트를 반드시 작성해야 한다.
사용자 관점에만 집중하다 보면, 정작 비즈니스 임팩트를 작성하는 것을 잊는 경우가 있다.
PRD는 궁극적으로는 비즈니스 목표를 달성하기 위한 문서다.
사용자의 문제를 해결하는 것도 결국 비즈니스 가치를 창출하기 위함이다.
따라서, 사용자 중심으로 PRD를 작성하더라도 비즈니스 임팩트는 반드시 포함되어야 한다.
사용자 관점을 놓치지 않으면서도 비즈니스 임팩트를 작성하기 위해서는 사용자가 느끼는 가치를 고려해야 한다.
단순히 '매출 증가', '사용자 증가' 등의 상위 목표로는 부족하다.
예를 들어, 알림 기능의 비즈니스 임팩트는 아래와 같이 작성해야 한다.
사용자는 중요한 업무 정보를 놓치지 않고 받을 수 있다.
> 알림 오픈율 15% 증가
> 일 평균 앱 실행 횟수 2.3회 증가
사용자는 업무에 집중하면서도 필요한 알림을 받을 수 있다.
> 알림 설정 사용률 40% 증가
> 사용자 이탈률 8% 감소
비즈니스 임팩트를 작성하면 사용자의 행동 하나하나가 비즈니스에 어떤 의미가 있는지 명확해진다.
동시에, 직관적인 숫자로 눈에 보이기 때문에 디자이너, 개발자 등 팀원들에게 확실한 동기부여 요인이 된다.
이런 식으로 PRD를 작성하다 보니 예상치 못한 깨달음이 있었다.
나는 생각보다 더 사용자에 대한 이해가 부족한 상태로 프로덕트를 만들고 있었다는 것이다.
'사용자가 정말 이것을 원하는 게 맞나?', '우리가 정의한 타깃이 비즈니스 임팩트로 이어질 만큼 유효한가?' 같은 질문들에 대답해야 하니까 자연스럽게 사용자를 더 깊이 들여다보게 되었다.
결국 PRD는 단순한 기능 명세서가 아니라 우리가 사용자를 얼마나 이해하고 있는지를 보여주는 거울 같은 존재였다.
그리고 그 거울을 더 선명하게 만드는 것이 바로 PM으로서 계속 성장할 수 있는 방법이라고 믿는다.
