11년 동안의 SaaS 제품 전략

이번주 주간SaaS 소개 글

11년 동안 SaaS 제품 전략에 관해 실수도 성공도 경험하며 얻은 교훈을 담은 글입니다. MVP단계를 시작으로 PMF 단계를 거쳐 성장의 단계에서 제품 전략의 큰 틀은 어떻게 하면 좋을지 배울 수 있는 좋은 글 이면서 재밌는 글 입니다 :)

지난 한 해 동안 Tanda는 단일 제품 회사에서 벗어나 서로 잘 어울리는 여러 신제품을 출시 했습니다. 이를 계기로 지난 10년간 제품 전략의 변화 단계를 되돌아보게 되었습니다. Tanda는 제품이 전혀 없는 상태에서 시장 리더로 성장했습니다.

0단계: 로드맵은 단지 아이디어일 뿐

모든 제품, 프로젝트, 회사는 이 단계에서 시작합니다. 아직 만들어진 것은 없고 아이디어만 존재합니다. 이 단계에서는 아이디어를 구체화하여 사용자 또는 구매자에게 제시하고 그들의 의견을 들어볼 수 있을 정도로만 만들면 됩니다. 스타트업 업계에서는 이를 MVP(Minimum Viable Product)라고 부릅니다.

이 단계에서 계획은 유용하지만, 이후 단계의 계획과는 매우 다릅니다. 성숙한 기업에서 제품 계획 경험이 있는 사람이라면 여기서 성공하기 위해 많은 것을 버려야 합니다. 왜냐하면 이 단계에서 "계획"이란 만들어야 할 것에 대한 2문장으로 요약해서 작성하는 것이기 때문입니다.

예를 들어, "Android 기기에서 실행되는 직원 출퇴근 시간 기록기를 만들 것입니다. 클라우드 웹사이트에 연결되어 별도의 IT 지원이 필요하지 않습니다."와 같이 간략하게 작성합니다.

어떤 사람들은 시장을 먼저 파악한 다음 제품을 시장에 맞춰야 한다고 말합니다. 유사한 100명의 잠재 구매자를 인터뷰하고, 그들이 원하는 것을 파악하여 정확하게 구현하라는 것입니다. 제 경험상 이 조언은 자주 듣게되는 조언이지만, 실제로 지켜지지 않는 경우가 많습니다. 만약 여러분이 사람들이 원하는 것을 두 문장으로 설명할 수 있는 무언가에 대해 아직 알지 못한다면 사업을 시작해서는 안 됩니다.

고객 조사 방식을 고집한다면 최소한 대본이라도 작성하세요. 창업 희망자들이 "잠재적인 문제점을 파악하고 제품 아이디어를 얻기 위해 고객 개발 인터뷰를 할 수 있는지" 물어보면 시간 낭비라는 답변만 듣게 됩니다.

1단계: 다음에 무엇을 만들어야 할지 명확하다

제품의 첫 두 문장을 구현하고 일부 사용자를 확보했습니다(유료 사용자면 더 좋겠죠). 이 단계에서는 다음에 무엇을 만들어야 할지 꽤 명확해 보일 수 있습니다. 왜냐하면 고객이 기대하는 기능보다 훨씬 적은 기능만 갖추고 있기 때문입니다. 제품-시장 적합성을 향해 가고 있는 것입니다.

Tanda의 경우 수상 해석, 로스터, 초기의 간단한 버전의 근무 시간표 및 휴가, 급여 내역서 등이 이에 해당했습니다.

왜 명확 했을까요? 누구에게 명확 했을까요? 저는 다음과 같이 생각합니다. 고객 또는 잠재 고객과 대화할 때 고객이 "X 기능이 있나요?"라고 묻는 대신 "X는 어떻게 하나요?"라고 묻는데, 여러분이 "아, X는 하지 않습니다. 이유는 다음과 같습니다."라고 자신 있게 대답할 수 없다면, 그것은 명백한 기능 부족입니다. 1) 고객이 해당 기능이 있어야 한다고 생각했기 때문에 당연한 요구 사항입니다. 2) 해당 기능이 없는 것에 대한 정당화 근거가 없으므로, 암묵적으로 고객에게는 명백한 기능 요구 사항입니다.

