Try Dogfooding
도그푸딩이라는 리서치 방법에 대해 한 번씩 들어보셨을 것입니다.
피엑스디에서도 프로젝트 중 도그푸딩을 몇 번 시도했었습니다. 아직 시장 성숙도가 낮은 블록체인 관련 프로덕트를 리딩하며 느낀 점은 사용자를 이해하는 것에 앞서 팀이 프로덕트 관련된 지식을 잘 쌓을 수 있게 돕는 것이 무엇보다 중요하다는 것이었습니다. 특히 간단한 설명만으로는 쉽게 이해한다는 수준에 도달하기 어려운 비즈니스이기에 스스로 만들고 있는 프로덕트가 어떤 환경에서 사용될지 상상하기 어려운 경우도 많은데요, 팀의 이해도를 높이기 위해 시도해 본 여러 방법 중에서 도그푸딩을 시도해 본 경험을 소개해 보려고 합니다.
도그푸딩이란?
ChatGPT의 설명입니다.
도그푸딩이란 회사나 조직이 만든 제품이나 서비스를 직원들이나 내부 사용자가 스스로 사용하는 것을 말합니다. 이를 통해 직원들은 제품이나 서비스를 직접 사용해 보면서, 문제점을 발견하고 개선할 수 있습니다. 또한, 내부 사용자들의 피드백을 반영하여 제품이나 서비스의 완성도와 품질을 높일 수 있습니다.
도그푸딩의 대표적인 예로는 IT 기업들이 자사 제품을 직접 사용하는 것이 있습니다. 예를 들어, 구글 직원들은 구글의 서비스인 구글 검색, 구글 드라이브, 구글 메일 등을 일상적으로 사용합니다. 이러한 방식으로 구글 직원들은 구글 서비스의 문제점을 발견하고 더 나은 서비스를 제공할 수 있도록 개선할 수 있습니다. 또한,
도그푸딩은 제품이나 서비스의 사용자 경험을 향상하는 데에도 큰 도움이 됩니다. 내부 사용자들이 직접 제품이나 서비스를 사용하면서 발생한 문제점을 해결하고, 사용자들이 원하는 기능을 추가할 수 있기 때문입니다. 결론적으로,
도그푸딩은 제품이나 서비스의 완성도와 품질을 높이는 데에 큰 역할을 합니다. 회사나 조직에서 도그푸딩을 적극적으로 도입하면, 보다 나은 제품과 서비스를 제공할 수 있을 뿐 아니라, 직원들의 참여도와 업무 만족도도 높일 수 있습니다.
도그푸딩 도입하기
바쁘게 진행되는 프로젝트에 참여하는 팀원들에게, 도그푸딩이라는 새로운 방법을 소개하고 시간 내어 참여를 유도하는 것은 쉽진 않았습니다. 하지만, 모든 팀원들이 시간을 쪼개어 참여하고 긍정적인 경험을 나누어 준 것에 대해 이 글을 빌어 갑자기 감사드리고 싶습니다. 😂
지난 시간을 짚어 보며 어떻게 진행했는지 그 과정에서 무엇을 얻었는지 따라가 보도록 하겠습니다.
0. 먼저, 어떤 맥락을 가진 프로젝트였는지 소개합니다.
저희 팀은 게임+블록체인+금융이 모두 합쳐진 플랫폼을 만들었습니다. 프로덕트로서의 성숙도는 낮은 편이고, 프로젝트를 시작하며 유사한 목표를 가진 사례를 찾기 어려워 비즈니스 자체를 이해하는데 애를 먹었던 기억이 납니다. 이 비즈니스를 이해하기 위해 사용자를 겨우 찾아 3명, 4명 인터뷰를 진행하며 비즈니스에 대한 이해를 해 나갔습니다. 이와 같은 사용자 인터뷰는 프로젝트 시작 단계 및 프로토타입을 진행하며 총 5회 진행을 했는데 사용자의 의견을 듣는 것은 도움은 되었지만 뭔가 100% 깔끔하게 소화되지 않는 느낌을 받았던 것 같습니다.
어느 순간 사용자의 의견도 좋지만, 팀이 이 비즈니스를, 우리의 프로덕트를 잘 이해하고 있는지 질문하게 되었고, 어떻게 하면 직접 프로덕트를 만드는 사람으로서 이해도를 높일 수 있을지 고민하게 되었습니다. 그때 생각난 방법이 도그푸딩이었습니다. 생소한 분야를 만들고 있기에 더더욱 필요했고, 그래서 모두가 너무나 바쁜 일정을 소화하고 있어 부담이 됐지만 일단 해 보기로 합니다.
- 도그푸딩의 목표 설정하기: 프로덕트의 성숙도를 고려하여 목표를 설정합니다.
앞서 말씀드렸듯이, 일단 저희가 다루는 시장 성숙도도, 프로덕트는 성숙도도 낮습니다. 그렇기 때문에 도그푸딩의 목표를 잘 설정하는 것이 필요했습니다. 일단 가장 먼저 점검해야 할 것은 “우리는 프로덕트의 사업적 목표에 맞게 디자인하고 있는가”를 스스로 점검하는 것이 필요하다고 생각했습니다. 왜냐하면 자칫 잘못하면 너무 구체적인 사용성 관점의 의견 중심으로 모아져 애초에 도그푸딩을 하려는 목표인, 팀의 이해도를 높이는 목표를 달성하지 못할 수도 있기 때문입니다. 우리 스스로가 비즈니스 목표에 잘 얼라인되어 있는지 스스로 디자인한 프로덕트를 평가하며 확인할 수도 있다고 믿었고요.
사실 도그푸딩을 초기 프로덕트 단계에서 시도해 볼 수 있는 것인지 의심을 했었는데요 ‘내가 만들고 있는 제품을 만드는 사람이 아닌 쓰는 사람의 입장에서 경험한다’는 목적만 잊지 말자는 생각으로 시도해 보기로 결정했습니다.
2. 언제 실행할지 결정하기: 팀이 어느 정도 의견을 낼 수 있는 시점을 노립니다.
첫 번째 도그푸딩은 초기 프로토타입 단계에 시도했습니다. 이 시기를 택한 이유는 1) 아직 디자인이 완료되지 않아 새로운 인사이트가 생겨도 수정할 수 있는 여지가 있고 2) 모두가 비즈니스에 대한 이해도를 한층 더 높이면 이후 단계에서 더 도움을 받을 수 있을 거라 예상했기 때문입니다. 결과는 실패였습니다. 실패의 요인은 여러 가지 있었지만 1) 모두의 이해도가 낮았기 때문에 오히려 의견을 내기가 쉽지 않았던 것이 가장 컸고, 2) 프로젝트 진행 속도가 너무 빨랐기 때문에 이 과정이 왜 필요한지 공감을 하기에도 어려웠다 점이 가장 큰 원인인 것 같습니다.
두 번째 도그푸딩은 디자인이 거의 완료된 상태에서 진행이 되었습니다. 결과적으로는 이 시기에 도그푸딩을 진행한 것이 유효했습니다. 1)시간이 흐르며 팀원들의 이해도가 점점 높아지면서 각자 이런저런 의견을 가지고 있던 상태이기도 했었고, 2) 디자인이 거의 완료되어 마음의 여유가 조금 생겼던 것도 중요했습니다. 도그푸딩이 멍석이 되어 여유 있는 마음에 피어나고 있던 각자의 생각을 펼칠 수 있게 도와주었다고 생각합니다.
3. 도그푸딩 질문 구성하기: 우리의 비즈니스가 어떻게 전달될지 구체적인 시나리오로 만듭니다.
앞서 말씀드렸듯이 이번 도그푸딩의 목표는 “우리는 프로덕트의 비즈니스 목표에 맞게 디자인하고 있는가”를 점검하는 것이었습니다. 그러기 위해, 비즈니스 목표를 이해하는 것이 선행되어야 했는데요, 처음에는 이 점을 간과하여 역시 시행착오가 따랐습니다.
첫번째 도그푸딩에서는 아주 단순하게 접근했습니다. 1) 비즈니스의 목표를 하이 레벨에서 이해시키고, 2) 목표를 달성하기 위해 잘 설계가 되어 있는가?라는 질문을 던졌고 3) 이런저런 이유 때문에 잘 반영이 된 것 같아요와 같은 답변을 기대했는데 결과는 완전 실패였어요. 비즈니스 목표를 완전히 이해하지 않는 이상 누구라도 답변하기 어려운 그런 접근법이었습니다. 따라서 비즈니스 목표를 아주 구체적이고 눈에 보이는 형태로 구체화하면 어떨까 하는 생각을 하게 됐어요.
두번째는 도그푸딩에서는 조금 더 고민을 해 보았습니다. 이 비즈니스 목표를 어떤 상황에서 사용자에게 전달되어야 하는지를 고민했고, 조금 더 구체적인 시나리오로 풀어 보기로 했습니다. 또 팀원에게 던질 질문도 좀 더 단계적으로 접근했습니다. 체험해 보고, 평가해 보고, 대안을 제시해 보는 과정으로 말입니다. 결과적으로는 훨씬 접근하기 쉽고 구체적인 답변을 많이 얻을 수 있었기 때문에 나름대로 성공적인 방법이었다고 생각합니다.
4. 도그푸딩 실행하기: 끊임없이 알림을 주고 독려해야 합니다. 열심으로요.
목표를 세우고 질문까지 준비를 했다면 이제 도그푸딩을 실행해야겠죠. 도그푸딩이 잘 진행되게 하기 위해서는 바쁜 팀원들이 잊지 않고 참여할 수 있게 끊임없이 알려 주고 독려하는 리더의 열심이 필요합니다. 처음에는 “오늘 꼭 해주세요~”라는 공지를 하고 끝냈더니 프로젝트 인원의 10%도 안 되는 인원만이 참여했더라고요. (그 10% 분들께 눈물 나게 고마웠던 기억이 납니다.)
두 번째 도그푸딩에서는 1) 모든 팀원이 의견을 잘 작성할 수 있게 샘플 답변도 시간을 들여 미리 작성도 해 두었고, 2) 제가 생각한 참여 목표(80% 참여)에 이를 때까지 2시간에 한 번씩 슬랙 공지를 보냈었습니다. 원래 나 하나쯤이야… 참여하지 않아도 괜찮겠지… 싶다가도 다른 사람들이 쓴 의견을 보면 내 의견도 떠오르고 적고 싶고 그런 심리가 있잖아요. 결과적으로 모든 인원이 참여하여 좋은 의견을 내주었습니다. 성공! 😃
5. 피드백을 검토하고 개선하기: 모든 의견을 함께 검토해 보는 시간이 결과적으로 긍정적인 경험을 만들었습니다.
우리가 잘 아는 더블 다이아몬드를 생각해 볼까요. 지금까지 다이아몬드를 넓히는 과정이었다면, 지금부터는 다이아몬드를 좁혀 개선을 하는 과정으로 진입해야 합니다.
시트에 빼곡하게 모아진 의견을 다시 화면 단위로 정리하여 빠르게 개선할 수 있게 준비하는 것이 필요했습니다. 이 과정을 위해서 화면 단위로 피그마 파일에 의견을 쭉 정리했고, 이후 모든 팀원이 서로 제시했던 의견을 함께 살펴보며 왜 이 영역이 문제로 제시되었는지, 개선해야 할 점은 무엇인지, 어떻게 개선하면 좋을지, 빠르게 되어야 할 부분은 무엇인지 우선순위를 나열해 보는 등 의견을 나누었습니다.
이후, 2개의 팀을 이루어 좀 더 구체적으로 개선안을 정리해 보는 시간이 있었는데요, 저는 이 단계가 팀원들에게 도그푸딩이 할만한 액티비티구나…라고 생각하게끔 만든 영향을 끼쳤다고 생각합니다. 그 이유는 세가지인데요, 1) 내 생각과 다른 팀원들의 생각을 들어볼 수 있다는 점, 그리고 2) 화면의 완성도에 집중하느라 못 보고 있었던 플랫폼을 관통하는 시나리오를 생각해 볼 수 있었다는 점, 3) 그리고 함께 이야기를 나눈다는 것입니다. 화면 단위, 모듈 단위로 업무가 진행되면 진행하는 모듈 외의 부분에 대해서는 이해도가 더 낮아지고 프로덕트의 큰 그림을 보기 어려울 수도 있습니다. 예를 들어 게임을 담당하는 사람이 GameFi(게임을 이용한 블록체인 금융 서비스)를 제대로 알기 어렵고, GameFi를 담당하는 사람이 NFT에 대해서 알기 어렵습니다. 이 상황에서 전체 화면을 나열해 보고 도그푸딩으로 제시했던 시나리오가 잘 연결될지 확인하는 과정은 프로덕트를 객관적으로 경험하는데 큰 도움을 되었습니다. 또, 당시 거의 모든 업무가 재택으로 진행된 가운데 왁자지껄 자유롭게 이야기를 나눌 수 있는 분위기를 오랜만에 맞이한 것도 도그푸딩이 긍정적이라고 느낀 데에 한몫했을 것 같습니다.
6. 회고를 통해 프로세스를 다듬고, 팀의 프로세스로 내재화 하기
도그푸딩이라는 새로운 시도를 해 봤다면 팀원들이 실제로 어떻게 받아들였는지 되돌아봐야겠지요. 긍정적인 프로세스로 느껴졌다면 정규 프로세스로 내재화시키고, 굳이 할 필요 없는 프로세스라고 느껴졌다면 이번 시도가 마지막이 될 수도 있겠지요. 다행히 팀의 긍정적인 의견, 개선 방향 등을 바탕으로 도그푸딩을 내부에서 밟아야 할 프로세스로 정착시키는 노력을 하는 중입니다. 아주 많은 열심이 필요할 테지만요.
도그푸딩 후 실제 개선까지 해나가는 과정들이 고객사의 제품(요구사항을 잘 반영해주는)이 아닌, 우리의 제품을 만드는 자세(적극적, 주도적)를 갖추기 위한 좋은 연습이 되는 것 같다. 다만, 론칭 후 GA와 함께 진행한다면, 또는 개선 결과를 AB테스트와 같은 방법으로 테스트해 본다면 더 효과적일 것 같다. 또한, 처음이라 그런지 콘텐츠나 기능을 추가하는 방향의 아이디어가 주로 나왔었던 것 같다. 예를 들면 팝업을 띄우자, 히어로 영역을 추가하자 등등. 앞으로 더 많은 경험이 쌓이면 기존에 진행했던 내용을 해치지는 않는지, 어떤 것을 최우선으로 강조하는 게 맞는지, 복잡해지지는 않는지 등에 대한 고려가 많이 필요할 것 같다. — SH
나의 관여가 높았던 모듈은 한 발 물러나 다시 보게 하고, 관여가 적었던 부분은 더 가까이 들여다보게 한다. 내가 깊게 관여하지 않았던 모듈이나 기능을 비틀어 보는 과정에서 새로운 관점의 아이디어를 내볼 수 있는 것 같다. 그러면서도 서로가 비슷한 얘기를 하는 지점이 있었는데 이것은 제품 전반에 걸친 보완점임을 인지하는 계기가 되었다. 그리고 다음에는 이렇게 해보면 더 좋겠다. 체험 가능한 디바이스를 모두 세팅하고 사용하기. 사용해 볼 수 있는 모든 디바이스를 미리 준비해 놓고 돌려보면 반응형 디자인이 더 적나라하게 드러날 것 같다. 특히, PC 모니터는 주요 해상도별로 세팅해 놓고, 휴대폰은 노치와 엣지, 일반형을 모두 준비하면 미세한 부분을 더 체크할 수 있을 것 같다. — HB
일반적으로 도그푸딩은 자신들이 만든 서비스를 사용자 입장에서 사용해보면서 문제점이나 개선 포인트들을 찾아내는 것인데, 우리는 서비스가 오픈되기 전, 개발도 이제 막 시작되는 단계에서 하다보니 ‘이걸 내가 지금 말해도 될까?’ 싶은 이슈들을 조금은 편하게 이야기 할 수 있는게 좋았습니다. 또, 도그푸딩을 하다보니 내가 맡은 모듈 외에 다른 모듈들과 담당한 모듈과의 연관성들도 쉽게 파악이 되어서 맡은 모듈에 대한 기획이나 디자인에 대해서 자연스럽게 한번더 고민해볼 수 있게 하는 역할도 해주는 것 같았어요. (아 익명으로 작성하니까 주니어분들도 하기 어려운 얘기를 좀 더 편하게 작성할 수 있지 않았나 싶습니다 ㅎㅎ) 다만, 개발되기 전이라 키스크린이나 프로토타입핑만으로 도그푸딩을 해야되다보니 도그푸딩을 하는 것 자체가 조금은 수월하지 않았던 것 같고, 이제 서비스가 곧 오픈될 예정이니까, 서비스 오픈 후에 도그푸딩을 전사적으로 그리고 주기적으로 하면 좋을 것 같아요~ — JH
시행착오를 통해 얻은 체크 포인트
✅ 프로젝트의 목표와 개발 단계를 고려하여 도그푸딩의 목표를 설정
✅ 도그푸딩의 목표를 팀원이 이해할 수 있는 시나리오로 잘 번역
✅ 모든 팀원이 도그푸딩 피드백을 함께 보고 공감하는 과정을 꼭 강조
✅ 제안한 피드백이 100% 개선사항으로 연결되는 것은 아니라는 점을 이해하는 것도 중요. 도그푸딩이라는 액티비티 자체의 의미를 이해하고 팀에 도움되는 방향으로 활용하는 것이 필요
✅ 리더는 팀원이 도그푸딩을 잘 진행할 수 있게 독려
마치며
도그푸딩은 ‘내가 만들고 있는 프로덕트를 만드는 사람이 아닌 쓰는 사람의 입장에서 경험한다’는 취지의 액티비티입니다. 특히 프로젝트가 일상적이고 익숙한 내용이 아니라면 만드는 사람들은 쓰는 사람에 빙의하기 앞서 내용을 이해하기에도 바쁘기 마련이지요. 사용자 조사를 하며 프로토타입을 정교하게 업데이트하는 과정과 함께 팀원 스스로 사용자의 환경을 배우고 느끼는 과정이 중요하다면 도그푸딩을 시도해 보는 것이 하나의 방법일 것 같습니다.
