| AI 사업 오픈 채팅방 (암호: gpters)를 운영하고 있습니다. AI와 프로덕트 마켓 핏에 대해서 대화를 나눠요! |
빌딩 밖으로 뛰쳐 나가서 고객과 대화를 하라! 이 만트라가 유명한 정도에 대비해서, 실제 뛰쳐 나가서 어떻게 하라고 친절히 알려주는 책은 잘 없다. 최근에 스터디파이 린스타트업 스터디가 기회가 되어서 신디 알바레즈의 Lean Customer Development를 읽게 되었는데 이 책이 몇 권 안되는 책 중에 하나이다.
나중에 참고 하기 위해서 이 책의 내용을 요약해 봤다
1. Lean Customer Development
이 책은 먼저 왜 고객 개발이 필요한지부터 시작한다. 요즘은 뭐 스타트업 쪽에서는 이 개념을 모르는 사람을 찾는게 더 어려우니 패스하고 … 그 다음에 그럼 어떻게 시작하지 라는 질문에 저자가 답을 준다. 당신의 제품(혹은 비즈니스)의 가정(Assumption)을 아래와 같은 포맷으로 써 보라고 한다
- 나는 (누가) (어떤 일)을 할 때 (어떤 문제)를 가지고 있다고 생각한다
그리고 저 사람이 누구인지, 나이-성별-지역 이런 구시대 마케팅에서나 다루는 데모그래픽이 아닌 정말 저런 가정에 딱 들어 맞는 사람이 누구인지 특정지어 찾아서 대화를 하라고 한다.
2. Interview Questions
감사하게도 대화를 나눌 때 사용할 수 있는 기본 인터뷰 질문들도 제공해 주셨다.
Development interview
- 최근에 가장 마지막에 ___ 했던 것에 대해 얘기해 주세요
- 만일 오늘 어떤 문제든 하나를 해결해 준다고 하면, 어떤 것을 해결하고 싶나요?
- 문제를 해결하기 위해 현재 쓰는 제품이나 서비스가 있나요? 자세히 알려 주세요
- __ 제품을 쓰기 시작했을 때 어떤 기능을 기대하였었나요?
- 얼마나 자주 _____을 하나요? 지난 달에 몇번이나 하셨나요?
- 그 문제가 발생했을 때 비용이 얼마나 들게 되나요?
- 또 누가 이 문제를 심각하게 겪고 있을까요?
- ___을 하기 직전에 준비하기 위해서, 혹은 직후에 하는 일이 있나요?
Questions for existing products
- 우리 제품을 사용하기 직전에 하는 일이 있나요?
- 우리 제품에서 가장 유용한 그리고 가장 자주 쓰는 기능은 어떤것인가요?
- 만일 요청한 피처가 오늘 구현된다면, 그게 어떤 문제를 해결해 주는가요?
- 다른 사용자들은 _____ 문제가 있다고 하는데 겪어본 적이 있나요?
인터뷰를 통해서 학습해야 할 내용은 (고객이 자신의 행동을 예측하는 내용이 아닌) 고객이 실제 했던 과거 행동이다. 문제가 있었다면 그 문제를 해결하려고 뭔가를 했을 것이다. 하지 않았다면 문제가 아니거나, 그 사람이 우리가 찾던 고객이 아니거나 둘 중 하나이다.
저자는 인터뷰를 진행할 때 필요한 핵꿀팁을 하나 남겨 주셨다. 5명을 인터뷰하고 나서 아주 유망한 고객을 만날 수 없다면, 그 가정은 Invalidated 된 것이라고 한다. 그리고 더 이상 새로운 것을 발견할 수 없을 때 인터뷰는 그만 해야 한다는 … 인터뷰를 언제까지 해야 하는지에 대해 명확한 기준을 제시해 주었다.
실제 제품이 이미 있는 경우는, 실제 고객들이 우리 제품을 어떻게 쓰는 지 보는 것이 큰 도움이 된다고 한다. 책에 있는 내용은 아니지만, 이런 방법을 활용해서 슈퍼휴먼과 같이 Product-Market Fit을 엔지니어링 할 수도 있을 것이고.
3. MVPs
정성적으로 고객을 이해하고 나면, 자 이제 이 사람들이 나도 달라고 애원할 제품을 디자인을 하면 된다. 그리고, 그 제품을 만들기 전에 진짜 그 생각이 나 혼자만의 생각은 아닌지 다시 고객을 통해 확인 해야 한다. 그때 여러 가지 방식의 MVP(Minimum Viable Product)들이 사용된다 (MVP의 개념을 모르신다면 린스타트업이나 Four Steps to Epiphany 책으로 다시 돌아가 보시길…).
책에 나온 MVP의 종류
- Pre-order MVP
- Audience Building MVP
- Concierge(= Wizard of Oz) MVP
- Single Use Case MVP
- Other People’s Product MVP
- Story telling MVP
각 MVP의 뜻은 이름에 거의 나와있다. 아 귀찮지만, 그래도 한 줄 요약을 해 보자.
Pre-order MVP는 제품 소개 만으로 고객이 구매 전환 될 수 있는지를 보는 MVP이다. Wix.com 혹은 카페24 등으로 만들 수 있겠다.
Audience Building MVP는 어떠한 문제를 해결하려 하는 커뮤니티 활동을 하는 것으로 사전에 고객을 만들어 가는 것이다. 우리 나라에선 단톡방, 네이버 카페 정도?
Concierge MVP는 내가 가장 좋아하는 방식이다. 제품이 제공해야 할 기능을 사람이 다 제공하는 것이다 ㅋㅋ 이거 개발자 없이 할 수 있고, 몸으로 고객에게 어떤 서비스를 제공해야 할지 배우는 거라 참교육 받을 수 있다.
Single Use Case MVP는 고객 문제를 해결하려면 여러 기능이 있어야 하나, 그 중 하나의 기능만으로 제품을 만들어서 실제 사람들이 Engage되는 지 보는 방법이다.
Other People’s Product MVP는 다른 사람의 제품을 우리 제품인것 처럼 제공해서 검증하는 방법이다. 그 제품이 더럽게 비싼데 우리가 싸게 만들어 제공할 수 있다면 요 방법이 유용할 것 같다.
Story Telling MVP는 가상의 인물이 제품을 사용하는 스토리와 비주얼을 보여주면서 고객의 반응을 보는 방법이다. 어떤걸 어디에 써야 할지는 각자 고민해 보시길.
4. Ongoing customer development
이미 제품이 돌아가고 있는 상황에서 고객 개발을 하는 경우이다. 창업을 하는 경우가 아니면 대부분이 여기에 해당한다. 요컨데, 고객과 접점이 있는 모든 팀원들이 모두 고객에 대해 더 학습할 수 있도록 프레임워크를 제공해 주기, 고객이 제품을 어떻게 쓰는지, 고객이 제품을 어떻게 다른 사람에게 묘사하는 지 확인하기, 고객 개발의 과정을 팀원들과 잘 공유해서 모두가 잘 이해하게 하기, 등의 실제 실행 방법을 제공하고 있다.
의견: MVP 만들기 전의 사업 검증
나의 경험에 비춰 볼 때, 고객 개발의 핵심은 … 그놈의 사랑하는 고객을 특정하고 찾아 내는 것이다. 나머지 부분은 상대적으로 쉽다고 생각한다. 보통 주변을 봐 보면, 고객을 찾는데 어려움을 겪는 분들은 별로 없어 보인다. 근데 그게 진짜 문제이다. 정말 고통을 느끼고 있는 고객을 찾아서 그 사람들이 현재 그 고통을 피하기 위해서 발버둥 치는 그 생생한 경험을 들어야 하는데 … 보통 그 정도로 고통스러운 고객을 찾지 못하고 (실제로 X나 어렵다, 이런 사람들 찾는 것 말이다 …), 어느 정도 고객 군에 들어오는 사람을 인터뷰 하는 것으로 만족하는 것이다. 그러면 약간은 엇나간 고객들의 말을 듣고 제품을 개발하게 된다.
예를 들어, 레퍼런스 체크를 API로 제공하는 SaaS 사업을 하는 곳이 있다고 하자 (그래, 그 사업 구상중이다 ㅋㅋ). 배달 시장이 폭발하고 있으니, 배달 라이더를 채용하는 쪽에서 이런 API에 대한 수요가 있다고 판단할 수 있다. 즉, 배달 라이더 채용팀이 라이더 지원자가 미래에 사고 칠지 안 칠지 사전에 파악하는 게 너무 어렵다고 생각할 수 있다. 그런데, 아이 돌봄 서비스를 제공하는 회사를 생각해 보면, 그 경중이 엄청난 차이가 난다. 음식 배달을 맡길 사람 vs. 내 아이를 맡길 사람. 당연히 아이 돌본 서비스 회사가 훠얼씬 고통을 느끼는 고객일 것이다.
또 하나는, 진정 핵심 고객을 찾아 낸 다음에는 그 사람들의 현재 대안에 대해 100% 이해한다면, 우리가 제시하려는 제품이 사용자 반응을 끌어 낼 수 있을지 대략 감이 온다. 진짜 이건 생각보다 더 명확하게 답이 나온다. 그래서 아주 초기의 고객 개발 활동이라면, 애시당초 MVP까지 만들 일도 잘 없다.
예를 들어, 아까 얘기한 레퍼런스 체크 사업을 다시 한번 생각해 보자. 아이 돌봄 서비스 회사에서도 엄마들이 자식을 맡길 돌봄 선생님이 문제가 없는지 확인하는 것을 정말 중요하게 생각하고 있었다. 그래서 회사가 현재 하고 있는 레퍼런스 체크 방법은 (1) 아직 때묻지 않은 대학생을 주로 매칭하고, (2) 범죄 기록은 경찰서를 통해서 확인하는 것을 하고 있었다. 이 상황에서 10배 더 나은 솔루션은 아마도 API로 범죄 기록을 확인하는 정도 일텐데, 이건 경찰청장 아버지가 없는 경우라면 어려우니 … 기존 대안보다 더 나은 SaaS API를 제공하는 것은 당장은 어려워 보인다. 물론 더 알아보면서 10x 더 나은 솔루션을 찾을 수도 있겠지만, 지금 고려 중인 솔루션이 있는 그대로의 모습으로는 나가리라는 것은 쉽게 알 수 있다.
이 두 가지 — 핵심 고객을 찾는 것과 그 고객의 현재 대안으로부터 솔루션을 검증하는 것은 어떤 MVP도 만들지 않고 사업의 일부를 검증하는 것이기 때문에 전체 고객 개발에 들어가는 시간을 가장 아껴줄 수 있다. 예를 들어, 이 사전 검증은 몇 일 ~ 1개월 걸린다면, MVP 검증은 MVP 기획, 개발, 테스트, 회고를 포함하기 때문에 대략 수 배 이상의 시간이 걸린다.
그럼에도 불구하고 MVP 이전 검증을 실제 빡세게 진행하는 스타트업 창업자나 신사업 PM을 많이 만나 보지는 못했다 (오히려, VC들이 더 활용하지 않나 하는 생각이 든다). 왜냐하면 이 부분이 불안해지고 우울해지기 쉬운 과정이기 때문이다. 우리가 뚜렷한 비전을 가지고 그걸 준비해 나가는 과정에서는 그 일에 집중할 수 있고 조그만 성과 하나 하나에 동기 부여를 받을 수 있다. 하지만, 이 MVP 이전의 사전 검증 과정은 백지에 무얼 그릴까 고민하고 알아 보는 과정이다. 이 산업, 저 산업을 번갈아 가며 봐야 하고, 좋다고 생각했던 사업 아이디어가 검증에 떨어져 나갈 때 이젠 뭘 하지라는 불안함과 우울함이 찾아 온다. 그래서 대부분 사전 검증을 빡세게 하지 않거나, 현실을 직시하지 않고 즐거운 MVP 검증 과정으로 넘어간다.
물론 대부분의 사업이 이런 체계적인 방법으로 잉태되는 것도 아니고, 결국 성공의 가장 큰 선행 지표는 실행력과 그릿(Grit)이라는 데 나도 동의한다. 하지만, 시간을 더 효과적으로 사용하기 위해서는 고객 개발 실무에서 MVP 이전의 사업 검증이 큰 역할을 할 수 있다.
| AI 사업 오픈 채팅방 (암호: gpters)를 운영하고 있습니다. AI와 프로덕트 마켓 핏에 대해서 대화를 나눠요! |
