제작 - 적은 인원으로 프로덕트를 만드는 법

좋은 프로덕트를 만드는 것은 쉽지 않다.

그것도 적은 인원으로는 더욱 더 쉽지 않다.

하지만 정말 소수의 경우를 제외하고는 프로덕트를 만든 다는 것은 인원, 예산, 기간 등 항상 꽤나 타이트한 제약사항이 따르기 마련이다.

그렇다면 적은 인원으로도 성공하는 프로덕트를 만드는 가장 효과적인 방법은 무엇일까?

나 역시도 창업 했을 때 스스로 이 질문에 대한 답을 갈구하곤 했다. 그러다 우연히 읽게 된 폴그레이엄의 아티클에서 발견한 인사이트를 내 경험과 함께 공유하고자 한다.

적은 인원으로도 성공하는 프로덕트를 만드는 가장 효과적인 방법.

그것은 바로 “확장 가능하지 않은 일” 을 하는 것이다.

방법 1. 행복(Hapiness) 지표를 추적한다.

새로운 중요한 지표: 유저의 행복도

사람들은 프로덕트를 만들때 보통 크게 두 가지 지표를 측정한다. 바로 유저수와 매출이다. 하지만 폴 그레이엄은 또 다른 한 지표를 추적해야한다고 한다. 그것은 바로 우리 상품을 쓰는 초기 유저의 행복도이다. 그리고 다른 지표처럼 그 행복지표를 높이기 위해 노력해야한다고 한다.

You should take extraordinary measures not just to acquire users, but also to make them happy.

“행복도”에 집중하라는 말이 비직관적인 이유

하지만 그럼에도 불구하고 매출이나 유저 수 등 이런 중요한 KPI가 아닌 유저의 행복도에 집중하라니 비이성적이고 너무 감성적이라는 생각이 들 수도 있겠다. 그렇다면 프로덕트를 만드는 사람들에게 행복도에 집중하라는 말은 왜 이리도 비직관적일까?

이 말이 그리 직관적이지 않은 이유로는 크게 세 가지가 있다.

1. 이 방법이 확장 가능하지 못한 방법일까봐 걱정되어서
2. 고객응대는 내 일이 아니라는 엔지니어적 사고방식 때문에
3. 일상생활에서 그런 기업을 잘 경험해보지 못했기 때문에

하지만 그럼에도 불구하고 Airbnb, Stripe, 그리고 최근들어 상장한 Reddit 등 세계적인 기업들이 성장해 온 모습을 가장 가까이서 지켜 본 폴 그레이엄은 유저 행복도를 측정하는 것은 중요하다고 말한다. 단 초기 유저를 너무 행복하게 만들어서 망한 스타트업을 단 사례는 한번도 못 보았다는 말과 더불어 말이다.

I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.

나의 경험: 유저의 피드백은 받기 어렵다. 그러니 “받아내야”하는 것이다.

따라서 나도 시작(seezak)을 만들던 당시, 유저들의 행복도를 측정해보기 위해 많은 노력을 기울였다. 하지만 현실은 생각보다 녹록치 않았는데 그 이유는 유저들이 행복하던 안행복하던 피드백을 얻는다는 일이 쉽지 않았기 때문이다.

MAU가 약 1,000명 정도 되던 시기에 웹사이트에 24시간 언제든지 피드백 달라는 메세지와 함께 구글 폼을 올려놓았는데 몇 달간 수집된 피드백은 고작 3건에 그쳤으며, 접근성이 문제일까하여 추가한 카카오톡 방에는 아예 사소한 피드백 조차도 없었다.

이런 피드백 부족 문제를 해결하기 위해 우리 팀은 오프라인 모임, 은근슬쩍 전법, 그리고 집착 전법을 활용했다.

1. 오프라인 모임

   유저들이 관심 있어할 만한 오프라인 이벤트(와인, 디자인 피드백, 네트워킹 등)를 열어서 가서 직접 유저들과 어울리고 모임이 끝날 무렵쯤 다가가 우리 플랫폼이 어떤지, 불편한 점은 무엇인지 편한 점이 무엇인지 물어보았다.

