[TIL] 내일배움캠프 251209 - 목적과 결론을 잊지 않기

📍근데, 아래의 이 수많은 아티클들을 읽으며 정리도 했는데, 그래서 결론이 뭐야?

그리고 또.. 이게 기술 블로그를 들어가서 보다 보면,
예를 들어 우리 강의에서 '가설 검증'에 대한 사례라고 하자.
정말 1:1 로 가설 검증에만 매칭되는 사례가 아니라 프로젝트 전반에 대해 기술되어있기 때문에
전체를 읽다 보면 '그래서 이게 강의에서 왜 나왔다고?' 이렇게 될 때가 많음..
또한 뭔가 내가 알고 있는 것들 사이에서도 계속 연결이 일어나는데...😂

진짜 핵심이 무엇인지? 관통하는 이야기가 무엇인지?
이 부분에 좀 더 여유를 갖고 생각을 해 볼 필요가 있다.

우선 오늘은
· 돌고 돌아 목표 수립 - 문제 정의 -가설 수립 - 액션 및 검증 - 결과 프레임 워크
· 문제 해결도, 내가 하는 학습도 목적과 결론을 잃지 않기

 

**특히 배민, 토스 이 두 글이 한 번에 안 읽혔음
(배민은 튜터님께 문의드림! 쓰신 분이 튜터님이라니 참 좋다..)

 

 

 

---

목표 수립 - 문제 정의 - 가설 수립 - 액션 및 검증 - 결과
의 프레임 워크로 고민하기

⭐문제를 정의하고 해결하는 과정⭐
    1. 문제 현상 확인
    2. 현상이 끼친 영향 분석
    3. 문제의 원인 파악
    4. 해결 방안 가설 수립
    5. 가설 검증 방법 설계
    6. 검증 결과 분석

 

ㄴ 약간씩 달라서 헷갈리네 아마 점차 내 언어로 정리가 되겠지

---

 

하나의 방법만 쓰는 게 아니라

VoC → 데이터(앰플리튜드) → 가설 수립 → 프로토타입 → UT/인터뷰 → 개발 배포 → A/B테스트 검증 → 100% 배포

강남언니에서는 위 방법들 중 하나의 방법만 파고드는 것이 아니라, 적절한 타이밍에 서로 상호보완하는 방향으로 유연하게 활용하고 있습니다. 정성적인 방법에는 한계가 분명히 있고, 정량적인 방법에도 단독으로 사용하기에는 한계가 분명하게 있기 때문이죠. 다음은 포괄적으로 제품을 설계하고 만드는 방법을 설명해보도록 하겠습니다.

VOC를 통해 고객이 느끼는 문제를 발견하고 이 문제가 강남언니 전반에 퍼져있는 문제인지 확인하기 위해서 Amplitude를 확인합니다. 대다수가 겪고있는 문제, 혹은 정말 중요한 고객 경험을 해친다고 생각되면 가설을 세워 문제를 정의합니다. 그 문제를 해결하는 화면을 프로토타입으로 만듭니다. 대상 고객을 모집해 고객에게 보여주며 사용하는 모습을 관찰합니다. 제작한 기능을 의도한 대로 잘 사용하는지, 문제라고 생각했던 화면에서 실제로 문제를 겪고 있는지 확인하는 시간을 거칩니다. 그리고 인터뷰를 통해서 생각하고 있는 뿌리에서 어떤 문제가 있었는지 발견합니다. 고객이 겪고 있는 문제가 점점 명확해지면 솔루션 단계로로 넘어가 화면을 그려 개발하고 배포하는 과정을 거치게 됩니다. 그 솔루션이 의도한 대로 명확하게 사용되는지 A/B테스트를 통해서 데이터로 검증을 거칩니다. 솔루션이 지금 보다 더 나은 결과를 만들어준다면 그 화면이 100% 배포되는 형태로 진행됩니다.

---

 

문제 발견 단계에서 A/B테스트 사용 시 궁금한 점

 

CRM 에서 푸시부터 IAM까지 수많은 A/B테스트를 했는데

물론 수치적으로 상승되었고, 가설에 대한 인사이트도 얻었지만...
A/B테스트 유의미한 표본? 수치에 대한 판단 근거 이런 게 있었던 거 같은데.. 찾아봐야겠다.
A/B 테스트 표본 크기와 유의미한 결과의 관계 - 요즘IT

아마도 이런 내용일 듯 

→ 이것은 이후 진행된 A/B 테스트 특강으로 얼추 해결 완료!

 

그리고 Firebase를 이용한다고 되어있어서.. 회사에 있었지만 나는 안 썼던지라
갑챠기스러운데 Firebase 개념 다시 알기 ㅋ

