brunch

You can make anything
by writing

C.S.Lewis

by 오즈 Oct 12. 2024

회고록 - 24년 10월 2주차

생각보다 PM으로서 많은 유저 대상의 실험을 해본 적이 없음을 깨달았다.



배운 것


[QA 경험] 트래킹코드 QA 후 개발 정도는 내가 직접 하는게 진짜노동이 아닐까 싶다. (이슈 티켓을 만들고 검토를 요청하면 맥락을 파악하는 가짜 노동이 증가하는듯하다.)(개발자는 무대 앞 노동이라 진짜 노동이라고 인식할 비율이 높을 수 있지만, PM은 무대 뒤 노동자이기 때문에 항상 가짜 노동인지 경계해야할 것 같다.)

[QA 경험] QA플로우를 직접 짜기 위해서는 유저 저니맵을 깊이 고민해봐야 할 것 같다. 다양한 엣지케이스를 고민하기 위해서는 어떤 고민이 필요할까? 잘 짠 QA플로우는 시간 단축, 개발 안정성 측면에서 중요할 것이다.

[이벤트 운영 경험] 이벤트 운영을 위해 노출수&유저수를 비교하면서 MAU의 반 이상이면 진행한다 - 는 기준을 잡을 수 있다는 것을 배웠다!

[알림 메시지 최적화 경험] 토스 알림 UX가이드 스터디해보고 싶다! 이번 알림 문구 적을 때 토스를 많이 참고했는데 성과가 좋다고 전해주셨다. (아직 확인은 못해봄) + 추가로 이모지를 넣으면 효과적이라고 하셨는데, 진짜일까? 토스에서 이모지 쓰는 것은 보지 못한 것 같은데 왤까?

스프린트 회고 발표는 작년에 주기적으로 해온게 도움이 많이 된 것 같다 … 항상 회고를 이끌어오고 IR을 하는 것들이 스피치에 자신을 붙였다.

현 상황 (전략을 시도하게 된) 을 명확히 인지하지 못한 채로 기획에 도입하면 잘못된 방향으로 접근하게 된다.

작년에 이어 반복적으로 느끼는 생각이지만, 생각이 너무 많다. 스스로 어떤 기획이 좋을 지 떠올리기 어렵다 보니 많은 정보를 수집하고 싶어지고, 그 때문에 쓸데없는 지표를 뒤져보게 되는 것 같다. 물론 다양한 선택지 중 최선을 선택하려는 의도는 좋지만, 그 시간이 길어졌을 때에는 효율성이 오히려 떨어지는 경험을 한다.



앞으로 해보고 싶은 것


[알림 최적화] 내가 발송한 알림 메시지가 확인 비율이 많았는지

[알림 최적화] 토스 가이드 스터디 & 알림 보내는 가이드 정리해두자

[블로그 SEO] 내가 발행한 블로그 글로 실제 유입 수가 늘었는지 (조회수)

[블로그 SEO] 블로그 채널의 의의 고민

[QA] 이후 실제로 QA 플로우 짜는 단계부터 경험해보기

[QA] PM하시면서 에러수/ QA 시간 감소에 대한 데이터가 있으신지 여쭤보기

[QA] 트래킹코드 QA 후 개발은 내가 작업하는게 어떨지 나중에 제안드려보기

[referral] 이벤트를 통해 유입되는 유저수 / 단가 비교해보기

기획 시, 1) 왜 해야하는지, 2) 무슨 상황인지, 3) 최종 산출물이 뭔지 - 를 확인하고 백워드하게 일하기. BPSSH에 매몰되지 말자.


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari