특강) 기획명세서(PRD) + 오늘의 Q&A

[게시글 목차]

1. PRD는 왜 필요한가
2. PRD 개념 정리
3. PRD - 사례로 연습하기

 

+) 오늘의 Q&A
   Q1. 핵심 기능을 돕는 기능도 MVP에서 제외해야 하나요?
   Q2. PRD에 유저 저니맵을 반드시 넣어야 하나요?
   Q3. 한계와 향후 방향도 작성하나요?
   Q4. MVP의 예상 리스크와 해결방안을 별도로 작성해야 하나요?
   Q5. 기존 서비스의 기능 추가·고도화에도 PRD를 작성할 수 있나요?
   Q6. 내가 쓴 PRD가 잘 쓴 문서인지 어떻게 확인하나요?

++) 오늘의 인사이트 / KPT 회고

 

1. PRD는 왜 필요한가

• PRD(Product Requirements Document) : 제품을 만들기 전에 협업자들의 판단 기준을 맞추는 문서
• 개발자·디자이너·이해관계자가 아래와 같은 내용을 같은 기준으로 이해하도록 돕는다.
  • 왜 이 제품을 만드는가
  • 누구의 어떤 문제를 해결하는가
  • 무엇을 만들고 무엇을 만들지 않는가
  • 어떤 결과가 나오면 성공으로 판단하는가
    → PRD의 핵심은 문서 형식이 아니라 공통 이해와 의사결정 기준의 통일!

🔹좋은 PRD의 기준

◾전달력이 있어야 한다.

• 처음 보는 사람도 문서만으로 제품의 배경과 요구사항을 이해할 수 있어야 한다.

◾필수 기능 범위가 명확해야 한다.

• 이번 버전에서 반드시 만들 기능과 제외할 기능이 구분되어야 한다.

◾핵심이 먼저 보여야 한다.

• 두괄식으로 쓰고, 주장과 설명·예시를 분리한다.
• 논문처럼 길게 설명하기보다 보고서에 적합한 블릿형 구조를 활용한다.

◾독자와 목적에 맞게 구성해야 한다.

• 정해진 템플릿을 채우는 것보다 누가 읽고 어떤 결정을 내려야 하는지를 먼저 고려한다.

🔹PRD의 기본 구성

• PRD의 항목은 고정되어 있지 않지만, 일반적으로 다음 요소를 조합한다.

순서	목차	내용
1	목표	• 서비스 목표 • 서비스가 제공하는 핵심 가치
2	배경	• 시장 동향 • 경쟁사 및 기존 서비스의 한계 • 사용자 리서치 결과
3	핵심 타겟	• 제품이 가장 먼저 해결하려는 핵심 사용자
4	문제 정의 및 솔루션 가설	• 사용자의 페인포인트 • 관찰된 문제 현상 • 해결해야 할 핵심 문제 • 문제의 중요성 • 솔루션 가설과 근거
5	핵심 MVP	• 핵심 유저 플로우 • 기능 목록과 우선순위 • 이번 범위에서 제외한 기능 • 주요 와이어프레임 • 기능명세서 또는 연결 링크
6	기대효과	• 정량·정성 성공지표

🔹PRD의 형식은 제품과 조직에 따라 달라진다

• PRD를 쓰는 목적은 같지만, 적절한 형식과 상세 수준은 조직 문화와 제품 특성에 따라 달라진다.

환경	문서 특징	그렇게 쓰는 이유
쿠팡	핵심과 임팩트를 앞에 둔 간결한 문서	빠르게 핵심을 파악하고 결정하기 위해
배민	위키 기반의 비교적 친절하고 풍부한 문서	맥락·참고자료·레퍼런스를 함께 공유하기 위해
네이버·카카오 등	PPT·Figma·위키 형식이 혼재	기존 PC 기반 기획 문화와 현재 협업 방식이 함께 존재하기 때문에
외주·대행 프로젝트	화면별 요소와 요구사항을 세밀하게 정의	발주자와 제작자가 상세 기준을 명확하게 합의해야 하기 때문에
백오피스·결제·정산	정책과 기능명세를 상세하게 작성	작은 오류도 업무나 금액에 큰 영향을 줄 수 있기 때문에
단기 MVP 프로젝트	문서와 기능 범위를 간소화	기간이 짧고 변동성이 크며, 빠른 검증이 중요하기 때문에
→ 따라서 PRD는 양식이 고정된 게 아니라 현재 프로젝트에서 어떤 합의가 필요한가를 기준으로 문서 수준을 결정해야 한다.

🔹AI 시대에 PM이 해야 할 일

• AI는 PRD 초안을 빠르게 작성할 수 있지만, 좋은 방향인지를 대신 판단해 주지는 못한다.
• PM에게 더 중요해진 역할
  • 문제와 목표가 논리적으로 연결되는지 판단하기
  • 조사 자료 중 목표를 뒷받침하는 근거만 선별하기
  • 핵심 타겟의 범위를 적절하게 설정하기
  • MVP에서 반드시 검증할 기능을 선택하기
  • AI가 만든 와이어프레임과 기능명세 초안을 계속 수정하기

 