2. 은근슬쩍 전법

   기회가 될 때마다 지원자 또는 기업에게 전화해서 CS를 가장한 유저의 행복도 조사를 계속 ‘은근슬쩍’ 진행하였다.

3. 집착 전법

   카톡방, 서비스 구매, 네트워킹, 지인 등 기회가 될 때마다 피드백을 어떻게든 받아보려고 노력했다.

이렇게 피드백을 받아내고자 노력한 결과, 두 가지 아주 중요한 교훈을 얻을 수 있었다.

• 취준생 - 취준생에게 필요한 것은 다른 사소한 기능이 아닌 지원과정에서 발생하는 불편함이다.
• 기업 - 기업들이 불편한 것은 채용공고 작성에 대한 부담이다.

이렇게 받아낸 피드백들은 일종의 해설지와 같았다. 현재 우리가 하고 있는 일들이 올바른 방향인가 아니면 틀린방향인가를 알려주는 해설지. 일부 피드백들은 “역시 내 생각이 맞았어!” 하는 자신감이 되어주기도 했고 어떤 피드백들은 “아 이건 내 예상과 다르게 유저들이 관심이 전혀 없는 부분이구나?”라며 새로운 교훈을 주기도 했다. 이렇게 소중한 피드백들을 바탕으로 우리는 원래 개발하고자 했던 기능을 취소하고, 유저가 원하는 기능의 개발로 방향을 틀 수 있었다.

방법 2. 자동화시키지 말고 노가다로 유저문제를 해결한다.

자동화 대신 노가다를 택한 기업들

프로덕트를 만들 때 한 가지 흔한 착각 중 하나는 유저문제를 꼭 소프트웨어로 자동화를 하여 풀어줘야한다는 생각이다. 성공한 많은 큰 기업의 앱/웹사이트가 첫날부터 멋지게 작동했을 것만 같지만 실제로는 그렇지 않았다. 결제회사 Stripe의 경우, 유저가 생길때마다 직접 유저의 컴퓨터에 자신의 프로그램을 설치해주러 방문해야했었고, Airbnb는 뉴욕의 집집마다 노크해가면서 돌아다니며 집주인들의 방을 웹사이트에 등록해주었다고 한다. 이 외에도 많은 성공한 스타트업들은 초기에 자동화가 아닌 “노가다”를 통해서 유저의 문제를 직접 해결해주었다.

여기서 내가 드는 의문은 이 창업가들은 ‘노가다식’ 문제해결이 잘못된 방법이 아닐까라는 두려움은 없었을까하는 생각이다. 물론 어느 정도의 두려움은 있었을 것이다. “이게 사람이 적을때만 작동하는 모델이면 어떡하지?”, “지금 자동화가 안됐는데 유저가 많아지면 어떡하지?” 라며 이들도 걱정했을지도 모른다.

하지만 이런 두려움에도 불구하고 이들이 자동화 대신 노가다를 이유는 잘못된 문제를 푸느라 낭비되는 시간을 피하기 위해서였다. [유저의 문제]를 노가다로 풀어주는 것은 약간 두려운 일이지만, [아무의 문제도 아닌 문제]를 자동화로 푸는 것보다는 안 무서운 일이기 때문이다.

It would be a little frightening to be solving users' problems in a way that wasn't yet automatic, but less frightening than the far more common case of having something automatic that doesn't yet solve anyone's problems.

나의 경험: 노가다로 기업공고를 올려준다.

당시는 폴그레이엄의 글을 읽기도 전이었지만, 우리 팀도 초기에 플랫폼을 만들 당시 기업공고를 일일이 노가다로 올렸었다. 우리가 푸는 문제가 정말 존재하는 문제인지를 빠르게 확인하고나서 개발을 하고 싶었기 때문이다. 따라서 우리는 회원가입, 로그인, 폼작성기능 등 이런 기능을 개발하는 것 대신에 기업에 전화해 허락만 받으면 다른 채용사이트에 올려진 공고를 보고 우리가 직접 등록했다.

