PRD 작성법을 검색해 보면 깔끔한 템플릿이 끝없이 나옵니다. 그런데 막상 빈 문서를 열면, 막히는 건 양식이 아니라 첫 칸입니다. 무엇부터 채워야 할까요. 많은 분이 곧장 기능부터 적기 시작합니다. 화면 목록, 버튼 동작, 예외 처리. 먼저 결론부터 말씀드리겠습니다. 좋은 PRD는 기능 목록이 아니라, 풀려는 문제와 그것이 사용자에게 가져올 결과를 먼저 적는 문서입니다. 기능은 맨 마지막에 옵니다. PRD의 진짜 목적은 만들 것을 명세하는 게 아니라, 우리가 왜 이걸 만드는지를 팀 전체가 같은 그림으로 보게 만드는 데 있기 때문입니다.
PRD 작성법을 찾기 전에, 먼저 던져야 할 질문
불편한 숫자 하나로 시작해보겠습니다. 프로덕트 분석 기업 펜도가 2019년 사용 데이터를 집계한 결과, 소프트웨어 기능의 약 80%가 거의 또는 전혀 쓰이지 않았습니다. 일일 사용량의 80%를 만들어내는 건 전체 기능의 12%뿐이었죠. 더 오래된 스탠디시 그룹의 조사에서도 기능의 45%는 한 번도 쓰이지 않고, 19%는 거의 쓰이지 않았습니다. 우리가 밤새 스펙을 쓰고 만들어 출시한 기능의 절반 이상을, 사용자는 열어보지도 않는다는 뜻입니다.
왜 이런 일이 반복될까요. 저는 그 출발점에 PRD가 있다고 생각합니다. 많은 PRD가 “만들 기능의 목록”에서 시작합니다. 그러면 팀은 무엇을 만들지에는 합의하지만, 왜 만드는지에는 합의하지 못한 채 개발에 들어갑니다. “왜”가 빠진 문서는 만드는 동안 길을 잃습니다. 정작 풀려던 문제가 무엇이었는지 아무도 다시 묻지 않게 되죠. 관점을 한번 바꿔보겠습니다. PRD는 채워야 할 양식이 아니라, 팀이 같은 곳을 보게 만드는 합의의 도구입니다.
기능에서 시작하면 안 되는 이유
프로덕트 사상가 마티 케이건은 좋은 팀과 그렇지 못한 팀을 가르는 기준으로 아웃풋과 아웃컴의 구분을 듭니다. 아웃풋은 우리가 만든 기능이고, 아웃컴은 그 기능이 사용자와 비즈니스에 만들어낸 변화입니다. 기능 목록으로 채운 PRD는 아웃풋의 약속일 뿐, 아웃컴에 대해서는 아무 말도 하지 않습니다. 만들었다는 사실이 곧 문제를 풀었다는 뜻은 아닌데도요.
그래서 저는 아마존의 방식을 좋아합니다. 아마존은 신제품을 기획할 때 코드 한 줄, 예산 한 푼 정하기 전에 보도자료부터 씁니다. 제품이 이미 출시됐다고 가정하고, 고객이 이 제품으로 무엇이 좋아졌는지를 고객의 언어로 먼저 적는 것이죠. 여기에 예상 질문과 답을 덧붙인 문서를 PR/FAQ라고 부릅니다. 핵심은 순서입니다. 고객이 얻을 결과를 먼저 정의하고, 거기서 거꾸로 걸어 들어와 “그러려면 무엇을 만들어야 하는가”를 마지막에 도출합니다. 만들 것에 정이 들기 전에 풀 문제를 못 박아두는 겁니다.
테레사 토레스의 기회-솔루션 트리도 같은 방향을 가리킵니다. 가장 위에 원하는 결과가 있고, 그 아래에 사용자의 기회, 즉 충족되지 않은 니즈가 놓이며, 구체적인 솔루션은 가장 끝의 가지입니다. 기능은 나무의 뿌리가 아니라 잎입니다. 잎부터 그리기 시작하면 줄기가 없는 제품이 됩니다.
PRD 한 장을 쓰는 순서
그러면 실제로 무엇부터 채울까요. 같이 한 단계씩 풀어보겠습니다. 흔한 순서와 거꾸로 쓰는 순서를 먼저 비교해보죠.
| 기능에서 시작하는 PRD | 결과에서 시작하는 PRD |
|---|---|
| 만들 화면·기능 목록 | 누구의 어떤 문제인가 |
| 각 기능의 상세 동작 | 성공하면 무엇이 달라지는가 (측정 지표) |
| 예외 처리·화면 흐름 | 그 결과를 만들 가설로서의 해결책 |
| 일정과 리소스 | 모르는 것, 안 할 것, 리스크 |
순서를 뒤집으면 PRD는 다섯 단계로 정리됩니다.
1단계, 문제와 사용자부터 적습니다. 누가, 어떤 상황에서, 무엇이 막혀 있는지를 한 문단으로 씁니다. 기능이 아니라 사람과 상황에서 출발하세요. “이 화면이 필요하다”가 아니라 “이 사용자가 이 순간에 이걸 못 해서 떠난다”로요. 다만 그 막히는 순간은 책상에서 상상해 채우면 안 됩니다. 사용자에게 직접 물어 확인해야 하는데, 이때 의견을 묻는 대신 과거의 구체적 행동을 물어야 답이 오염되지 않습니다. 그 방법은 유저 인터뷰, 물어볼수록 틀린 답을 얻는 이유에서 따로 풀었습니다.
2단계, 성공의 모습을 먼저 그립니다. 이 제품이 잘됐을 때 사용자에게 무엇이 달라지는지를 보도자료 한 문장처럼 적고, 그것을 어떻게 측정할지 지표를 함께 답니다. 측정할 수 없는 결과는 합의되지 않은 결과입니다. 다만 이때 매출이나 가입자 수 같은 후행 지표를 고르면 곤란한데, 그 이유는 노스스타 지표를 매출로 잡으면 안 된다에서 따로 다뤘습니다.
3단계, 맥락과 경계를 정합니다. 왜 지금 이 문제인지, 그리고 무엇을 안 할지를 명시합니다. 비범위를 적는 칸은 PRD에서 가장 과소평가된 자리입니다. 안 할 것을 정해야 할 것이 또렷해집니다.
4단계, 해결책은 가설로 적습니다. 이제야 기능이 등장합니다. 단 “확정된 명세”가 아니라 “이 문제를 푸는 하나의 방법”으로, 가능하면 대안 한두 개와 함께 적습니다. 기능은 정답이 아니라 검증할 베팅입니다.
5단계, 모르는 것을 남겨둡니다. 열린 질문과 리스크를 FAQ처럼 적습니다. 좋은 PRD는 모든 답을 가진 문서가 아니라, 무엇을 아직 모르는지 솔직하게 드러내는 문서입니다.
덧붙이자면, 에이전트나 AI 기능을 다루는 PRD라면 여기에 권한 경계와 실패 모드, 비용 상한 같은 축이 더 필요합니다. 다만 그 경우에도 출발점은 같습니다. 기능이 아니라 문제와 결과에서 시작한다는 원칙은 변하지 않습니다.
실제로, 기능 정의서부터 썼던 날들
솔직한 회고를 하나 하겠습니다. 예전에 한 숙박 서비스의 모바일 주문 앱을 0에서 기획할 때, 저희 팀은 가장 먼저 기능 정의서를 펼쳤습니다. 화면을 그리고, 버튼을 정하고, 예외를 채웠죠. 당시에는 그게 가장 성실한 일이라 믿었습니다. 그런데 출시 후 데이터를 열어보니, 공들여 만든 부가 기능들의 사용률은 바닥이었고 정작 고객은 단 하나의 흐름, 빠르게 주문하고 끝내는 경로만 반복해서 썼습니다.
다음 프로젝트에서는 순서를 바꿔봤습니다. 화면을 그리기 전에 “고객이 이 앱을 열어 30초 안에 끝내려는 일이 무엇인가”라는 결과부터 한 문장으로 적고 거꾸로 내려왔습니다. 그러자 처음 계획했던 기능의 절반가량이 자연스럽게 빠졌습니다. 만들 것이 줄었는데 핵심 지표는 더 좋아졌습니다. 그때 깨달았습니다. PRD에서 기능을 더하는 일보다 어려운 건, 결과를 먼저 정의하고 나머지를 덜어내는 일이라는 걸요.
결론
PRD는 만들 것을 적어두는 문서처럼 보이지만, 사실은 왜 만드는지를 팀이 함께 바라보게 하는 지도입니다. 그러니 다음에 빈 PRD 문서를 열면, 기능 목록부터 채우려는 손을 잠깐 멈춰보세요. 그리고 첫 줄에 이렇게 적어보는 작은 실험을 제안합니다. “이게 잘되면, 사용자에게 무엇이 달라지는가.” 그 한 문장에서 거꾸로 걸어 들어오면, 기능은 알아서 제자리를 찾아갑니다. 좋은 제품은 많이 만든 팀이 아니라, 왜 만드는지를 끝까지 잊지 않은 팀에서 나옵니다.
참고 자료
- Marty Cagan, 『인스파이어드』 (Inspired, 2017) — 아웃풋과 아웃컴, 프로덕트 디스커버리
- Colin Bryar & Bill Carr, 『Working Backwards』 (2021) — 아마존 PR/FAQ와 거꾸로 일하기
- Teresa Torres, 『Continuous Discovery Habits』 (2021) — 기회-솔루션 트리
- Pendo, “The 2019 Feature Adoption Report” — 기능의 약 80%가 거의·전혀 사용되지 않음
- The Standish Group, “CHAOS Report” — 기능의 45% 미사용, 19% 거의 미사용
