강남언니가 일하는 방식에서 배운 것

강남언니 공식 블로그에 스터디할만한 인사이트를 가득 담은 글들이 참 많다.

공부하면서 배운 내용 정리! 일 잘하고 싶다는 욕구가 뿜뿜해지네. 🤓

 

강남언니 / 이미지 출처 = 강남언니 웹사이트

 

실험하려다 파편화 부채를 청산했어요 (23.06.20)

• 고객이 서비스를 이용할 때, 원하는 것을 알기 위해서 화면이나 경험의 패턴을 최소화하는 것이 중요함
• 조금씩 쪼개지고 달라지는 정보를 한 화면에서 보게 되면 고객은 혼란을 겪을 수 있음
• 이때, 요소를 최소화함으로써 고객은 특별한 학습 없이 물 흐르듯 우리가 의도한 대로 제품을 사용할 수 있게 됨

 

강남언니에는 비즈니스 자가진단 키트가 있다 (23.04.26)

• 비즈옵스 스쿼드에서 전사의 주요 사업지표를 볼 수 있는 WBR(Weekly Business Review) 대시보드를 생성하였음
• WBR을 기반으로 1주일 단위로 주요 사업지표를 모니터링하고, 모니터링 과정에서 문제가 발견되면 담당 스쿼드가 드라이브하여 빠르게 문제를 해결하는 형태로 업무를 진행함
• 기본적인 지표 현황을 파악하는 것에서 나아가 주요 지표를 정의하고 전사가 같은 곳을 바라보도록 하는 것에 집중하였음
• 매주 핵심 지표들이 자동으로 업데이트되고 서비스 전반에 대한 데이터를 한눈에 볼 수 있다는 장점이 컸지만, 지표의 변화가 있었을 때 그에 대한 원인을 파악하여 언어화하지 않아 전주의 기록이 휘발되는 문제점이 있었고 중요한 변화를 대시보드에서 확인하기 어려웠음
• 지표를 좀 더 세분화하고 전주 대비 차이가 큰 지표들은 하이라이트 하여 주요하게 봐야 할 지표들이 눈에 띄도록 대시보드 수정. 전주 대비 차이가 컸던 지표들은 매주 월요일 WBR 분석 담당자가 원인을 최대한 분석해서 매주 문서로 작성하였음
• 사업의 Input → Output → Outcome의 구조가 좀 더 잘 보이도록 대시보드 개선. '핵심 지표' 외에 이를 달성하기 위해 각 스쿼드가 수행하는 '액션 지표'를 대시보드에 추가하여 주 단위로 각 스쿼드의 액션이 아웃풋으로 잘 이어지고 있는지 확인할 수 있는 환경을 만들었음
• 분석을 진행할 때부터 담당 스쿼드와 커뮤니케이션을 통해 함께 더 깊이 원인을 분석해 보거나 빠른 시간 안에 문제를 해결할 수 있도록 넛지를 주는 방향으로 변경하여 문제 발견부터 해결까지의 시간을 크게 감소시켰음

 

PO가 비즈니스 전략을 제품에 녹이는 방법 (23.01.05)

• 강남언니가 비즈니스의 확장과 고객의 문제 사이에서 교집합을 찾아 성장을 이루어낸 과정!
• 1단계 - 지역 확장에 대한 고객의 니즈를 확인하기
  • 데이터를 통한 확인 - VOC 분석, 검색어를 통한 수요 확인
  • Usability Test를 통한 확인 - 4번의 UT, 12명의 고객 대상으로 UT를 진행하여 두 가지 그룹으로 고객군이 나누어지는 것을 발견하였음(지역 우선 vs 가격 후기 우선)
• 2단계 - 지역 확장에 대한 전사의 지표와 팀의 지표를 align 시키기
  • Step1 - 고객의 문제와 가장 밀접하게 관련된 critical path가 무엇인지부터 정의
  • Step2 - 고객의 critical path에서 어떤 퍼널을 성장 지표로 잡을지 정의
  • Step3 - 다른 퍼널들을 상수로 두었을 때, 성장 지표로 잡은 퍼널(key metric)을 얼마나 올려야 회사의 목표에 도달할 수 있을지 계산
• 3단계 - 문제 해결을 제품에 반영하기 & 성과 확인하기
• 4단계 - 이 과정을 통해 무엇을 배웠는가 > 회고

 

목적을 생각하면, 일하는 방식이 바뀐다 (22.06.13)

