260410 TIL

·2026년 4월 10일

🏃TIL

목록 보기
37/47
post-thumbnail

팀 아티클 카타

참고 아티클
https://yozm.wishket.com/magazine/detail/2826/

1. 아티클 정보

  • 제목 : 모두가 알지만 누구도 제대로 쓰지 못하는, PRD
  • 작성자(저자) :

2. 핵심 내용 요약

  • 이 아티클의 주요 메시지 PRD는 제품 개발 프로세스의 시작점이자 기본. 많은 조직이 이를 무시하거나 제대로 쓰지 못하고 있는데, 요구사항이 명확하게 정의된 ‘제대로 된 PRD’는 PM의 역량이며 제품과 함께 완성되어야 한다. 이는 PM의 성장과도 직결되어 있다
  • 핵심 키워드 : prd 불확실성 해소 명확한 요구사항 페르소나 여정

3. 흥미로운 점/새롭게 알게 된 점

  • 읽으면서 가장 흥미로웠던 부분 : 불과 2년 전 글인데도 이 때는 PRD에 대한 실무적 인식이 매우 빈약했다는 사실이 흥미롭다. PRD가 개발 스프린트 중간에 바뀌는 것은 당연한 과정이다. 과정에서 마주치는 불분명한 부분을 규정하고 불확실성을 해소해나가는 과정일 뿐이다. MRD와 PRD모두 제품의 완성과 함께 완성되어야 한다. PRD를 100% 완성하는 것은 팀과 함께 ! PM은 목적을 위해 꾸준히 “글”로 제품을 개발해야 하는 사람이다. PRD의 목적은 문서를 작성한 사람과 읽는 사람 간 비주얼라이제이션 싱크를 갖는 것. 이 큰 목적을 잊고 작성하면 안된다 !
  • 이전에는 알지 못했거나 새롭게 배운 내용 : 입문 과제에서도, 지금 숙련 과제에서도 (심지어 페르소나가 주어져있는데도 !) 페르소나의 여정이나 디테일한 시나리오를 이만큼이나 고려해보겠다는 생각은 하지 않았었는데 생각이 바뀌었다. 어떤 사용자가 어떤 요구사항을 가지고 있는지를 정의하려면 당연히 페르소나의 상세한 시나리오가 기반이 되어야할 것이다. 우리 제품이 어느 고객군을 첫번째 고객으로 접근할 것인가가 서비스의 방향성을 결정한다. 메인 시나리오 안에서 자신의 삶을 살아가는 페르소나를 설정하면, 제품의 정책을 결정하는 시점에서 결정의 관점을 제공해줄 수 있다. 그 정도로 상세하고 디테일하게 인물을 ‘창조’해야한다. +) 보고서는 간결해야하는데, 디테일한 페르소나의 시나리오는 간결함에 위배되는 행위는 아닐까? 특히 아티클 내에 예시로 들어있는 페르소나 정의나 메인 시나리오 자체는 내가 튜터님이라면 이걸 누가 다 읽냐고 하실 것 같은 느낌적인 느낌 … 정답이란건 없는거지만 기준선은 어디쯤일지 고민해봐야할 것 같다 유저저니 맵에서 발견한 인사이트는 어떻게 PRD로 번역될 수 있나
    유저 저니 맵은 브레인 스토밍 단계로 놔두고 거기서 도출한 결론단만 작성을 해야하는건지, 유저 저니 맵도 포함시켜서 작성을 하는 게 맞는 건지 … 내가 발견한 유저의 맥락을 어떻게 텍스트인 요구사항과 예외 케이스 정책 등으로 고정시킬 수 있을까 실제 실무에서도 PRD를 스킵해도 되지 않냐는 팀을 만난다면 어떻게 설득할 수 있나? ~….

4. 나의 한 문장 요약

  • 이 아티클을 한 문장으로 요약하면? 진짜 문제를 해결하기 위한 PRD부터 탄탄하게 작성하는 것이 가장 빠르고 정확한 문제 해결을 위한 지름길이다.

팀 논의 요약

  1. PRD는 제품이 기능하여 요구사항을 충족하는 형상을 제품개발팀과 공유하는 것이므로
    PRD를 명확하게 작성하여 팀원들과 비주얼라이제이션 싱크를 해야 한다.
  2. 매출 증가, 트래픽 증가 등의 거대한 목표를 작성하는 것이 아닌 제품의 요구사항을 정의하는 문서이다.
  3. 요구사항이 명확하게 정의된 PRD는 PM의 역량이고 제품과 함께 완성되어야 한다.
  4. PRD 초반에는 PM이 초안을 30% 이후 제품 개발에 참여하는 모두가 함께 작성하는 것이다.

팀 공통 인사이트 or 느낀 점 요약

  1. 페르소나에 대한 메인 시나리오까지 구체적으로 작성해보며, 우리 제품을 마주하는 첫 번째 고객이라고 가정하고 접근한다.
  2. PRD를 완성하고 개발을 진행하는 것이 아닌 개발 과정에서 PRD를 채워 나아간다.

