How to Write a Product Requirements Document (PRD)

PM의 직무를 생각할 때, 기획서 작성 업무를 빼놓을 수 없지만 정형화된 방법이 있는 것은 아니라 서비스나 회사 문화, 프로젝트 팀의 성격, 그리고 PM에 따라 형태가 많이 달라지곤 한다. 기획서는 해당 기획의 큰 틀이 담겨있기 때문에 잘 작성할수록 좋은데, 다른 회사에서는 어떻게 작성하는지 찾아보다가 발견한 글인데 여러모로 도움이 많이 되어 기억하고 싶은 글이라 번역해서 작성한다.

— Omar Eduardo Fernandez 2020.8.1 / 원문 (링크)

PRD가 무엇인지 알고 싶습니까? 아니면 어떻게 작성해야 할까요? 프로덕트 매니저는 다음과 같은 몇 가지 주요 질문에 답하기 위해 제품 요구 사항 문서(PRD; Product requirement document)를 작성합니다.

우리가 이 기획을 진행하는 이유는 무엇입니까? (WHY)
문제에 어떻게 접근하고 있습니까? (HOW)
올바른 솔루션은 무엇인가요? (WHAT)

우리는 이러한 질문에 답할 뿐만 아니라 올바른 제품을 구축하고 사용자에게 성공적으로 제공할 수 있도록 팀이 함께 나아가기 위해 PRD를 작성합니다. 올바르게 사용하면 어떤 개발 프로세스를 따르든 관계없이 훌륭한 제품 개발 도구입니다. PRD 작성이 처음이라면 프로세스를 최대한 활용하는 데 도움이 되는 몇 가지 팁이 있습니다.

PRD에는 무엇이 있습니까?

가장 기본적인 형태의 PRD는 다음의 섹션이 포함되어 있는 간단한 문서입니다.

요약 및 배경(Summary and Background): 무엇이 문제이며 왜 문제가 됩니까? 비즈니스 메트릭 정보, 과거 사용자 조사 또는 기획의 중요성을 강조하는 기타 통찰력을 포함할 수 있습니다.
대상 사용자(Target Users): 솔루션을 사용하거나 혜택을 받을 사람은 누구입니까? 이러한 사용자가 중요한 이유와 이들의 불편함(pain points)을 우선 순위를 지정하는 것이 중요한 이유는 무엇입니까?
핵심 사용자 여정(Critical User Journeys, CUJs): 문제를 해결한 후 사용자는 무엇을 달성할 수 있습니까? 특정 솔루션이 아닌 사용자 요구에 집중하십시오.
기능적 요구사항(Functional requirements): 문제를 해결하기 위해 제안된 솔루션에 대한 설명입니다. PM으로서 기능적 요구 사항을 자세히 설명하는 것이 중요하지만 특정 솔루션을 지시하는 것은 피해야 합니다.
지원 문서(Supporting documents): 디자인 및 엔지니어링 담당자와 협력하여 솔루션의 상호 작용 디자인 및 기술 구현을 정의합니다. PRD의 기능 요구 사항을 유지하되 추가 세부 정보를 위해 UX 및 엔지니어링 설계 문서에 대한 링크를 추가합니다.
시장 진출(Go-to-market): 기능이 사용자에게 어떻게 출시될 것인지에 대한 고려 사항과 마케팅, 영업, 고객 지원 및 기타 사용자 대면 기능에 대한 기대치.

이것이 PRD의 기본 섹션이지만 제품의 수명 주기를 포함하여 다른 많은 고려 사항에 대해 작성할 수 있습니다. 내가 함께 일한 이전 팀에서 PRD 템플릿에는 사용자 권한 고려 사항, 성능 요구 사항, 데이터 가져오기 또는 내보내기 고려 사항, 성공 지표, 플랫폼 간 호환성, 새로운 접근성 고려 사항 등을 설명하는 섹션이 포함되어 있습니다. 위의 기본 섹션으로 시작하고 팀과 함께 작업하면서 중요한 질문을 해결하기 위해 필요에 따라 새 섹션을 추가합니다.

PRD 작성 시 발전을 위한 팁

조기에 팀 피드백 받기

종종 PM은 피드백을 위해 PRD를 공유하기 전에 PRD에 너무 많은 시간을 할애합니다. 대신 처음부터 하나의 사용자 경험(UX)과 PRD에 대한 피드백을 검토하고 제공하는 데 적극적으로 참여할 엔지니어링 상대 한 명을 정하세요. 위의 세 가지 주요 질문(이 기획서의 이유, 방법 및 내용)에 대한 답을 요약한 PRD의 첫 번째 초안을 작성하고 공유하십시오.

PM의 첫 번째 임무는 팀원들에게 이 기획이 중요한 이유와 우선 순위를 정해야 하는 문제를 설명하는 것이지만 문제에 대한 솔루션은 엔지니어링 및 UX 담당자와 협력하여 정의해야 합니다. 조기에 자주 피드백을 받으면 시간을 효과적으로 집중할 수 있습니다.

따라야 할 좋은 경험 법칙은 이전에 논의된 기본 PRD의 처음 세 섹션(요약 및 배경, 대상 사용자, CUJ)의 초안을 작성한 경우 섹션 4(기능 요구 사항)로 진행하기 전에 피드백을 받아야 한다는 것입니다. 사용자와 CUJ는 특정 솔루션을 설명하는 기능적 요구 사항을 정의하려고 시도하면 문제를 조정하기 전에 귀하와 팀이 상당한 시간을 낭비하게 될 수 있습니다.

PRD를 흥미롭고 체계적이며 소화하기 쉽게 만드세요.