• '고객가치'를 목적에 두고 일하려면
  • 내가 풀고 싶은 문제가 아니라, 고객의 문제를 발견할 것
  • 만들고 싶은 제품을 만드는 것이 아니라, 고객이 원하는 제품을 전달할 것
  • 최종적으로 고객으로부터 피드백을 수렴하고 조정해 만족하게 할 것
• 고객에게 가치를 전달하는 제품의 탄생 과정 - 발견과 전달의 병렬 진행!
  • Product Discovery - 고객의 문제를 잘 발견해야 한다. 고객의 요구사항을 이해하고 우선순위를 찾는 데 집중한다.
  • Product Delivery - 발견한 고객의 문제를 잘 해결해서 전달해야 한다. 작지만 고객에게는 가치 있는 기능을 반복해서 전달하는 데 집중한다. 
• HPP(Healingpaper Product Proposal)이란?
  • 조직의 미션을 달성하기 위한 제품 아이디어 제안서
  • Problem - Solution - Benefit - FAQ 항목으로 구성
  • 이 문서는 극도의 투명함을 추구함. 원한다면 누구나 문제의 핵심과 솔루션을 볼 수 있고, 자유롭게 의견을 남길 수 있음. 그리고 반복 리뷰를 통해 실험하기에 충분히 설득력을 갖춘 문서가 됨. 이 장치를 통해 이해 관계자들은 고객의 문제 영역과 실험의 방향성을 조율하게 됨
  • 설득력을 갖춘 HPP 문서만 실험되기에 정기적 & 비정기적으로 고객 인터뷰를 진행하고, 이를 통해 HPP 작성의 근거를 모음. 특히 이때 가설이 맞는지 UT를 진행하고 데이터에서 인사이트를 뽑는 노력은 매우 중요함

구분	상세내용
Problem	고객의 문제로부터 시작했는가? "고객은 ~한 문제를 겪고 있다"고 첫 문장을 시작할 수 있는가?
Solution	이 자리에 고객이 있다면 솔루션의 가치를 이해할 수 있는가? 고객이 궁금하지 않도록 실행 로드맵(일정)을 러프하게 보여줄 수 있는가?
Benefit	XYZ 가설을 이용해서 설명할 수 있는가? - X : 우리는 표적 시장의 몇 퍼센트를 차지할 수 있나요? - Y : 우리의 표적 시장은 무엇입니까? - Z : 표적 시장은 우리 제품에 어떤 식으로, 정확히 어느 범위까지 호응할까요?
FAQ	고객 입장에서의 FAQ - 어떻게 시작하나요? - 어떻게 주요 경험이 완성되나요? - 문제가 있을 때 어디서 도움을 받을 수 있나요? - 사용 경험은 어떤가요? 동료 입장에서의 FAQ - 이것이 고객 경험의 기준을 어떻게 향상할 수 있나요? - 왜 이 고객 문제/기회가 현재 중요한 것인가요? - 이것이 전체적인 서비스 경험과 어떤 관계가 있나요? - 내부적으로 논의가 유발될만한 사항은 무엇이 있나요?

• 강남언니는 Product Delivery 과정에서 User Story를 주요 도구로 사용함
  • HPP에서 정의한 문제를 겪고 있는 고객을 페르소나로 설정하고 누구나 이해할 수 있는 쉬운 언어로 사용자 스토리를 쓰는 것을 개발보다 먼저 진행. 그리고 고객이 만족할 수준으로 통과할 수 있는지 조건/테스트 시나리오를 미리 작성함. 마지막으로 해당 Story를 달성하기 위한 세부 Task를 뽑아내고 비로소 개발을 시작하게 됨
  • 처음에는 초반 Planning 시간이 예상보다 길어져 정작 개발할 시간이 줄어들어 비효율적인 것은 아닌지 의심하는 동료들이 있었으나 지금은 User Story로 솔루션의 적절한 크기를 찾는 것이 익숙해지면서 가장 중요한 것에 집중할 수 있게 되었음

 

강남언니가 고객의 문제를 찾는 방법 (22.03.16)

• 숫자로 측정하는 정량적인 방법
  • 앱에 쌓인 데이터를 통해서(Amplitude)
  • A/B 테스트를 통해서(Firebase)
• 고객에게 직접 듣는 정성적인 방법
  • VOC를 통해서
  • UT & 인터뷰를 통해서

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

 

우리는 고객을 전혀 모르고 있었어요. UT를 하기 전까지는요! (22.03.07)

