비효율을 개선하자!
workflow에 집착한 지난 Q3 회고
요즘 나의 최대 관심사는 #노코드 #로우코드. 실험의 속도를 빠르게 하려면 dependency를 줄이고, 누구나 가설을 실험할 수 있는 환경이 중요하다고 느낀다. 개선하고 싶은 비효율이 가득한 이곳은 나에겐 놀이터처럼 보였고, 빠르게 해 보라고 독려해주신(?) 리모님 덕분에 몇 가지의 소소한 시도들을 해볼 수 있었다.
1. 커뮤니티 활성화
1-1. Problem
- CS에 들어가는 리소스 문제
대부분의 고객사들의 60~80%의 질문들은 굉장히 공통적인 부분에서 반복적으로 나타난다. 모든 질문을 private 채널에서 소통하는 게 최선일까? public 채널에서 응대하고 이전 history를 searchable하게 만들 수 없을까? 더 나아가 우리 팀이 대응하기보다, 사용자 간의 다양한 의견 교류를 통해 기본적인 질문은 해결될 수 있었으면 좋겠다.
- 죽어버린 커뮤니티, 심패소생술을 하자
원대한 꿈('요즘 제품 개발 잘하는 사람들이 모인 공간')을 가지고 시작했던 A/B 테스트 실무자 커뮤니티. 여러 가지 내부 사정으로 인해, Impact 대비 리소스가 많이 든다고 판단했고, 고객사 슬랙을 메인 커뮤니티로 키우는 게 Conversion측면에서 더 낫겠다는 결론이 나왔다. 다만 기존 고객사 슬랙은 엔터프라이즈 서포트를 위해 private 채널 위주로만 운영되고 있었기 때문에, 탐색할 수 있는 콘텐츠가 없었다.
1-2. Solution
늘 그렇듯, 벤치마크 조사부터 시작했다. 이를 기반으로 우리의 Key Objective는 무엇인지, MVP Scope을 어떻게 잡고 갈지, 매우 구체적인 Next Action Item을 직접 세우고 피드백을 요청드렸다.
- 슬랙 채널은 유지한다
애초에 슬랙 밖을 나가는 것은 고려 사항도 아니었지만, 슬랙을 어떻게 효율적으로 쓸 수 있을지는 고민되는 포인트였다. 1천 명이 넘는 커뮤니티를 슬랙 유료 플랜으로 유지하는 건 ROI가 안 나온다. 3개월 이전의 메시지/자료들은 다 휘발되어버리는데, 이것을 어떻게 보완할 수 있을까.
- SaaS를 위한 SaaS, linen.dev와 commonroom을 사용해보자
기존에 커뮤니티에 조인하신 분들을 대상으로 웰컴 메시지를 수기로 보내고 있었는데, commonroom을 사용하여 workflow를 만들어 보았다. 커뮤니티 활성화를 위해 만든 여러 개의 public채널들을 소개하고 홍보하기 위해서도 웰컴 메시지를 잘 세팅하는 것은 너무 중요했다.
Our Onbaording Journey커뮤니티 활성화가 메인 job이 됐을 때, commonroom은 훌륭한 대시보드(커뮤니티 활성화 유저 수, Segment 만들기, Account별 멤버 activity보기)를 제공해주고 있기 때문에 유료 플랜을 사용해봐도 좋을 듯하다. 아직까진, 무료 플랜으로 웰컴 메시지 보내는 용도로만 사용 중이다.
linen.dev는 슬랙 커뮤니티를 searchable website로 옮겨주는 SaaS이다. 앞서 언급한 3개월이 지나면 메시지가 휘발되는 슬랙 무료 플랜의 단점을 커버해준다는 점에서 매우 유용하다. 다만, 아직 콘텐츠가 제대로 채워지지 않은 상태에서 꼭 필요한 서비스는 아닌지라 홀드 했다. 무료 플랜으로 trial 해본 사이트 링크는 : https://www.linen.dev/s/hackle-community
- 채널 활성화, 어떻게 시작할 것인가!
샘플 질문과 콘텐츠를 만들었다. 그리고 채널에 미리 올려두었다. 참가자들이 채널의 성격을 파악하는데 용이하기를 바라며... 콘텐츠 추천, 서비스 업데이트 채널은 RSS봇 피딩을 통해 해결하고자 했다.
2. 업데이트 노트
2-1. Problem
- 서비스 업데이트 노트의 부재
굉장히 서비스 고도화를 많이 하고 있는데, 이러한 기능 업데이트 소식이 고객에게 충분히, 적시에, 효과적으로 전달되고 있지 않는다는 문제가 있었다. 제품팀과 비즈니스팀이 효과적으로 소통하고 있지 않음도 큰 문제였다.
2-2. Solution
- 소통합시다
되도록이면 칸반 스크럼엔 필참 했다. 그리고, Sprint 단위로 쪼개어 언제 어떻게 고객에게 커뮤니케이션돼야 하는지를 제품팀도 함께 인지하고 있어야 했다.
- Readme Changelog 활용
리디아 님이 고객사 슬랙을 통해 커뮤니케이션하는 식으로 초기 Iteration을 진행했고, 나는 이후 readme changelog로 migration 하는 작업을 진행했다. (사실상 숟가락 얻기) 때 마침, 고객사 중에서 회사 슬랙에서 기능 업데이트를 받아볼 수 있냐는 질문이 들어왔고, 상시 확인할 수 있도록 RSS 피드를 만들었다. 내친김에 webflow로 빌드한 블로그도 RSS 구독도 만듬.
3. 프로세스 가이드
3-1. Problem
- Sales에서 필요한 Lead 확보
매주 X개의 데모 신청과 X개의 리드 정보가 수집될 수 있도록, 빠른 주기/적은 리소스로 행사를 기획해보자는 아이디어가 나왔다. 그렇게 탄생한 PO세션.
3-2. Solution
- 누구나 디벨롭할 수 있는 초기 가이드 만들기
프로세스란 개념 자체가 본질적으로 과거 지향적입니다. 어제 일어난 문제들에 대한 대응으로 개발된 프로세스를 성스러운 것으로 취급한다면 이는 전진을 방해할 수 있습니다.
사실 나는 문샷 책에서 이 구절을 참 인상 깊게 보았다. 프로세스 가이드를 만들면서, 우려됐던 점은 그 자체가 목적이 되면 안 된다는 것. 우리는 지금까지 늘 그렇게 해왔거든(x) 그게 계속 유지해야 할 타당한 이유가 없는 한, 모든 것을 바꿔도 좋다!(o)를 이 가이드를 보는 사람들이 잊지 않도록 만들어야 한다는 것.
Timeline에 맞춰 만들어본 가이드 초안나의 가이드는 operation cost를 낮추는데 기여하는가?
- Do Small Test and Iterate
진행한 행사의 횟수만큼, 가장 많이 진화했던 나의 프로젝트. 광고도 행사 기획도 발표자료도 타겟도, 행사를 진행하면서 점차 고도화해나갔다. 행사의 제목은 최대한 한 번에 정하는 것을 지양했다. 여러 가지의 소구점을 광고로 선 테스트해보고, 메인 포스터와 행사 카피를 잡아서 커뮤니티 및 여러 채널들에 뿌리는 형태로.
