제품 초기 인터뷰와 외주 계약
인터뷰를 통한 PSF(Problem-Solution-Fit) 찾기
PART 1. 프로덕트 총괄 창업 멤버 L의 이야기
아이디어를 현실로, PSF의 중요성
BSS의 전체 기능 중 일부 기능을 따로 떼어내서 서비스를 개발하기로 한 가장 큰 이유는 제품 개발 시간을 단축하여 빠르게 시장에 진입하고, 고객의 반응을 보기 위함이었다.
고객에게 제대로 작동하는 일부 기능을 찾기 위해서 대표는 곧바로 고객에게 인터뷰를 요청했다.
초기 인터뷰가 중요한 이유
초기 아이디어를 구현할 때, 잊지 말아야 할 사항은 인터뷰를 통해 제대로 된 Problem-Solution-Fit을 찾아야 한다는 점이다. PSF(Problem-Solution-Fit)란, 제품 개발에 본격적인 투자를 하기 앞서 우리가 만들고자 하는 제품이 실제 가치가 있고, 수익까지 창출할 수 있는지 여부를 검증하는 과정이라고 생각하면 된다.
PSF를 찾기 위해서는 첫 번째로 최소한 10명 정도의 잠재 고객이 공통적으로 해결하고 싶어 하는 문제임을 검증해야 한다. 즉, 잠재 고객이 반드시 필요(Must-have)하다는 피드백을 해야 한다. 두 번째, 이 중 최소 절반이 넘는 사람들이 실제 제품(혹은 MVP)을 사용하며 하나 이상의 기능에 대해서는 실제 비용을 지불하거나 그에 준하는 강한 지불 용의를 보여야 한다. 가령, 가계약 서명 혹은 신청 이메일이나 전화번호 제출 등이 포함된다.
초기 인터뷰에서 정확한 PSF를 찾아야 PMF가 나오고, 이를 기반으로 강력한 성장을 이룰 수 있게 된다. 잘못된 문제 정의에서 옳은 답변이 나올 수는 없다.
초기 인터뷰 How-to
원활한 인터뷰 진행을 위해서 준비해야 하는 부분들은 여러 가지가 있지만, 그중에서도 내가 생각하는 핵심 3가지는 다음과 같다.
1. 인터뷰의 목적을 정확히 한다
2. 인터뷰의 일정을 산정하고 기간을 정한다
3. 질문지를 반드시 준비하되 유연하게 인터뷰한다
이 세 가지가 준비되지 않으면,
일정이 늘어져서 인터뷰 일정 취소의 가능성이 높아지거나
중간에 인터뷰의 내용이 산으로 가버리거나
고객이 제대로 된 답변을 주지 못할 가능성이 높아진다.
또한 인터뷰 진행에 있어서 몇 가지 팁이 있다.
고객이 먼저 말할 수 있는 상황을 만든다. “요즘 어떤 일이 가장 힘드신가요?”와 같은 열린 질문과 답변에 대한 공감이 고객의 마음을 여는 가장 좋은 방법 중 하나이다. 고객이 먼저 어떤 부분이 개선되면 좋겠고, 지금은 어떤 상황인지 말하도록 기다리자. 우리가 만들고자 하는 서비스를 먼저 설명하면 고객의 답변 양식이 정해져 버릴 위험이 있다.
인터뷰는 2명이 방문하는 것이 바람직하다. 한 명은 인터뷰를 진행하고, 한 명은 실시간으로 인터뷰의 내용을 기록해야 한다. 기획자는 무조건 참석해야 하며, 다른 한 명은 기획자가 아닌 다른 실무자(마케터나 영업팀)가 참여하는 것이 좋다. 다른 부서의 실무자는 인터뷰를 다른 시각으로 바라볼 수 있다.
고객이 말하는 내용만 듣기보단, 고객의 감정 변화, 바디 랭귀지도 살펴보아야 한다. 물론 이 또한 기록으로 남겨두는 것도 중요하다.
우리도 어떤 문제가 있는지 나열하는 고객의 말을 주의 깊게 들으며 내용을 받아 적고, 그중에서 우리의 가설과 비슷한 부분을 캐치해서 순발력 있게 해당 내용들에 대해 조금 더 이야기를 나눴다.
실제로 고객들이 나열하는 여러 가지 문제들 중에 우리가 곧바로 간단하게 해결할 수 있는 것이 있었다. 바로 “요양 시설 내 보호자와의 소통이 힘들어요”라는 문제였는데, 우리가 진입하고자 하는 시장에 적합한 커뮤니케이션 툴이 없었던 것이 원인이었다. 당시에는 카카오톡이나 밴드를 이용해서 보호자와 소통을 진행하고 있는 상황이었으나 아무래도 종사자 본인의 휴대폰을 사용하다 보니 직업과 일상의 분리가 쉽지 않았고, 시설 위탁 어르신 별 보호자 알림장 전송 기능이 없었다. 따라서 카카오톡과 밴드는 요양 시설에게 비교적 효율적 인 툴은 아니었다.
우리는 이 문제를 해결할 수 있는 요양 시설 전용 알림장 서비스 개발 착수를 시작했다. 제대로 된 PSF를 찾은 기분이었다.
문제를 확인하고 대표는 며칠 후 풀스택 개발자를 외주 프리랜서로 데려왔다. 물론 빠른 개발을 위해서였다. 당시 나는 와이어프레임 몇 개를 그려두고, 내가 원하는 요구사항을 개발자에게 말하며 서비스를 만들었다. 결론부터 말하자면 결과물은 엉망이었다.
대표와 나는 결과물로 만들어진 애플리케이션을 보며 고개를 저었다.
“야 이게 뭐야? 이걸 어떻게 쓰라고 만든 거야?”
우리는 곧바로 피드백 회의를 했고, 어렵지 않게 원인을 찾아냈다. 개발자는 마법사가 아니었다. 화면 몇 개 그리고 설명을 다는 것은 기획이 아니었다.
"글을 쓸 수 있게 해 주세요"라는 요청 사항에는 작성 기능만 있었고, 수정하거나 삭제할 수는 없었다. 누가 가입하고, 어떻게 사용하는지 또한 알 수 없었다. 이런 것들 말고도 수많은 결함이 있었지만 가장 큰 문제는 따로 있었다.
흰 것은 배경이요. 검은 것은 글씨인 간격이 제멋대로인 디자인이었다. 아무리 최소 기능 제품이라고는 했지만, 진짜 너무하다 싶을 정도로 엉망.. 이였다.
“이건 못 쓴다..”
우리의 표정을 본 개발자는 안쓰러웠는지 추가비용을 받지 않고 수정을 해준다고 했지만 도대체 어디부터 손대야 하는지 감을 잡을 수 없었던 우리는 그대로 외주 계약을 종료했다. 그렇게 첫 번째 시도는 몇 백만 원짜리 교훈을 남기며 막을 내렸다.
우리는 이 일을 통해 두 가지를 배웠다. 외주 업체를 이용하기 위해서는 서비스를 제대로 설계할 수 있는 기획자와 외주사와의 소통과 프로젝트 간 생기는 이슈를 관리할 수 있는 PM이 있어야 했다. 모두 고용할 수 없는 상황이었기에 일단 외주를 진행할 비용으로 인하우스 개발자를 채용하는 것을 선택했다. 물론 디자이너도 채용했다. (계속)
외주 계약은 실패 가능성이 99%다
잠깐 막간을 이용해서 한 가지만 말하고 싶다.
IT를 잘 모르는 사람들이 가장 많이 하는 착각 중에 하나는, 외주 업체 혹은 개발 프리랜서를 고용하면 모든 게 다 해결되리라는 믿음이다. 이 믿음 때문에 적게는 수백만 원부터 크게는 몇 억 원까지 공중에 날리는 모습을 심심치 않게 볼 수 있다.
외주 업체들이 받는 의뢰 중 재개발 요청이 상당히 많다고 한다. 그 말은 첫 번째 외주 개발이 실패했다는 의미이다. 외주 개발을 할 때에는 개발사의 역량도 중요하지만 고객사의 외주 관리 능력이 훨씬 중요하다. 만약 개발 진행에 문제가 있었다면 중간 결과를 보고 클레임을 걸거나 중지해야 한다. 이런 과정이 없이 최종 결과물만 가지고 평가한다면 고객사의 관리 능력이 부족하다고 말할 수밖에 없다.
그렇기 때문에 외주사에게 개발을 맡기는 경우 명확한 요구사항과 기획서를 전달하는 것이 중요하다. 또한 주기적으로 진행 현황과 중간 결과물을 점검하고, 충분히 소통해야 한다. (제대로 된 외주 계약을 진행하는 방법도 브런치에 함께 게재할 예정이다)
