[용어정리] PRD 작성 방법

애자일(Agile)한 방법으로 제품을 개발하기 위해 Product Requirement Document, PRD(제품 요구사항 문서)를 활용한다.

PRD는 만들고자 하는 제품의 기능이 고객의 어떤 문제를 해결하는지를 정리한 문서다.

기업은 PRD를 통해 고객이 제품을 통해 얻는 경험과 이로움이 무엇인지 총체적으로 확인할 수 있다. 즉, PRD는 제품 개발의 시작점!

 

💡 PRD 작성 전 고민해야 하는 지점

1. 우리가 만들고자 하는 것은 무엇인가?
2. 왜 이 제품을 만들어야 하는가?
3. 제품 개발을 통해 달성하고자 하는 목표는 무엇인가?
4. 목표 달성을 위한 검증 지표는 무엇인가?

 

💡 PRD 작성 법

 ' 작성법은 기업이나 PM 재량에 따라 상이할 수 있다 '

 

 

1. 개요

  제품을 개발해야 하는 근거를 제시하기 위해 작성한다. 우리가 만들 제품이 어떤 문제를 해결하기 위한 것인지, 우리의 제품이 나오게 된 배경은 무엇인지, 문제를 가지고 있는 사용자는 누구인지, 그러한 사용자가 우리의 제품을 어떻게 사용할 수 있을 것인지, 우리의 제품을 사용하면서 사용자가 가지게 될 가치는 무엇인지, 제품을 만드는 과정에서 원칙은 무엇인지를 기재한다.

 

가. 문제 정의 

  문제는 어렵게 적기보다는 이해관계자 모두가 공감할 수 있도록 적는 것이 좋다. 또한 뒤에 이어서 작성하게 될 목적 및 배경, 주요 사용자와 이어지는 내용이어야 한다. 결국 문제는 우리의 제품을 사용하게 될 사용자의 니즈를 말하는 것이고, 그 사용자의 니즈를 해결하는 것이 제품을 만드는 목적 및 배경이기 때문이다. 즉, 뒤에 나올 내용과 방향성이 같아야 함.

 

나. 목적 및 배경(왜 이 제품이 필요한가요?)  

   문제가 발생하는 사회적인 배경 혹은 우리 제품의 기획 목적 및 배경을 설명해도 괜찮다. 해당 부분은 우리가 만들고자 하는 제품이 왜 만들어져야 하는지를 설득하는 영역

 

다. 주요 사용자(Target User)  

  문제를 겪고 있는 대상이 누구인지를 기재해보자. 앞서 기재한 문제를 겪고 있는 대상이 바로 주요 사용자가 될 것이다. 주요 사용자를 작성할 때는 단순하게 사용자의 형태만 표현하기보다는 어떤 어려움을 겪고 있는 사용자인지를 함께 표현해주는 것이 좋다.

주요 사용자는 여러 유형이 될 수 있다. (e.g. 호스트, 게스트)

유저 페르소나를 구체적으로 설정하는 것도 이해와 공감에 도움이 될 듯.

 

라. User Story / User JourneyMap(고객은 어떠한 행동을 보여줄까요?)  

  User Story는 주요 사용자가 문제를 해결하기 위해 행동하는 상황을 묘사한다. 문제를 겪던 시점부터, 우리의 제품을 인식하게 되거나, 우리의 제품을 어떠한 방법으로 사용함으로써 문제를 해결하게 되는지 일련의 스토리를 그려보는 것이다.

 User Story와 User JourneyMap의 모습은 조금 다를 수 있다. User Story는 어떤 상황에 놓인 유저가 무엇을, 왜 원하는지를 기재한다. 간단하게 표현하자면 ‘As Who, I Want What, so that’이 된다. 가령 ‘As a Product Manager, I Want Write a Product Spec, so that I can make the product’의 형태로 기재하는 것이다. 이를 통해서 Story마다 무엇을 만들어야 할지 생각해볼 수 있다.

반면, User JourneyMap 은 말 그대로 이를 사용여정(타임라인) 순으로 나열한 것. (인식 – 탐색 – 비교 – 사용 – 구매 의 일련과정)

 

마. 사용자 가치(고객을 위해 어떤 일을 하는 걸까요?)  

  사용자 가치는 사용자가 우리의 제품을 통해서 문제를 해결할 수 있는지, 우리의 제품으로 무엇을 할 수 있을지, 우리의 제품을 통해서 어떤 가치를 느낄 수 있는지를 명시한다. 여기서 사용자 가치는 앞서 명시한 문제, 목적 및 배경과 관련이 있는 것이어야 한다.

(e.g. 캐치테이블 유저는 빈자리 예약알람 기능을 통해 예약에 실패한 식당의 예약권을 획득할 수 있는 기회를 얻을 수 있다.)

단, 앞서 설정한 배경/목적 과 동떨어진 가치일 경우에는 확장성의 측면으로 분리하여 부가적인 목표, 또는 지표와 함께 표현하자. 

 

바. 개발 원칙

  개발 원칙은 의사결정이나 개발 가이드가 될 수 있는 원칙을 제시하는 것을 의미한다. 이는 만약 PM이나 기획자가 부재하는 상황에서 개발의 우선순위를 개발자가 스스로 선택할 수 있도록 하기 위함이다. 또한 커뮤니케이션이 잘 이루어지지 않는 경우의 경우 가장 핵심적으로 구현해야 하는 기능에 리소스를 투입할 수 있도록 유도할 수 있다.

