내게 필요했던 서비스가, 고객에게도 필요할까?

최근 여러 팀과 멘토링하면서 자주 꺼내게 된 이야기가 있다.

서비스를 만들 때 사용자를 일찍 만나고, 그 사람의 필요를 확인하면서 개발하자는 이야기다. 어떤 기능을 넣을지 결정하기 전에, 누가 어떤 상황에서 그 기능을 필요로 하는지부터 알아보자는 것이다.

이 이야기를 하는 나도, 내가 필요한 서비스를 먼저 만들어 본 적이 있다.

그리고 다른 사람들도 필요로 할 것이라고 생각했던 그 서비스를 중단한 경험이 있다.

내가 현장에서 필요했던 도구

나는 현재 낮에 요양보호사로도 일하고 있다.

일을 처음 시작했을 때는 교육에서 배운 내용을 실제 현장에 적용하면서 다시 확인하고 싶은 것이 많았다. 내가 맡을 수 있는 업무의 범위, 특정 상황에서의 대응 원칙, 교육에서 배운 지원 절차 같은 것들이었다.

분명 배운 내용인데도 필요한 순간에 구체적인 내용이 바로 떠오르지 않을 때가 있었다.

현장에서는 손을 자유롭게 쓰기 어려운 순간도 있다. 그때마다 자료를 찾아 읽는 일은 번거로웠다. 궁금한 것을 말로 물어보고, 필요한 안내를 빠르게 들을 수 있다면 도움이 될 것 같았다.

그래서 서비스를 만들었다.

관련 기관의 공개 자료와 이용할 수 있는 교재, 튜토리얼 등을 바탕으로 질문에 답하는 도구였다. 현장에서 음성으로 질문하고, 오래 기다리지 않고 안내를 받을 수 있도록 하는 것이 목표였다.

음성 입력을 생각한 데에는 이유가 있었다. 내가 일하는 상황에서 손을 쓰기 어려울 때가 있었기 때문이다. 빠른 응답을 원한 것도 같은 이유였다. 나중에 공부할 자료와 지금 궁금한 내용을 확인하는 도구는 사용 상황이 달랐다.

문제도 있었고, 사용 환경도 알고 있었고, 만들고 싶은 기능도 분명했다.

적어도 나에게 왜 필요한지는 설명할 수 있었다.

서비스를 만든 뒤에는 요양보호사를 관리하는 미국의 에이전시들에 소개하고 사용해 보기를 권했다.

반응은 기대만큼 좋지 않았다.

기관들이 더 시급하게 고민하던 문제

당시 내가 이야기 나눈 에이전시들이 중요하게 여기는 문제는 따로 있었다.

첫 번째는 요양보호사 부족이었다.

사람을 구하는 것도 어려운데, 함께 일하던 사람이 그만두거나 예정된 근무에 나오지 않는 일이 생겼다. 충분한 사전 연락 없이 빠지거나 퇴사하면 기관은 갑자기 생긴 공백을 해결해야 했다.

이직과 갑작스러운 근무 공백은 인력을 확보하고 유지하는 문제와 연결되어 있었다.

두 번째는 스케줄 관리와 대체 인력 배치였다.

정기적으로 한 클라이언트를 돌보던 요양보호사가 휴가를 가거나 개인 사정으로 일할 수 없게 되면, 그 시간에 대신 일할 사람을 찾아 배정해야 했다. 누가 가능한지 다시 확인하고, 비어 있는 근무를 채워야 하는 일이 반복됐다.

나는 현장에서 궁금한 내용을 빠르게 확인하는 방법을 생각하고 있었다. 기관은 필요한 시간에 돌봄을 맡을 사람을 확보하고 배치하는 일을 고민하고 있었다.

두 관점을 질문으로 정리하면 이렇다.

일을 막 시작한 나: “이 상황에서 내가 알아야 할 것은 무엇일까?”
당시 만난 에이전시: “이 시간에 돌봄을 맡아줄 사람을 어떻게 구하고 배치할까?”

같은 돌봄 현장을 바라보고 있었지만, 먼저 해결하고 싶은 문제가 달랐다.