다음에 무엇을 만들어야 할지 명확할 때 제품 계획은 쉽습니다. 명백한 것 하나를 선택하고, 가능한 가장 간단한 버전으로 만들고, 반복합니다. "우선순위 설정"은 피하십시오. 우선순위를 설정해야 한다는 것은 무엇을 만들어야 할지 명확하지 않다는 것을 암묵적으로 인정하는 것이며, 이 단계에서는 진정으로 명백한 것만 만들어야 합니다. 가장 최근에 질문받은 명백한 것을 선택하여 만들고 반복합니다.

노련한 제품 관리자들은 이 작업을 너무 많이 하면 서로 잘 작동하지 않고 일관성이 없는 모든 종류의 무작위 기능을 만들게 될 것이라고 경고할 것입니다. 틀린 말은 아니지만, 그렇게 하지 않으면 파산할 것이라는 점을 간과합니다. 이 단계에서는 많은 것을 만들고, 일부는 형편없고 나쁜 고객을 끌어들일 수 있다는 것을 받아들이고, 이 정보를 사용하여 이상적인 고객이 누구인지 파악해야 합니다. 그런 다음 원하지 않는 기능과 고객을 점차 제거하십시오.

이 단계에서는 우선순위 설정이 좋지 않지만 범위 설정은 그렇지 않습니다. 명백한 요구 사항을 매우 정교한 버전으로 만들고 싶은 유혹에 빠지기 쉽습니다. 너무 많은 틈새 기능을 제공하거나 너무 세련된 기능을 만드는 것입니다. "v1이 부끄럽지 않다면 너무 늦게 출시한 것이다"라는 말이 여기서 나옵니다. 모든 명백한 기능의 첫 번째 버전은 약간 못생겨 보여야 하며, 100%의 고객이 정확히 같은 방식으로 사용할 기능만 포함해야 합니다. 다른 모든 것은 나중에 다시 처리할 수 있습니다. 곧 필요할 것이라고 "확신"하기 때문에 미리 계획하고 싶은 유혹이 있을수 있습니다. 하지만 이 유혹을 물리치십시오. "곧"이 실제로 곧 다가오더라도 (그렇지 않은 경우가 많습니다!) 범위를 공격적으로 제한하고 나중에 추가하는 것이 좋습니다.

이 단계에서는 실제로 명백한 요구 사항이 아닌 많은 것들을 요구받을 것입니다. Tanda의 경우 직원용 모바일 앱이 가장 대표적인 예였습니다. Tanda는 처음 4년 동안 앱 스토어에 앱이 없었습니다. "직원들이 앱을 어떻게 설치하나요?"라는 질문을 항상 받았습니다. 우리의 대답은 "모바일 웹사이트가 있고 중요한 모든 것은 이메일과 SMS로도 처리됩니다."였습니다. 고객에게 앱이 필요하지 않지만 정말 정확한 수상 해석기가 필요하며, Tanda만이 그것을 가지고 있다고 설명했습니다.

우리가 기본적으로 네이티브 앱에 반대했기 때문에 이렇게 말한 것은 아닙니다. 결국 우리는 앱을 만들었습니다. 하지만 오랫동안 그것은 우리의 작은 팀이 만들 수 있었던 다른 것들만큼 중요하지 않았습니다.

2단계: 다음에 무엇을 만들어야 할지 정말 알기 어렵다

갑자기 모든 명백한 것들이 이미 만들어졌다는 것을 깨닫게 될 것입니다. 갑자기 우선순위 설정은 매우 쉬운 일에서 매우 어려운 일로 바뀝니다. 기능 요청, 버그 보고서, 제안(요청으로 표현됨), 기술 부채에 대한 불만 등 수많은 의견이 쏟아집니다. 그리고 대부분 나쁜 생각처럼 보이지는 않지만, 어느 것도 중요해 보이지 않습니다.