2. PRD 개념 정리

🔹목표와 배경의 관계

• 배경은 조사한 내용을 모두 모아놓는 자료 창고가 아니다. → 목표가 왜 타당한지를 증명하는 근거
  ex. 목표가 '사용자가 제로·저당 식품을 쉽게 선택하도록 돕는다'라면 배경에는 다음과 같은 내용이 연결되어야 한다.
  • 제로·저당 식품 시장이 확대되고 있다.
  • 소비자의 관심과 구매가 증가하고 있다.
  • 사용자는 성분표와 제로 표기 기준을 이해하기 어렵다.
  • 관심은 높지만 실제 제품 선택에는 정보 장벽이 존재한다.
    → 조사 자료가 많아도 목표와 관련 없는 내용은 제외할 것.

🔹핵심 타겟

• 타겟은 단순히 성별·연령·직업으로 정의하지 않는다.
  실제 서비스 사용과 연결되는 관심, 문제, 행동이 중요하다.
  • 좁은 타겟: 제로·저당 제품에 관심이 높고 선택 과정에서 어려움을 겪는 사용자
  • 넓은 타겟: 다이어트나 건강 관리를 위해 식품 성분에 관심을 가진 사용자
• 초기 MVP에서는 좁은 핵심 타겟에 집중하고, 제품이 성장하면 타겟을 확장할 수 있다.

🔹핵심 MVP

• MVP는 '있으면 좋은 기능을 모은 작은 서비스'가 아니라 핵심 가설을 가장 적은 자원으로 검증하는 범위다.
• 기능이 너무 많아 선택하기 어렵다면 다음처럼 접근한다.
  1. 후보 기능을 모두 적는다.
  2. 핵심 가치를 직접 구현하는 기능 하나를 먼저 고른다.
  3. 나머지 기능에는 우선순위를 부여한다.
  4. 1순위 기능이 완성된 뒤 시간이 남을 때 다음 기능을 만든다.
• 핵심 기능을 돕는 기능이라도 지금의 가설 검증에 필수적이지 않다면 과감히 제외하는 편이 낫다.

🔹유저 저니맵

• 유저 저니맵은 PRD의 필수 항목이 아니다.
  • 이미 모두가 서비스 흐름을 이해하고 있고 여정이 단순하다면 생략할 수 있다.
  • 신규 서비스이거나 여러 사용자와 단계가 복잡하게 얽혀 있다면 공통 이해를 높이는 데 유용하다.
• 즉, 유저 저니맵은 문서를 그럴듯하게 만드는 장식이 아니라 복잡한 사용자 흐름을 설명해야 할 때 쓰는 도구다.

🔹향후 방향과 리스크

• 장기 프로젝트라면 1·2·3단계 로드맵 중 현재 MVP가 어느 단계인지 제시할 수 있다.
• 한계를 길게 나열하기보다는 검증 결과에 따라 다음에 무엇을 할지 간단히 적는 것이 유용하다.
• 예상 리스크와 해결방안은 필수 항목이 아니며, 프로젝트의 복잡도와 의사결정 필요성에 따라 포함한다.

 

3. PRD - 사례로 연습하기

🔹제로·저당 식품 분석 서비스

◾목표

• 복잡한 식품 성분표를 직관적으로 분석하여 사용자가 다이어트, 혈당 관리, 저당 식단 등 자신의 건강 목표에 맞는 제로·저당 식품을 쉽고 빠르게 선택하도록 돕는다.

PM 업무 흐름	내용
비전	건강 목표에 맞는 식품을 누구나 이해하고 선택할 수 있게 한다.
목표	성분표 이해의 어려움을 줄이고 제품 선택 시간을 단축한다.
리서치	시장 성장, 소비자 관심 변화, 기존 서비스의 한계, 사용자 인터뷰를 확인한다.
문제 발견	사용자는 제로·저당 제품에 관심이 있지만 표기 기준과 성분표를 이해하기 어렵다.
문제 정의	정보가 없는 것이 아니라, 정보가 사용자의 건강 목표에 맞게 해석되지 않는 것이 문제다.
우선순위	커뮤니티·추천·기록 기능보다 성분표 분석과 결과 설명을 먼저 검증한다.
가설	식품 성분을 사용자의 건강 목표에 맞게 쉽게 설명하면, 사용자는 제로·저당 제품을 더 빠르고 확신 있게 선택할 것이다.
검증 방법	• 프로토타입 사용성 테스트 • 사용자 인터뷰 • 분석 결과 화면의 이해도 조사 • 제품 탐색부터 선택까지 걸리는 시간 비교

 

 

---

 

오늘의 Q&A

 

 