• 현재 강남언니의 제품팀은 최소 주 1회 모든 제품팀에서 UT를 하는 조직으로 바뀌었음. UT를 통해 '고객을 이해하고, 고객의 진짜 니즈와 행동을 파악해서 고객이 원하는 제품'을 만드는 팀이 될 수 있었던 이유
• UT(= Usability Test, 사용성 테스트)가 중요한 이유
  • 고객의 진짜 니즈를 파악할 수 있음 - 사용자가 우리 제품을 어떻게 사용하는지 행동을 '관찰'해서 (고객도 모르는) 고객의 진짜 니즈, 고객의 진짜 문제를 생생하게 발견할 수 있음
  • 개발없이 솔루션을 검증할 수 있음 - UT를 통해 우리가 제공하려는 솔루션이 정말 고객의 문제를 풀어주는게 맞는지를 '개발하기 전'에 확인하고 확신이 들 때까지 개발 비용없이 수정할 수 있음

 

프로덕트 디자이너가 PO를 한다면? (20.09.15)

• 문제의 본질을 파고드는 습관 - why에 대한 고민을 더 깊게 하게 되었음
• 효과적인 공유에 대한 고민 - 스쿼드 구성원과의 공유, 타 스쿼드에게 현재 우리가 집중하고 있는 일에 대한 공유 등 다양한 사람들과 계속해서 커뮤니케이션하며 의논하고 공유함
• 고객가치전달의 끝은 배포가 아니다!
  • 치열한 고민끝에 제품을 만들고 배포하면 고객가치전달의 여정이 끝이 난 것 같지만 오히려 이제 시작
  • 제품 배포 이후에도 운영적으로 고객이 이 제품을 잘 사용할 수 있게 추가적으로 장치를 마련해야 하는 것은 없는지, 만약 제대로 제품을 사용하지 못하고 있다면 그 원인은 무엇인지 등 끝까지 추적해야 함
  • ex1) A/B 테스트를 통해 가치 전달을 위한 가설이 맞았는지 검증
  • ex2) 제품을 내보내기 전/후로 UT를 진행해 고객이 의도한 대로 제품을 잘 사용하고 있는지 검증

 

UT로 고객 이해하기 (20.07.31)

• 사용성 테스트(UT)는 사용자 인터뷰와 다름. 사용자 인터뷰는 진행자와 사용자가 만나서 사용자의 의견을 물어본다면, 사용성 테스트는 사용자에게 할 일(Task)를 주고 사용자의 모습을 관찰한 뒤 질문을 던져서 사용자의 행동 이유를 파악함
• 사용성 테스트를 진행하기 위한 준비
  • 사람 - 참가자, 진행자, 관찰자
  • 공간 - 테스트 공간, 관찰 공간
• 사용성 테스트 언제, 어떻게 진행하면 좋을까?
  • 강남언니 팀은 제품의 개선 전과 개선 후에 사용성 테스트를 통해 사용자를 관찰하고 있음
  • 1단계 - 테스트를 통해 확인하고 싶은 것 정하기
    • 사용성 테스트를 통해 발견해야 할 문제를 정하고, 사용성 테스트에서 관찰해 볼 것들을 정함
  • 2단계 - 테스터가 할 일 정하기
    • 참가자가 사용성 테스트에서 해야 할 일을 미리 정하기(참가자가 테스트 시간을 충분히 채울 수 있는 양으로)
    • 참가자가 상황에 이입해서 Task를 수행할 수 있도록 구체적인 상황이 제시된 시나리오 형태로 작성하는 것이 좋음
    • 각 시나리오마다 알고 싶은 점을 함께 정리하면 테스트 진행에 도움이 됨
  • 3단계 - 테스터 정하기
    • 사용성 테스트를 통해 확인하고 싶은 것을 가장 잘 보여줄 수 있는 참가 대상 정하기
  • 4단계 - 테스트 환경 구성하기
  • 5단계 - 테스트하고 지켜보기
    • 참가자에게 시나리오를 하나씩 제시하고 참가자가 시나리오를 어떻게 수행하는지 관찰
    • 시나리오를 통해 알고 싶은 내용이 보이지 않는다면 참가자에게 추가적으로 질문할 수 있음. 질문할 때에는 참가자가 질문의 의도를 파악하지 못하도록 중립적이고 객관적인 시각으로 질문해야 함
    • 테스트가 진행되면 관찰자들은 관찰 공간에서 테스트 과정을 실시간으로 지켜보고 각자 발견한 문제점을 메모함
  • 6단계 - 공유하고 개선하기
    • 하나의 테스트가 끝나면 관찰자들은 각자 발견한 문제점을 서로 공유
    • 공유한 내용은 다품 제품 개선의 액션 아이템으로 활용

 

---

https://blog.gangnamunni.com/blog

강남언니 공식 블로그