1편에서는

1. 리서치 방법론의 종류

2. 목적별 리서치 방법의 차이에 대해 사례를 들어 얘기해보았는데요.

🔗 B2B 프로덕트 디자이너가 고객을 만나는 법 1편 보러가기

2편에서는

3. 리서치의 필요성에 대해 구성원들을 설득하는 방법과

4. 유저 리서치 과정에서 어려웠던 점과 배운 점에 대해 자세히 적어보겠습니다 🙂

당시 원골 스쿼드 구성원들은 고객 인터뷰의 중요성을 그렇게 잘 알지 못했어요. 특히 Dayle은 PO인 David을 설득하기 위해 같이 ‘더 맘 테스트’라는 인터뷰 강의를 함께 듣고 서로에 대한 생각을 이야기하기도 했었죠. 이 시간을 계기로 어느 정도 고객 인터뷰에 대해 시간을 투자해볼 수 있겠다는 합의점을 끌어올릴 수 있었습니다.

그 결과 리더 인터뷰를 9건 정도 진행했고, 퍼소나 중 리더가 실제로 목표 제품을 사용하면서 어떤 어려움을 겪고 있는지 ‘주기적’으로 관찰하는 게 중요하겠다는 점을 원골 스쿼드 구성원 모두가 깨달은 계기가 되었어요.

Dayle의 설득 경험을 바탕으로 저 또한 웨이브 스쿼드에서 ‘고객 경험 인터뷰에 대한 중요성’을 어필했습니다. 저는 강의를 들을 시간이 부족했기 때문에 책이나 아티클과 같은 많은 자료를 활용했는데요. 특히 B2B에서 고객을 직접 만나 고객에 대한 정보를 모두 수집하는 것이 왜 중요한지에 대해, 책이 설명하는 내용 일부와 제 실제 실패 사례를 들어서 자료를 만들어보기도 했습니다. 그 자료를 바탕으로 워크숍을 진행했고, 이 시간을 통해 PO와 엔지니어분들 모두 자연스럽게 고객 인터뷰를 통한 가치 검증이 얼마나 중요하고 의미 있는지 이해할 수 있게 되었어요.

디자이너는 제품팀 말고도 다양한 관계자와 협업하게 되는데요. 그중에서도 B2B 분야에서는 특히 비즈니스팀과의 업무 소통이 가장 중요합니다. 고객과 직접적인 소통을 가장 많이 하는 팀이기 때문이죠. 비즈니스팀이 고객을 만나는 수많은 순간마다 제품팀이 필요로 하는 정보를 잘 수집해 오실 수 있도록, 제품팀이 알고 싶은 내용과 제품 방향성에 대해 비즈니스팀과 최대한 싱크를 맞추려 하고 있습니다.

비즈니스팀이 고객에게 전달받은 내용을 정리해서 제품팀에 공유하는 내용 정도로는 고객의 문제가 발생하는 정확한 맥락을 파악하는 것이 어려울 때가 종종 있는데요. 이때 디자이너로서 문제를 뾰족하게 해결하고 맥락을 더 잘 이해하기 위해서라도, 비즈니스팀이 수집해오는 VOC 파악과 유저 리서치의 병행이 반드시 필요하다고 생각합니다.

참고로, Dayle은 유저 리서치의 목적에 대해 비즈니스팀과 싱크를 맞추려고 <사용자 리서치 구분 유형> 문서를 준비해서 공유하기도 했어요.

다시 말해, 비즈니스팀의 미팅 목적과 유저 리서치 인터뷰의 목적이 다르다는 사실을 비즈니스팀 분들에게 전달하고 생각을 맞추기 위해 만들어진 문서입니다.

일반적으로 비즈니스팀의 경우에는 세일즈가 가장 큰 목적이기 때문에 장점 위주의 어필, 구매자가 필요로 하는 스펙 수취가 미팅의 주요 목적이 될 때가 많죠. 그러나 사용자가 실제로 겪고 있는 문제는 구매자가 원하는 스펙 이면에 숨겨져 있는 경우가 많습니다.