이제 실제로 우선순위를 설정해야 합니다.

저는 이 단계의 전환이 정말 어렵다고 느꼈습니다. 몇 년 동안 좋은 생각이라고 느껴지는 것을 만들어 왔고, 대부분 옳았습니다. 이제 모든 사람들이 더 이상 그렇게 할 수 없다고 말하고, 잘못된 것을 만드는 것을 방지하기 위해 많은 새로운 프로세스를 만들어야 한다고 말했습니다. 돌이켜보면 갑작스러운 급격한 변화의 필요성에 대해 더 회의적 이어야 했습니다. 하지만 저는 그렇지 않았고, 제품 전략을 수행하는 방식을 바꾸는 데 몰두했습니다.

우리는 Tanda에 의존하는 고객 수가 끊임없이 증가하는 상황에서 우리의 본질적인 기민함과 균형을 맞추는 올바른 방법을 찾으려고 노력하는 동안 몇 년에 걸쳐 많은 실수를 저질렀습니다. 효과가 없었던 몇 가지 사항은 다음과 같습니다.

대기업 고객의 압력에 굴복

대기업 고객은 항상 자신들만 사용할 것이 분명한 기능을 만들어 달라고 요구할 것입니다. 한 명의 고객이 로드맵을 좌우한다면 거절해야 한다는 조언은 수없이 많이 나와 있습니다. 하지만 그런 기회가 처음 생겼을 때 저항하기는 여전히 어렵습니다.

저는 이렇게 하면 안 되는 이유가 고객이 원하는 것을 만드는 쳇바퀴에서 벗어날 수 없기 때문이라고 생각했습니다. 우리는 첫 번째 기업 고객과 함께 몇 년 동안 그 쳇바퀴를 돌렸지만, 실제로는 그만두기로 결심했을 때 그렇게 어렵지 않았습니다. 우리는 (책을 인용하여 더 공식적으로 만들었습니다) 어떻게 일하고 싶은지 매우 단호하게 설명했고, 그들은 그것을 존중하고 우리 방식대로 일하도록 허락했습니다.

진짜 문제는 단일 고객이 개발 압력을 가하는 기능을 만들 때 이를 다른 고객이 사용할 수 있는 방식으로 만드는 것이 엄청나게 어렵다는 것입니다. 우리는 이것을 배우기 전에 몇몇 중요한 대기업 고객을 위해 몇 가지 기능을 만들었고, 그 기능들은 해당 고객과 규모와 업종이 같은 경우에만 정말 잘 작동합니다. 다른 사람들에게는 너무 혼란스러워서 사용할 가치가 없습니다. 이를 내면화하고 모든 고객에게 효과가 있도록 제대로 노력하는 데 오랜 시간이 걸렸습니다.

몇 번의 실수를 통해 상처를 입은 우리는 큰 결정을 내렸습니다. 단일 고객만 원하는 기능은 만들지 않겠다는 것이었습니다. 이것은 문서상으로는 좋아 보였습니다. 하지만 실제로는 다음과 같은 결과를 초래했습니다.

MRR 기준 "우선순위 설정"

이는 기능에 대한 내부 제안(때로는 버그 보고서도 포함!)에 기능을 제안한 잠재 고객 또는 고객 목록과 해당 매출을 포함하는 방식입니다. 그러면 우선순위 설정은 가장 높은 매출과 관련된 항목을 선택하는 것이 됩니다.

이는 "이 기능을 만들면 이 모든 신규 고객을 확보할 수 있다" 또는 "이 기능을 만들지 않으면 이 모든 고객을 잃게 될 것이다"라는 의미입니다. 하지만 이는 결코 사실이 아닙니다. 한 가지 기능의 존재 여부만으로 비즈니스 소프트웨어 제품을 구매하거나 이탈하는 경우는 매우 드뭅니다. 그런 일이 자주 발생하고 그 고객을 원한다면 우선순위 설정이 필요하지 않습니다!

