PRD 작성 단계별 활용 방법
PRD 실무에서 어떻게 활용해야할까?
좋은 프로덕트를 만들기 위한 PRD(Product Requirement Document) 작성법은 익혔는데 실제 PRD를 작성하면서 어떤 과정을 거쳐야할까?
무작정 처음부터 끝까지 작성하면 그것은 좋은 PRD를 만들 수 있을까?
PRD를 작성하기로 했다면 초안을 작성한 후에 끊임없이 팀원들과 소통하며 발전시켜 나가야한다.
그 과정에서 내가 생각하지 못한 문제나 해결책을 발견하거나 새로운 지식을 얻을 수도 있기 때문이다.
그럼 작성하기로 마음 먹은 이후부터 어떻게 하면 될지 단계별로 알아보자.
1. 작성 단계별 가이드
PRD는 '처음부터 완벽하게 작성해야 한다'고 생각하면 부담감에 오히려 작성하기가 매우 어렵다.
따라서 '초안을 잡고 팀과 함께 발전시켜 나가는 문서’로 PRD를 쓸 때는 아래의 단계를 고려하면 좋다.
1) 초안 작성
초안 작성시에는 팀원들에게 최대한 자주 공유하며 '우리가 문제를 제대로 정의했는지?', '해결 방향으로 도출한 가설이 가치를 제공할지?', 'KPI에 영향을 끼칠지?'에 대한 논의를 함께 진행한다.
a) 아이디어 구조화
해결하고자하는 문제에 대해 목표와 배경, 필요한 기능들을 생각나는대로 정리한다.
예시
"이 기능을 통해 유저들이 어떤 가치를 얻을 수 있는가?"
"주어진 문제 상황은 무엇이며, 내가 해결하고자 하는 것은 어떤 부분인가?"
b) 범위 확정
어느정도의 기간을 사용할 수 있는지 MVP 단계인지 혹은 조금 더 확장된 단계를 목표로 하는지 등 개발 범위를 명확히 한다. 필요에 따라 경영진과의 미팅이 사전에 필요할수도 있다.
c) 가설 설정
정의한 문제에 대한 가설(해결방안)을 세운다.
"이 기능이 실제로 가치를 제공할 것이다"라는 전제 하에 측정해야 할 KPI나 성과, 달성 목표를 구체적으로 생각하여 정리한다.
아이디어가 확정되기 전 단계이므로 관련된 팀원들(디자이너, 개발자, 비즈니스, 마케터 등)과 캐주얼한 미팅을 통해 의견을 공유한다.
PRD 공유시에는 짧은 1on1 미팅을 통해 프로젝트의 동기를 이끌어내는것이 필요하다.
잦은 공유로 각자 다른길로 가지 않아야한다2) 상세 기획
가설을 바탕으로 어떤 구조로 유저에게 가치를 전달할지 플로우를 정의하는 과정과 도출한 기능에 대한 우선순위를 정한다. 이 과정에서 개발팀과 추가적인 미팅이 필요할 수 있고 가능한 개발 범위를 확정 지을 수 있도록 한다.
a) 사용자 플로우 정의
유저가 제품을 사용할 때 어떤 과정을 거치는지 화면 단위로 시나리오를 설계한다.
예시
"로그인 후 첫 화면에서 어떤 액션이 가능한가?"
"유저가 목표를 달성하기까지 거치는 단계를 어떻게 디자인할 것인가?"
b) 기능 우선순위 정하기
꼭 필요한 기능(P0*)과 나중에 고려해볼 기능(P1 ~ P2) 등을 구분해야한다. 여기서 이해관계자들과 "왜 이 기능이 P0여야 하는가"를 적극적으로 논의해야한다.
c) 핵심 지표 및 성공 기준 설정
이전 단계에서 잡았던 가설에 근거해 목표 지표(KPI)나 성공 기준(OKR 등)을 구체화한다.
PRD가 어느정도 구체화 되었다면 주요 기능에 대한 의견 조율을 위해 개발팀, 디자인팀, QA팀 등 개발 관련 팀원 전체와 함께 미팅을 진행한다.
간단한 프로토타입 또는 화면을 보며 기능별로 검토해야 할 예상 리소스, 개발 난이도, 리스크 등을 확인하고 우선순위를 다시 확정한다.
*P0 ~ P2 : Priority를 의미하며 중요도에 따라 P0 ~ P2를 설정하곤 한다. 일전에 설명했던 PRD에서 정의한 내용으로는 P0 는 Must Have, P1은 Should Have, P2는 Could Have에 해당한다.
3) 문서 보완
a) 상세 요구사항 기재
앞선 미팅을 바탕으로 상세 요구사항을 기재한다. 문서에 '어떤 데이터를 입력받고 어떤 데이터를 출력해야 하는가?'와 같은 구체적인 요건과 샘플 데이터 등을 기재한다.
- Figma 등 화면 단위 요구사항을 구체적으로 작성
- API 스펙, DB 구조 등 기술적인 요구사항 포함
b) 전체 플로우 점검
작성된 요구사항들이 전체 사용 시나리오와 잘 맞물리는지 다시 한번 확인
- 엣지 케이스(예외 상황)나 장애 상황에서의 대처 방안도 포함
c) 디자인 시안 검토
디자인 시안이 있다면, PRD 내 요구사항과 일관된 스펙인지 검토한다. 글로 풀기 어려운 상세 화면이나 UI 요소는 와이어프레임 또는 목업을 링크로 첨부하면 팀원들이 이해하기 쉽다.
이때는 각 직무 담당자들과 지속적으로 소통하며 산출물의 퀄리티를 높이는데에 집중한다.
4) 내부 검토 & 피드백 수렴
a) 팀원 리뷰 요청
일정 수준으로 문서가 정리되면 팀원들과 리뷰 세션을 갖는다.
- PRD를 처음 보는 사람도 내용을 쉽게 이해할 수 있는지 확인
- 추가 수정이 필요한 부분, 모호하게 서술된 부분을 체크
b) 프로토타입 공유
실제 구현에 앞서 빠르게 MVP 프로토타입을 만들 수 있다면 프로토타입에 대한 피드백과 PRD 간의 불일치를 확인한다. (실제 동작 방식을 보다보면 PRD가 잘못됐을수도 있다.)
필요시에 사내 다른 구성원들에게 프로토타입으로 간단한 유저인터뷰를 진행하기도 한다.
5) 최종 확정 & 버전 관리
a) 최종 범위 및 일정 확정
모든 요구사항과 우선순위, 일정을 확정한다.
b) 버전 관리
확정했더라도 개발 중 변경사항이 있을 수 있기에 문서를 변경 이력 관리가 필요하다.
c) 이후 커뮤니케이션 전략
PRD는 최종 확정이 끝이 아니라 릴리즈 전후로 지속해서 업데이트되고 개선되어야 한다.
문제정의를 잘하자...2. PRD 작성 시 주의사항
1) 혼자서 모든 내용을 '결정'하지 않기
PRD는 혼자서 만들어서 통보하는 문서가 아니라 팀 전체가 이해하고 참여해야 하는 문서이기 때문에 독단적으로 확정지어버리면 다양한 시각이나 전문 지식에서 오는 통찰을 놓치기 쉽다. 또한 구성원들에게 동일한 문제 인식과 동기부여를 할 수 없는 문제도 발생하기 때문에 Document Owner는 PM이지만 프로젝트 전 구성원이 '함께' 만들어 나간다는것을 기억하면 좋다.
2) 지나치게 디테일하거나 혹은 너무 추상적이지 않게
문서의 양이 너무 많거나 자세하면 읽는 팀원들이 핵심을 파악하기 어렵고 이해하기를 포기하는 경우가 생긴다. 내용은 간략하게 작성하되, 반드시 필요한 내용만 담도록 한다. 너무 자세한 문서는 나중에 수정하기가 힘들어질 가능성이 높다.
또한 구체적이지 않고 추상적으로 작성하면 각자가 이해하고 경험한 내용을 바탕으로 진행하기 때문에 결과물이 생각한것과 다르게 나올 수 있다. 어떤 방식으로든 진행할때 가장 중요한건 팀원과의 '지속적인 공감'과 '소통'이다. (On the Same page)
3) 명확한 목표와 지표 없이 작성하지 않기
"왜 이 제품/기능을 만드는지"에 대한 답과, "만약 성공이라면 어떻게 측정할 수 있는지"가 문서에 분명히 드러나야 한다. 목표가 분명하지 않으면 프로젝트 전체가 흔들릴 수 있고 왜 이 프로젝트를 하는지에 대한 동기를 잃게 된다. 동기를 잃은 구성원들은 점점 창의성을 포기하게 되고 수동적으로 변할 위험이 높으니 목표에 공감할 수 있도록 하고 프로젝트 완료후에도 지표 추적을 하여 결과를 공유해야한다.
4) 문서의 오너십과 최신성 유지
작성자가 PRD의 오너일 수는 있지만, 모든 팀원들이 최신 버전을 쉽게 확인하고 의견을 추가할 수 있는 환경을 마련해야 한다. 바쁘다보니 가장 놓치기 쉽지만 최악의 경우 개발이 문서보다 앞서 가 있어 신규 입사자가 따라갈 수 없는 상황이 발생한다.
3. PRD 활용법
1) 팀 간 커뮤니케이션 허브로 활용
개발자, 디자이너, QA 등 다양한 직군이 모두 보는 '문서'로 활용하도록 해야한다. 각 팀원이 궁금한 부분이 생겼을 때 PRD를 가장 먼저 참조할 수 있도록 유도해야 서로 커뮤니케이션 미스가 생기지 않는다.
2) 진행 상황 및 QA에 활용
스프린트나 칸반 보드를 운영할 때 PRD에 적힌 요구사항과 현재 개발 현황을 계속 대조하면서 일정 및 범위 관리를 해야한다. 또한 QA 팀이 테스트 케이스를 작성할 때 PRD의 시나리오와 요구사항을 기준으로 삼으면 누락 없이 테스트를 진행할 수 있다.
3) 의사결정 근거 자료로 활용
기능의 중요도나 구현 방식을 두고 의견이 갈릴 때 PRD에 명시된 목표나 우선순위, 배경을 근거로 하면 의사결정의 기준이 사전에 잡혀있기 때문에 결론을 도출하기가 수월해진다.
또한 회고시에도 결과물과 PRD에 적힌 목표 및 요구사항을 비교해보며 이번 프로젝트에서의 부족했던점을 다음 PRD 작성에 반영할 수 있다. 이처럼 지속적인 회고를 바탕으로 팀의 기준에 맞춰 업그레이드 해나가면 된다.
끝으로
PRD는 단순히 '기능 명세'를 나열하는 문서가 아니라, 팀을 하나로 모으고, 공통된 목표를 향해 나아갈 수 있도록 하는 로드맵의 역할을 한다.
나의 부족함을 들키기 싫어 '완벽할때 공유해야겠다. 최대한 잘써야한다.' 는 부담을 가지고 작성하면 오히려 더 안좋은 결과를 가져올 수 있으니 최대한 자주 공유하여 소통하는 방식을 시도해보자.
결국 다 사람이 하는 일이고 능동적인 사람들은 자신의 아이디어를 쏟아내는것에 적극적이니 이를 활용하면 더 좋은 문서를 작성할 수 있다.
그리고 그들도 자신들의 아이디어가 프로덕트에 반영되는 경험을 하다보면 자연스럽게 신뢰가 쌓이게 될것이고 후에 조금 논리나 배경이 부족하더라도 신뢰로도 가설에 도전하는 과정을 만들어낼수도 있을것이다.
