Buffer의 개발 초기 단계 이야기

The Hustle에 Buffer의 개발 초기 단계의 이야기가 소개됐습니다.

요약하면 이렇습니다.

1. Buffer의 첫 번째 MVP(Minimum Viable Product: 최소 요건 제품)는 기능과 요금제를 보여주고 요금제를 선택하면 “아직 준비 중이다”라고 하고 이메일 주소를 입력받는 게 전부였다. 이렇게 해서 얼마나 많은 사람들이 얼만큼의 가치를 지불할 용의가 있는지 확인했다.
2. November Startup Sprint라는 이벤트를 발견하고 이를 목표로 개발을 시작했다. 일정을 맞추는 게 우선이었고 꼭 필요하다고 생각했던 많은 기능을 포기해야 했다. (예. 단계별로 진행되는 회원가입 프로세스)
3. 계획대로 되는 것은 없다. 사용자가 어떤 기능을 필요로 하는지 사용자에게 직접 듣는 노력이 필요하다. 인내심을 갖고 개선해나가야 한다.
4. 제품이 어느 정도 적당한 수준에 도달하면 추가 기능 개발보다는 마케팅과 사용자 확보에 힘써야 한다.

이 글은 원래 Buffer의 블로그에서 “Building Buffer”라는 시리즈의 일부로 쓰여진 글인데 현재는 삭제된 상태입니다. 원본 글을 번역하여 소개합니다. 문맥을 고려하여 표현을 수정한 부분이 있습니다. 번역이나 내용에 대한 의견 환영합니다.

이 글은 Building Buffer 시리즈의 첫 번째 글이다. 이 시리즈에서 우리가 경험하고 배운 것을 공유할 예정이다. 다른 사람들에게 이 글이 도움이 됐으면 한다. 거꾸로 비슷한 경험을 한 다른 사람에게 우리가 배울 수도 있고.

돌이켜보면…

최근 두 달은 Buffer를 출시한 이래로 가장 많은 것을 이룬 시간이었다. 우리는 500명이 넘는 사용자를 확보했다. 그들의 대부분은 활성 사용자이다. 유료화도 했다. 월 요금제 출시 후 매출이 발생하고 있고 유료 전환율은 4% 정도이다. Buffer를 처음 시작하던 때로 돌아가보자.

번뜩이는 아이디어에서 시작하다

Buffer는 아주 작은 아이디어에서 시작됐다. 이미 많은 트위터 클라이언트와 앱들이 스케줄링 기능을 제공하고 있었지만 나는 부족함을 느꼈고 그 기능을 훨씬 더 좋게 만들 수 있다고 생각했다. 나는 한 가지 기능만 있어도 앱을 만들기에 충분하다고 믿어왔고 정말 유용하면서도 뛰어난 경험을 제공하는 것을 만들고 싶었다. 다른 트위터 스케줄링 앱을 사용하다가 아이디어가 하나 떠올랐는데, 그건 여러개의 트윗을 한 번에 예약하는 방법을 만드는 것이었다. 이렇게 하면 트윗 하나하나를 개별적으로 스케줄링하는 불편함을 해소할 수 있었다. 나는 아침마다 트위터에 테크 & 스타트업 뉴스를 올리곤 했는데, 팔로워들의 타임라인이 내 트윗으로 흘러넘치는 걸 피하기 위해 스케줄링 앱을 사용하고 있었다. 이 스케줄링 아이디어는 한 번 떠오른 뒤로 머릿속에서 사라지질 않았다. 내가 사용하던 트위터 스케줄링 앱의 개발사에 이 아이디어를 제안하기도 했지만 반영되지 않았다. 그래서 직접 만들어보기로 했다.

첫 버전은 가능한 미니멀하게

나는 Eric Ries가 제안한 린 스타트업(Lean Startup)방법론의 추종자이다. 스타트업을 처음 시작하면서 린 스타트업에 대해 많은 것을 배웠고 실제로 적용하기 위해 많은 노력을 했다. 하지만 현실은 이론과 달랐다. 최소한의 사업성 검증도 하지 않고 Buffer를 개발하기 시작했다. 뭔가 잘못됐다는 걸 깨닫고 그 즉시 개발을 멈추고 숨을 고르고 스스로에게 되뇌였다. 이번엔 정말 제대로 해보자. 우선 사람들이 이런 서비스를 원하긴 하는지 직접 확인해보기로 했다.

MVP에 대한 Ries의 가이드에 따르면, “MVP는 얼마나 미니멀하게 만들어야하는가?”에 대해 고민해봐야 하는데, 그에 따르면 정답은 이렇다.

“생각하는 것보다 훨씬 더 미니멀해야 한다.”

나는 이 문장을 읽고 또 읽었다. 다른 사람들에게 말해주기도 했다. 그리고 그걸 직접 실행해보기로 했다.

최소한의 테스트

첫 버전은 아래와 같았다.