그렇게 어느정도 기업들의 수요가 있다는 것을 확인하고 나서야 해당 기능을 자동화시켰다. 그 과정 속에서 우리는 기업과 가까이 연락하면서 그들의 고충을 더 자세히 알 수 있었고, 어떤 부분을 올리고 싶어하는지, 어떤 부분은 올리기 꺼려하는지에 대해 한층 잘 이해할 수 있었다. 이를 토대로 빠르게 서비스를 성장시켜 로톡,맘편한세상 등과 같은 스타트업은 물론 국민은행,우아한 형제들 등과 같은 큰 기업들의 공고 또한 받을 수 있었다.

만약 처음부터 여러 사소한 자동화에 집중했다면 문제에 집중하여 서비스를 성장시키기 어려웠을 것이다.

방법 3. 미친 프로덕트가 아니라 미친 경험을 만든다.

미친 프로덕트보다 미친 경험을

제한된 인원으로는 모든 기능이 구현된 ‘미친(insanely great)’ 프로덕트를 만드는 것은 거의 불가능한 일일 것이다. 하지만 좋은 프로덕트를 만드는 것과 좋은 경험을 주는 것은 다른 일이다. 폴 그레이엄은 매우 좋은 프로덕트가 아닌 매우 좋은 경험을 주도록 노력해야한다고 한다.

하지만 그런 경험을 만드는데도 돈과 인력이 든다. 그렇다면 과연 그런 경험을 주는 일은 애플과 같이 돈과 인력이 많은 대기업들만 할 수 있는 걸까?

그렇지 않다. 폴 그레이엄은 애플의 사례를 통해 작은 팀의 강점을 설명한다. 팀 쿡은 우리가 맥북을 산다고 해서 손편지를 써주지 못하지만 우리는 가능하다는 점. 이것이 바로 큰 기업보다 작은 기업이 가진 강점이라고 말한다.

It's not the product that should be insanely great, but the experience of being your user.

허접하지만 멋진 경험을 만들어낸 Wufoo의 사례

위와 같은 얘기를 실제로 실행한 멋진 스타트업의 사례가 하나 있다. 온라인 폼 빌더 스타트업 wufoo(약 500억에 엑싯)는 초기에 유저가 가입 할 때마다 손수 적은 레터를 보냈다고한다. 그냥 사이트를 가입했을뿐인데 허접하지만 정성이 담긴 레터를 받는다면 유저의 그 경험은 어떠할까? 과연 해당 서비스에 팬이 되지 않고 버틸 수 있을까?

나의 경험

유저들이 가장 궁금해하는 연봉정보 알려주기

나 또한도 채용플랫폼 시작(seezak)을 만들 당시 유저에게 ‘미친 경험’을 주기 위해 항상 신경을 쓰고 있었다. 하지만 모든 스타트업들이 그렇듯, 우리에게는 모든 경험이 완벽한 그런 웹사이트나 앱을 만들 시간이 없었다.

그래서 완벽한 플랫폼을 만드는 대신에 허접하더라도 꼭 알고 싶어하는 정보, 연봉 정보를 제공해주고자 했다. 실제로 유저인터뷰를 해봐도 대다수의 사람이 연봉에 대해서 알고 싶어했기 때문이다.

하지만 세상에 없는 건 대부분 이유가 있는 법. 기업들은 자신의 연봉을 공개하기 꺼려한다. 그래서 기존 채용사이트에서 연봉이 공개된 곳은 거의 없었다. 우리도 처음에는 이런저런 말들로 기업을 설득을 해보았지만, 역시 통하지 않았다. 연봉을 공개해야하면 그냥 다른 사이트에 올리겠다는 반응이었다.

