전통적인 PRD 접근법을 피하고 제품을 만드는 방법
Razorpay 사례
저도 정리했지만 저자의 방향성에 동의하지만 PRD 형식에 대해서 완전히 동의가 되지는 않습니다. 읽어보시고 필요한 항목을 기획서, 제품 요구사항 문서 작성에 참고하시면 좋을 것 같습니다.
---
문제점 해결을 위해 프로덕트가 다룰 비즈니스 케이스, 기능 등을 포괄적으로 요구사항이라 부를 수 있다. 제품에 대한 이와 같은 요구 사항의 모음을 PRD라고 함.
PRD(Product requirements document)의 목표는 디자인, 분석, 엔지니어링, 데브 옵스, QA, 마케팅, 영업과 같은 cross-functional team이 효율적인 협업을 지원하는 것이 목표임
전통적인 PRD는 요구사항을 바탕으로 기능 목록을 나열하는 형태로 구성됨. PRD가 설명하는 기능 및 사양에 따라 Jira와 같은 툴을 통해 세분화되어 개발 담당자에게 배정되는 형태임. 전통적인 PRD는 제품에 대한 비전을 구성원에 팔지 못하며, 구성원에게 자극시킬 동기부여를 제공하지 못하며 아래에 대한 답을 제공하지 못함.
- 프로덕트가 중요한 이유는?
- 우리의 고객은 누군가?
- 고객의 문제점을 어떻게 해결할 것인가?
- 프로덕트 출시 이후 회사에 미치는 영향은?
결국 PRD는 고객의 목소리를 담는 것이 아닌 PM의 의견만을 담는 수단이 됨. 저자는 PRD가 what뿐만 아니라 why를 담아야 내야 한다고 설명.
- 고객의 pain point는 무엇인가?
- 이 제품에 적합한 고객은 존재하는가?
- 지금 이 제품을 출시하기 적기인가?
- 회사의 비전과 일치하는가?
PM은 문제점을 정의하지 않고 바로 솔루션을 정의하려는 유혹(또는 실수)에 빠짐. 이를 피하기 위해 Concept Note, User Stories를 PRD에 담을 것을 제안함
Concept Note는 제품 개발의 당위성, 풀려는 문제점 등을 담아 구성원의 공감대를 이루기 위한 것이 목적임. 솔루션을 하이 레벨로 풀어낸 사업계획서 같은 형태로 생각하면 됨.
User Stories는 에픽과 스토리로 구성되며, cross-functional team 담당자가 사용자에게 전달되는 기능 레벨로 상세하게 정의 필요. 스토리가 상세할수록 제품 개발 관련 스프린트 플래닝 단계에 도움이 됨.
Concept Note는 아래와 같이 구성됨
Project Summary – 첫 부분, 확실한 메시지 필요
Goal and Success Criteria – 목표와 성공 기준
OKR mapping – 회사의 OKR에 부합하는지 설명
Problem Statement – 문제점 정의, 데이터 뒷받침 필요
Customer Persona –고객 페르소나, 모든 고객군을 만족시킬 수 없음. 특정 고객군의 페인 포인트 해결 초점
Current Alternate – 현재 고객들이 해결책이 없는 상태에서 어떻게 문제점에 대응하는가?
Assumptions – 가설
Recoverable / Reversible in case of failure without impacting Customer experience – 실패 및 다른 기능에 치명적인 장애를 미치는 상황에 대한 대응 시나리오
Unknown/Future similar problem – 미래 발생 가능한 문제점 검토, 현재 솔루션이 이를 어떻게 해결할지 고검토.
Solution consideration – 단일 솔루션이 아닌 최소 3개 이상의 솔루션을 제안함(장단점 포함)
Solution Summary – 솔루션 요약
Happy Flows – 와이어프레임, 워크플로우 다이어그램 형태 등으로 표현 가능함. 솔루션ㅇ로 고객이 경험할 최상의 시나리오 설명
Un-Happy Flows – 엣지 케이스를 와이어프레임, 워크플로우 다이어그램 형태 등으로 설명. 프로덕트에 영향을 미칠 수 있는 부정적 요소 검토
Detailed Solution – 솔루션 상세화, 프로덕트를 구성하는 큰 단위의 요소와 블록 단위로 설명
Impact assessment and Metrics – 성과 분석 관련 성공 지표 정의
Internal Dependencies (optional) – 회사 내부의 어떤 조직에 의존성이 있는지 설명. 예를 들면 특정 데이터를 우리 팀이 아닌 다른 팀의 협조를 통해 얻어야 하면 이를 설명함
External Dependencies (optional) – 외부 이해관계자 의존성, 예를 들면 UAT 테스팅 환경, 샌드박스 환경 등
Competitive landscape (optional) – 시장 경쟁 상황
Risk assessment (optional) – 새로운 솔루션이 기존 제품의 다른 모듈에 영향을 미치는지? 기존 솔루션과 카니발라이제이션이 생기는지?
Release strategy and milestones – 배포 계획, 출시 계획.. 큰 프로젝트는 Go-to Market 전략
Future scope – 단계별 미래에 출시한 프로젝트 범위
User Stories는 아래와 같이 구성됨. 컨셉 노트가 비즈니스 및 기술 관련 이해 관계자의 동의를 얻는 목적이라면, 유저 스토리는 제안된 솔루션을 요구사항으로 분류하여 실제 구현에서 활용하기 위한 목적임.
사용자 스토리는 EPIC과 스토리(Stories)로 더 세분화. 프로덕트는 여러 개의 에픽으로 구성되며, 에픽은 스토리로 구성됨. 에픽은 큰 스토리라고 생각하면 됨( large user story)
- EPIC – 스프린트 1차 또는 1번의 이터레이션으로 배포할 수 없는 규모의 large user story. 일반적으로 여러 개의 작은 스토리로 구성된 제품의 key component를 정의함. 에픽에도 관련해서 end-user가 얻을 수 있는 beneift이 명시 필요
- User Stories – 제품에 반영하고 계획하는 기능 세트. 개발자가 시스템과 사용자의 상호작용을 잘 이해할 수 있는 수준으로 기능을 설명해야 함. 아래는 유저 스토리 작성을 위한 프레임워크임
유저 스토리 작성 위한 프레임워크
Summary of the story – 1-2 줄로 스토리가 다루고 있는 기능을 설명한 글
Benefit – 스토리 개발이 end-user에게 미치는 영향. 해당 스토리를 개발하는 담당자에게 해당 기능이 출시 후에 미치는 영향을 잘 이해시키는 목적
Acceptance Criteria – 해당 기능이 구현되었을 때 유저에게 예상되는 결과. 좋은 유저 스토리는 제품 솔루션 관점에서 인수 기준(Acceptance Criteria)이 정의되어 있음(디자인과 엔지니어링 구현 관점이 아닌)
Analytics Requirement – 이벤트, 데이터 포인트 같이 개별 스토리를 측정할 수 있는 분석 요구사항 정의
Giphy뉴스 레터 발행을 시작했습니다. 관심 있으신 분들께서는 아래 뉴스레터 링크에서 구독 부탁드립니다 :)