이 두 페이지짜리 MVP로 사람들이 우리 앱을 사용할 생각이 있는지를 확인해보기로 했다. 나는 웹사이트 링크를 트위터에 올렸고 사람들에게 어떻게 생각하는지 물었다. 몇몇 사람들이 웹사이트에 들어와 이메일 주소를 등록했다. 이메일과 트위터를 통해 유용한 피드백을 얻은 뒤 이 MVP가 “검증됐다"고 판단했다. Eric Ries의 표현을 빌리자면, 나는 고객에 대한 첫 번째 “검증된 학습(validated learning)"을 한 것이다. 그리고 이 검증된 학습으로부터 한발 더 나아가보기로 했다.

배움의 연속

그렇게 사람들이 우리 제품을 원할 것이라는 것을 검증했고 이제 사람들이 돈을 내고도 우리 제품을 사용할 것인지 확인해보기로 했다. 방법은 매우 간단했다. 첫 MVP의 두 페이지 사이에 가격 정책을 보여주는 페이지를 추가했다. 출시 알림을 받기 위해 이메일 주소를 등록하기 전에 한 번의 클릭이 추가된 것이다. 추가된 페이지는 가격 정책을 검증하고(사람들이 어떤 요금제를 클릭하는지를 추적했다) 제품에 대한 수요를 한 번 더 검증했다(한 번 더 클릭하는것만큼 제품을 더 원한다는 것이기 때문에). 페이지가 추가된 두 번째 버전은 다음과 같았다.

실험 결과, 사람들은 여전히 이메일 주소를 등록하기 위해 버튼을 클릭했고 일부는 유료 요금제를 선택했다. 이 결과를 얻은 후, 망설임 없이 최소한의 기능민 포함된 Buffer의 실질적인 첫 번째 버전을 만들기 시작했다.

출시

운이 좋았다. Hacker News에서 “November Startup Sprint”라는 것에 대한 얘기들이 돌고 있었다. “November Startup Sprint”는 11월 말까지 뭔가 만들어서 출시해보기로 약속하고 실행해보는 이벤트였다. 처음에는 Buffer의 첫 번째 버전을 만드는 데 걸리는 시간을 너무 작게 추정했다(1주일이면 된다고 말하고 다녔다!). 그리고나서 “November Startup Sprint” 일정에 맞춰 스스로 최종 기한을 11월 말로 정했다. 밤낮없이, 주말도 없이 7주 동안 개발에 몰두했다. 11월 말은 생각보다 빨리 다가왔고, 꼭 필요하다고 생각했던 많은 기능을 포기해야 했다. 단계별로 진행되는 회원가입 프로세스도 그 중 하나였다. 난 출시하는 것에 전념했다. Buffer는 11월 30일에 출시됐고 Hacker News 커뮤니티에서 굉장한 피드백을 얻었다.

변덕스러운 긴 여정에 대비하기

Buffer를 만들기 시작하기 전에 이미 제품을 만들어본 경험을 갖고 있었다. 그때는 많은 것들이 계획대로 되지 않았다. 운이 좋게도, 나는 이 경험을 통해 인내심을 갖게 됐고 정말 가치있는 무언가를 만들기 위해서는 끊임없는 개선이 필요하다는 것을 알게됐다. 사람들에게 질문을 함으로써 받게되는 이메일들을 통한 고객 발굴의 중요성도 알게됐다. 사람들이 그 제품을 원하는지 검증하기 위해 충분히 많은 사람들에게 “이런 문제를 겪고 있나요?”라고 물어봤어야 했는데, 그 제품을 만들때는 그러지 못했다.

모든 것이 잘 되어갈 때

나는 운이 좋았다. 긴 여정에 대한 나름의 준비도 되어있었고 나중에는 인내심도 필요한만큼 갖추게 됐었지만, Buffer에 있어서는 무엇보다 운이 따랐다. Buffer는 사용자들의 마음을 움직였고 많은 사람들이 겪는 문제를 해결하고 있었다. “다듬어지지도 않은 모습으로” 출시된 지 나흘 만에 첫 번째 유료 고객을 확보했다. 이는 제품의 사업성이 충분하다는 강력한 신호였다.

첫 번째 유료 고객을 확보했을 때 이것이 중요한 기점이라는 것을 깨달았다. 무엇에 집중하는지에 대한 약간의 변화가 필요했고, 그렇게 하기로 결심했다. 이런 시점에 개발자 입장에서는 기능만 계속 추가해나가기 쉽다. 하지만 나는 마케팅과 추가적인 고객 발굴에 집중해야 하는 시점이라는 것을 알고 있었다. 우리는 “충분히 좋은" 제품을 가지고 있었고, 개발, 마케팅 그리고 고객 발굴 사이의 균형이 필요한 시점이었다. 나는 한 가지 소중한 교훈을 얻었다. “제품이 충분히 좋다는 신호가 있다면, 그 제품에 대해 떠들어라!”