AI PRD 검토 및 개선(AI PRD Review & Improvement)

아무도 원하지 않는 기능을 출시한 PRD

그로스 단계 스타트업의 친구에게서 들은 실화입니다. 그녀가 14페이지짜리 PRD를 썼습니다. 3라운드의 검토를 거쳤습니다. 엔지니어링이 견적을 내고, 디자인이 목업을 만들고, 팀이 두 스프린트에 걸쳐 만들었습니다. 6주 후 채택률 0.3%로 기능이 출시됐습니다.

돌이켜보면 PRD에는 모든 올바른 섹션이 있었습니다. 문제 정의, 사용자 페르소나, 요구사항, 성공 지표. 하지만 빠진 게 있었습니다 — 1페이지에 묘사된 문제를 사용자가 실제로 가지고 있다는 핵심 가정을 아무도 검증하지 않았던 거죠. PRD는 구조적으로 완전했고 전략적으로 공허했습니다.

왜 PRD 검토가 모두의 사각지대인가

Marty Cagan은 수년간 이렇게 말해왔습니다: 가장 큰 리스크는 그것을 잘못 만드는 것이 아니라, 잘못된 것을 만드는 것이라고. 그러나 대부분의 PRD 검토 프로세스는 거의 전적으로 전자에 초점 맞춥니다. 명확한 요구사항, 엣지 케이스, 기술 실현 가능성을 점검하죠. 문제가 실재하는지, 타깃 사용자가 올바르게 정의됐는지, 기능이 완벽히 작동했을 때 성공 지표가 실제로 움직일지를 압박 테스트하는 경우는 드뭅니다.

Pendo의 2024 State of Product Leadership 보고서에 따르면 기능의 80%가 거의 또는 전혀 사용되지 않습니다. 제품 팀이 만드는 것 10개 중 8개가 사용자에게 의미가 없습니다. 그건 엔지니어링 문제가 아닙니다 — PRD 문제입니다. 결정이 업스트림에서 잘못됐고, 검토 프로세스가 그것을 잡아내지 못한 거죠.

두 번째 실패 모드는 유연성으로 위장한 모호함입니다. "경험이 직관적이어야 한다"나 "로딩이 빨라야 한다" 같은 요구사항은 모두가 끄덕여서 검토를 통과합니다. 그러고 나면 엔지니어링은 "빠른"을 2초로 해석하고 PM은 200밀리초를 의미했고, 그 격차는 QA 단계에서야 발견됩니다.

이 프롬프트의 도움 방식

이 프롬프트는 PRD에 대한 스태프 PM 검토자 역할을 합니다. 여덟 차원에서 평가합니다: 문제 명확성, 사용자 정의, 성공 지표 품질, 요구사항 구체성, 엣지 케이스 커버리지, 기술 실현 가능성 신호, 스코프 통제, 이해관계자 정렬. 각 차원이 점수와 구체적 피드백을 받습니다.

진짜 송곳니는 후속 질문에 있습니다. "성공 지표가 약합니다"라고만 말하는 대신, "이 기능이 설계대로 정확히 작동한다면 어떤 구체적 숫자가 바뀝니까? 얼마나? 어느 기간에? 그 답을 못한다면, 그 지표는 지표가 아니라 — 희망입니다"라고 묻습니다.

언제 손을 뻗을까

• 빌드 시간을 낭비하는 격차를 잡기 위해 엔지니어링과 공유 전 PRD 검토
• 며칠간 문서를 들여다봐서 신선하고 비판적인 눈이 필요할 때
• 공식 검토 프로세스에 PRD 제출 전 자기 검토 체크리스트로
• 신규 PM이고 자신의 PRD 품질을 높은 기준에 캘리브레이션하고 싶을 때
• 기능이 부진한 후 다음번에 점검할 것을 배우기 위해 PRD를 사후 감사하고 싶을 때

좋은 모습

강한 출력은 정직한 점수가 있는 스코어카드를 전달합니다 — 모든 게 5/5는 아닙니다. 가장 가치 있는 피드백은 거기 있는 것이 무엇이 잘못됐는지가 아니라 무엇이 빠졌는지를 식별합니다. 강한 검토는 암묵적 가정을 표시합니다 ("사용자가 이미 X 개념을 이해한다고 가정하고 있는데 — 그게 검증됐나요?") 그리고 모호한 요구사항에 대한 구체적 재작성을 제안합니다. 목표는 엔지니어가 읽고 명확화 질문 없이 바로 만들기 시작할 수 있는 PRD입니다.

참고 자료

• Inspired: How to Create Tech Products Customers Love — Marty Cagan / SVPG
• State of Product Leadership 2024 — Pendo
• The PRD is Dead, Long Live the PRD — Lenny's Newsletter