안녕하세요? 국내 1위 IT아웃소싱 플랫폼 위시켓입니다.
위시켓은 저번 시간에 이어, 오늘도 PM분들에게 도움이 될만한 꿀팁을 가져왔습니다. 이번에 소개해드릴 글은, Lina L님이 각색한 「구글 프로덕트 매니저가 알려주는 기획서 작성 꿀팁」입니다.
원문 작성자인 Omar Eduardo는 구글의 프로덕트 매니저입니다. 이 글을 통해 WHY 기반의 기획서 형태인 PRD(Product Requirement Document)를 어떻게 써야 할지, 어떻게 활용해야 할지 현업의 경험을 토대로 알려주고 있죠. 이번 글을 통해 위시켓에 IT프로젝트를 의뢰하시는 클라이언트님께도, 프로젝트를 맡게 되신 파트너님께도 매우 유익한 시간이 되시길 바랍니다.
제품 기획 문서(PRD) 작성 및 활용법 A to Z 정리
우리 PM들은 예로부터(?) 기획서라는 이름 하에 수많은 형태의 문서들을 작성해왔습니다. 기능 요구정 의서, 명세서, UX 설계 문서 등등 이름도 다양하고 형태도 다양하죠. PPT나 디자인 툴로 와이어 프레임을 직접 그리기도 하고, 에러 케이스부터 시작해서 세부 개발 요구사항들까지 꼼꼼히 기록하기도 하고요.
PM들이 과연 얼마나 상세하고 많은 분량의 기획을 해야 할지에 대해서는 서비스나 회사 특성, 개발 문화에 따라 달라집니다. 워터폴 방식의 몇 개월짜리 프로젝트라면 몇백 장의 PPT가 될 수 있고, 애자일하게 작은 가설을 테스트하는 팀에서는 한 장으로 충분할 수 있습니다.
소프트웨어 개발은 변동사항이 많고, 우리는 고객에 대해 결코 백프로 이해하고 있지 않습니다. 그 와중에 빠른 테스트가 가능한 애자일 문화가 확산되면서 ‘기획서’는 HOW를 완벽하게 정의한 개발 요건 문서에서 목적, 즉 WHY에 초점을 맞춰 팀이 함께 HOW를 논의할 수 있는 토대로 변화하고 있는 것 같습니다.
프로덕트 매니저가 작성하는 PRD(Product requirement document)는 다음의 핵심 질문에 답변하기 위해 작성됩니다.
- 우리가 이 기획을 왜 해야 하나요? (WHY)
- 이 문제는 어떻게 접근해야 하나요? (HOW)
- 가장 적합한 솔루션은 무엇인가요? (WHAT)
PRD의 중요한 목적은 올바른 제품을 만들고 사용자에게 잘 전달하기 위한 방향으로 팀이 함께 나아가도록 하는 것입니다. 잘만 활용된다면, PRD는 어떤 개발 프로세스를 따르더라도 훌륭한 제품 개발 도구가 될 수 있습니다. 이 글에서는 PRD를 최대한 활용하기 위한 몇 가지 팁을 소개하고자 합니다.
PRD에는 무엇을 작성해야 하나요?
가장 기본적인 형태의 PRD는 다음의 섹션이 포함되어 있는 단순한 문서라고 볼 수 있습니다.
- 요약과 배경(Summary and Background): 문제가 무엇이고, 왜 이것이 중요한가요? 이 기획의 중요성을 강조하기 위한 사업 지표나 유저 리서치 내용 또는 여러 다른 인사이트를 포함시키는 것도 좋습니다.
- 주요 사용자(Target Users): 이 해결책은 누구를 위한 것인가요? 이 유저들은 왜 중요하며, 이들의 불편함을 우선순위를 높여 해결해야 하는 이유는 무엇인가요?
- 핵심 사용자 여정(Critical User Journeys, CUJs): 문제를 해결했을 때 사용자가 얻을 수 있는 것은 무엇인가요? 구체적인 솔루션보다는 사용자 니즈에 집중해서 작성해주세요.
- 기능적 요구사항(Functional requirements): 솔루션의 세부 기획을 작성합니다. PM으로서 기능적 요구사항을 상세히 쓰는 것은 중요하지만, 특정 솔루션을 너무 강요하지는 않도록 합니다.
- 관련 문서(Supporting documents): 솔루션의 세부 인터랙션 디자인이나 기술적 구현에 대해서는 디자이너, 엔지니어와 논의할 텐데요. PRD에 관련 UX 플로우 또는 개발 설계 문서를 추가적으로 연결해 참고할 수 있도록 해주세요.
- 배포 계획(Go-to-market): 해당 기능 출시와 관련된 여러 고려사항과 출시 후 마케팅, 영업, CS 등 고객과 맞닿아있는 조직이 예상하고 있는 바에 대해 작성합니다.
이 내용들은 PRD를 구성하는 가장 기본적인 사항들이지만, 이 외에 수많은 다른 고려사항들도 추가적으로 작성할 수 있습니다. 제가 일했던 팀에서는 PRD 템플릿에 권한 허용, 성능, 데이터 추출, 성공 지표, 플랫폼 간 호환성, 신규 사용자 접근성 등등 여러 다양한 내용이 포함되어 있었습니다. 일단 위에 제시된 기본적인 내용을 먼저 채운 다음, 협업하는 과정에서 나타나는 중요한 이슈들을 다루기 위한 새로운 섹션을 추가해보세요.
PRD를 잘 활용하기 위한 팁
팀원들의 피드백을 초기에 받으세요.
PM들은 종종 피드백을 받기 전의 문서에 너무 많은 시간을 들입니다. 대신 초기부터 적극적으로 피드백을 줄 수 있는 UX 디자이너와 엔지니어를 찾아보세요. 세 가지 주요 질문(왜, 어떻게, 무엇을)에 대한 초안을 작성하고, 바로 공유하세요.
PM으로서 해야 할 가장 첫 번째 일은 이 문제가 왜 중요하며 왜 우선순위를 높여 해결해야 하는지 팀원들에게 분명히 설명하는 것입니다. 하지만 문제에 대한 솔루션은 엔지니어나 UX 디자이너와 협업하는 과정에서 정의되어야 합니다. 초기에 자주 피드백을 받으면 시간을 낭비하지 않을 수 있습니다.
경험적으로 제일 좋은 방법은 처음 세 파트(summary and background, target users, CUJs)를 작성한 다음, 네 번째(functional requirements)로 넘어가기 전에 피드백을 받는 것입니다. 문제나 사용자 여정에 대한 싱크가 안 되어 있는 상태에서 특정 솔루션에 대한 기능적 요구사항을 정해버리면, 모두의 시간을 상당히 낭비하게 될 수 있습니다.
재미있고 읽기 쉬운, 구조화된 형태의 PRD를 만드세요.
좋은 PRD는 동료들이 불필요하게 많은 노력을 기울이며 읽지 않아도 중요한 정보를 적절하게 전달할 수 있어야 합니다. 이를 위해 다음 세 가지를 주의하면서 PRD를 작성해보세요.
- 문제에 집중하기: 너무 뻔한 내용이나 관계없고 필요 없는 세부 내용은 지우고 문제에만 집중하세요. 초기에 피드백을 받아야 하는 중요한 이유는 논점이 될 만한 부분이 어디인지 찾기 위함입니다. 이렇게 찾은 논점을 깊이 파고드는 데 집중해서 팀이 앞으로 나아갈 수 있도록 하세요. 관련이 없고 뻔한 내용인데 단순히 문서 작업을 위해 뭔가 작성하라고 요청받았다면 과감히 부록으로 빼세요.
- 한눈에 쉽게 읽을 수 있도록 구조화하기: 동료들이 어떤 것에 관심 있을지 생각하고 그 내용을 잘 찾을 수 있도록 구조화하세요. 제목과 부제목을 스마트하게 써서 주요 논점이 잘 드러나도록 하세요. 그렇게 하면 여러 팀의 동료들이 중요한 포인트에 빠르게 집중해서 인사이트를 줄 것입니다.
- 와이어프레임이나 도식, 표 활용하기: 글이 너무 많으면 지루해질 수 있습니다. 여러 옵션에 대한 비교를 하거나 전후 차이 설명 또는 데이터 흐름을 보여줄 때, 타임라인에 따른 고려사항을 논의할 때 등 다양한 상황에서 표나 차트, 목업을 활용해보세요. 추가적인 노력이 들 수 있지만, 명료하게 정리된 내용은 큰 이득이 됩니다. 동료들이 PRD의 정보를 쉽게 소화하여 반복적인 질문을 하지 않을 수 있게 될 테니까요.
PRD 기반으로 논의를 이끌어보세요.
만약 PRD가 흥미로운 지점에 초점을 맞추고 있고, 논점을 잘 기술하면서 중요한 솔루션을 다루고 있다면 논의에 불이 붙을 것입니다. 동료들에게 피드백과 코멘트를 남기도록 독려해주세요. 피드백을 리뷰하고 적절히 답변하는 것이 PM의 일입니다.
- 코멘트 확인하고 응답하기: 코멘트에 동의한다면 그렇다고 알려주세요. 동의하지 못한다면 맥락을 설명하고, 놓치거나 잊고 있었던 부분은 없는지 확인하기 위한 질문을 해보세요. 이 과정을 통해 중요한 이슈나 의견 불일치를 파악하고 나아가 기획의 성공률을 높일 수 있습니다.
- 자존심은 잠시 넣어두기: 공들인 기획일수록 누군가가 참견해서 비판적이고 무례하게, 또는 잘 모르는 채 코멘트를 남기면 짜증 날 수 있습니다. 감정적으로 흥분한 상태로 반응하지 말고 차분해진 뒤에 응답하세요. 객관적으로 보면 유용한 내용을 발견할 수도 있습니다.
- 중요하고 복잡한 사항은 미팅에서 논의하기: 주요한 의견 불일치가 있다면 미팅을 잡고 해당 이슈를 다루어보세요. 논의할 주제를 명확히 하고, 꼭 필요한 사람들만 초대하여 집중할 수 있도록 합니다.
- 언제 어떻게 논의를 마무리할지 파악하기: 방향이 정해지고 모든 관계자가 준비되었다면, 방해 요소나 범위·기능(scope/feature)의 변화를 반드시 최소화해야 합니다. 해당 솔루션이 모두의 동의를 받았다는 점을 PRD에 명시하는 것이 중요합니다. 저는 문서에 더 이상 적극적인 피드백을 받지는 않는다는 의미로 ‘Status: Final’이라고 남깁니다. 모든 새로운 코멘트나 제안에 대해서는 당사자에게 해당 피드백이 고려되었으나 왜 반영되지 않았는지 알려주세요. 친절하고 사려 깊게 답변하되 혼란을 줄이기 위해서는 분명히 해야 합니다.
계속 반복하고 학습하세요!
저는 지난 6년 동안 수십 개의 PRD를 작성했고, 매번 목적이나 팀 구성에 따라 PRD의 내용은 조금씩 달라졌습니다. 최종 결과물을 봤을 때 똑같은 PRD는 하나도 없었습니다. 하지만, 마지막 단계까지의 작성 과정은 유사했습니다. (초안을 쓰고 → 팀원들에게 피드백을 받고 → 디자이너, 엔지니어와 협력해서 최종 솔루션을 찾고 → 미팅에서 골치 아픈 이슈들을 해결하고 → 최종적으로 마무리 짓기)
완결된 PRD는 최종적으로 적용된 솔루션뿐 아니라, 팀이 해당 솔루션에 도달하기까지의 전 여정을 담고 있습니다. 최종 목적에 도달하기까지의 여러 우여곡절을 담은 PRD는 학습과 개선을 위한 최고의 자산이 되어줄 것입니다.
원문: 위시켓 블로그
이 필자의 다른 글 보기