튜터님의 피드백

  • PRD를 활용하는 곳도 있지만 안 쓰는 곳도 있어서 조직마다 굉장히 다르다.
  • 어떤 문서든 완벽한 문서를 들고 간다는 개념보다는 기획자가 채울 수 있는 부분을 채우고 이해관계자들과 논의를 거쳐 채워나가야 하는 것이다. (물론 작성하는 것 자체는 PM의 역할)

질문

보고서는 간결해야하는데, 디테일한 페르소나의 시나리오는 간결함에 위배되는 행위는 아닐까?

💡
페르소나의 목적

  • 기획자의 문제정의
  • 메이커에게 타깃 전달

최종 정제 버전을 PRD에 담는다고 생각하자. 목적을 상기하며 !

prd 안에 링크형태로 담거나, 별도 문서로 빼는 경우도 있음

유저저니 맵에서 발견한 인사이트는 어떻게 PRD로 번역될 수 있나? 유저 저니 맵은 브레인 스토밍 단계로 놔두고 거기서 도출한 결론단만 작성을 해야하는건지, 유저 저니 맵도 포함시켜서 작성을 하는 게 맞는 건지 고민

💡
우리 서비스가 없는 상태에서 사용자가 어떻게 문제를 해결했나? 어떤 문제를 맞닥뜨렸나?를 찾아내기 위해서 하는 것이 유저저니맵. 문제정의에 대한 것 : 근거로써 활용

PRD는 솔루션에 대한 것! 우리는 어떤 대안을 만들어야하는가

사용자의 문제 → 대안에 대한 구체적인 스펙을 적는 문서

실제 실무에서도 PRD를 스킵해도 되지 않냐는 팀을 만난다면 어떻게 설득할 수 있나?

💡
PRD를 통해 딴소리하는 시간을 줄이기 위해서 작성하는 거다 (ㅋㅋ) … 커뮤니케이션 비용을 낮추기 위해서 ! 의사결정을 문서 토대로 할 수 있게 만드는 문서. 각자의 역할에 집중할 수 있도록 미리 정리해둔 가이드라인


수요일에 진행했던 아티클 카타 <북극성 지표> 에 대해서도 피드백을 받았다.

피드백

북극성 지표는 조직마다 설정 여부가 다르다

조직마다 프로덕트를 개발하는 프로세스가 다르다
→ 전사적인 비즈니스 목표를 중시하는 경우도 있기 때문

북극성 지표를 전사적으론 사용하지 않더라도 제품 차원에서 전략을 수립할 때 비전을 같이 고민하면서 설정하기도 함

논의된 내용 중 ‘매출’ 이라는 지표는 결과물로 확인해야하는거라 했는데 PM입장에서는 비즈니스, 유저, 기술적 구현 가능성을 같이 고민해야 함

매출이라는 지표는 중요하긴 하지만 그것만 쫓게 되면 사용자의 불편함을 야기시키는 전략을 선택해버릴 수도 있다.

그 전략이 사용자의 이탈을 유발하면 매출에도 악영향을 미치게 되므로, 그런 걸 다 고려해서 의사결정을 해야함

가드레일 지표에 대해선 정리가 잘 되어있음

실무에서 북극성 지표를 활용할 때, 체리피커같은 부작용이 생길수도 있어서 가드레일 지표를 함께 살펴봐야함

지속적 개선에 대해 잘 짚어냈다

0to1이라는 초기 단계에서는 어쩔 수 없이 리텐션이 북극성 지표로 채택될 가능성이 높음

고도화될수록 다른 지표에 대한 중요성이 커져 재설정하게 된다

질문

매출이 기준이 아니라면, 매출이 잘나오면서 서비스가 망가지는 케이스도 있을 수 있겠다. 반대로 고객 가치는 확실한데, 매출이 안나오는 경우는 어떻게 봐야하는가?

💡 대부분의 초기 제품들은 고객가치가 확실한데 매출이 안나온다. 설득을 통한 투자를 받고 조직의 힘을 키워나가면서 수익성을 개선하는 방향을 모색하는 것

지금 당장 돈을 못 벌기 때문에 가치를 가지고 투자를 받는 것 !
고객가치가 확실한 것이 첫번째로 가장 중요한 것. 매출을 만들 수 있는 방법은 다양하다.

뭔가 단기적으로 뻥튀기가 가능한 (마케팅 / 세일즈로) 지표는 본질적인 핵심지표로 설정할 수 없다. 그렇다면 이 ‘뻥튀기’가 가능한 후행지표는 어떤 의미를 가지고 있는가? 마케팅과 세일즈의 노력으로 단기적으로 올리는 지표를 통해 어떤 인사이트를 도출할 수 있는가.

💡 ‘허상지표’ 허울을 좇는 지표

활용수단 :

  • 마케팅 효율을 측정하거나 (유입 지표 등) 캠페인 기간 중 일간, 주간 단위로 일별 이용자 수 등을 분석하는 것 (코호트 분석) 등을 통해서 어떻게 사용자가 우리 서비스를 인지하고 어떤 포지셔닝을 가져갈 수 있을지 점검이 가능
  • 광고 타겟을 제대로 설계했는지, 온보딩 프로세스에서 이탈을 야기하는 문제는 없는지 확인이 가능
  • 우리 회사를 PR하는 수단으로 활용할 수도 있음

