실용적인 요구 사항 정의서 (PRD)

date

Jul 25, 2020

slug

prd

author

status

Public

category

Product

updatedAt

May 29, 2023 03:10 AM

제품 관리자(Product Manager)가 타겟 고객과 그들의 문제를 잘 찾았다면 이제부터 제품에 대해서 정의를 시작할 때이다. 그런데 막상 쓰려고 하면 어떻게 써야할 지 막막해서 결국 구글링에 의존하면 다양한 제품 요구 사항 정의서(PRD) 폼을 만나게 된다. (결정장애 ㅠ.ㅠ)

보통은 PRD를 작성한다고 하면 엑셀이나 구글 스프레드시트 등을 활용하여 표형식으로 많이 작성한다. 그러나 이런 경우 가장 큰 문제점은 가독성이다. 솔직히 작성한 본인도 나중에 다시 보기 싫은 형식인데 그 외 제품 관계자들은 더욱 읽기 어려운 문서가 되어버리기 쉽다. 결국 매번 모여서 설명이 필요하거나 사실상 사용되지 않는 문서가 되어 버리곤 한다.

“문서가 결국은 가장 효율적인 의사소통 수단이 된다 (물론 어떤 관점에서 어떻게 작성하느냐에 달려있지만)”는 견해를 가지고 있는 필자로서는 효율적인 PRD의 형식이 어떤 것일지가 늘 물음표였고, 다양한 시도 끝에 여전히 완전하지는 않지만 꽤 효율적인 나만의 PRD 문서의 폼을 찾게 되었다.

이번 글에서는 이 PRD 형식을 소개하고자 한다. 어차피 정답이 정해져 있다기 보다는 각 제품팀에 맞는 방식이 존재할 뿐이므로 그저 참고가 되거나 일부라도 도움이 되길 바랄 뿐이다.

필자가 현재 사용하고 있는 PRD의 형식은 크게 3개의 부분으로 나뉘어져 있다. 첫번째는 제품 개요 페이지인데 필자는 Heading Page 라고 부르고 있다. 두번째는 유저 관점 흐름도 그리고 마지막 세번째는 요구사항 정의이다. 그럼 각각에 대해서 간단히 설명해 보면,

PART1: 제품 개요

PRD에서 가장 중요한 부분으로, 아래 사항들을 쉽게 파악하고 토론을 유도할 수 있어야 한다.

누구나 제품의 목적(타겟 고객/문제/솔루션)을 10~20분 이내에 쉽게 이해 가능한가

이 제품이 정말 시장에서 가치가 있는가

제품팀이 역량을 가지고 있는가

타겟 고객에게 서비스 확산이 가능한가

이러한 목적을 가장 효과적으로 만족시킬 수 있는 문서의 폼으로 아마존의 Internal Press Release 폼을 추천한다. 아마존 내부에서 실제 사용하는 것으로 알려져 있는데, 기획 초기 단계에 지금 상품을 출시한다고 생각하고 1~2장 이내의 프레스 릴리스 문서를 작성하는 방식이다. 경험상 제품팀 관계자들이 가장 빠르게 제품에 대해 이해하고 몰입을 유도할 수 있었다. 작성 가이드는 구글에서 “amazon internal press release” 로 검색해보면 잘 설명된 자료된 쉽게 발견할 수 있다. (참고 링크)

아래 예시는 좀 더 구체적인 이해를 돕기 위해 필자가 이전에 제품 초기 단계에 작성했던 것이다. (결코 잘썼다고 볼 수 없고 공개하긴 부끄럽지만 진심으로 도움이 되길 바라는 마음에 올립니다.)

PART2: 유저 관점 흐름도

제품 개요 파트에서 제품 관계자의 공감과 합의를 끌어내고 방향을 확정했다면(아마 이를 위해서는 디자인 스프린트가 필요할 것이다) 이제 좀더 유저관점에서 제품을 구체화해볼 필요가 있다. 이때 유저의 라이프 사이클을 흐름도 형태로 작성하면 다수의 관계자에게 가장 오해없이 제품에 대한 사용자 시나리오를 구체적으로 전달할 수 있었다.

아래 예시를 보면 작성이 상당히 어려울 것 처럼 느껴질 수 있지만, 판단(다이아몬드)과 상태(둥근 직사각형)만 잘 사용해도 대부분의 흐름도를 무난하게 작성할 수 있다. 참고로 필자는 이러한 유저 관점 흐름도 작성을 위한 툴로 Diagrams.net 을 추천한다. 이유는 일단 무료이고 구글 드라이브와도 잘 호환되기 때문이다.

PART3: 요구사항 정의

