
할 수 있는 만우절 장난이 고작 이거라니
| 시간 | 학습내용 | 소요시간 | 메모 |
|---|---|---|---|
| 아침 | 아티클 카타 | ||
| 점심 전 | 문제 원인 분석 및 정의 | ||
| Arvo | 문제 원인 분석 및 정의 + 문서화 | ||
| Evening | 문제 원인 분석 및 정의 + 문서화 |
문제 원인 분석 및 정의 + 문서화
문제 원인 분석 및 정의 + 문서화
문제 원인 분석 및 정의 + 문서화
문제 원인 분석 및 정의 + 문서화
.....
PRD 작성 시 PM의 목적: 팀의 방향을 맞추고 공감대를 형성하는 것
PRD에는 정답이 없다 (심지어 필요 없다면 안 써도 됨)
PM은 정답을 찾는 사람이 아니다. 의사 결정을 위한 합의와 조율을 빠르게 이끌어내는 사람!
메이커들의 동기 부여와 창의성을 제한하지 않도록 주의하자
지양할 점(no-goal)도 문서에 포함시킨다. (Must / Should / Could로 중요도를 정하고, 우선 순위를 세우기도 한다)
“간단히 말하면 정보를 제공하는 웹 서비스였는데, 모든 퍼널을 거쳐 우리가 의도한 정보를 습득하는 것으로 만족할 것인가 vs 우리의 정보를 바탕으로 쉽게 선택할 수 있도록 할 것인가였다
그때의 우리는 후자를 선택해서 이와 관련된 지표를 메인 KPI로, 전자 관련 지표를 서브 KPI로 설정하였다.”
PRD문화가 없을 때 PM은 무엇부터 시작하나?
문서 작성, 데이터 분석 시 정답을 찾아야 한다는 생각에 빠지기 쉽지만
PM의 역할은 정답을 찾는 게 아니라 의사결정을 돕는 것.
정답을 찾기보단 빠르게 결정을 내리고 검증해보는 것에 집중.
Q . PRD 작성 시 UX 및 개발 설계문서와 중복되지 않도록 해야한다는데, 이게 무슨 의미인지?
💬 PRD의 내용이 다른 문서와 겹친다면 그건 PRD가 꼭 필요한 상황이 아니라는 것. 그럴 땐 굳이 PRD를 작성하는데 리소스를 쓸 이유가 없다. 결국 저 말도 어렵게 생각할 거 없이 문서의 목적에 맞게 작성하라는 뜻. PRD면 PRD인 이유가 있어야하고, PRD에 필요한 내용만 담으라는 것.
자아 없이 문제정의를 하기로 했다.
튜터님이 지적하신 답정너가 되지않기 위해 뇌피셜 근거 빼고 순서대로 진행하기로함.
결과부터 말해보자면 순서대로? 순?서?대로?
월요일 8시 올림픽대로가 내 순서대로보다 안 막힐듯. 푸하하

우선 자아를 없애니까 많—은 문제들이 보이기 시작했다.
그래서 OKR 수립부터 시작했다.
지선 튜터님이 알려주신 것 처럼 목표가 명확한 상황에서는 OKR수립을 먼저할 수 있으니까.
"리텐션 향상" → 어쩌라고;
그래서 시작된 둘의 데이트 (둘 = 나 & 리텐션)
리텐션에 대해 생각하다보니 놀랍게도 리텐션이 뭔지 모르고 있었다는 걸 알 수 있었다.

#참고자료
브런치 | 리텐션에 대한 근본적인 오해
ThinkData | 사용자 리텐션 측정의 핵심! 코호트 분석 방법 총정리
Ver 1. "혜택 인지 경험 개선을 통해 멤버십 사용자 리텐션 강화"
혜택 인지 경험이 너무 추상적임. 하나도 와닿지 않음.. 한귀듣한귀흘하기 딱 좋은 허울뿐인 말경험 개선도 약간 어쩌라고임. 어떻게 개선하자는건데;리텐션 → 멤버십 사용자 리텐션으로 명확한 방향을 설정한 것. 사용자 이였는데, 멤버십 사용자로 더 좁혀버림.그렇게 개선사항을 반영한 Objective Ver.2는 다음과 같다.
"혜택을 지속적으로 체감할 수 있는 경험을 구축하여 멤버십 사용자의 재구매 리텐션을 강화한다"
Objective가
“지속적으로 체감” + “리텐션 강화” 로 설정 되었기 때문에
KR은 [인지] → [행동] → [결과]이 연쇄적으로 평가될 수 있게 설계하고자 했다.
최종적으로 전달하고자 한 OKR의 의도는:
혜택을 더 잘 보이게 만들고 → 실제로 쓰게 만들고 →그 결과로 리텐션이 올라가는지 검증한다
Objective 결정하고 KR 설정하면서 문서를 훑어보는데 문득 든 의문.
리뷰 데이터 분석 결과 알고리즘,인프라 카테고리가 가장 높은 우선순위 점수를 얻었는데
왜 혜택문제를....다루고 있었지?
왜냐면....첫번째 시도의 레거시가 남아있었기 때문...
(AI 추천 시스템을 개선하기 위해서는 결국 혜택 가시성을 개선해야한다는 '그' 접근)
그래서 열심히 이유를 만들어냄!
알고리즘, 인프라 카테고리의 불만사항은 서비스 자체 결함이 아닌 사용자의 문제일 수도 있기 때문에 문제 심각도에 대한 신뢰도가 낮고, 개발 공수가 큰 데 비해 단기적인 성과측정이 까다롭기 때문에 과제영역으로 삼지 않았다 – 라고 만들어냈는데, 급조한 거 치고 굉장히 납득되는 이유라서 다행..
점심에 프랭크 버거에서 PBnJ 치즈 버거를 먹었다. 정말 맛있었다.
전날 피드백에서 지적 받은 부분을 최대한 고쳐보려고 노력했는데, 아직도 논리 흐름을 탄탄하게 만드는 게 참 어렵다. 그래도 문서화나 방법론에 얽매이지 않고 논리구조에 집중하기로 했더니 조금씩 진척되는 느낌이 든다.
다들 본인의 쪼가 과제에 묻어나오는 거 같다며 좋은 점은 취하고 안 좋은 점은 개선해야겠다는 얘기를 했다. 생각해보니 나의 쪼는 아무래도 영화 전공에서 시작 된 듯...
생각이 한 갈래로 이어지지 않고 여기저기 연결돼서 퍼져나가는 것 + rhetoric writing...
앞으로 열심히 개선해보기로~!