프로덕트팀의 PRD 도입기 (2)
PRD에 필요한 요소와 적용 방안은 무엇인가?
앞선 글에서는 PM이 전통적인 스토리보드 방식으로 UX/UI와 제품 상세 기획까지 모두 담당하며 생긴 팀의 병목 현상과 팀의 역할에 대한 고민으로 인해, 스토리보드를 탈출하여 PRD를 도입하기로 한 배경에 대해 이야기했다.
이번 글에서는 이러한 배경에서, 구체적으로 어떤 양식으로 PRD를 세팅했고, 이를 어떻게 실제 업무에 적용했는지 공유하고자 한다.
기획자/PM이 제품의 상세 기획을 프로덕트 디자이너에게 위임하기 위한, PRD의 양식과 적용 방안은 무엇인가?
문제 정의 : 제품을 통해 누구의 어떤 문제를 해결할 것인가?
제품은 고객의 문제를 해결하고 가치를 제공하는 수단이다. 그래서 제품 요구사항 정의서의 공통 사항이자 핵심 사항은 바로 어떤 고객의 어떤 문제를 해결하고, 이를 통해 어떤 가치를 제공하는 제품이 될 것인가? 에 대한 내용이다. 그리고 이는 초기 문제의 발굴 및 정의 단계이므로 PM이 작성한다.
1. Target User 어떤 고객의 문제를 해결할 것인가?
- 어떤 유형, Segment의 고객의 문제를 해결할 것인가?
- 어차피 모든 유형의 고객의 문제를 해결할 수는 없다
2. Pain Point / Problem-to-solve 고객의 어떤 문제를 해결할 것인가?
- 고객은 우리 제품 내에서 어떤 문제, 미충족 수요를 겪고 있는가?
- 고객은 시장 내에서 어떤 문제, 미충족 수요를 겪고 있는가?
- 고객은 왜 그런 문제를 겪고 있거나, 아직 수요가 충족되지 못했는가?
3. VP 고객의 문제를 해결함으로써 제품은 궁극적으로 어떤 가치를 제공하는가?
- 결국 제품을 통해 고객은 어떤 가치를 제공받는가?
- 이 부분이 제품의 소구점, 마케팅 포인트, PR의 핵심이 된다
문제 해결 : 유저의 문제를 구체적으로 어떻게 해결할 것인가?
발굴 및 정의된 문제를 바탕으로, 이를 해결하기 위한 옵션과 세부 정책 등을 설계하고 검토하는 단계이다. 잘 정의된 문제더라도 이를 해결하기 위한 방안은 여러 개가 있으므로, 이를 리서치하고 검토하고, 검토한 내용을 바탕으로 세부적으로 설계 및 기획하게 된다. 이 과정은 팀과 함께 진행된다.
4. 옵션과 레퍼런스
- 대부분의 문제는 이미 존재하고 있고, 이를 해결하기 위한 대략적인 방안 역시 이미 존재한다.
- 따라서 유사 서비스, 경쟁사의 서비스 등을 스터디, 리서치하여 옵션 안을 마련할 수 있다
- 단, 이 단계에서 옵션을 확정 짓거나 세부 기획/정책을 설계하진 않는다. 어디까지나 '이런 옵션이 있다' 정도를 알아보는 용이다
옵션 검토 w/팀
- PRD의 항목이 아닌, 4번 단계까지의 정의가 끝난 후 팀과 함께 공유 및 검토를 진행하게 된다.
- 제시된 옵션의 개요를 설명하고 팀 또는 이해관계자와 질의응답, 의견 논의를 진행하여 최종적으로 옵션을 선택하게 된다.
5. 세부 정책과 기능, 예외 사항
- 팀과의 검토를 통해 옵션이 최종적으로 정리되면, 이후 해당 옵션에 따른 세부 정책과 이에 따라 유저가 할 수 있어야 하는 행동/기능을 정리한다. 이는 기존의 User Story 정도의 항목으로 세부 Description을 의미하지는 않는다.
- 단, 기존 제품과의 충돌이 우려되는 사항 등, 예외적인 사항에 대해서 함께 서술하여 디자인 및 개발 단계에서 참고할 수 있도록 한다.
6. 구체적인 기능 정의 및 우선순위
- 기능이 여럿일 경우 우선순위를 작성한다. 이는 PM이 부재하거나, 리소스가 한정된 경우 팀이 제품의 핵심에 대해 동일하게 이해하고 판단할 수 있기 위함이다.
세부 정책 및 기능 검토 w/팀
- 6번까지 완료된 경우 이를 바탕으로 최종적으로 팀, 이해관계자와 공유 및 검토한다.
- 이미 1차 검토서 옵션의 방향에 대해서는 공유 및 결정되었지만, 세부 기능은 중간에 변경되거나 추가될 수 있으므로 공유와 검토가 필요하다.
- 이번 MVP 및 프로젝트에서 실질적으로 구현하게 될 제품의 상세 사항이며
- 디자이너와 개발팀은 이를 바탕으로 실제 작업에 착수하게 된다
제품의 검증과 성장 : 어떻게 검증하고 어떻게 성장시킬 것인가?
문제 정의와 문제 해결에 대해 설계되었다면, 이를 통해 최종적으로 무엇을 기준으로 제품의 성공 또는 가설의 성공을 검증할 것이며, 이를 위해 제품을 어떻게 유저에게 알리고, 또한 가설이 성공한 경우의 팔로업 방향에 대한 개요를 작성한다. 결국 이 역시도 문제 정의와 가설 검증, 그리고 이를 통한 제품의 성장에 관한 부분으로 PM이 작성하게 된다.
7. 제품의 성공의 정의
- 모든 제품은 가설을 검증하기 위한 수단이다
- 문제 정의, 문제 해결안 역시 하나의 가설이다. '이런 유저에게 이런 문제가 있고, 이 문제를 이 방안으로 해결할 수 있을 것이다'일 뿐, 제품 출시 전까지는 확답할 수 없다.
- 따라서 제품의 성공, 또는 가설의 검증을 확인하기 위한 핵심 지표가 무엇인지 정의한다.
8. 제품 노출 및 홍보 방안
- 제품이 유저에게 도달, 노출, 인지되어야만 사용이 발생한다.
- 공지, 마케팅, 프로모션 등 제품을 알릴 방안에 대해 검토한다
9. 제품의 그로스, 스케일업 방안
- 가설이 검증된 이후 이를 성장시키기 위한 방안의 개요에 대해 검토한다.
- 100% 실패도 없고 100% 성공도 없으므로 실패한 부분 중 어떤 부분을 다르게 재시도할지, 성공했다면 어떤 걸 더 빠르게, 더 잘, 더 많이, 더 높이 해볼 것인지에 관한 내용이 된다.
PRD 이후의 단계 = UX/UI
이 과정은 PRD를 바탕으로 실제 제품을 설계하고 프로젝트에 착수하는 것에 관한 부분이다. 잘 살펴보면 위의 PRD는 모두 줄글, 텍스트로 구성되어 있으며 이 중 어느 부분에도 UX/UI를 고려하지 않았다. 그리고 바로 이것이 기존의 스토리보드 형태의 제품 기획서와의 차이다. PM으로서 집중한 것은 문제 정의였고, 문제의 해결방안에 대해서는 팀과 함께 검토 및 논의했다.
따라서 9번 항목까지 작성 및 검토 완료되어 PRD가 확정되면, 이를 바탕으로 디자이너는 UX/UI를 설계한다. 핵심은 PRD의 정의, 검토 과정에서 PM과 팀이 제품에 대해 동일하게, 그리고 상세하게 이해했다면 PM/기획자의 와이어프레임 없이도 디자이너가 바로 작업에 들어갈 수 있다는 점이다.
1. 시안 작성 및 협의
- PRD에서 정의된 타깃과 문제, 그리고 제품의 정책과 기능을 바탕으로 UX/UI 시안을 작성한다
- 기존 레거시, 디자인 가이드 등을 고려하여 제품팀과 시안에 대해 협의한다
2. UT
- 협의된 시안이 유저의 사용에 있어서 불편함, 난해함 등이 없는지를 테스트한다.
- UT를 통해 알게 된 것, 발견하게 된 것들은 다시 디자인에 반영한다
3. 워크플랜 및 일정 설계
- 최종 확정된 제품 디자인을 바탕으로 개발 구현 일정과 필요 상세 항목을 설계한다
이러한 항목과 역할, 그리고 논의 단계 등은 어디까지나 하나의 예시이다. 팀의 구성과, 프로덕트의 성질과, 혹은 상황에 따라 얼마든지 변경되고, 추가되고, 삭제된다. (가령 제품 개발이 아닌 상세페이지에서의 작은 실험을 위주로 하는 팀의 경위 위의 항목 중 상당수가 팀에 부적절하다는 의견을 남겼다)
결국 PRD의 핵심은 앞선 글과 본 글의 초두에 이야기했듯이
1. PM은 문제 정의와 가설 검증에 집중하고
2. UX/UI의 설계는 디자이너에게 위임하는 부분이다.
본 글에서 설명한 PRD의 양식 샘플을 아래 링크로 참조한다
https://docs.google.com/spreadsheets/d/1-0S1HtFkVF_UvcH8olWPGEoraYhyNcpoY1JDDr4p2qE/edit?usp=sharing
