제품 요구사항 정의서(PRD) - 좋은 문서를 작성하는 방법

제품 요구 정의서 : 제품을 만들거나 업데이트할 때 기능을 기획하는 단계에서 요구사항을 설명하는 문서입니다.

이번 글을 통해서 PRD가 중요성, 핵심 구성 요소, 주의점에 대해서 소개 하겠습니다.

 

기본적으로 PRD는 아래 질문에 대한 답변을 풀어내어야 합니다.

1. Why?
   이 제품 혹은 프로젝트를 진행하는 이유는 무엇인가?
2. What?
   문제에 어떻게 접근하고 있는가?
3. How?
   올바른 해결책은 무엇인가요?

PRD의 중요성

간단한 제품은 혼자 만들 수 있습니다.
하지만 많은 사람들을 대상으로 하는 제품은 여러 이해관계자가 모여서 만들어집니다.
디자이너, 개발자부터 제품을 시장에 진입 및 확장시킬 마케터 혹은 영업부서까지 필요하죠.

 

PRD를 작성하는 것은 단순히 요구사항을 전달하는 것을 넘어서서
모든 팀원들이 한 방향을 바라보게 하는 중요한 수단입니다.
그렇기 때문에 PRD를 ‘잘’ 작성하는 것은 중요합니다.

 

이 제품을 왜 그리고 누구를 위해 만드는 것이며, 어떻게 제품을 만들 것이고
제품을 만들었을 때의 기대효과와 시장에 어떻게 진출할 것인지를
일목요연하게 누가봐도 이해할 수 있을 정도로 쉽게 만들어야 합니다.

 

위에서 말했다 싶이 PRD를 읽는 독자는 많으며 각 섹션마다의 주 독자가 정해져있습니다.
때문에 해당 부분에서 읽는 사람에 따라 그들이 실행할 수 있을 정도의 단계로 풀어낼 수 있어야 합니다.
또한 해결해야하는 문제에 대해서 명확하게 정의해야 합니다.

 

PRD의 핵심 구성 요소

대표적으로 아래와 같은 섹션들이 PRD를 갖추기 위해 필요합니다.

1. 요약 및 배경
   문제가 무엇이며 왜 중요한가?
   비즈니스 지표 정보, 과거 사용자 조사 또는 이니셔티브의 중요성을 강조하기 위한 기타 인사이트를 포함할 수 있습니다.
2. 타겟 유저
   누가 솔루션을 사용하거나 혜택을 받을 수 있는지를 작성합니다.
   이러한 사용자가 중요한 이유는 무엇이며, 이들의 고충을 우선적으로 고려해야 하는 이유는 무엇인가요?
3. 주요 유저 여정
   문제를 해결한 후 사용자가 무엇을 성취할 수 있을까요? 특정 솔루션이 아닌 사용자의 요구사항에 집중해야 합니다.
   주로 유저 인터뷰를 진행해서 정의됩니다.
4. 기능 요구사항
   문제를 해결하기 위해 제안된 솔루션에 대한 설명입니다. 유저 입장에서 필요한 기능을 정의합니다.
   기능 요구 사항은 대체로 가설을 기반으로 만들어집니다.
   당연하게도 가설이 검증된 프로덕트를 개발할 수록 성공할 확률이 높아지겠죠.
   
   ** 기능 요구 사항을 MECE하게 작성하는 방법에 대해서는 다음에 작성해보겠습니다.
5. 보완 문서
   디자인 및 엔지니어링 담당자와 협력하여 솔루션의 인터랙션 디자인과 기술 구현을 정의합니다.
   기능 요구사항은 PRD에 그대로 유지하되, 자세한 내용은 UX 및 엔지니어링 설계 문서에 대한 링크를 추가하세요.
6. 시장 진입 전략
   독자에게 기능을 출시하는 방법과 마케팅, 영업, 고객 지원 및 기타 사용자 대면 기능에 대한 기대치를 고려합니다.

주의점

모든 것이 완벽히 완성되었을 때 공유하려고 하는 생각은 지양해야 합니다.
물론 이런 생각이 들 수도 있습니다. “어? 완벽하지 않은 문서를 공유했을 때 실무자들이 헷갈리지 않을까?”
하지만, 제품은 모든 팀원이 함께 만드는 것입니다.
오히려 실무자들에게 늦게 공유할 수록 이미 돌아가기에는 너무 멀리 와버린 상황이 될 수도 있습니다.

예를 들어 이런 것이죠. 햄버거를 만든다고 가정해봅시다.
PM이 생각하기에는 빵, 야채, 패티, 소스가 필요하다는 것을 큰 골격으로 정의할 수 있습니다.
여기서 PM이 정확하게 알지 못하는 경우 패티를 만들기 위해 축사를 가서 조사를 하게될 수 있습니다.
하지만, 패티 전문가가 팀 내에 있는 경우 높은 퀄리티의 패티를 공급하는 업체에 연락하여 30분만에 문제를 하게될 수 있습니다.
시간도 절약할 수 있고, 초기부터 우리가 이루고자 하는 방향에 대한 싱크를 맞출 수 있게되는 것이죠.

 

PM이 모든 문제에 대해 정확한 해결책을 내지 않아도 됩니다.
오히려 문제를 잘 정의하고, 문제를 해결할 수 있는 사람에게 빠르게 조언을 구하는 것이 중요합니다.
우리가 만들어야 하는 제품에 대해 팀원들의 이해를 맞추는 것, 그리고 그 내용을 바탕으로 같은 방향을 바라보게 하는 것이 중요합니다.

 

PRD는 끝이 없습니다. 항상 진행형입니다.
끝을 낸다기 보다는 가이드를 잘 잡고 항상 업데이트 하는 방향으로 생각합니다.(매몰 비용의 오류에 빠지지 않도록)
어떻게 하면 큰 변경없이 지속적으로 확장 가능한 구조로 만들 수 있을지 고민하는게 중요한 것 같습니다.

 

위와 조금 상충되지만 또 한 가지의 주의점은 최대한 지양해야하는 부분은 ‘담당자가 알아서 하겠지’입니다.
PM은 프로덕트의 매니저입니다. 앞에서 끌어주면서도 뒤에서 밀기도 하며, 흘리는 것은 닦아주고 떨어트린 것은 닦아주어야 합니다.
정확하게 기술적인 것까지 알기 어려울 수 있지만 왜 그렇게 판단했고, 실행하는지 알아야 합니다.
그리고 대채로 기술적인 것이더라도 일반인이 이해할 수 있는 수준으로 충분히 설명이 가능하니 파고들면 됩니다.

 

PRD는 나침반이자 지도입니다.

PM이 지도를 잘 만들어야 팀원들이 길을 잃지 않습니다.

좋은 제품을 만드는 좋은 PM이 될 수 있도록 항상 성장해봅시다!

 

부족한 부분이 있다면 언제든 yungsu2391@gmail.com으로 연락주세요!

참고문서 : https://www.tryexponent.com/blog/how-to-write-a-prd