명확하고 논리적인 제품 요구사항을 작성하자
문제 해결 가설을 제품으로 탄생시킬 설계도, 제품 요구사항(PRD)
-
제품 요구사항(PRD) 이란?
문제의 핵심 원인을 파악하고 가설을 세웠다면 프로덕트 매니저는 제품을 만들기 위한 요구사항을 작성한다. 제품 요구사항(PRD, Product Requirement Documents)은 해결하려는 문제와 목적이 무엇인지, 왜 해야 하는지, 해결 가설과 성공 여부를 측정할 지표, 어떻게 제품으로 구현할지를 담은 문서이다. 이를 참고하여 디자이너, 엔지니어는 문제 해결 방향성을 이해하고 제품을 구현한다.
요구사항을 작성하는 도구와 탬플릿은 조직의 협업 방식, 제품화 단계, 개인 성향에 따라 다를 수 있다. 필자도 파워포인트, 카카오 오븐, 구글 독스, 컨플루언스 등을 사용했다. 그러면서 느낀 점은 어떤 도구, 탬플릿을 사용하는지 별로 중요하지 않다는 것이다. 중요한 건 제품 방향성을 논리적으로 명확하게 작성할 수 있어야 한다는 점이다. 이를 어떻게 작성해야 하는지 주요한 요소별로 알아보겠다.
-
목적과 배경
먼저 제품의 목적을 설명한다. 무엇을 목적으로 문제를 하는지 방향성을 간결하고 명확하게 담고 있어야 한다. 이후 왜 이 문제를 해결하려는지 배경을 설명한다. 정량적/정성적 근거를 활용해 문제가 왜, 어떻게 발생했으며, 현재 상황은 어떠한지 서술한다. 모두가 바쁜 시간을 쪼개어 이 요구사항을 검토한다. 문서의 목적과 배경만 읽어도 제품 방향성이 무엇인지를 빠르게 이해할 수 있도록 작성하는 게 좋다.
예시)
목적: 유형별로 알림 설정을 세분화하여 푸시 알림을 꺼놓은 유저 비율을 낮춘다
배경 1: 최근 x 주에 잦은 푸시 알림으로 불만을 표시한 VOC가 y건 발생했다
배경 2: 최근 x 주에 푸시 알림을 꺼놓은 유저 비율이 y% 증가했다
배경 3: 최근 x 주에 발송된 푸시 알림은 이전 대비 y% 증가했다
배경 3: 현재 푸시 알림은 일괄로 on/off 처리만 되는데, 주문, 배송 등의 중요한 알림을 놓칠 수 있다.
-
가설과 지표
이제 문제를 해결할 가설을 작성한다. 가설은 문제를 해결할 하나의 가정을 뜻하며 검증할 수 있어야 한다. 가설을 작성할 때에는 'X라는 문제를 Y로 해결하면 고객 경험이 Z로 개선될 것이다'라는 형식으로 작성하면 좋다.
이와 함께 가설을 검증할 데이터, 즉, 제품의 성공 여부를 측정할 지표를 정의해야 한다. 지표는 제품의 향후 의사결정을 판단할 기준이 된다. 또한 제품 개발에 참여하는 팀원들이 달성해야 할 목표치이다. 그만큼 다음과 같은 기준으로 지표를 주의 깊게 세워야 한다.
첫째, 문제가 해결되었는지 명확히 판단할 수 있어야 한다. 즉, 제품을 개발했을 때 개선될 고객 경험을 제대로 측정할 수 있는지를 확인해야 한다. 둘째, 개발할 제품과 직접적으로 연관성이 있어야 하며 다른 요인에 영향을 받아서는 안된다.
예로 검색 결과 페이지를 개선한다고 해보자. 여기서 '거래액'이란 지표는 모호하다. 유저는 검색 결과 이후에 상품 상세, 결제 페이지를 거쳐 결제를 완료하기 때문이다. 따라서 거래액에 영향을 주는 경로가 여러 개다. 또는 시즌에 영향을 받는 서비스라면 거래액도 변동될 수 있다. 보다 명확한 지표로는 '검색 결과에 진입한 유저의 상품 클릭률', '결제를 마친 유저 중에서 검색 결과를 경유한 비중' 등으로 세워야 한다. 셋째, 제품을 배포하고 다음에 어떤 결정과 액션을 해야 할지 명확히 알려주는 액셔너블한 지표여야 한다. 아무리 다양한 데이터를 담고 있어도 무엇을 해야 할지 알 수 없다면 의미 없는 지표이다.
예시)
가설: 중고거래 상품등록 과정의 단계를 축소하면 유저들이 쉽게 상품을 등록할 것이다
지표 1: 주 단위 전체 유저에서 상품등록을 완료한 유저 비율
지표 2: 주 단위 전체 상품에서 신규로 등록된 상품 비율
지표 3: 주 단위 상품등록을 시작한 유저에서 등록을 마친 유저 비율
-
사용자 스토리
완성한 제품을 고객이 어떻게 사용할지 시나리오를 작성한다. 먼저 제품을 사용할 고객이 누구인지, 우리 서비스에서 어떠한 특성과 패턴을 보이는지 파악한다. 사용자 스토리의 시작점은 고객이 제품을 어디서, 어떻게 접하는지부터이다. 이후 어떤 과정으로 제품을 사용할지를 설명한다.
이렇게 작성된 스토리는 하나의 제품 구현 테스크가 될 수 있다. 예로 '유저가 선택한 카테고리별로 최근 구매상품을 보여준다'는 스토리는 해당 화면에 카테고리를 표시하는 테스크, 카테고리를 선택했을 때 해당 유저의 구매이력에서 연관된 상품 DB를 불러오는 테스크, 해당 상품을 선택한 카테고리 하단에 표시하는 테스크로 나뉠 수 있다.
예시)
가설: 카테고리별로 고객이 구매했던 상품을 보여주는 기능을 제공하면 편리하게 재구매를 할 것이다
타깃 유저: 최근 x개월 장보기 서비스를 이용했던 유저
스토리 1: 유저는 메인화면 상단 탭에서 '자주 구매'를 발견할 수 있다
스토리 2: '자주 구매'에 진입하면 '카테고리'를 선택할 수 있다
스토리 3: '카테고리'를 선택하면 최근에 구매했던 상품을 확인할 수 있다
스토리 4: 해당 상품을 바로 장바구니에 옮길 수 있다
-
제품 개발 목록과 구현 단계
사용자 스토리를 기준으로 디자인 및 개발할 테스크를 나열한다. 테스크를 정의하기 모호한 부분이 있다면 해당 작업자에게 피드백을 받는 게 좋다. 누가 어떤 테스크를 맡을지 명확히 분배하는 것도 프로덕트 매니저의 중요한 역할이기 때문이다. 각 메이커들의 상황을 고려해 적절히 테스크를 나누는 게 좋다.
많은 디자인, 개발 리소스가 필요한 제품이라면 무리하게 진행하기보다는 단계별로 구현할 필요학 있다. 성공 여부를 판단하기 전에 무리한 리소스를 투입하는 건 비효율적이기 때문이다. 먼저 가설 검증이 가능한 수준의 최소기능제품(MVP, Minium Viable Product)을 만들고, 지표 성과에 따라서 단계적으로 확장해본다.
예시)
가설: 카테고리별로 고객이 구매했던 상품을 보여주는 기능을 제공하면 편리하게 재구매를 할 것이다
1단계(MVP): 메인화면에 '자주 구매' 탭을 표시하고, 진입 시 주요 카테고리와 구매했던 상품정보 표시
2단계: 어드민에서 노출할 카테고리를 생성하고 관리하는 기능 구현
3단계: 유저의 구매이력 별로 카테고리 순서 자동정렬, 자주 구매 인기상품 추천 로직 구현
-
플로우 차트
플로우 차트는 화면 단위로 제품이 어떠한 순서로 실행되는지 설명한다. 되도록 직접 작성하기보다는 제품 디자이너에게 맡기는 걸 권한다. UX/UI를 전문적으로 설계하는 디자이너가 화면의 흐름을 정의하는 게 올바른 업무 분담이기 때문이다.
그러나 제품 기획이 익숙지 않은 주니어라면 직접 작성해보는 걸 권한다. 전체 구조를 시각화하여 이해할 수 있고, 제품이 동작하는 과정을 논리적으로 따져볼 수 있기 때문이다. 예로 유저의 선택에 따라 분기 처리를 해야 할 것, 조건에 해당되지 않는 유저에게 필요한 예외 케이스를 점검해볼 수 있다.
-
제품 방향성을 정했다면 요구사항을 세세히 작성하는데 너무 많은 시간을 들이지 말자. 우선 핵심 내용을 위주로 메이커들에게 빠르게 피드백을 받아보길 권한다. 제품을 구현하는데 고려할 사항, 예상 이슈, 보다 효율적인 해결법을 찾을 수 있기 때문이다.
제품화 스펙을 확정 짓기 전에 요구사항으로 연관된 이해관계자들에게도 리뷰를 미리 해두자. 운영, 비즈니스, 법무에 관한 이슈를 미리 점검하고 대응책을 마련할 수 있기 때문이다.
프로덕트 매니저. 조금 더 알고 싶으세요?
클래스 101에서 커리어 강의를 오픈했어요. 프로덕트 매니저 직무 탐색, 고객/사업/기술을 이해하는법, 제품문제를 분석하고 해결하는법, 제품 출시 관리 및 커뮤니케이션까지 그간 쌓아온 경험을 꾹꾹 눌러담았어요.
클래스 보러가기