서비스 기획 숙련 과제

네 저 했어요 다 엎어버렸어요 !!!!!
문서의 전체 방향성이나 흐름에 대한 고민을 진지하게 하지 않고 냅다 데이터부터 판 탓에 데이터 기준을 수정하니까 전체를 전부 ~~~ 엎어야 되는 사태 발생 !!!

그래도 어떡해 해야지 ....

이번에는 전체 문서화의 흐름을 생각하며 다시 제로부터 시작했다 ...

데이터를 기반으로 페르소나 추출을 다시 했는데 몇 가지 놓쳤던 사실을 얻을 수 있었다.

  1. 고가 유저는 장바구니 전환율이 제일 높지만, 구매 전환율이 0이다. 0. (체류시간 120초 이상 기준)
  2. 저가 속전 속결 유저는 가장 큰 규모의 집단이다
  3. 저가 속전 속결 유저는 장바구니 전환율은 가장 낮지만, 구매 전환율은 가장 높다

이외에도 많았지만 이 세가지가 가장 유의미한 해석이었고, 현재 과제의 목표는 '상세페이지에서 장바구니 전환율을 높이는 것'이다.

근데 전체 서비스 흐름을 파악하기 위해 전체 서비스에 대한 분석도 진행한 결과, 전체 세션의 장바구니 담기 전환율은 30.7% -> 구매 전환율은 29.9%였다.

아하모먼트
내가 전체 서비스 흐름 분석을 하지 않고 바로 페르소나 별 데이터 분석부터 시작한 바람에 전체 서비스에서 각 페르소나가 의미하는 바가 무엇인지를 놓쳐서 방향성을 잃었었구나

전체적으로 장바구니 담기 전환율 -> 구매 전환율이 높은 것은 페르소나 b의 영향력이다. (가장 높은 지표, 가장 많은 인원수)

그런데 역설적으로 장바구니 담기 전환율이 가장 낮다?
담기만 하면 구매 전환율은 가장 오르는 집단이?

찾았다 내 페르소나 .....
구매 의사가 강력한 집단의 전환율을 상승시키자 !

궁극적으로 장바구니 전환율을 상승시킨다는 것은 전체 서비스의 장바구니 -> 구매 전환율의 흐름에 따르면 구매로의 유도를 하는 중간 단계의 목표라고 생각이 들었다.

그래서 목표 정의를

구매 의사가 검증된 핵심 유저의 장바구니 전환율을 상승시켜 서비스 전체 매출을 상승시킨다

로 잡고, 왜 이 페르소나의 장바구니 전환율을 상승시키는 것이 서비스 전체 매출을 상승시키는 것인지에 대한 근거를 확립했다.

갈피를 잡기 시작해 조금씩 써내려가며, 지난 과제에서 피드백 받았던 두괄식, 논문이 아닌 보고서 형식의 '읽는 사람 입장'을 생각해 글을 쓰려고 노력했다.

그러기 위해서 우선 깔끔한 두괄식 목차 정렬을 완성하고, 안에 들어갈 내용을 핵심만 간추렸다.

내 글을 읽는 사람은 바쁜 사람이다.. 바쁜 사람이다 ...
염불을 외우며 ..

방향성을 잡고, 세부 데이터 분석을 마저 진행했다.


데이터끼리의 관계성을 통해 얻은 인사이트로 더욱 확실하게 페르소나 선정에 대한 근거를 얻을 수 있었다.


여기까지 꽤 ~ 나 오래 걸렸다
아마 다음주에 시작했으면 생각보다 조급해서 이렇게까지 도출을 하긴 어려웠을지도 ??

타깃 페르소나를 확정한 이후, 페르소나 b에 대한 심층 분석을 진행했다.



좀 더 손 보긴 해야겠지만, 들어가야하는 핵심내용은 이정도로 간추려보았다.

이번 과제에서 내가 제일 집중해야 할 것은 논리와 문서화!
데이터가 주어진만큼 데이터 내에서 논리적인 접근을 통해 근거를 뽑아내려고 노력 중이다 ~.~

드디어 주말이 온다
주말아 내게로 ......

다음주엔 핵심 문제 정의 및 가설 수립까지 달려보자
야르

profile
내일배움캠프 PM 6기

2개의 댓글

comment-user-thumbnail
2026년 4월 10일

이번 과제 피드백 받으면서 느낀 건데, 보고서를 간결하게 유지하는 것과 구체적인 설명을 제시하는 게 서로 상충하는 게 아니더라구요? 글이 길어도 말하고자 하는 바가 명확하게 드러나면 좋은 보고서가 되는 거 같아요. 만약 그 페르소나 시나리오도 문제 상황을 설명하는데 꼭 필요한 내용이라면 보고서에 포함시켜야 하는 것 아닐까요.. (사실 그 판단이 제일 어려움;;;)

1개의 답글