더불어 비즈니스팀의 입장에서는 ‘이미 우리가 고객을 많이 만나왔고 고객의 소리를 제품팀에 전달했는데, 왜 또 유저 리서치 인터뷰를 더 하지? 비효율이 아닌가?’라고 생각할 수 있지요.

이런 측면에서 유저 리서치의 필요성, 비즈니스팀도 고객을 만날 때 이 방법론을 활용할 수 있다는 이야기를 디자이너로서 전달하기 위한 공유였습니다. 이 문서의 공유는 디자이너와 비즈니스팀이 서로의 상황을 더 잘 이해하고 하나의 목표를 위해 고객에 대한 집착을 할 수 있었던 계기가 되기도 했습니다.

우리는 늘 VOC만 받아서 일할 수도 없고, 고객 인터뷰를 매번 할 수도 없잖아요. 이 계기를 통해서 정말 필요한 경우(문제가 선명하지 않은 경우)에만 고객 인터뷰를 진행하자는 결정을 할 수도 있었어요. 🙂

우리는 제품을 만드는 사람이기에 고객이 실제로 필요로 하는 것보다는 습관적으로 단순히 우리가 만들어내고 싶은 걸 만들기 쉽습니다. 그래서 스스로 의도적으로 끊임없이 의심하고, 검증하는 과정이 필요하다고 생각해요. 그게 우리 디자이너의 큰 역할이라고 생각하기도 하고요. 😊

Dayle이 이전에 재직했던 서치 베이스의 회사나, 큰 규모의 조직을 가진 회사의 경우는 유저 리서치나 고객 인터뷰를 자연스럽고 당연한 프로세스로 여깁니다. 하지만 레몬베이스와 같이 이 프로세스가 구축되어있지 않은 작은 팀의 경우는 유관 동료들을 어떻게 설득하고 이 문화를 정착시켜나가야 할지 고민이 많이 됐어요.

그중에서도 가장 어려운 부분은 인터뷰 리크루팅*이었습니다. 사실 인터뷰 리쿠르팅도 더 깊게 들어간다면 전문성이 필요한 영역인데요. 제품팀이 인터뷰어로 참여할 경우, 이미 그 문제에 대해 너무 잘 알고 있다는 것이 인터뷰를 진행할 때 방해 요소로 작용합니다. 그렇기 때문에 Fresh한 시선으로 인터뷰를 진행하고 문제를 파악하기 위해 전문 에이전시를 찾아가기도 하죠. 저희 팀은 미리 이 부분을 인지하고 연속적인 맥락 속에서 인터뷰를 진행했기 때문에 조금은 수월하기도 했지만, 여전히 막막함은 존재했던 것 같습니다.

초기 팀에서 유저 리서치 프로세스를 구축하는 과정이 결코 쉽지 않지만, 이를 통해 진짜 문제를 파악하는 데에 도움이 된다는 것을 믿고 끝까지 해볼 수 있었어요.

*인터뷰 리크루팅 : 인터뷰 대상자를 선정하고 참여하게끔 설득하는 것

사무실 책상에 앉아 알 수 있는 것은 없으며, 현장으로 나가서 고객들을 직접 만나고 많이 듣는 것이 중요하다는 것을 다시금 느끼게 됐어요. 실제 고객의 모든 경험을 수집해야 하고, 그 데이터를 적절하게 활용해야 한다는 것도 배웠습니다.

특히 초기 신사업, 신제품은 확실한 것이 아무것도 없는 상황에서 시작하게 됩니다. 창업자인 CEO와 PO, 그리고 제품팀은 비전과 가설을 검증하고 확실한 사실로 만들어 나가는 노력이 필요하고요. 이를 위한 가장 효과적인 방법은 고객을 다양한 방법(정성/정량적)으로 만나는 것입니다. 이 방법은 고객을 이해하고, 그들의 니즈와 요구사항을 파악하며, 고객이 제공하는 피드백을 수집해서 제품이나 서비스를 만들고 개선해나가는 데에 매우 중요한 절차라는 것을 이번 케이스를 통해서 더 확실히 알게 되었던 것 같아요.