스타트업의 대표나 제품 관리자들이 요구사항 정의에 대해서 생각보다 중요하게 생각하지 않는 경우를 많이 목격하게 된다. 제품의 요구사항에 대해서 관계자들이 오해없이 이해하도록 잘 정의하는 일은 쉬운 일이 아니다. 특히 제품에 대한 방향, 이슈 등 여러가지 사안을 챙기고 최종 의사 결정을 하느라 바쁜 제품 관리자로서는 요구사항 작성에 많은 시간을 들이기 아까워 말로 때우거나 어느 정도 방향을 잡아 주기만 해도 된다고 생각할 수 있다. 나머지는 제품팀의 전문가들이 찰떡같이 알아듣고 잘 만들어 줄 것이라고 믿는 것이다.

그러나 필자의 경험상 요구사항 정의가 가독성이 떨어지거나 내용이 불충분하면 바로 그 지점에서 늘 사고가 발생한다. 대표적인 사고 사례는 원래 의도와 다른거나 과잉 기획 및 개발이다. (엄한 산 가거나 기획, 개발을 거치면서 일정이 대폭 늘어나 버리는 사태는 대부분 겪어 봤으리라.. ㅠ.ㅠ)

제품 개요(amazon internal press release)와 디자인 스프린트 등 으로 시장에 먹히는 최소 기능 제품(MVP)를 찾았다면, 제품 관리자는 최대한 가독성있고 구체적으로 제품의 요구사항 정의서를 작성해야만 한다. 필자의 경험상 MVP를 가장 빠르고 정확하게 시장에 내보내기 위해서 그 어떤 것보다 중요하다고 생각한다.

그럼 좀더 구체적으로 요구 사항 정의를 잘 작성하기 위한 몇가지 팁을 정의하면 다음과 같다.

유저 관점 흐름도를 바탕으로 기능을 단계별로 그룹핑하고 가장 적절한 기능 그룹 이름을 정의한다. (1단)

각 기능 그룹(1단)을 세분(Break-down)하여 가독성 좋은 문장 형태로 정의한다. (2단)

이런 식으로 기능 그룹을 단계별로 필요한 만큼 구체화해 나간다 (3단, 4단, …)

핵심적인 부분은 개발자도 이해할 정도로 구체적으로 작성한다.

필자의 경험상 구글 문서를 사용하여 일반적인 문서 형태로 가독성 있게 정의하는 것이 가장 효과적이었다. (참고로, 우선 순위 높은 것은 형광펜 등으로 강조할 수도 있고, MVP에서 제외되는 것은 취소선으로 표시할 수도 있다) 물론 요구 사항 정의서도 초안 상태에서 확정 되기까지 제안 및 토론 등을 통해 지속적으로 업데이트 되어야 한다. 이때 구글 문서의 댓글 기능을 적극 활용하면 제품 관계자들의 시간을 크게 낭비하지 않으면서 가장 효율적으로 업데이트할 수 있었다. (정말 뛰어난 제품팀은 늘 모이지 않더라도 상시 활발한 의사 소통이 가능해야 한다. 진짜 좋은 아이디어는 퇴근길 지하철에서 떠오르는 법이고 그 순간 휴대폰으로 바로 댓글로 달 수 있는 팀이어야 한다. 효율적인 제품팀 회의 방식에 대해서는 다음에 회고록을 남길 예정이다.)

PRD 작성시 절대 하지 말아야 할 것은 예시나 참조 수준을 넘는 메뉴 트리 및 화면을 그려 주는 것이다. 이것은 기획자나 개발자의 창의성을 제한할 가능성이 높다. 반드시 제품팀의 기획자나 개발자에게 요구 사항 정의서가 메뉴나 화면을 정의하는 것이 절대 아니며 이 부분에 대한 판단은 그들의 역할임을 분명히 알려주어야 한다. (물론, 이후 기획서 등에 대해서 PM은 꾸준히 피드백을 전달하고 필요하다면 다양한 근거를 가지고 설득을 해야한다.)

이해를 돕기 위해 아래 필자가 작성했던 유저 관점 흐름도와 그 중 메인 기능으로 그룹핑하여 작성한 요구사항 정의 파트의 예시를 추가하였다. (예시를 추가하는 것은 늘 부담스럽지만 진심으로 도움이 되길 바랄뿐이다.) 예시에서 보면 슬롯 정의와 같이 서비스 운영팀과 결정할 부분은 미리 논의하여 정의를 해 둔다면 기획자와 개발자가 이런 부분에서 쓸데 없는 창의성을 발휘하는 낭비를 줄여줄 수 있다.

PRD 꼭 필요한 것일까?

여전히 누군가는 PRD가 없이도 제품이 성공했거나 별 문제 없이 제품팀이 운영될 수 있다고 생각할 수 있다. 그럴 수도 있다. 모로 가도 서울만 가면 될 수도 있다. 다만 진심으로 제품의 성공을 열망하는 제품 관리자나 스타트업 대표라면 아마도 제품의 성공 확률을 조금이라도 높이고 싶을 것이다. 아래 삽화처럼 정확한 의사 소통은 늘 쉬운 일이 아니었다. 필자의 경험상 제품팀은 언제든지 방향을 잃고 헤메일 수 있고 이때 PRD는 나침반처럼 가야할 길을 가리켜 줄 것이다.