짚티한테 초등학생도 이해하게 설명하라고 했음..ㅎㅎ

 

• 앱 = 가게
• Firebase = 가게 뒤에서 도와주는 직원들 (캐시어, 창고 관리자, 알바 등)

가게는 직접 꾸며야 하지만
운영은 Firebase가 많이 도와줘서 가게를 빨리 열 수 있음.

---

 

PM, 디자이너, 개발자가 함께한 배달의민족 입점 과정 개선기

PM, 디자이너, 개발자가 함께한 배달의민족 입점 과정 개선기 | 우아한형제들 기술블로그

 

ㄴ 이거 이탈 데이터도 앰플리튜드로 보신건가? 튜터님께 나중에 여쭤봐야겠다! 여쭤보기 완료!

 

---

 

 5 whys 의 root cause 

 

문제 정의를 위한 프레임 워크인  5 whys 의 root cause 란 말을 보며 생각하다보니..
헤이조이스 강연에서 라인플러스 이은정 대표님이 원인의 원인을 찾아 root cause 까지 간다 이런 얘기를 해주신 게 메모장에 있다. (근데 이제 어느 지점에서 그 이야기가 나왔는지 생각 안 나는 게 문제)
모쪼록 어느 직무를 막론하고 '왜'가 중요하구나를 또 생각함.

그럼 왜 중요한데? 현상만 해결하는 게 아니라 진짜 원인을 찾아서 제거해야 하니까!

= 즉, 좋은 해결책을 찾을 수 있다.

 

EX. 자전거가 자꾸 넘어져서 힘들다.

• 증상 해결: 넘어질 때마다 무릎에 반창고 붙이기
• Root Cause 해결: 바퀴가 펑크 났다는 걸 찾아서 고치기

바퀴를 고치면 잘 넘어진다는 문제가 사라짐.

---

 

문제정의 시 주의점

가장 많이 하는 실수는 문제 정의를 제대로 하기 전에 미리 ‘해결 방안’을 정해두고 시작한다는 것. 

ㄴ 사용자 또는 내가 불편함을 느꼈다고 해서 얼레벌레 후다닥 수정할 게 아니라(그렇게 되지도 않겠지만) 문제에 대해 다각도로 보는 관점이 중요하겠다.
정말 불편한 문제인지? 전에 봤던 이 아티클에서 'PM에게 훌룡한 제품과 전체 고객보다 중요한 나머지 일부 고객과 이해 관계자는 없다. 제품을 망치지 않기 위해서는 여러 이유에 의한 잘못된 기능 개발을 하지 않아야 한다.'는 것을 보았는데 그게 생각났다.
비슷한 맥락으로 보인다.

---

더 쪼개서 더 정확히 분석하면 가능하다.

 

토스 기술 블로그

 

 

그로스 도메인이 토스를 성장시키는 방법

그로스 도메인이 토스를 성장시키는 방법

 

여기 아티클에 나오신 두 분, 올해 원티드 하이파이브 그로스 세션에서 뵌 분들이라 놀랐다!
이후 클래스101으로 가신 것으로 아는데.. 토스의 '그로스 도메인'에 계셨던 거구나.
프로덕트 매니지먼트에도 역시 그로스가 중요하구나. (그러니 그로스해킹이 커리에 있겠죠?)

근데 도메인이라니 토스 내에 어떤 어떤 도메인이 있는 거지?

 

---

 

데이터 중심으로 실험을 잘 할 수 있는 환경,
무엇보다 트래픽이 커서 작은 실험도 빠르게 결과를 할 수 있다는 점이 너무 부럽다! 그런 회사에 가고 싶다!

 

 

당근 기술 블로그

당근 기술 블로그

당근 기술 블로그

 

 

 

 

---

 

 

단편적인 문제정의/가설설정/액션 말고, 스파르타적 예시를 잘 참고하자!

 

 

 

---

 

 

이 사례를 보고 정성 리서치, 설문 조사 결과를 맹신해서는 안 되겠다는 생각과 더불어 교차 검증의 중요성을 알게되었다.

정확도를 높이는 두 리서처의 교차검증

정성 리서치와 정량 리서치는 상호보완의 관계를 띈다. 인터뷰 답변과 같은 정성 데이터를 정량 리서치로 검증하는 것이 대표적이다. 고객은 자신이 깊게 고민해보지 않은 상황에 대해 질문 받은 경우 ‘나라면 이렇게 행동하지 않았을까’ 추측하여 답하는 경향이 있다. 이때 객관적으로 고객의 실제 행동을 분석하여 수치적인 데이터로 검증하는 것이 바로 정량 리서처의 역할이다. 나아가 유사한 고객 집단에서도 공통적인 행동 패턴을 보이고 있는지 데이터를 교차 검증하며 리서치 결과의 정확도를 높여나간다. 다음은 고객의 인터뷰를 교차 검증한 사례다.