이 차이를 알게 되면서, 내가 만든 서비스를 기관들이 왜 크게 필요로 하지 않았는지 이해할 단서를 얻었다.

‘요양보호사를 돕는 서비스’라는 설명만으로 기관의 도입 이유까지 충분히 설명되지는 않았던 것이다.

‘요양보호사’라는 한 단어로는 부족했다

다른 차이도 있었다.

나처럼 일을 시작한 초기에는 배운 내용을 다시 확인하고 싶은 순간이 있었다. 그러나 경험이 많은 요양보호사들에게는 내가 당시 느꼈던 만큼의 필요가 크지 않았다.

처음에는 고객을 ‘요양보호사’라고 생각했다. 조금 더 들여다보니, 내가 크게 느낀 불편은 요양보호사 일을 시작한 초기의 상황과 밀접하게 연결되어 있었다.

같은 직업이라고 해서 같은 도움을 필요로 하는 것은 아니었다.

일을 막 시작했는지, 이미 익숙한지, 어떤 상황에서 어려움을 겪는지에 따라 필요한 것이 달랐다. 처음에 필요했던 도움이 이후에도 같은 정도로 필요한지도 확인해야 했다.

필요는 분명했다. 일을 시작한 초기의 요양보호사라면, 배운 내용이 바로 떠오르지 않을 때 확인하고 싶은 순간이 있었다. 다만 그 필요가 내가 시간을 들여 개발하고 출시할 만큼 넓은지, 그 일이 수익으로까지 이어질 수 있는지는 다른 문제였다.

요양보호사가 가령 수십만 명이라 해도, 그 사람들이 모두 이 도구를 쓰는 것은 아니다. 일을 시작한 초기이고, 그중에서도 이런 확인이 필요한 사람만 남는다. 그 비율을 몇 퍼센트로 보수적으로 잡아 보면, 내가 이 서비스를 계속 만들어 갈 만큼 크지 않았다.

정확한 필요가 파악되고, 해결할 만한 문제라도 마찬가지였다. 시장을 살펴보고 반응을 들어 보면, 그 크기가 프로젝트를 이어 갈 만큼인지도 함께 알 수 있다.

나는 그때 확인한 반응과 이 크기를 바탕으로 서비스를 중단했다.

돌아보면 내 경험 덕분에 사용 상황을 이해한 부분은 있었다. 음성으로 질문해야 편리한 이유, 빠른 응답을 원하는 이유를 구체적으로 생각할 수 있었다.

그다음에는 다른 사람에게도 그 문제가 얼마나 중요한지 알아봐야 했다.

내가 경험한 필요가 어느 사람에게, 어떤 시기에, 얼마나 자주 생기는지. 서비스를 소개한 기관은 어떤 문제를 먼저 해결하려고 하는지. 이런 질문이 개발 과정에 더 일찍 들어왔어야 했다.

내게 필요하다는 사실은 알고 있었다. 더 확인해야 했던 것은 누구에게, 언제, 얼마나 필요한가였다.

초기에만 필요한 도구에도 가치는 있을 수 있다. 다만 그 필요가 생기는 시기와 지속 기간에 맞는 제공 방식이 무엇인지는 별도로 확인해야 한다.

내가 내린 중단 결정 역시 당시 확인한 반응, 그 필요가 닿는 크기, 그리고 처음 구상한 방향을 바탕으로 한 판단이었다. 이 경험이 남긴 질문은 더 구체적이었다.

나는 어떤 고객의 어떤 순간을 위한 제품을 만들고 있었던 걸까?

멘토링에서도 같은 질문을 만나게 된다

이 경험을 떠올리면 자신에게 필요한 기능을 열심히 만드는 팀의 생각을 이해할 수 있다.

직접 불편을 겪었으니 해결하고 싶다. 하나를 해결하면 그 옆의 문제도 보인다. 기능을 연결하고, 자동화를 추가하고, 조금 더 완성된 서비스를 만들고 싶어진다.

최근 멘토링에서 만난 한 팀도 자신의 필요에서 출발해 영상 제작을 돕는 서비스를 만들고 있었다. 주제 탐색부터 대본, 음성·자막, 장면 수정, 썸네일까지 이어지는 흐름이었다.