Q1. 핵심 기능을 돕는 기능도 MVP에서 제외해야 하나요?

• 대부분의 기능은 어느 정도 도움이 되기 때문에 제외가 어렵다.
• 우선 핵심 가치를 직접 구현하는 기능 하나를 고르고, 나머지에는 우선순위를 부여한다.
• 현재 가설 검증에 필수적이지 않다면 과감히 제외하는 편이 낫다.

Q2. PRD에 유저 저니맵을 반드시 넣어야 하나요?

• 필수는 아니다.
• 사용자와 흐름이 복잡하거나 신규 서비스의 이해도를 높일 필요가 있을 때 사용한다.
• 이미 모두가 흐름을 알고 있고 과정이 단순하다면 생략해도 된다.

🔹복잡한 유저 저니맵이 필요한 서비스

• 폐식용유 수거·가공·판매 서비스에는 식당 사장, 개인 수거 기사, 업체 소속 기사,
  창고 운영자, 필터링 업체, 판매 업체 등 여러 사용자가 참여한다.
• 식당 배출 → 기사 수거 → 창고 보관 → 필터링 → 판매
• 이처럼 사용자 역할과 단계별 책임이 복잡할 때는 유저 저니맵을 통해
  전체 흐름과 접점을 시각화하는 것이 유용하다.
  반면 일반적인 의류 구매 서비스처럼 흐름을 모두가 이미 이해하고 있다면 반드시 만들 필요는 없다.

 

Q3. 한계와 향후 방향도 작성하나요?

• 프로젝트 성격에 따라 다르다.
• 한계를 길게 적는 경우는 많지 않지만,
  장기 프로젝트라면 현재 단계와 이후 로드맵을 제시해 전체 방향을 이해시킬 수 있다.

Q4. MVP의 예상 리스크와 해결방안을 별도로 작성해야 하나요?

• 필수 항목은 아니다.
• 문서 복잡도를 높일 수 있으므로 실제 의사결정에 필요할 때 포함한다.
  MVP 가설이 검증되거나 검증되지 않았을 때의 다음 행동을 간단히 적는 방식은 유용하다.

Q5. 기존 서비스의 기능 추가·고도화에도 PRD를 작성할 수 있나요?

• 작성할 수 있다.
• 전체 서비스를 새로 만드는 경우뿐 아니라 카카오톡 선물하기,
  생일 알림처럼 큰 피처나 개별 기능도 하나의 제품 단위로 보고 PRD를 작성할 수 있다.
  다만 회사마다 이를 PRD, 기획안 등 서로 다른 용어로 부를 수 있다.

Q6. 내가 쓴 PRD가 잘 쓴 문서인지 어떻게 확인하나요?

• 문서 내용을 모르는 사람에게 보여주고 다음 질문으로 확인한다.
  • 왜 만드는지 이해할 수 있는가?
  • 누구의 어떤 문제를 해결하는지 알 수 있는가?
  • 이번에 무엇을 만들고 제외하는지 구분할 수 있는가?
  • 읽은 뒤 필요한 의사결정을 내릴 수 있는가?

 

---

 

오늘의 인사이트

 

이전에 VOD에서도 추천하셨던 도서

'회장님의 글쓰기'와 '기획의 정석'을 다시 추천해 주셨다.

집에 우연히 기획의 정석 2편이 있던데(1편은 어디다 팔아먹고...)

언젠가 시간이 되면 읽어보도록 하자...

 

문서 작성에 대한 특강이 디테일하게 다뤄지는 걸 보니

당연한 소리지만 문서가 중요하긴 한 모양이다.

(그만큼 어려워하는 사람이 많다는 뜻이기도 하겠지)

 

 

---

 

오늘의 KPT 회고

 

Keep	• PRD를 작성하기 전에 독자와 문서의 목적을 먼저 정의한다. • 목표와 배경이 서로 논리적으로 연결되는지 확인한다. • 핵심을 먼저 쓰고, 주장과 설명·예시를 구분한다.
Problem	• 타겟을 성별·연령 같은 인구통계 정보만으로 정의할 수 있다. • 도움이 되는 기능을 모두 MVP에 포함해 검증 범위가 커질 수 있다. • 유저 저니맵, 리스크 등 템플릿 항목을 필요성 없이 채울 수 있다.
Try	• PRD 첫 부분에 왜 만드는가 / 누구를 위한 것인가 / 이번에 무엇을 검증하는가를 한 문단으로 정리한다. • 모든 배경 자료 옆에 '이 근거가 목표를 어떻게 지지하는가?'를 표시한다. • MVP 후보 기능 중 핵심 가설을 직접 검증하는 기능 하나를 먼저 선택한다. • 기능별로 필수 / 후순위 / 제외를 구분하고 제외 이유를 기록한다. • PRD 리뷰 시 내용이 아니라 독자의 의사결정 가능 여부를 기준으로 피드백을 받는다.