성공하는 PM들의 소통법, PRD를 알고 계신가요?

새로운 프로덕트를 만들거나, 기존의 프로덕트에 새로운 기능을 추가하는 프로젝트를 기획하려고 할때, 많은 PO/PM 분들은 '기획서'를 작성하실 거라고 생각합니다.

혹시 여러분이 작성하는 '기획서'는 어떤 모습인가요? 그리고 그 '기획서'는 제 역할을 다하고 있나요?

저희 팀 역시 새로운 프로덕트, 혹은 프로젝트를 시작할때 프로덕트를 직접 만들어나가는 디자이너, 개발자 분들과 소통하기 위하여 PPT 형식의 기획서를 작성했었습니다. 하지만 기획사항이 빼곡하게 적혀있는 100장이 넘어가는 기획서는 디자이너에게도, 개발자에게도, 그걸 작성하는 기획자에게도 효과적인 소통방식이 아니었습니다.

그래서 제가 프로덕트를 만들어나가는 팀의 다양한 구성원들과의 효율적인 소통에 대해 고민하고 있을 때, 저희 팀의 프로덕트 멘토님께서 추천해주신 양식이 바로 PRD 였습니다. 해외 PM들은 전부 PRD를 작성하고, 우리나라에서 쓰는 그런 100페이지가 넘는 기획서를 쓰는 나라는 한국과 일본뿐이라며 조언해주셨습니다.

PRD란 Product Requirements Documents로, 쉽게 말해 우리 팀에서 만들고자하는 프로덕트의 용도, 특징, 기능 및 동작을 포함하여 특정 제품의 요구사항을 정의하여 비즈니스 및 개발 팀원들이 제품의 제작, 출시를 위해 필요한 가이드를 정리한 문서라고 생각하시면 됩니다. 정의로만 봐서는 기존의 기획서와 뭐가 다른가, 싶으시겠지만 PRD의 가장 중요한 점은,

Nobody likes writing bloated, ultra-detailed product requirements documents.

아무도 비대하고 매우 상세한 제품 요구 사항 문서를 작성하는 것을 좋아하지 않습니다. 

Turns out nobody likes using them, either.

아무도 그것을 사용하는 것 역시 좋아하지 않는 것으로 밝혀졌습니다.

PRD의 핵심은 자세하고, 구체적인 기획서를 지양한다는 점입니다. PRD는 새로운 프로덕트의 목적과 방향성을 정의하는 문서로, 나침반이 되어 줄 뿐 구체적이고 장황한 설명서가 아닙니다.

화면을 구체적으로 정의하고, 모든 동작에 대한 엄격한 요구사항을 제한하는 것이 아닌, 우리 팀이 왜 이 프로덕트를 만들어야 하는지, 이 프로덕트를 사용할 유저의 시나리오는 무엇인지, 이 프로덕트를 통해 우리 팀은 어떻게 발전할 것인지 등 해당 프로젝트의 방향성만을 확실히 하여 개발자와 디자이너에게 최대한의 창의성과 자율성을 보장하여 훨씬 효과적이고 효율적인 방법으로 프로덕트를 생산할 수 있게 도와주는 것이 바로 PRD입니다.

그렇다면 PRD라는 문서는 어떤 내용들을 담아야할까요?

우선 일반적으로 PRD 문서를 이루는 목차는 다음과 같습니다.

1. 기본정보
2. 참여자
3. 상태
4. 런칭 일시
5. 팀 목표와 비즈니스 목표 (최대 2개를 넘어가지 않도록 최상위 목표를 제시합니다. )
6. 배경 및 전략적 적합성 ( 우리 팀이 기능을 만드는 이유, 혹은 이 기능이 전체 회사 목표에 어떻게 부합하는 지 간결하게 설명합니다.)
7. 가정
8. 기술적 가정 (해당 프로젝트가 개발에 효율성을 가져오는 이유를 설명합니다. )
9. 비즈니스적 가정 (해당 프로젝트가 경제적 가치를 어떻게 가지는 지, 얼마만큼 가지는 지 설명합니다.)
10. 고객 가정 (어떤 고객들이 해당 기능을 사용하게 되는지 설명합니다.)
11. 유저 스토리
12. 고객 인터뷰 등 구체적인 고객의 목소리(VOC)
13. 고객 사용 시나리오 (유저 저니 맵)
14. 와이어프레임 (각 유저 시나리오에 대한 솔루션을 와이어프레임으로 구체화하여 설명합니다.)
15. 예상 질문과 그에 대한 답
16. 우리가 하지 않는 일 What’s we’re not doning (우리가 이번에 다루지 않을 일을 구체적으로 명시 합니다.)

실제로 저희 팀은 올 6월부터 PRD라는 문서를 통해 프로덕트, 혹은 프로젝트의 시작을 알리고 있는데요, PRD를 통해 빠르게 새로운 프로젝트의 시작을 알릴 수 있었고, 화면 정의나 기능 설명보다 팀의 목표와 비즈니스 목표, 유저 스토리를 전달하는 것이 효율적인 커뮤니케이션을 위해 선행되었어야 한다는 걸 몸으로 느낄 수 있었습니다.

앞서 설명 드린 목차에서 저희는 가끔 특정 항목을 빼기도 하고, 출시일이 정해져 있는 경우 스프린트를 추가한다던가, 유저 페르소나가 다양한 경우 유저 스토리를 구체적으로 작성한다던가 하며 필요한 부분을 강조하고, 필요없는 부분을 과감하게 제외하며 PRD의 핵심 가치를 지키려고 노력하고 있습니다.

모든 팀에 PRD라는 양식이 효과적인 커뮤니케이션을 불러온다고는 할 수 없을 것 같습니다. 하지만 혹시 기획<>디자이너<>개발자 사이의 커뮤니케이션과 관련해서 고민하고 있으신게 있다면, PRD를 한번 작성해보시는 건 어떨까요? 혹은 우리 팀에서 하고 있는 효과적인 소통방법이 있다면 꼭 알려주시면 좋겠습니다!