쉽고 빠르게 영상을 만들어 꾸준히 올리고 싶다는 필요는 분명했다.

나는 그 서비스를 다른 사람이 사용한다면 어떤 결과를 얻고 싶어 할지 함께 생각해 보자고 했다.

제작 시간을 줄이려는 사람인지, 주제를 정하기 어려운 사람인지, 편집에 익숙하지 않은 사람인지에 따라 중요한 기능이 달라질 수 있기 때문이다. 같은 영상 제작자라도 현재 작업 방식과 목표가 다를 수 있었다.

나의 경우에도 ‘요양보호사’라는 직업만으로는 필요를 충분히 설명할 수 없었다. 영상 제작 서비스 역시 ‘크리에이터’라는 이름에서 한 걸음 더 들어가야 했다.

고객을 구체적으로 이해하는 일은 기능의 우선순위를 정하는 일과 연결된다.

내가 유용하다고 느끼는 기능을 더하는 동안에도, 그 기능을 사용할 사람의 상황을 계속 확인해야 한다.

가설을 세웠다면, 그 사람이 최근에 겪은 일을 듣자

개인적인 필요에서 출발한 아이디어는 고객에 대한 가설로 적어 볼 수 있다.

다음과 같은 문장이 출발점이 된다.

[어떤 상황의 사람]은 [어떤 문제]를 겪는다. 현재는 [어떤 방법]으로 해결한다. 우리는 [어떤 도움]을 제공하면 [어떤 변화나 행동]이 나타날 것으로 예상한다.

내가 만든 서비스에 적용한다면, 처음부터 대상을 조금 더 좁혀 볼 수 있었을 것이다.

‘요양보호사는 현장에서 질문할 도구가 필요하다’에서 출발해, 일을 시작한 초기의 요양보호사는 언제 어떤 정보를 다시 확인하는지, 현재는 누구에게 묻거나 어떤 자료를 찾는지 알아보는 것이다.

여기서 잠재 고객을 만나는 목적은 내 아이디어에 동의하는 사람을 찾는 데 머무르지 않아야 한다. 그 사람이 겪는 일을 이해하고, 내가 중요하게 생각한 문제가 실제로도 중요한지 확인해야 한다.

인터뷰에서는 구체적인 최근 경험을 묻는 것이 도움이 된다. 고객을 만나 제품의 방향을 정하는 일을 정리해 온 테리사 토레스도, 인터뷰에서 특정한 과거 경험을 이야기하도록 요청하는 방식을 권한다. 상황과 행동을 함께 이해하기 위한 접근이다.

이번 경험을 돌아보며 질문을 준비한다면 다음과 같이 해볼 수 있다.

이런 대화에서는 예상하지 못했던 답이 나올 수 있다.

내가 문제라고 생각한 부분을 이미 다른 도구나 사람의 도움으로 해결하고 있을 수도 있다. 번거롭기는 하지만 바꿀 만큼 중요하게 여기지 않을 수도 있다. 오히려 내가 지나쳤던 일이 더 큰 부담으로 드러날 수도 있다.

그때 가설을 고쳐 써야 한다.

인터뷰 이후에는 설문으로 문제의 경험 여부나 현재 사용하는 대안을 더 넓게 살펴볼 수도 있다. 이미 시제품이 있다면 짧은 사용 테스트를 병행할 수도 있다. 지금 가장 불확실한 질문에 맞춰 방법을 고르면 된다.

처음 만난 사람에게 다시 보여 주면 변화 과정을 이해하기 좋다. 여기에 새롭게 만나는 잠재 고객도 포함하면, 기존 참여자에게는 익숙해진 부분까지 다시 살펴볼 수 있다.

경험에서 시작해, 고객과 함께 가설을 고치는 과정

사용자와 도입 담당자가 다른 서비스에서는 두 관점을 함께 확인해야 한다. 조사와 개발은 이 과정 안에서 반복된다.

