최근 Dataframe은 프로덕트의 타겟과 방향을 *피벗하고 Prequel.ai로 다시 태어났습니다. Prequel의 비전은 “All-In-One Workspace for data analysts” 데이터 분석가를 위한 올인원 워크스페이스가 되는 것인데요. 조금 더 설명하면 기존에는 쿼리 하나를 쓰기 위해서는 여러가지 툴과 문서를 뒤지거나 직장 동료에게 물어가며 데이터에 대해 먼저 파악해야 했고, 쿼리를 쓰고 난 후에도 그 결과를 따로 문서화해야만 했습니다. 하지만 Prequel은 위의 모든 SQL Workflow를 단 하나의 툴에서 손쉽게 할 수 있도록 만들어 데이터 생산성을 높입니다.
*Pivot(피벗): 피벗은 현 비즈니스의 일부를 중심축으로 회전, 전환, 혁신을 모색하는 것
Prequel에 대한 사전 설명은 이만하는 거로 하고 다시 글의 주제였던 Dogfooding에 대해 얘기해볼게요. 위에 설명드린 Prequel처럼 특정 ‘인더스트리’, 특정 ‘직업군’을 타겟으로 하는 프로덕트인 경우는, 프로덕트를 만들어가기 위해서 해당 인더스트리와 유저에 대한 이해가 필수적입니다. 혹시 프로덕트를 만드는 디자이너, PM/PO, 개발자, 기획자로서 유저에게 공감하기 위해 어디까지 해보셨나요?
내가 만드는 프로덕트의 유저에게 공감하기 위한 가장 빠른 방법은 바로 Dogfooding 입니다. Dogfooding? 개밥먹기? 저도 이 용어를 처음 들었을 때 이게 대체 무슨 소리지? 했는데요. Dogfooding(개밥먹기)은 자신의 제품이나 서비스를 직접 사용하며 테스트하는 방법입니다.
Dogfooding — Eating your own dog food
자신의 제품이나 서비스를 직접 사용하며 테스트하는 방법
이 용어는 애완견 사료 제조업체인 마스(Mars)의 경영진이 실제로 오래전부터 자기들이 생산하는 개 사료를 직접 먹은 것에서 비롯되었다고 합니다. 또 1988년, Microsoft 매니저 Paul Maritz가 테스트 매니저 Brian Valentine에게 “Eating our own Dogfood”이라는 제목의 이메일을 보내 직원들이 자사 제품을 더 쓰도록 요청하면서 용어의 사용이 회사 전체로 퍼졌다고 하네요.
저도 저희 회사 제품인 Prequel을 이용해 Dogfooding을 하고자 했으나 하나의 큰 문제가 있었습니다. 바로 저는 *Data analyst가 아니고 *SQL을 사용할 줄 모른다는 것이었죠. 이 부분이 대중을 타겟으로 하는 이커머스 혹은 프로덕트와 가장 다른 부분 같은데요. 특정 분야의 지식이 부족하면 프로덕트를 직접 사용해보기도 어렵고, 유저에 대해 공감하기가 정말 어렵습니다. 지난 기간 동안 데이터 인더스트리에 대해 꾸준히 공부해오긴 했지만, 아직 데이터 분석가의 워크 플로우를 온전히 알지 못했고, SQL의 대략적인 형태는 알았지만 제가 쓸 수 있는 단계는 전혀 아니였습니다.
*Data analyst(데이터 분석가): 데이터를 해석해서 비지니스 의사결정을 돕는 정보로 만드는 사람으로 주로 SQL, R, Python 등의 언어를 사용합니다.
*SQL(Structured Query Language): 관계형 데이터베이스에서 데이터를 정의, 조작, 제어하기 위해 사용되는 표준 프로그래밍 언어로 우리가 흔히 아는 html, python과 같은 언의 한 종류입니다.
고민을 조금 하다가 저희 팀의 다른 디자이너님과 SQL을 함께 공부하기로 했어요. SQL 초급 강의를 수강했고 며칠 동안 수업을 들으면서 기본적인 SQL 문법에 대해 학습하고 직접 SQL을 쓰며 공부했습니다. 사실 수업을 들으면서 왜 이제야 SQL을 공부했을까 후회했을 정도로 만족도가 높았는데요. 이유를 정리해보면 다음과 같습니다.
유저의 페인 포인트에 공감할 수 있다.
유저의 주 사용 언어인 SQL을 배우면서 유저의 페인 포인트에 대해 공감할 수 있었습니다. 그리고 우리 프로덕트가 주는 가치, 프로덕트의 존재 이유에 대해서 몸소 깨달을 수 있었어요.
예를 들면 이런 식인데요. 저는 이번에 언어를 배우는 동안 저희 프로덕트 Prequel이 아닌 DBeaver라는 프로그램을 사용했습니다. 그런데 여기서 SQL 즉 쿼리를 쓰기 위해서는 어떤 정보가 어디에 담겨있는지를 먼저 알아야 했는데 DBeaver에서는 알 수가 없었어요. 계속해서 여러 정보를 뒤져가며 찾거나 이미 적혀진 설명을 참고해야 했습니다. 이것이 바로 Prequel의 존재 이유인데요. 그전에는 이 모든 과정을 매니저에게 설명으로 듣거나 글을 읽고 이해했다면 지금은 몸소 깨달은 거죠.
내가 만드는 프로덕트와 그 기능에 대해 정확히 이해할 수 있다.
사실 제가 프로덕트를 디자인하면서도 그 기능과 그 필요성에 대해 완전히 이해하지 못하는 경우도 간혹 있었는데요. 지금까지는 PRD(Product requirements document)를 보면서 제가 이해한 만큼 최대한 논리적인 디자인을 했었다면 언어를 배우는 과정에서 제가 이미 디자인했던 기능들이 떠오르면서 “아, 그래서 이런 기능이 필요했구나”, “이런 기능은 너무 중요하겠다”라는 생각이 들었습니다.
Dogfooding이 가능해진다.
이제 Dogfooding이 가능해졌습니다. 물론 제가 저희 유저인 데이터 분석가만큼 전문적으로 SQL을 쓸 수 있는 것은 아니지만, 초보 데이터 분석가의 마음으로 “자 그럼 이제 무엇을 봐야 하지?”, “무엇을 써야 하지?”라는 생각을 가지고 직접 프로덕트를 사용해보기 시작했어요.
유저의 입장에서 니즈를 찾고 기능을 제안할 수 있다.
그렇게 사용을 하기 시작하자 그제야 정말 수많은 니즈가 눈에 들어오더라고요. “이건 너무 불편하네, 단축키가 있으면 더 편하겠다.”, 또는 “이 탭에 들어가면 이런 정보를 기대할 것 같은데 다른 정보가 나오네” 이런 생각이 하나 둘 쌓이기 시작했습니다. 더 이상 프로덕트를 만드는 사람의 시각이 아닌 프로덕트의 사용하는 사람의 시각으로 프로덕트를 바라볼 수 있게 된 것이죠.
이번의 경험을 통해서 하나 깨달은 것이 있다면 ‘유저에게 진심으로 공감하기 위해서는, 직접 유저가 되는 수밖에 없다’ 라는 것입니다. 아무리 전해 듣고, 읽고, 찾아보더라도 사람은 직접 경험하지 않으면 깨달을 수 없는 것 같아요.
입사 초반에는 완전히 새로운 데이터 인더스트리와 유저에 대해 이해하는 게 너무나 어려웠고, 디자이너로서 유저에게 직접 공감할 수 없다는 게 가장 아쉬운 점이였는데요. 방법은 유저가 되는 것이었는데 고민만 너무 오래 한 것 같아 조금은 아쉽기도 합니다. 혹시나 저처럼 유저에 대한 공감에 대해 고민하고 계신다면 오늘부터 직접 유저가 되어보는 거로 해요!
