림보는 '정보의 단계' 자체를 구분하지 못하는데에서 온다.
설문으로 PMF 찾는 스타트업? 그냥 동아리다.
가끔 스타트업과 얘기하다보면 대면 인터뷰 없이 설문조사를 기준으로 지난 3-6개월간 프로덕트를 만드는 조직들을 본다.
구글 폼, Tally로 설문조사를 때로는 몇백개 돌리고, Notion에 정리한뒤에 고객이 원하는 기능을 만들고 있다고 생각하곤 하는데, 이는 의도적인게 아니라, 잘 몰라서 이렇게 하는 경우가 99%이다.
처음엔 조용히 혼자 한숨을 쉬곤 했지만, 요즘은 빨리 도와드려야 겠다 생각을 한다.
파운더의 이러한 림보는 '정보의 단계' 자체를 구분하지 못하는데에서 온다.
우리가 새로운 기능이나 런칭한 솔루션으로 고객을 설득할 때 알아야 할 정보는 크게 두 가지다.
1️⃣ 맥락적인 정보 (Contextual Insight)
· 고객이 실제로 겪고 있는 상황과 그 안에서 느끼는 감정.
· 문서로 정리하기 힘든, 오묘하고 개인적인 맥락.
· 케이스마다 다르고, 특정 고객에만 해당될 수도 있는 “Why”의 영역.
2️⃣ Binary한 팩트 기반 정보 (Fact-based Filter)
· 고객을 필터링하기 위한 Yes or No 로 떨어지는 정보. And/or
· 시장 크기, 예산, 기술 스택, 인증 여부 같은 구체적이고 단순한 데이터.
예를 들어, 데이터 거버넌스 솔루션을 만든다고 하자.
맥과 크롬 환경에서 DB 접근제어가 가능하고, ISMS 인증을 받고 싶어하는 개발자/DBA들을 타겟팅한다고 가정해보자.
A. 여기서 맥락 정보는
왜 DB 접근제어 툴임에도 불구하고 결제 승인 기능이 중요한가?
=> 민감정보를 다루는 DB 쿼리를 할 때 리걸팀, CTO 승인을 동시에 받아야 하는 실무 상황 때문.
이걸 이해하면, 결제 및 쿼리 로그를 남기는 아키텍처 설계, 어떤 기능을 먼저 만들어야 할지, MVP의 핵심이 무엇인지까지 세세하게 감을 잡을 수 있다.
B. 팩트 정보는
· 어느 규모의 IT 기업인지? (1-10인, +1000명, 또는 Series A 이후 단계 등)
· 맥북을 쓰는 개발자 비율이 높은지?
· ISMS 인증을 매년 받고, 이를 위해 연간 X천만 원단위의 예산을 집행하는지?
등 이건 Yes or No 또는 단위로 필터링하는 데 쓰는 정보다.
CTA.
따라서 위 개념을 고객 인터뷰에 적용해보면,
1/ 직접 파운더가 필드에서 파악해야 하는 것
*절대 설문조사로는 못 한다. 심지어 비대면 줌콜도 위험하다.
· 왜 우리 솔루션을 찾아왔는지.
· 이 문제가 왜 유독 당신에게 아픈지.
· 어떤 대안을 시도했는지.
이 답변들은 우리 솔루션의 "Why", "How", 그리고 제품의 온도감을 구체적으로 알려준다.
2/ 데스크 리서치로 파악해야 하는 것
*이건 위 같이 난이도 있는 대면 인터뷰의 정확도를 높여주는 준비 과정이다.
· 고객사 최근 투자 유치 내역 (버짓 확인)
· 담당자 기술 스택
· 조직 구조 (의사결정권자 여부)
· 데이터거버넌스 툴의 예시로 돌아가서, ISMS 인증을 갱신 주기 등
지금까지 대면 인터뷰 없이, 설문조사 몇백 개 돌려서 지난 3–6개월간 제품을 개발했는가?
냉정하게, 그냥 창업 동아리라고 보면 된다.
이는 우리가 그저 만들고 싶은 걸 만드는 조직이며, 팀이 이미 내린 결론에 확증하기 위해 설문조사를 하는 것에 가깝다고 시인하는것과 같다. 창업팀은 이렇게 서서히 무한 SISP(Solution-in-search-of-the-Problem) 루프에 빨려 들어간다.
결국, 초기 고객 인터뷰는 감정과 컨텍스트를 직접 느끼고 팩트는 조용히 조사해서 보완하는 Iteration 게임이다. 매번 인터뷰 이후에 망치로 머리에 맞은 듯한 깨달음이 있어야 한다. 설문지 돌리면서 PMF를 찾았다고 말하지 말자.
그건 그냥 취미이자 창업 동아리이다.
____
· 사진은 Kinloch Laggan에서 만난 Hairy Coo.
· 실리콘벨리를 품는 창업가들을 위한 영어 뉴스레터 - https://lnkd.in/gK67Fw_u
· 생산성의 두가지 모드 - https://lnkd.in/g2qRqHss