좋은 PRD는 불필요한 노력을 많이 들이지 않고도 동료에게 중요한 정보를 적절하게 전달하는 것입니다. 이를 위해서는 몇 가지 사항을 염두에 두고 PRD를 편집해야 합니다.

문제에 집중하기: 확실한 것을 포함하여 PRD에서 관련이 없거나 쓸모없는 세부 정보를 제거하고 문제 영역에 집중합니다. 조기에 팀 피드백을 받는 주요 이유는 충돌 영역이 있을 수 있는 위치를 찾기 위함입니다. 이러한 갈등을 파헤치고 팀이 앞으로 나아가도록 돕는 데 시간을 집중하십시오. 문서화 목적이나 CYA모름에 대한 내용을 적어 달라는 요청을 받았지만 관련이 없거나 명백한 세부 사항이라고 생각되면 부록에 추가하는 것을 고려하십시오.
한눈에 스캔할 수 있도록 PRD를 구조화하기: 다양한 동료들이 무엇에 관심을 가질지 생각하고 쉽게 찾을 수 있도록 PRD를 구성하십시오. 주요 논의 사항을 쉽게 파싱할 수 있도록 제목과 부제목을 현명하게 사용하세요. 이렇게 하면 여러 팀의 동료가 자신에게 중요한 사항에 빠르게 집중하고 통찰력을 제공할 수 있습니다.
와이어프레임이나 다이어그램, 표 활용하기: 단락과 중요 항목이 너무 많으면 뇌가 지루한 상태가 될 수 있습니다. 옵션을 비교하거나, 변경 전후를 설명하거나, 데이터 흐름을 설명하거나, 타임라인 고려 사항을 논의하는 경우 모든 사람이 표, 차트 또는 목업을 사용하는 것이 도움이 될 수 있습니다. 이것들을 합치려면 더 많은 작업이 필요하지만 그것이 가져올 수 있는 명확성은 큰 이득이 됩니다. 그러면 더 많은 동료가 PRD의 정보를 소화하는 데 도움이 되어 반복적인 질문으로 이어지지 않을 수 있습니다.

논의를 이끌어보세요.

PRD가 흥미로운 점에 초점을 맞추고 갈등 영역을 다루며 중요한 해결책을 논의하면 대화가 시작될 것입니다. 독자가 피드백과 의견을 남기도록 권장해야 합니다. 그런 다음 피드백을 검토하고 적절하게 대응할 때 신중하게 생각하는 것이 PM의 임무입니다.

커멘트 확인하고 응답하기: 댓글에 동의하는 경우 독자에게 알려주세요! 동의하지 않는 경우 추가 컨텍스트를 제공하거나 누락되거나 잊어버린 것이 있는지 확인하기 위해 명확한 질문을 합니다. 이 프로세스는 중요한 문제를 식별하고 불일치를 표면화하며 기획의 성공 가능성을 높이는 데 도움이 됩니다.
자존심은 잠시 넣어두기: 기획을 수행한 후 다른 사람이 PRD에 헬리콥터를 타고 비판적이거나 무례하거나 무지한 의견을 남기면 짜증이 날 수 있습니다. 감정이 고조되었을 때 대응하기보다는 숨을 고르고 정신을 딴 데로 돌리고 차분해졌을 때 피드백을 고려하십시오. 댓글을 객관적으로 고려하면 댓글에서 유용한 정보를 찾을 수 있습니다. 그때 대답하세요.
중요하고 복잡한 사항은 회의에서 논의하기: 기획 진행 방법에 대한 주요 불일치 또는 의견 불일치가 있는 경우 문제를 논의하기 위한 회의 일정을 잡습니다. 논의할 명확한 불일치 주제를 갖고, 토론에 필수적인 사람들만 초대하여 초점을 유지하십시오.
논의를 마무리할 시간을 파악하기: 일단 방향을 설정하고 모든 주요 플레이어가 참여하면 산만함과 범위/기능 변경을 최소화해야 합니다. 해결책에 동의했음을 PRD에서 명확히 하는 것이 중요합니다. 나는 더 이상 적극적으로 피드백을 구하지 않는다는 신호로 문서 상단에 "상태: 최종"을 추가하는 것을 좋아합니다. 열려 있는 모든 댓글이나 새로운 제안에 대해 피드백이 고려되었음을 사람에게 알리고 피드백이 포함되거나 포함되지 않은 이유를 알리고 댓글을 해결합니다. 혼란을 피하기 위해 친절하지만 명확하게 신중하게 수행하십시오.

계속 반복하고 학습하세요!

나는 지난 6년 동안 수십 개의 PRD를 작성했으며 매번 기획과 관련된 목적이나 팀 구성원에 따라 조금씩 PRD의 내용은 조금씩 달랐습니다. 이것은 최종 결과를 볼 때 분명하게 나타나며 두 개의 PRD가 동일하게 보인적은 없습니다. 그러나 최종 상태에 도달하려면 초안을 작성하고, 팀원의 많은 피드백을 통합하고, 설계 및 엔지니어링 담당자와 최종 솔루션에 대해 협력하고, 회의에서 까다로운 문제를 해결하고, 궁극적으로 PRD를 마무리하는 유사한 프로세스는 같았습니다. 최종 PRD는 구현된 최종 솔루션을 반영할 뿐만 아니라 더 흥미롭게도 팀이 솔루션에 맞추기 위해 거쳐온 여정도 반영합니다.

각 여정은 고유하며 모든 기복과 함께 끝까지 도달한 방법을 반영하여 다음 번에 학습하고 개선하는 데 가장 좋은 자산이 될 것입니다.