인력 부족과 스케줄링이 중요하다는 이야기를 들었다고 해서, 곧바로 일정 관리 기능을 만들면 된다는 결론이 나오는 것도 아니다.

새로운 서비스를 검토한다면 추가로 알아봐야 한다. 배치할 사람이 부족한 것인지, 가능한 사람을 찾는 과정이 오래 걸리는 것인지, 연락과 확인 과정에서 어려움이 생기는 것인지에 따라 도울 수 있는 범위가 달라진다.

문제를 발견한 뒤에도, 그 문제가 실제 업무에서 어떻게 나타나는지 더 가까이 들여다봐야 한다.

MVP의 범위는 확인할 질문에서 정하자

고객의 상황을 이해하고 가설을 조금 더 구체화했다면, 그다음에는 작은 경험을 만들어 반응을 확인할 수 있다.

이때 필요한 질문은 “기능을 어디까지 만들까?”와 함께 “이번에 무엇을 알아야 다음 결정을 내릴 수 있을까?” 하는 것이다.

린 스타트업을 제안한 에릭 리스는 MVP를 최소한의 노력으로 고객에 관한 검증된 학습을 얻을 수 있는 제품의 버전으로 설명한다. 확인하려는 가설에 따라 필요한 형태와 범위가 달라진다는 뜻이다.

다른 멘토링 팀과는 일정 관리, 스티커 수집, 정원 꾸미기를 연결하는 서비스를 이야기했다.

할 일을 끝내면 보상을 받고, 보상을 모아 자신만의 공간을 꾸미는 구상이었다. 만드는 사람에게는 세 가지가 하나의 완성된 경험이었다. 어느 부분을 빼면 서비스의 매력이 충분히 전달되지 않을 것 같았다.

그래서 사용자 반응을 확인하려면 이 전체를 모두 만들어야 하는지에 대한 고민이 나왔다.

나는 전체 구상에서 먼저 확인할 연결을 찾아보자고 제안했다.

일정을 등록하고, 완료하고, 보상을 받는 짧은 경험을 사용자가 어떻게 받아들이는지부터 살펴보는 것이다. 그 흐름이 이해되는지, 보상을 즐겁게 느끼는지, 다음에 기록할 때도 다시 찾는지 확인해 볼 수 있다.

정원을 꾸미는 경험 자체가 핵심 가설이라면, 그 매력을 느낄 수 있는 작은 경험도 포함해야 한다. 확인하려는 가치를 경험할 수 있을 만큼은 만들어야 한다.

큰 구상을 가지고 있더라도, 이번에 확인할 가정은 작고 구체적으로 정할 수 있다.

아래는 제품의 단계에 따라 선택해 볼 수 있는 실험 예시다.

각 실험이 알려 주는 것은 다르다.

화면을 이해한다는 것만으로 반복 사용이 확인되지는 않는다. 첫 사용에 만족했다는 사실만으로 비용을 지불할 이유까지 확인되는 것도 아니다.

이번에 배운 것과 아직 모르는 것을 구분해야 다음 개발 범위를 정하기가 쉬워진다.

좋은 반응을 들었다면, 그다음 행동까지 살펴보자

서비스를 보여 줬을 때 편리해 보인다는 말을 들으면 기쁘다. 출시하면 알려 달라는 말도 관심의 단서가 된다.

그다음에는 실제 선택을 확인할 필요가 있다.

자신의 일에 사용했는가? 중요한 작업을 끝낼 수 있었는가? 결과물을 활용했는가? 다음에 같은 문제가 생겼을 때 다시 찾았는가?

앞서 말한 테리사 토레스의 ‘증거의 사다리’도 미래 행동에 관한 추측에서 구체적인 경험과 관찰 가능한 행동으로 나아가며 더 유용한 근거를 얻는 관점을 제시한다.

관찰한 결과를 해석할 때는 이유를 서둘러 단정하지 않는 것이 좋다.

사용하지 않았다면 필요가 약했을 수도 있고, 사용 방법을 이해하지 못했을 수도 있고, 결과의 품질이 부족했을 수도 있다. 다음 사용 기회가 아직 오지 않았을 수도 있다.

이유에 따라 다음 행동은 달라진다.

