[서비스 기획] 의사결정을 위한 한 판의 그림, PRD
한 장으로 대신하는 백마디의 말.
기획자를 따라다니며 괴롭히는 질문.
이 기능이 '꼭' 필요한가요?
야심차고 비장하게 상세 기획서를 리뷰한 후, 이런 근본적인 질문을 받는다면 당황할 수도 있다.
'설득에 실패했군.'
하지만 상대방도 리뷰를 듣는 내내 머릿속에서 의문이 떠나지 않았을 터.
상세 기획서가 나오기까지 수많은 컨펌 과정을 거쳤던 시간을 돌아보며 회의감에 빠지지 않도록
기획자를 구출해 줄 하나의 문서가 있다면 지금부터 소개할 PRD이다.
PRD
PRD(Product Requirement Document)는 프로덕트 요구사항 정의한 문서.
간단하게 말하하면 사용자의 "어떤" 문제를 "어떻게" 해결할지 가이드를 제공하는 문서 양식이다.
PRD는 아래의 목차를 기본 골격으로 한다. (아주 상세한 목차로 구성된 PRD들도 있지만)
배경
문제정의
가설과 목표
요구사항
PRD가 상세 기획서와 다른 점은 '어떻게' 구현할지에 대한 문서가 아닌
'왜' 구현해야 하는가를 작성하는 문서라는 것이다.
한 문장으로 비교하면 다음과 같다.
상세 기획 : A 영역의 a 기능을 이렇게 변경하겠습니다.
PRD : ~한 배경으로 사용자의 진짜 문제는 A이고 가설에 따라 a로 해결하겠습니다.
PRD가 주목 받기 시작한 건 애자일한 환경에서 빠른 의사결정에 도움이 되기 때문이라고 한다.
그러나 내가 생각하는 PRD의 가장 큰 장점은
무엇보다 PM 스스로 '진짜' 문제를 찾아내고 더 뾰족하게 해결책을 다듬는데 기여하는
생각의 툴이자 방법론이기 때문이다.
그렇다면 어떻게 작성해야 PRD로 진짜 문제를 찾아낼 수 있을까?
PRD를 작성할 땐
첫째, 사용자 관점에서 작성한다.
회사에 돈을 벌어다주는 존재는 결국 고객! 하지만 우린 때때로(아니, 대체로) 조직 내 의사결정자의 취향에 따라 프로젝트를 기획할 때가 있다. 그러나 의사결정자가 원하는 목표도 결국 그 본질은 사용자의 만족이다. 최대한 사용자에 의한, 사용자를 위한 관점에서 작성하도록 노력한다.
둘째, 하나의 방향을 가리키도록 '논리적으로' 작성한다.
배경부터 요구사항까지 각 항목은 한 판의 논리 퍼즐이어야 한다. 그림을 완성하기 위해 퍼즐은 꼭 필요한 조각들로만 구성된다. 남는 퍼즐이 있으면 헷갈리니까. 나의 생각을 하나의 방향으로만 갈 수 있게 논리적으로 담자. 쓰고 싶은 내용, 쓸 수 있는 내용이 더 있더라도 논리적으로 도움이 되지 않는다면 과감하게 덜어내야 한다.
셋째, 최대한 쉬운 문장으로 이해하기 쉽게 작성한다.
어렵게 작성된 문서는 내용을 이해하기 위해 더 많은 시간과 집중력을 할애해야 하고 그때마다 떠오르는 물음표들은 의사결정을 지연시킨다. 누가 언제 봐도 쉽게 이해할 수 있는 문장으로 작성하여 의사결정의 속도를 높이자.
1. '배경'을 작성할 땐
배경에는 문제 정의를 위한 모든 내용을 담는다. 정의하는 '문제'가 답이라면 배경은 그 답을 도출하기 위한 해설집이라고 생각해보자. 해설집을 봐도 그 문제의 정답을 찾아낼 수 없다면 문제를 이해하지 못한 학생은 영원히 그 답을 도출할 수 없다.
그러나 위에서 언급한 것처럼 불필요한 내용까지 담아야 한다는 것은 아니다. 방향이 다른 자료들은 가지치기 한 후, 문제 진단에 결정적 단서가 되는 내용들로만 작성한다.
2. '문제 정의'를 작성할 땐
문제를 정의할 때 가장 주의할 것은 "사용자"에게 진짜 문제가 무엇인지 고민해보는 것이다. 예를 들어, 로딩 시간이 오래 걸리는 문제가 있다. 'API 과부하로 로딩시간이 길다.' 라고 문제를 작성하기 보다 '사용자가 오래 기다려야 한다.'라고 작성해보자. 사소한 차이처럼 보이지만 '사용자 관점'에서 작성된 문구만으로도 사용자가 겪는 불편에 집중하여 문제를 바라볼 수 있다.
전설처럼 내려오는 '오티스사' 사례를 잠시 살펴보자. 1853년, 고층 빌딩 열풍속에서 안전한 엘리베이터를 개발했던 오티스사. 그러나 속도가 빠르지 않아 고객들의 불만이 많았다. 오티스사가 문제를 '속도가 느린 엘레베이터'라고 정의했다면 더 빠른 속도의 엘리베이터를 개발하는 것에만 집중했을 것이다. 그러나 한 직원의 아이디어로 오티스사는 엘리베이터에 거울을 부착하게 된다. 속도가 느린 엘리베이터에 탔을 때 사용자가 겪는 불편은 '지루함'이었기 때문이다. 진짜 고객이 겪는 문제인 '지루함'을 거울을 통해 효율적으로 해결한 사례다.
고객의 관점에서 '진짜 문제'를 찾는 것은 이처럼 더 효율적인 해결방법을 찾아낼 수 있는 지름길이다. 그렇기 때문에 문제 정의를 작성하면서 해결방법부터 고려한 정의를 해서는 안된다. 문제 자체만을 바라보자.
3. '가설과 목표'를 작성할 땐
가설을 작성할 땐 앞서 작성한 '진짜 문제' 해결에 잘 동작할 수 있는지 집중하여 작성해야 한다. 그렇게 세운 가설에 대한 목표는 가설과 1대 1로 대응되도록 작성하되, 다른 요인에 의해 왜곡되지 않는 지표를 찾는 것이 중요하다. 오직 이번 프로젝트만의 영향 또는 성과라고 볼 수 있는 객관적 지표로 작성해보자.
4. '요구사항'을 작성할 땐
요구사항은 문제 해결을 위해 가장 우선순위가 높은 것부터 순차적으로 나열하여 작성해보자. 그리고 문제해결에 꼭 필요한 요구사항을 MVP로 설정해보자.
배경, 문제정의, 가설과 목표, 요구사항까지.
각 항목을 작성할 때 어떤 것에 집중할 것인가에 대해 고민하다 보면
PRD의 기본적인 골격을 작성해보는 것만으로도
'이 기능이 꼭 필요한가요?'에 대한 답을 논리적인 흐름으로 구성해 볼 수 있다.
'홈 전시 콘텐츠 클릭 수의 하락'이라는 이슈에 대해 작성된 2개의 PRD를 비교해보자.
A와 B는 같은 이슈에 대해 서로 문제를 다르게 정의하면서 다른 해결 방법이 도출됐다.
어떤 차이가 있었을까?
A의 PRD
우선 A의 PRD는 잘 작성된 문서가 아니다.
배경 : 정의한 문제, '홈 전시 콘텐츠가 고객에게 매력적이지 않다.'까지 도달하며 A가 생각한 논리적 흐름 배경에서 충분하게 설명되지 않았다.
문제 정의 : 배경에서 충분하게 설명되지 못했기 때문에 A가 정의한 문제는 주관적인 해석으로만 보인다. 또한 구체적으로 어느 부분이 매력적이지 않다고 생각했는지에 대해서도 알기 어렵다. 매력적이지 않게 보이게 하는 이유가 배치의 문제인지, 레이아웃의 문제인지, 콘텐츠 큐레이션의 문제인지 등.
가설과 목표 : 정의한 문제를 해결하는데 기여할 수 있는 가설로 보이지 않는다. 또한 목표에 대해 '클릭 수 증가'라고 설정했는데, 클릭 수는 방문자 수의 영향을 받기 때문에 클릭율로 보는 것이 더 합리적이다. 하지만 클릭수든 클릭율이든 다른 요인에 의해 영향 받을 수 있는 지표이기 때문에 클릭수가 늘어났다고 해서 해당 작업의 성과라고 볼 수 있는 객관적 지표가 아니다.
A의 문서가 엉망진창으로 작성된 이유를 상상해보면, 아마도 '경쟁사 대비 전시영역 수가 적은 것 같은데, 우리도 몇 개 더 추가하지?'라고 지시 받아 평소처럼 깊은 고민 없이 작성한 문서일 가능성이 높다.
B의 PRD
B의 PRD는 A의 PRD 보다는 논리적으로 작성된 문서이다.
배경 : 다양한 관점에서 지표들을 찾아보았고 문제정의에 필요한 요소들을 포함하였다.
문제 정의 : 고객의 관점으로 작성하였고 '진짜 문제'일지에 대해서는 고민이 더 필요하겠지만 적어도 주관적 해석으로 느껴지지는않는다.
가설과 목표 : A의 목표보다는 좀 더 다른 요인에 의해 영향받지 않을 수 있는 지표를 찾고자 노력한 것으로 보인다.
결과적으로 A와 B는 같은 이슈로 시작하여 서로 다른 프로젝트로 문제를 해결할 것이고 '이 기능이 꼭 필요한가요?'라는 질문에 더 잘 방어하며 논리적으로 설명할 수 있는 사람은 B일 것이다.
겨우 한 페이지가 채 되지 않는 문서지만, 4가지 질문을 통해 '진짜 문제'를 고민해 본 기획자는 그 결과도 태도도 달라질 수 있다.
오늘부터 노트 한 페이지를 열어 30분만이라도 작성해보면 어떨까?