이 방법론은 이론적으로는 합리적으로 들리지만 실제로는 완전히 엉망인 것들 중 하나 입니다. 영업 담당자와 고객 관리자는 매우 설득력이 있을 수 있으며, 그들이 요구하는 것을 만드는 것을 거부하기는 정말 어렵습니다. 동시에 그들의 말을 전혀 듣지 않는 것도 좋지 않습니다. 다음에 무엇을 만들어야 할지 명확하지 않을 때 좋은 제품 결정을 내리려면 이러한 극단 사이의 줄타기를 해야 합니다.

강제 혁신

MRR 기반 개발에 지친 몇몇 팀은 선을 그었습니다. "지금부터는 크고 혁신적인 것에만 집중할 것입니다." 이는 내부적으로 매우 인기가 있었습니다. 개발자들은 "큰" 프로젝트를 좋아합니다. 모든 사람이 혁신적인 새로운 것을 좋아합니다. 싫어할 이유가 없지 않나요?

혁신을 강요하는 문제는 회사 내에 획기적인 아이디어가 무한정 존재하고, 아직 구현하지 않은 유일한 이유는 제품 팀이 원하지 않았기 때문이라고 가정한다는 것입니다. 만약 여러분의 회사가 이런 상황에 해당된다면 엄청나게 부유해지기 직전입니다. 하지만 대부분의 회사에서는 그렇지 않습니다. 좋은 제품을 만드는 것은 정말로 원하기 때문이 아니라 훌륭한 제품을 만들 수 있는 조건을 조성하기 때문입니다. 6주마다 팀이 어떤 새로운 혁신을 출시할지 선택하는 환경에서는 새로운 것을 발명할 수 없습니다.

이것이 우리가 강제 혁신을 시도하면서 배운 교훈입니다. 화려한 이름을 가진 복잡한 기능들이 많이 나왔지만, 고객의 삶이나 운명을 실질적으로 바꾸는 것은 없었습니다.

데이터 기반 개발

대부분의 제품 팀과 마찬가지로 우리는 Amplitude와 같은 제품 분석 도구를 구입하고 설정하는 데 많은 시간을 투자했습니다. 그리고 대부분의 제품 팀과 마찬가지로 Amplitude 내부 데이터를 사용하여 좋은 결정을 내리는 데는 거의 시간을 투자하지 않았습니다.

Amplitude는 멋지고 잘 만들어진 도구입니다. Amplitude가 통찰력의 다이아몬드를 찾는 데 정말 유용한 제품과 회사가 있다고 확신합니다. 하지만 우리의 B2B SaaS 세계에서는 이미 알고 있는 매우 명백한 것들("매일 많은 사람들이 로그인합니다", "모든 사람이 사용자 프로필을 정기적으로 사용합니다")만 드러났습니다.

FullStory와 같은 녹화 도구도 마찬가지입니다. 달리 재현하기 어려운 몇 가지 버그를 발견할 수 있었고, 그 점은 다행이지만, 설정 페이지의 화면 녹화를 보면서 훌륭하고 활용되지 않은 제품 통찰력을 발견하지는 못했습니다.

이러한 모든 도구는 고객과 대화하는 것에 대한 좋지 않은 대안입니다.

3단계: 조율하기

이것이 바로 오늘날의 모습입니다. 회사가 성장하면서 기능을 개발할 때 가장 큰 효과를 얻는 것은 회사의 다른 부서에서도 해당 기능에 맞춰 업무를 조정할 수 있을 때라는 사실을 알게 되었습니다.

당연한 이야기 같지만, 아침 식사를 하며 기능 아이디어를 구상하고 저녁 식사 후에 출시하여 고객이 발견하기를 바랐던 초창기와는 상당히 큰 변화입니다.