개발 원칙은 제일 중요할수록 상단 또는 1번에 배치하고 중요도에 따라 내림차순으로 기재하는 것이 좋다.

(e.g 000 기능 구현을 최우선으로 진행합니다. 000 정보를 제공하기 위해 업체 정보 db 구축을 해야 하며, 이 과정은 운영과정에서 담당자가 수기로 작성합니다.)

 

 

2. 기회 및 임팩트

  현재 시장에 어떤 기회가 있는지, 어떤 제품이 트렌드가 되고 있는지, 주요 통계자료나 데이터는 어떠한지와 같은 것들을 토대로 작성한다. 여기서 우리 제품을 통해 사용자가 어떤 행동을 하게 될지를 기재하고, 그 행동을 통해서 어떤 임팩트가 세상에 나올 수 있을지를 표현하게 된다.  > 데스크 리서치 사이트 (오픈서베이, 삼성글로벌리서치, LG 경영연구원 등)

 

가. 기회  

  기회는 우리가 만들 제품의 제반 환경을 의미한다. 시장 환경이 될 수도 있고, 사회적 분위기가 될 수 있고, 기술의 발전이나 정부의 정책이 기회가 될 수도 있다. 보통 많이 쓰이는 방식으로 시장 환경 분석의 일환인 SWOT 분석이나 STP와 같은 방식으로 기재하기도 하나, 최근의 트렌드나 정부 정책, 사회적인 분위기 등을 간단하게 기재할 수도 있다.
* 판단 혹은 사회적 현상 작성 후 관련 통계 데이터 첨부는 설득력 강화에 필수적이라고 볼 수 있다.

 

나. 가설 및 가설 검증 지표  

  시장에서 우리의 제품이 고객의 문제를 명확하게 해결할 수 있는 것인지, 우리의 제품으로 수익을 창출할 수 있을 것인지는 제품을 출시하고 고객이 직접 사용해보기 전까지는 검증하기 어려운 부분이기 때문에 이렇게 가설을 수립함으로써 빠르게 검증하고, 해결방안을 모색 해야 한다. 만약 우리의 가설이 검증 지표의 통과 기준에 적합하지 못해서 실패한 가설이라는 판단이 들면 재빠르게 다음 행동을 정해야 한다. 사용자가 겪고 있는 문제가 무엇이었는지 명확하게 다시 검증을 진행한다거나 제품의 디자인이나 기능을 개선 및 보완할 수도 있고, 어쩌면 제품이나 기능의 pivot 을 진행하는 결정이 필요할 수도 있다.

(e.g. 가설 - 배달 시간을 약 50%로 줄이기 위해 유저는 배달비가 20% 높아져도 배민원 서비스를 이용할 것이다.

         가설검증 지표 - 배민원 서비스를 이용하는 월 사용자가 0000 이상이 되면, 가설 검증에 성공한 것으로 판단합니다. )

 

다. 임팩트 예측

  임팩트 예측은 우리의 제품이 가져올 경제적, 사회적 가치를 의미한다. 또는 사용자가 우리의 제품을 통해서 얻게 될 가치를 의미하기도 한다.  경제적, 사회적 가치를 작성하는 경우, 둘을 구분해서 작성하는 것이 좋고 명확하게 수치로 제공하는 것이 효과적이다. 두 개를 모두 적을 필요는 없으나, 최근에는 사회적 가치나 ESG에 대한 관심이 높아지고 있으며 가치 소비의 형태로 제품을 구매하는 경우가 많아지고 있어 어떤 제품을 만들 때 사회적 가치를 고려하는 것이 좋다.

(e.g. 캐치테이블 빈자리 예약기능을 통해, 점주는 갑작스런 노쇼로 인한 매출 피해를 00% 감소시킬 수 있다.)

 

 

3. 제품 정의 및 요구사항

 제품 정의 및 요구사항은 제품의 구체적인 형태를 제시하고, 제품을 구성하기 위한 기능 및 기술 요건을 기재한다. 이를 토대로 개발 및 디자인팀과 논의를 통해 구현 가능한 요인들을 산출하며, 비즈니스팀과는 제품이 나아가야 할 방향 및 전략을 도출할 수 있다. 또한 이 과정에서 더 나은 제품이 나올 수도 있고, 더 나은 기술 방안이 제시될 수 있다.

PRD 문서에서는 요구사항을 간단하게 적고 넘어가는 것이 좋을 듯. 예를 들어, 호스트와 게스트는 구분하여 회원가입, 로그인 할 수 있어야 합니다. 등. 사실 제품 요구사항은 별도의 문서로 작성하여 관리하는 것을 많이 봄.

 

 

4. 마일스톤

  마일스톤은 제품을 만들어가기 위한 일정을 제시한다. 글로 제시하는 경우도 있지만, 일반적으로는 타임라인으로 볼 수 있도록 간트차트와 같은 것을 토대로 구성한다.

일정과 투입 담당자를 명시해야 함(기획자/개발자/디자이너 구분)

 

 

5. FAQ

  FAQ는 PRD를 토대로는 파악하기 어려운 사항이나 각 팀에서 제품에 대해 궁금하게 생각할 수 있는 부분을 사전에 미리 고민해서 작성하는 부분이다.

 

참고 블로그 링크