고객 이 씨는 쿠팡의 유료 멤버십 서비스 ‘로켓 와우‘를 중도 해지한 고객이다. 인터뷰에서 이 씨에게 멤버십 해지 사유를 물으니 “혜택이 유용하지 않았다“고 답했다. 더불어 각 와우 혜택을 인지하고 있는지 서베이를 진행했을 때에도 무료배송, 새벽배송 및 당일배송이 와우 전용 혜택임을 모른다고 체크했다. 하지만 이 씨의 행동 데이터를 추적해보니, 무료배송, 새벽배송 및 당일배송 등 와우 멤버십 전용 혜택을 이용했음을 확인할 수 있었다. 이 과정을 통해 고객은 멤버십에 어떤 혜택이 있는지 잘 알지 못하며, 와우 전용 혜택을 경험하고도, 이를 혜택으로 인지하지 못한다는 가설을 세웠다. 이후 PO, 디자이너, 개발자는 리서치 결과를 토대로 고객이 혜택을 인지하고 경험할 수 있도록 UX를 개선하여 로켓 와우 회원의 이탈을 줄일 수 있었다.

두 리서처의 교차 검증으로 고객의 말과 실제 행동의 간극을 발견하여 정밀한 가설을 세운 사례다. 정성 리서처는 인터뷰에서 ‘혜택이 유용하지 않아서 멤버십을 중도 해지했다’는 인과 관계를 파악했다. 이 응답이 유효한지 검증하기 위해 정량 리서처가 해당 고객을 포함해 서베이를 진행하고, 동시에 실제 고객의 행동을 추적했다. 이렇듯 정성 리서치만으로는 정확도에 한계가 있고, 정량 리서치만으로는 고객의 진짜 의도와 속뜻을 증명하기 어렵기 때문에 신뢰할 수 있는 결과를 위해선 두 가지 리서치가 함께 진행되어야 한다.

 

 

---

 

하지만? 정량적 데이터에도 치명적 약점이 있다. = 최종 도착 지점만 확인할 수 있다는 것.

하지만, 정확한 결과를 알려주는 데이터에는 한 가지 치명적인 약점이 있어요. 사용자 행동의 최종 도착 지점만 확인할 수 있다는 건데요. 사용자가 ‘왜’ 이런 행동을 했는지 ‘근본적인 이유’는 데이터에서 뽑아내기가 어렵습니다. ‘맥락’을 파악할 수 없는거죠.
예전부터 행동의 이유와 맥락을 파악해야 한다는 필요성은 항상 대두되고 있었기 때문에, 간헐적으로 사용자 조사가 진행되고 있었어요. 그러다가, 이 역할을 더 깊고 넓게 해줄 수 있는 사람이 꼭 필요하다는 생각에 저희 팀이 꾸려지게 됐고요. 데이터 이면에 있는 고객의 목소리를 더 효과적으로 찾을 수 있는 역할을 전담하게 되었습니다.
- 토스 UX 리서처

 

즉, 정성과 정량 모두를 봐야 한다!

 

---

 

가설 검증 후, 예상과 다르게 결과가 좋지 않으면 어떻게 하나요?

- 물론 결과도 중요하지만, 실패를 통해 인사이트를 얻은 것이 중요합니다.
- 진짜로 안타까운 케이스는 오히려 가설 검증 자체가 불가능해서 아무 인사이트를 얻지 못한 케이스입니다.
- 예상보다 결과가 나쁘더라도, 이를 통해 얻은 인사이트를 기반으로 가설을 수정해서 다시 검증하면서 점진적으로 개선해나가면 됩니다.

 

---

 

 

전사 프로모션을 키비주얼을 위해 UT를 진행하셨다고 하는데
갑자기 전 회사 키비주얼을 IAM 에 어떻게 적용할지 고민하고 A/B테스트했던 것이 생각났다.
CRM 단에서.. 인앱 유저들의 IAM 클릭률을 올리기 위해 노력했었다.
물론 키비주얼을 정하는 것까지는 아니지만 그래도 같은 맥락에서..

암튼 이런 키비주얼 전략에도 UT 를 진행한다는 것을 알았다.

그리고 히트맵을 볼 수 있는 이 도구도! → [서비스리뷰]프로젝트 사용성을 테스트하는 도구 maze

 

오늘의집 기술 블로그