예를 들어, 몇 년 전 Tanda는 사람들이 일하는 교대 근무에서 다양한 종류의 점심 시간을 처리하는 방식을 개선했습니다. 이를 홍보하기 위해 모든 잠재 고객에게 KitKat 초콜릿과 함께 Tanda가 구축한 기능에 대한 전단지를 우편으로 발송했습니다. 사람들에게 물건을 우편으로 발송하는 것은 놀라울 정도로 큰 물류적 어려움이지만, Tanda가 하는 일에 관심을 끌고 사람들이 이야기하도록 만드는 데 매우 효과적 이었습니다. 또한 회사 전체가 같은 이야기를 하게되었죠. 기능을 설계하고 제작하고 KitKat을 상자에 넣는 과정에서 모두가 무슨 일이 일어나고 있는지 알고 있었기 때문에 새로운 기능을 잘 이해하여 고객에게 설명할 수 있었습니다.

저는 정말 중요한 두 가지 주기가 있다는 것을 알았고, 그 주기에 맞춰 제품을 만들 수 있다면 일이 잘 풀릴 것입니다.

저희의 경우 이 두 가지 주기에 대한 답은 3개월마다였습니다. 저희는 회사 전체에서 OKR을 사용합니다. 3개월마다 OKR을 새로 고칩니다. 그 한 달 전에 다음 분기의 제품 테마를 정합니다. 거기서부터 OKR이 흘러나오고 이를 바탕으로 개별 업무가 구체화됩니다.

즉, 모든 팀은 우리가 어떤 분야에 대해 생각하고 있는지, 어디에서 개선을 기대할 수 있는지 대략적으로 알고 있으며, 이를 자신의 업무와 연계할 수 있습니다.

여기까지가 현재 상황이며, 앞으로 Tanda가 여기서 저지른 모든 실수에 대한 업데이트를 작성하게 될 것이라고 확신합니다.

n단계: 또 다른 제품 추가

Tanda는 현재 새로운 제품을 만들고 출시하고 있으며, 이는 저에게 많은 생각을 하게 합니다. 왜냐하면 이러한 신제품은 아직 1단계(또는 0단계!)에 있기 때문입니다. 아직 누락된 기능이 많기 때문에 다음에 무엇을 만들어야 할지 너무나 명확합니다! 하지만 그 결과, Tanda는 일을 매우 빠르게 처리하고 있으며, 일부 실수를 저지르고 그 과정에서 일부 기능을 다시 만들어야 한다는 것을 알고 있습니다.

두 번째 제품을 언제 추가해야 할지 진작에 좀 더 고민했더라면 좋았을 텐데 하는 아쉬움이 있습니다. 아이를 갖는 것과 비슷합니다. 대부분의 사람들은 언젠가는 아이를 갖게 될 것이라고 생각하지만 준비가 될 때까지 기다리고 싶어 합니다. 준비가 되었다는 이메일을 기다린다면 영원히 아이를 갖지 못할 것입니다. 많은 일이 그렇듯이, 두 번째 제품을 만들기 시작하자 예상했던 것만큼 어렵지 않았고 훨씬 더 보람 있었습니다. 더 많은 제품을 구매하는 고객이 훨씬 더 행복해 보인다는 사실에 가장 놀랐고, 이는 모든 사람에게 활력을 불어넣어 주었다고 생각합니다.

더 일찍 했어야 했을까요? 저는 그렇게 생각합니다. 더 어려웠을 것이고, 준비가 덜 되었을 것이고, 더 많은 실수를 저질렀을 것이고, 제품 간에 더 많은 부담을 느꼈을 것입니다. 하지만 이러한 사고방식에는 매몰 비용 오류가 많이 있습니다.

더 유용한 질문: 이제 막 1단계에서 2단계로 넘어가는 사람이 기존 제품을 더 깊게 파고드는 대신 두 번째 제품을 추가하는 것을 고려해야 할까요? 충분히 검토한 후 추가하지 않기로 결정하더라도 적어도 고려해 보는 것이 좋습니다.

타임머신이 있다면

타임머신을 타고 2012년으로 돌아가 몇 가지 조언을 해 줄 수 있다면, 저는 다음과 같은 세 가지 중요한 팁을 줄 것입니다.

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요