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 수정하느라,

1. 스피드감을 잃어가면서 일하는게 좋지 않다

   a. 이미 골든 타임을 놓친 서비스에서 기획안 작성만 시간 쏟는게 미련해보였습니다.

2. 타인이 재설정한 방향성을 이해하기 어렵다

   b. 내 생각이 아닌 남이 기획한 가설과 데이터 접근법을 소화하기 어려웠고, 때론 납득을 못할 때도 있었습니다.

3. 나혼자만 설정한 metric

   c. 데이터와 one metric 에 대해 모니터링을 하는 것은 프로덕트 디자이너도 보는 사안이지만, 저는 고객 액션의 절댓값(기능 수행 횟수) 를 기준으로 삼았고, 다른 사람을 퍼널 전환율, CTA 를 보고 있어 프로젝트의 성공을 가르는 기준을 다르게 보고 있었던 적이 있었네요.

📍 세션을 들어보니, PRD가 ‘방향성 합의를 담은 문서’ 라고 생각하면 수정에 힘을 쏟고, 합의와 데이터 해석에서 싱크를 맞추는  노력했어야 정답이였네….싶어요.

실수 2 : 앞만 보다가 상위레벨 싱크 놓침

prd 를 제가 바텀업 문화에서만 진행한다고 생각했습니다. squad 의 조직안에서 자율성이 완벽하게 확보된 줄 알았지만... 이건 제 사업이 아니니 당연히 임원진의 컨트롤 범위 안에 있어야 했었어요. 하지만 메이커끼리 동기화도 바쁜데, 가끔 상위 레벨 컨펌을 했어야했는데 제 손에서 미끄러나간 적이 있었네요.

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

1. PRD 는 그럼 탑에 대한 생각만 담는가?

   : 탑에 대한 생각을 담으면서, 유저 인터뷰 & 메이커들끼리의 risk 를 인터뷰하면서 탑의 잘못 생각한 부분을 캐치하고 PRD 를 계속 수정합니다. 미팅(킥오프, 기획안 픽스 미팅, Dev, QA )을 이때 많이 열면서 되도록 같은 테이블에 이해관계자를 부릅니다. 킥오프 미팅은 특히 신경써서 유저 스토리/프로젝트 배경/문제정의 를 최대한 입체적으로 전달하고자 합니다. 그래야 모두가 납득이 되는 상항에서 프로젝트가 착수가 되고, 같은 그림을 그릴 수 있는 여정으로 나아갈 수 있습니다.

2. PRD 문서에 대한 이해도가 아예 다를때, 어떤 문화로 시작해야하는가?

   : PRD 문서가 뭐야? 부터 시작해서 같은 PO 끼리도 이해도가 다른데, 다른 직무끼리 싱크가 맞을 확률은 낮습니다. 하지만 1 pager 혹은 요구사항 정의서는 pm/po 직군이 작성하잖아요? prd 라는게 회사에서 working 하는 문서이니, 이 워딩과 양식에 갇히지 않는 것이 중요합니다. 이때, 필수로 담는 내용 (사용자 스토리, success metric, 배경) 만 구성원들이 잘 납득하는 것을 목적으로 삼는게 중요합니다.

3. 문서에 얼마나 리소스를 붓는가? 빠른 진행에 break 가 걸릴 수도?
   문서를 위한 문서 작성을 하지 말도록 노력합시다. 회바회라 거기에 맞게 고민하는게 중요하겠군요?

그래서 앞으로

✨ 탑과 싱크 미스 났을 때 혼나고, 메이커와 동기화 못해서 욕 먹는 prd 에 갇히지 말고 시행착오와 좌절에서 벗어나는 용기를 갖고자 합니다. 

그리고 prd 는 모든 구성원들간에 프로젝트 why 싱크 용에 가까웠다면  tech spec 문서는 프로젝트의 how 는 어떻게 작성되는지, 본격적으로 기능이 어떻게 동작되는지 정의하는 문서 같은데요. 기술언어로 메이커끼리 어떻게 소통하는지 궁금합니다!

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