올리브영 사례 발표 및 피드백
오늘은 한 주 동안 직무 스터디 한 내용으로 발표를 진행하였습니다.
한 주 동안 학습한 걸 한 번 더 정리하니 더 머리에 들어오는 것 같더라구요.
1. 발표
이커머스 분야에서 PM이 하는 일, 그 사용자 여정, 데이터 흐름을 따라 실제 분석한 사례 및 개선점을 발표하였습니다.
마지막으로는 추가적으로 논의하고 싶은 내용을 덧붙였는데요.
여기에서는 직무 스터디 4일 차에 작성한 다크 패턴과 데이터 수집 및 사용 시 문제점에 대해 다루었습니다.
발표는 성공적으로 끝났으며, 튜터님의 피드백은 아래와 같습니다.
- 실제 결과 도출, 수정 과정으로 신뢰도 있는 자료를 제시하였다.
(여기에서는 가상 데이터를 활용해서 예상 성과를 확인해 본 것이 좋게 평가되었습니다.)
- 개선점을 사용자, 비즈니스, 데이터 관점 모두에서 분석하였다.
- 사용자뿐만 아니라 비즈니스 관점을 놓치지 않고 밀도 있게 제시하였다.
- 현업에서 하는 것만큼 디테일하게 다루었다.
- 최근 화두에 오른 다크 패턴은 특히 이커머스 도메인에서 자주 활용되는데, 이 부분이 다룬 것이 좋았다.
좋은 피드백이 많아 뿌듯했고, 무엇보다 저희 조가 강조하고 싶은 부분을 콕 찝어서 말씀해 주신 것이 좋았습니다.
실제 현업에서 어떤 방식으로 진행되는지 알고 싶었고,
현업에 뛰어들기 전 경험해 볼 수 있는 기회가 보다 빠르게 다가온 것 같아서 좋았습니다.
2. 꿀팁
발표 피드백뿐만 아니라 여러 이야기를 들을 수 있었는데,
그 중 특히 좋았던 조언 몇 가지가 있습니다.
[PM TIP]
1. 레퍼런스를 잘 찾아야 한다.
2. 경쟁사 분석은 필수이다.
3. 논리적인 근거는 필수이다.
4. 주 타겟층에 대한 면밀한 분석이 필요하다.
5. 챗GPT를 잘 활용할 줄 알아야 한다.
6. 기술 블로그를 참고하는 습관을 들여야 한다.
7. 수요와 공급을 따지면 합리적인 근거가 된다.
기술 블로그를 활용하는 것은 정말 좋은 팁으로 작용했습니다.
실제 그 기업이 기술적으로 어떤 일을 진행하고 있는지 알고 있고, 추구하는 방향성 또한 알 수 있습니다.
이번 사례 분석 시 다루었던 올리브영 커뮤니티인 셔터에 관련해서도 찾아볼 수 있었습니다.
올리브영이 커뮤니티와 콘텐츠를 만드는 진짜 이유 | 올리브영 테크블로그
올리브영 콘텐츠프로덕트팀이 만드는 커뮤니티
oliveyoung.tech
3. 불편한 UX/UI, 왜 개선하지 않을까?
이커머스 도메인에 관련된 UX/UI 부분에 대해 알게 된 부분이 있습니다.
실제 사용자 입장에서 불편한데 왜 이렇게 만들었을까? 너무 불필요한 게 있지 않나?
이런 생각이 들었고, 개선점을 찾아야 한다고 생각했습니다.
현업 종사자의 말에 의하면 이커머스 도메인은 고객 여정, 사용자 경험이 가장 제한적이라고 합니다.
상품 구매, 결제, 배송 이외의 기능은 거의 다루지 않기 때문입니다.
따라서 사용자들이 아무 생각 없이 구매할 수 있도록 해야 하기 때문에 디자인을 수정하는 것이 어렵다는 것입니다.
이미 1~2년 정도 되면 고착화가 되기 마련입니다.
이때 UX/UI를 수정하면 오히려 사용자의 이용률이나 구매율 감소로 이어질 수 있습니다.
웹은 고착화가 더욱 심하며 SSG, 쿠팡 같은 경우에는 이미 구매율이 좋고 아웃풋이 잘 나오기 때문에 굳이 변화시키지 않는다는 입장입니다.
실제로 CS를 줄이기 위해 리뉴얼을 진행했는데 오히려 리텐션이 감소한 사례도 있다고 합니다.
4. 문제 해결의 우선순위 결정 방법
가장 중요한 것은 KPI를 활용하는 것입니다.
모든 우선순위 결정의 기본이 되는 과정입니다.
다음으로는 임팩트가 큰지 확인해야 합니다.
임팩트가 큰 것은 우선순위가 높아질 수밖에 없습니다.
비즈니스에 큰 비용을 초래하거나 매출을 높여 줄 수 있는 일이라면 우선순위를 높게 부여해야 한다는 것입니다.
5. 결과론적
사실 모든 일은 결과를 알지 못하기 때문에 우선순위를 명확하게 설정하기는 어렵습니다.
모든 일은 결과론적으로 작용하기 때문입니다.
51:49로 결정되는 일이 있는데, 당장에는 이 1%가 큰 영향을 미치지 않을 것입니다.
문제는 이 1%의 문제 발생이 복리적으로 작용하게 된다면 큰 부담을 초래할 수 있습니다.
따라서 일의 결과를 항상 회고하며 지속적인 개선을 통해 1%를 줄이기 위한 노력을 끊임없이 해야 합니다.
6. 금쪽이 개발자 관리
발표와 피드백, 튜터님의 조언 외 한 튜터님의 직무 라이브 세션에 참여했습니다.
실제 PM의 하루에 대해 들었을 때는 조금 걱정이 되면서도 기대가 되었습니다.
단 한 순간도 쉬지 못하는 스케줄에 진정한 개인 업무는 6시가 지나고 시작된다는 것이 조금 걱정이 되었습니다.
그러면서도 일하는 것을 좋아하고, 항상 일하고 싶어 하던 저에게는 조금 기대가 됐던 것도 사실입니다.
PM으로서 금쪽이 개발자를 잘 관리해야 한다는 말도 인상 깊었습니다.
개발자 출신인 저는 사실 약간의 PTSD가 올 뻔했습니다..
금쪽이 개발자라는 단어에 어떠한 부정도 할 수 없었습니다.
분명히 존재하니까요.
그러면서도 왜 개발자에게만 금쪽이 수식어가 붙을까 생각을 해 보았습니다.
단순하게 통제가 잘 안 되는 직군이라서인 것 같기도 합니다.
앞으로는 개발자가 아닌 PM으로서 개발자를 마주하게 될 텐데, 어떤 식으로 대해야 할지 잘 알아봐야 할 것 같습니다.
개발자의 시선이 아닌 이제는 PM의 시선으로 그들을 바라봐야겠습니다.
한 주가 지나간 게 아쉬울 정도로 유익한 기간이었습니다.
성공한 사람의 특징은 실패를 많이 했다라는 튜터님의 말을 타투로 새기고 싶을 정도로 감명 깊었습니다..
실패를 두려워하면 성공할 기회조차 주어지지 않을 수 있겠네요.
당연히 실패할 수 있습니다만 시도해 보는 것이 중요하다고 생각합니다. 😊
그리고 그 실패를 잘 회고해서 다음에 보완해야 한다는 것도 잊지 말아야 할 것입니다!