by
Jan 31. 2021
[웹 기획] 제품 요구 조건 문서(PRD) 구성 요소
제품 요구 조건 문서 도입 배경
서비스 기획 시 가장 먼저 하는 일은 요구사항 정의서 작성이었다.
하지만 기존에 작성한 요구사항 정의서는 아래와 같은 문제점이 있었다.
고객 수가 증가함에 따라 고객의 요구 사항이 다양해짐
문제에 대한 배경 설명이 부족함
솔루션에만 집중함 (Why가 부족함)
그러던 중 우연히 PRD(Product Requirements Document)를 알게 되었고 글쓴이가 마침 구글에서 근무하는 PM이어서 PRD에 관심이 생겼다. 원문 포스팅은 링크를 통해 확인할 수 있다.
PRD(Product Requirements Document) 구성 요소
원문에 따르면 아래와 같은 내용이 포함되어야 한다고 한다. 각 요소에 대한 나의 경험과 생각을 추가하였다.
1. 요약 및 배경: 문제가 무엇이며, 왜 중요한가? 기획의 중요성을 강조하기 위해 사업 지표나 인터뷰 내용 또는 기타 인사이트 자료를 함께 추가한다.
중요한 문제를 찾기 위해서는 인터뷰 자료를 많이 축적하는 것이 유리하다. 고객의 입에서 반복적으로 나온 이야기가 가장 먼저 해결해야 중요한 문제점인 경우가 많다.
그렇기 때문에 요구사항 정의서에 정리한 인터뷰 내용을 수시로 체크하고 업데이트해야 할 필요가 있다.
여기서 업데이트란 기록한 내용 중에 어떤 문제점이 가장 많이 나왔으며, 그 문제점과 연관된 문제점이 무엇인지 찾아야 한다. 단순히 기록만 한다고 해서는 문제점을 찾을 수 없다.
인터뷰를 시트에 정리하면 보기도 편하고 정리하기도 좋다.2. 대상 사용자 : 제품이 필요한 사용자가 누구인지? 해당 사용자가 중요한 이유는 무엇인가?
사용자를 정의한 후 문제점을 정의하는 것이 더 자연스러워 보이지만 포스팅 원문 순서대로 정리하겠다.
사업 초기에는 대상 사용자를 한 덩어리로 정의한다. 하지만 사용자가 서비스를 이용하는 순간부터는 사용자를 세분화할 수 있다고 생각한다.
질링스를 예를 들어 설명하겠다. 질링스의 고객은 1)스타트업, 2)스타트업을 지원하는 창업지원기관으로 정의한다.
창업지원기관도 여러 개로 구분할 수 있다. 서비스 출시 전에는 정부에서 운영하는 공공기관과 민간에서 운영하는 민관기관으로 구분하였고 서비스 소개 후 반응을 기록했다.
그리고 서비스를 출시한 후 사무 공간 지원을 하는 창업지원기관과 단순히 사업비만 지원하는 창업지원기관에 따라 요구사항이 달랐다. 그리고 지금은 관리하는 기업 수에 따라 사용자의 니즈가 다르다는 걸 발견할 수 있었다.
그동안 고객 인터뷰(사용자 피드백)을 분석한 자료3. 핵심 고객 여정(Critical User Journeys, CUJ) : 문제를 해결 한 후 사용자는 어떻게 서비스를 사용할 수 있는가? 특정 솔루션(기능)이 아닌 고객의 요구에 집중한다.
기존에 작성한 문서에서 가장 부족했던 점이 바로 이것이다. 이전에는 특정 기능에 대한 설명만 자세히 적어두었다.
특정 솔루션에만 집중할 경우 아래와 같은 문제가 발생할 수 있다.
더 좋은 (새로운)솔루션에 대한 아이디어를 같이 고민할 수 있음에도 불구하고 원천적으로 이를 차단하는 부작용이 발생
실제 문제와 상관없는 기능으로 정리될 수 있는데 문제점에 대한 내용 없이 특정 솔루션에 대한 정리만 이루어질 경우 이를 예방할 수 없다.