고객이 요청한 기능도 그 배경을 들어봐야 한다. 알림을 더 넣어 달라는 요청을 받았다면 최근에 어떤 일을 놓쳤는지, 현재 알림은 어떻게 사용하고 있는지 알아볼 수 있다. 기능 요청을 통해 사용자의 상황을 더 깊이 이해하는 것이다.

고객 개발을 제안한 스티브 블랭크 역시, 그 일을 고객 문제에 대한 가설과 제품이 그 문제를 해결하는지를 시험하는 과정으로 설명한다. 고객에게서 기능 목록을 수집하는 것만으로는 충분하지 않다는 의미다.

사용자의 이야기를 듣는 과정과 제품의 우선순위를 판단하는 과정이 함께 있어야 한다.

출시 이후에도 고객에게서 배울 것은 남아 있다

고객 중심 개발은 기획할 때 한 번 조사하고 끝나는 일이 아니다.

첫 사용에서 어떤 가치를 경험하는지, 필요할 때 다시 찾는지, 기존 방식과 비교해 어떤 차이를 느끼는지 계속 살펴봐야 한다.

서비스를 비즈니스로 운영한다면 비용을 지불할 이유와 지속해서 제공할 수 있는 조건도 확인해야 한다. 필요가 분명해도, 그 필요가 닿는 범위가 서비스를 계속 만들 만큼 큰지는 따로 보아야 한다. 고객에게 중요한 가치가 무엇인지와 그 가치를 제공하는 데 어떤 비용이 드는지가 연결되어야 한다.

처음에는 많은 사람이 관심을 보이는 것보다, 어떤 사람이 왜 실제로 사용하는지를 설명할 수 있는 것이 다음 결정을 내리는 데 더 도움이 될 수 있다.

개발을 이어 가면서 다음 네 가지 질문을 가까이에 두면 좋겠다.

• 지금 가장 구체적으로 이해하고 있는 고객은 누구인가?
• 최근에 그 고객에게서 새롭게 알게 된 것은 무엇인가?
• 그 사실 때문에 어떤 제품 결정을 바꾸었는가?
• 다음 기능을 만들기 전에 확인할 가정은 무엇인가?

이 질문에 답하다 보면 고객을 만나는 일과 제품을 만드는 일이 연결된다. 피드백은 개발이 끝난 뒤 받는 평가에서, 개발 방향을 정하는 근거가 된다.

같은 현장을 보고 있어도, 필요한 것은 다를 수 있다

내가 만들었던 요양보호사 안내 도구는 내게 실제로 필요했던 경험에서 출발했다.

그 경험 덕분에 현장의 사용 방식을 구체적으로 생각할 수 있었다. 동시에 그 경험이 누구에게까지 해당하는지는 다른 사람을 만나며 확인해야 했다.

당시 에이전시들이 더 시급하게 고민했던 것은 인력을 확보하고, 갑자기 생긴 근무 공백을 메우는 일이었다. 경험이 많은 요양보호사들의 필요도 일을 시작한 초기의 나와 같지 않았다. 일을 시작한 초기의 필요 자체는 있었지만, 그 비율을 보수적으로 잡아 보면 개발과 출시를 이어 가 수익으로 연결할 만큼 크지 않았다.

이 차이를 더 일찍 알았다면 어떤 가설부터 확인해야 할지, 어디까지 만들어 볼지에 관한 판단도 달라졌을 것이다.

그래서 멘토링에서도 내가 필요하다고 생각한 기능을 설명하는 자리에서 한 걸음 더 나아가 보자고 이야기한다.

그 기능을 사용할 사람을 만나고, 최근에 겪었던 일을 듣고, 현재 어떻게 해결하는지 살펴보고, 작은 경험을 제공해 실제로 어떻게 사용하는지 보자는 것이다.

아이디어가 나에게서 시작되는 것은 자연스럽다. 그다음에는 다른 사람의 경험이 제품 안으로 들어올 자리를 만들어야 한다.

다음 기능을 추가하기 전에, 그 기능이 필요할 것 같은 한 사람이 최근에 겪은 일부터 들어보자.