프로덕트 디자이너는 직접 오너십을 발휘하여 다양한 유저 리서치 방법론을 통해 MVP 문제 정의 검증을 위한 인터뷰를 진행하기도 하고, MVP 출시 이후 PMF를 찾기 위해 추가되는 기능에 대한 유용성/사용성 검증을 위한 인터뷰를 진행하기도 합니다.

최근 제가 속한 스쿼드에서 진행한 고객 경험 인터뷰에서의 가장 큰 수확은 인터뷰를 통해 우리가 풀려는 문제와 고객에 대해 스쿼드 구성원 모두가 자신감을 얻었다는 점이에요. 매번 인터뷰할 때마다 최초에 세웠던 가설을 지속적으로 검증해나가면서, 수정하고 또 검증하는 과정을 데이터 드리븐하게 반복했어요. 총 10개가 훌쩍 넘는 기업들과 인터뷰를 진행하였는데요. 정말 이 과정이 일주일 만에 일어난 일인가? 싶을 정도로 미친 듯이 몰입했습니다.

그 결과 PO, CEO에서 시작된 작은 가설과 비전이 더 구체화될 수 있었고, MVP에 대한 방향성을 잡는 데 큰 도움이 되었습니다. 더불어 협업하는 스쿼드 엔지니어뿐만 아니라, 비즈니스팀, 컨텐츠팀과도 구체적인 고객 데이터를 가지고 소통했을 때 훨씬 효과적이라는 점도 배울 수 있었습니다.

이처럼 한 디자이너의 경험은 다른 팀에 있는 디자이너에게 크고 작은 도움을 줍니다. Dayle의 소중한 경험 덕분에 고객 인터뷰의 중요성을 제가 속한 스쿼드 내부에 많이 알렸고, 실제 고객 인터뷰까지 직접 어레인지하고 진행할 수 있었어요.

현재 레몬베이스 디자인 챕터에서는 각자 스쿼드에서의 진행되고 있는 일들이나 자신만의 노하우를 이야기하는 자리를 매주 가집니다. 이를 통해 저는 디자인 챕터에서 다른 프로덕트 디자이너에게 자연스럽게 영감을 얻으며 실질적인 도움을 받게 되는 것 같아요.

디자이너들은 각각의 스쿼드에 따로따로 속해있고 업무 시간의 대부분을 스쿼드 업무에 사용하고 있기 때문에, 디자인 챕터에서의 활동이 당장 큰 효과가 나지 않는다고 여길 수 있을 것 같아요. 하지만 제가 직접 경험한 것처럼 서로의 경험을 나누고 인사이트를 주고받기 위해 꾸준히 방식을 개선하고 여러 목적의 미팅을 진행하다 보면 각자의 경험이 서로에게 정말 좋은 영향을 끼치게 된다고 믿고 있습니다.

이 글을 포함한 어떤 책, 자료도 고객의 소리를 듣고 문제를 효과적으로 푸는 완벽한 방법론이 되거나 답을 알려줄 수 없다고 생각해요. 각자의 비즈니스와 서비스의 특성, 회사 상황에 따라 달라질 수 있기 때문입니다.

하지만 레몬베이스의 사례를 통해 누군가는 힌트를 얻고, 누군가는 실제 실행에 옮기기 위해 동료를 설득하는 방법을 얻어갈 수 있다면 좋겠다는 마음으로 작성했어요.

여러분은 회사에서 어떻게 유저 리서치를 하고 계신가요? 여러분의 비즈니스/서비스/팀 상황에 맞게 시도하고 있는 방법론이나 팁이 있다면 저희에게도 들려주시면 좋겠습니다. 🙂

이 글을 읽고 계신 여러분들의 크고 작은 시도에 응원을 보내며, 글을 마칩니다.