PRD 그것은 무엇인가? PRD 의 모든 것 | 요구사항 정의서

 

PRD 세션에 참여하면서 얻은 인사이트를 정리해봤습니다.

세상에는 별 PRD 양식이 다 있더군요? 각 문서다 공통사항을 뽑으려 분석을 해보았습니다.

가장 좋은 건 kevinyien 양식입니다. 문서의 가독성 뿐 아니라, operational checklist / non-goal 의 개념을 세움으로써 모든 이해관계자들과 얼라인을 맞추려는게 좋았거든요.

 

[FYI]:https://docs.google.com/document/d/1B3GEUwgEIIQVgRp85l4DKLZOTzgGZmBIAjR06p4wuwY/edit#heading=h.e7u3ckqtru68 

[관련 아티클]

https://brunch.co.kr/@3035aa2574484ce/36?utm_source=oneoneone

[kevinyein PRD]

https://docs.google.com/document/d/1mEMDcHmtQ6twzNlpvF-9maNlAcezpWDtCnyIqWkODZs/edit#heading=h.7ueoyja6ijay

 

 

---

 

 

 

 

실무에서 상하좌우 레벨에서 중재자 역할을 하다가 제가 겪었던 시행착오가 떠오르네요.

PRD 세션을 들으면서 시행착오 및 개선해야할 부분을 정리해봤어요.

 

1. 메이커끼리 동기화하면서 업데이트 하지 못한 점

 

나름대로 양식에 맞춰서 success metric 과 가설 및 문제 정의를 해간적이 있었는데요. 메이커가 방향성 재설정 회의를 요청한 적이 있었습니다. 그때는 PRD 를 업데이트하기보다 최초 설정한 문서로 릴리즈하는게 좋다고 생각해 수정에 대해 부정적이였습니다.

 

왜냐면 PRD 수정하느라,

• 스피드감을 잃어가면서 일하는게 좋지 않다
  • 이미 골든 타임을 놓친 서비스에서 기획안 작성만 시간 쏟는게 미련해보였습니다.
  • 타인이 재설정한 방향성을 이해하기 어렵다
• 내 생각이 아닌 남이 기획한 가설과 데이터 접근법을 소화하기 어려웠고, 때론 납득을 못할 때도 있었습니다.
  • 나혼자만 설정한 metric
  • 데이터와 one metric 에 대해 모니터링을 하는 것은 프로덕트 디자이너도 보는 사안이지만, 저는 고객 액션의 절댓값(기능 수행 횟수) 를 기준으로 삼았고, 다른 사람을 퍼널 전환율, CTA 를 보고 있어 프로젝트의 성공을 가르는 기준을 다르게 보고 있었던 적이 있었네요.

 

📍 세션을 들어보니, PRD가 ‘방향성 합의를 담은 문서’ 라고 생각하면 수정에 힘을 쏟고,

합의와 데이터 해석에서 싱크를 맞추는  노력했어야 정답이였던 것 같습니다. 

 

 

---

 

 

2. 앞만 보다가 상위레벨 싱크 놓침

 

prd 를 제가 바텀업 문화에서만 진행한다고 생각했습니다.

squad 의 조직안에서 자율성이 완벽하게 확보된 줄 알았지만...

이건 제 사업이 아니니 당연히 임원진의 컨트롤 범위 안에 있어야 했었어요.

하지만 메이커끼리 동기화도 바쁜데, 가끔 상위 레벨 컨펌을 했어야했는데 제 손에서 미끄러나간 적이 있었네요.

 

그럼 고민이 되는 포인트는 아래와 같습니다.

 

1. PRD 는 그럼 탑에 대한 생각만 담는가?
2. : 탑에 대한 생각을 담으면서, 유저 인터뷰 & 메이커들끼리의 risk 를 인터뷰하면서 탑의 잘못 생각한 부분을 캐치하고 PRD 를 계속 수정합니다. 미팅(킥오프, 기획안 픽스 미팅, Dev, QA )을 이때 많이 열면서 되도록 같은 테이블에 이해관계자를 부릅니다. 킥오프 미팅은 특히 신경써서 유저 스토리/프로젝트 배경/문제정의 를 최대한 입체적으로 전달하고자 합니다. 그래야 모두가 납득이 되는 상항에서 프로젝트가 착수가 되고, 같은 그림을 그릴 수 있는 여정으로 나아갈 수 있습니다.
3. PRD 문서에 대한 이해도가 아예 다를때, 어떤 문화로 시작해야하는가?
   • PRD 문서가 뭐야? 부터 시작해서 같은 PO 끼리도 이해도가 다른데, 다른 직무끼리 싱크가 맞을 확률은 낮습니다.
   • 하지만 1 pager 혹은 요구사항 정의서는 pm/po 직군이 작성하잖아요? prd 라는게 회사에서 working 하는 문서이니, 이 워딩과 양식에 갇히지 않는 것이 중요합니다. 이때, 필수로 담는 내용 (사용자 스토리, success metric, 배경) 만 구성원들이 잘 납득하는 것을 목적으로 삼는게 중요합니다.
4. 문서에 얼마나 리소스를 붓는가? 빠른 진행에 break 가 걸릴 수도?
   문서를 위한 문서 작성을 하지 말도록 노력합시다. 회바회라 거기에 맞게 고민하는게 중요하겠군요?

 

 

---

 

 

 

 

그래서 앞으로

 

✨ 탑과 싱크 미스 났을 때 혼나고, 메이커와 동기화 못해서 욕 먹는 prd 에 갇히지 말고,

시행착오와 좌절에서 벗어나는 용기를 갖고자 합니다. 

 

그리고 prd 는 모든 구성원들간에 프로젝트 why에 대한 싱크용에 가까웠다면  

tech spec 문서는 프로젝트의 how 는 어떻게 작성되는지, 본격적으로 기능이 어떻게 동작되는지 정의하는 문서 같은데요. 기술언어로 메이커끼리 어떻게 소통하는지 궁금합니다!

 

다음 세션이 너무 기대되는군요?

kevinyien: PRD Template