그래서 우리는 어떻게든 방법을 찾아보기로 했다. 포기하지 않고 방법을 생각해보았다. 만약에 연봉 범위라면 그나마 낫지 않을까? 그리고 이미 몇몇 기업들이 연봉 범위를 밝히면, 아 내가 처음이 아니고 다들 하는구나~ 하는 생각에 괜찮아하지 않을까? 하고 생각했다.그래서 기업들에게 전화나 이메일을 돌렸다. 일부 기업은 거절하였으나, 몇몇 기업은 결국 OK를 했고 이런 공고들이 하나 둘 쌓이자 점점 다른 기업도 자신의 연봉 범위 공고에 적기 시작했다.

그 결과 시작에서는 연봉 정보를 제공할 수 있게 되었다. 앱도 없고 아직 웹사이트도 개발되지 않은 허접한 노션페이지였지만, 그렇게 원하는 정보를 제공해준 덕분에 구직자 디자이너들이 다른 큰 채용플랫폼들과 함께 챙겨보는 리스트 안에 들 수 있었다. “너무 유용해요”라는 피드백도 여러 번 받을 수 있었다.

피드백을 바로 반영해주기

추후에는 플랫폼이 개발되어서 기본적인 기능만 있는 웹사이트가 생기게 되었다. 그렇게 공고들이 올라오던 어느 날, 유저 피드백이 통 감감무소식이던 와중 한 유저가 이런 피드백을 남긴 일이 있었다.

”만료된 공고는 가장 아래로 정렬이 되었으면 좋겠어요”,
그리고 만료된 공고도 나중에 볼 수 있는 기능이 있었으면 좋겠어요…..

보통 개발 대기 중인 기능들은 끝도 없기에 보통 유저 피드백은 한참 뒤 반영되기 마련이다. 우리 또한 해야 할 일들이 많았기에 시간이 널럴한 것은 아니었다. 하지만 나는 귀한 피드백을 남겨준 유저에게 조금 다른 경험을 주고 싶었다.

그래서 그 날 밤, 안그래도 늦은 퇴근시간을 조금 더 미루기로 했다. 피드백이 오자마자 몇 시간만에 해당 기능을 개발해 유저에게 문자를 보냈다. 요청주신 기능이 개발되었고 내일 아침에 플랫폼에 반영이 될 예정이라는 문자였다.

이 피드백을 남긴 유저는 놀라워하며 좋아했다. 우리도 그런 유저의 반응을 보면서 즐거워했었다. 이런 일은 사실 항상 할 수는 없고, 여러 상황이 맞아야만 할 수 있는 1회성의 일일지도 모른다. 하지만 그럼에도 불구하고 최대한 멋진 경험을 주려는 그런 마음가짐은 성공적인 프로덕트를 만드는데 꼭 필요하다는 생각이 들었다.

4. 결론

— 유저 수가 아닌 유저 행복도에 관심 가지기

— 자동화가 안되더라도, 노가다를 통해서라도 문제 해결에 집중하기

— 미친 프로덕트가 아닌 미친 경험을 주기

모든 프로덕트는 부족한 예산, 부족한 인원 등 여러 제약이 필연적으로 존재하기 마련이다. 하지만 이러한 어려움에도 불구하고 적은 인원으로도 성공하는 프로덕트를 만들기 위해서는 위와 같은 일들에 집중해야 한다는 것을 나는 많은 시간이 지나고 나서야 배울 수 있었다.

이러한 확장가능하지 못한, 아니 그럴 것만 같아 보이는 이런 방법들을 통해서라도 정말 적은 유저수일 때부터 유저의 행복도에 집착한다면, 겉으로 보이는 지표에만 몰두하는 것으로는 절대 알지 못할 많은 것들을 알 수 있음을 깨닫는다.

확장 가능해보이지 않은 일들을 통해 유저를 행복하게 만드는 것.

그것이 바로 내가 여러 실패를 통해 깨달은 “적은 인원으로도 성공적인 프로덕트를 만드는 법”인 듯 하다.