[독후감] The Entrepreneur's Guide to Customer Development

The Entrepreneur's Guide to Customer Development
A "cheat sheet" to The Four Steps Epiphany
by Brant Cooper & Patrick Vlaskovits

이 책은 부제에서 명확히 밝혔듯이 Steven Gary Blank의 "The Four Steps to the Epiphany"를 알기 쉽게 요약(a cheat sheet)해 둔 것이다. 따라서 원책을 읽지 않고 보면 대개 남의 요약만 보았을 때 처럼 다소 산만한 느낌을 피할 수 없다. 다른 독자들의 평도, 원문보다 더 유용하고 쉽다는 평과, 난삽하다는 평이 공존하는 듯 하다.

1. Customer Development는 왜 필요한가?

2005년에 출간된 스티브 블랭크의 원 책은 모든 스타트업들은 제품을 제대로 못 만들어서 실패하는 것이 아니라, 시장을 제대로 못 만들었기 때문에 실패하는 것이라고 주장한다.

Most startups fail because they didn't develop their market, not because they didn't develop their product. p 11

실제로 많은 국내 대기업과 혁신적인 제품이나 서비스를 만들기 위한 프로젝트를 하면서, 그리고 여러 스타트업들이 제품을 만들어내고 실패하는 것을 보면서, 피엑스디에서 항상 첫번째 던지는 질문은 정말 어떤 사용자에게 어떤 가치(value)를 주는가?였다. 단지 고객사의 임원이나, 실무 담당자가 좋을 것 같다라고 막연하게 생각한 가정(assumption)을 가지고 실제 고객을 만나보면, 고객은 완전히 다르게 가치 판단을 하고 있거나, 혹은 방향은 비슷하더라도  반드시 넘어야할 커다란 벽(chasm)이 있는 경우가 많았다. 

전통적인 사용자 중심 프로세스에서는 이러한 잘못된 방향이나 벽을, 앞선 사용자 연구(User Research)를 통해 발견하고 미리 해결하여 제대로된 제품이 되도록 노력한다. 그런데 여기서 한 가지 불안한 부분은, "우리가 연구하여 발견한 내용이 혹시 잘못되었으면 어떻게 하지? 우리가 틀리지 않았다는 것을 어떻게 증명하지?" 하는 것이다. 잘못 사용자 연구를 몇 번 한 사람은 신뢰를 안 하게 될테고, 피엑스디처럼 반복적인 사용자 연구에서 맞다는 것을 증명 받아도 여전히 제품이 나와 소비자들에게 팔릴 때까지는 불안하게 느껴졌다. 지난 9번의 성공이 10번째의 성공을 보장해주지는 않으니까.

결국 여기서 피엑스디가 대개 선택하는 방법은 제품을 완전히 만들기 전에 프로토타입을 빨리 만들어서 테스트를 해 보는 것이었다. 그런데 이 프로토타입 테스트는 대개 세 가지 정도의 문제를 가진다. 첫째, 프로토타입이 나오는 시점(대개 프레임웍 스케치 단계)도 사실 꽤 늦을 수 있다는 것, 둘째, 프로토타입은 유용성이나 사용성은 검증하기 쉬워도 가치를 검증하기는 어렵다는 점(특히 반복하여 사용해야만 가치를 느낄 수 있는 제품/서비스에서), 마지막으로, 설령 개별 사용자에게 가치를 검증 받더라도, 시장성(즉 얼마나 많은 사람들이 돈을 주고 살 것인가?)을 판단하기는 매우 매우 어렵다는 점이다.

따라서 스타트업이나 신규 사업을 위해서는 이 보다 좀 더 안전하고 확실한 방법이 요구되는데, 그것은 바로 제품 개발을 하기 전에 고객 개발(Customer Development)을 먼저하는 방법이다.

2. 고객 개발이란?

린스타트업의 에릭 리스(Eric Ries)는 사실 이 고객 개발과 애자인 개발 방법론을 결합하여 린스타트업을 만들었다고 볼 수 있다.(서문) 결국 전통적인 Waterfall 방식에서 고객을 파악하고 그들의 요구 사항을 알아내기 위하여 사용자 연구 후, 퍼소나를 만드는 것에 대응하는 린스타트업 프로세스의 과정이 고객 개발이라고 볼 수 있다.
참고:위키피디아 고객 개발

고객 개발을 한 마디로 추상화하자면, 새로운 사업 구상의 기본 가정 (business assumption)을 확인하는 과정이라고 볼 수 있다. 다시 말하면, 제품을 판매할 시장을 찾아내고, 고객의 문제를 해결할 필수 기능을 수립하고, 고객에게 판매할 정확한 방법을 검증하여 사업을 키울 수 있도록 '발견하고 검증하는' 4개의 단계로 구성된 프레임웍이다.

Customer Development is a four-step framework to discover and validate that you have identified the market for your product, built the right product features that solve customers' needs, tested the correct methods for acquiring and converting customers, and deployed the right resources to the business. p19

여기서 네 가지 단계란, 동일한 문제를 갖고 있는 고객 집단을 발견하고(Customer Discovery), 시장성을 검증하고(Customer Validation), 사업의 성장성을 확인하며(Company Creation), 조직을 구성하는(Company Building) 것으로 구성된다. (p19)

특히 전통적인 사용자 연구&퍼소나 기법이 고객 개발의 1단계 (problem-solution fit)를 잘 설명하는데 그쳤다면, 그 다음 단계인 product-market fit은 우리가 불안해 하던 부분을 어느 정도 해결해 줄 수 있을 것 같다.

Product-Market Fit

간단히 요약하면 어느 정도 크기가 되는 시장을 형성할 수 있도록 충분한 수의 사용자가 해당 제품에 대해 열정을 가지고 강한 수요를 보여주는가?를 의심하는 것이다. (When a product shows strong demand by passionate users representing a sizable market. p37)

이는 크게 세 가지 요소가 만족되어야 하는데, 첫째, 고객은 기꺼이 제품에 대해 지불할 가치를 느낄 것. 둘째, 고객을 획득하는데 드는 비용이 제품을 제공하는데 드는 비용보다 낮을 것, 셋째, 시장의 크기가 사업을 유지할 수 있을 정도로 충분히 클 것 등이다. 이 때 특정 문제에 대하여 '매우 공감한다'라고 생각하는 고객이 적어도 40%는 되어야 가능하다고 본다는 것이다.

MVP(Minimum Viable Product)

이 책의 저자들은 기존 스티브 블랭크의 책에서 제시하는 'Product Feature Set'과 크게 다르지 않다고 하지만(p39) 이는 minimum testable product에 더 가까운 개념이고, MVP는 product-feature set이나 minimum testable product와는 매우 다른 질적 차이를 갖고 있다고 필자는 생각한다. 여기서 viable이란 고객이 정말 좋아하느냐를 매우 정확히 표현한 부분이며 기존 프로토타입 테스트와의 중요한 차이점이기도 하다.

반면, 기존 MVP를 공부할 때는 이것이 사업으로서 생존 가능한 부분, 즉 수익(money)으로 돌아와야만 MVP가 완성된다고 생각하여 혼란스러운 경우가 많았는데, 이 책에서 제시하는 MVP의 개념이 가장 지금의 내 생각과 일치한다. 

MVP란 고객이 기꺼이 자신의 (시간/돈 등) 자원을 지불할 정도로 특정 문제를 해결해 주는 최소한의 기능을 가진 제품을 말한다.

A product with the fewest number of features needed to achieve a specific objective, and users are willing to "pay" in some form of a scarce resource. p39

결론적으로 고객 개발은 원칙(Principles)이나 단계(The Steps)로서 이해할 수도 있겠지만, 철학(Philosophy) 수준에서 이해해 줄 것을 저자들은 당부하고 있다. 이 책에서 단 한 가지만 기억해야 한다면, 바로 고객 개발이란 사업 전략을 의심해 보는 것 ("Question Your Assumptions" p20)이란 사실이다.

3. 고객 발견의 8단계

고객 개발은 위에서 언급한대로 4단계로 구성되어 있으며, 그 첫 번째 단계인 고객을 발견하는 단계(Customer Discovery)를 이 책에서는 8단계로 다시 나누어 설명하고 있다.

C-P-S 가정 (Customer-Problem-Solution Hypothesis, 1단계)
자신이 생각하는 대상 고객의 특징(Customer), 그들이 갖고 있는 어려움(Problem), 그리고 그에 대한 사업 아이디어(Solution)을 먼저 정확하게 한정지어 보는 부분이다.(p68) 이 부분은 기존의 퍼소나를 작성하는 것과, 과정과 목표가 완전히 동일하므로 똑같은 어려움이 있을 수 있다. 예를 들어 초보 퍼소나 제작자들의 흔한 실수는, 퍼소나 구분과 그들의 상황과 문제(Attitude, Behavior & Pain Points), 마지막으로 그들의 목표(Goal)가 서로 1. 하나의 완벽한 세트로 연결되지 않거나 2. 충분히 좁혀지지 않거나 하는 문제이다. (시중에 나와 있는 퍼소나는 대개 이런 의미에서 잘못된 퍼소나다. 특히 2번 문제는 누가 우리의 퍼소나인가?라는 관점 보다, 누가 우리의 퍼소나가 아닌가?에 의해서 확립된다)

책에서는 주로 1번과 2번을 잘 만들기 위하여 현실에서 반복하는 것을 추천한다. 책의 68-70을 읽어 보면 모두 이러한 부분을 반복하는 것을 볼 수 있다. 즉 누가 고객인지 더 좁혀보고, 그들이 현재 채택하고 있는 불완전한 솔루션은 없는지 보고, 그들은 어떤 태도를 갖는지 보라는 것이다. 특히 주의할 것은 현재 솔루션의 약점을 반드시 고객의 눈으로 보라는 거다. 고객은 그것을 그렇게 큰 약점으로(솔루션을 현재 제품에서 당신네 제품으로 바꿀만큼) 보지 않을 수도 있고, 혹은 그 약점이 커도, 다른 혜택이나 감정적인 이유 때문에 계속 유지하고 싶을 수도 있다.(p70) 사용자는 감정을 가진 하나의 완전한 사람이라는 점을 잊지 말아야 한다.

반면 퍼소나에서는 다수의 사용자를 관찰하고, 그것을 기술하되, 사용자에 대한 좀 더 폭넓은 공감에 기초하여 정의한다는 점이 다르다. 퍼소나는 공감에 기초하므로 problem이나 solution이란 단어를 쓰지 않고, context, attitude, behavior, pain points, 그리고 goal 이란 단어를 사용하는데, 이러한 단어/방법론 사용 자체만으로도 우리의 시각을 넓혀주고 관점을 바꾸어 주는 효과가 있다. (시중에 나와 있는 퍼소나는 대개 이런 의미에서 함량 미달이다)

하지만 퍼소나의 약점은 이러한 부분을 철저하게 고객을 통해서 반복하여 검증하지 않는다는 점이 될 수 있다. 즉 반복을 염두에 두고 다듬어 나가는 방법이 필요하고, 검증을 염두에 두고 항상 testable한 hypothesis 형태로 만든다는 점이 (기존에도 없었던 것은 아니지만) 부족한 부분이다.

즉 다시 한 번 강조하면 UX가 UI에서 벗어난 가장 중요한 것은 방법론이 아니라 관점, 철학이고, 린스타트업 혹은 LeanUX가 이룬 것도 관점, 철학이다. UI와 UX, UX와 LeanUX를 서로 방법론으로 비교하면 답이 없다. 어떤 철학, 혹은 마음가짐(Mind-set)을 추가해야하는 가에 집중하고 나면 방법론이 동일해도 서로가 구분이 갈 수 있다. 따라서 이러한 고객 개발법은 이미 사용자에 대한 공감(UX)에 훈련된 사람이 활용할 때 가장 좋지 않을까 생각한다. 아마도 이것이 Lean UX의 포인트가 되지 않을까 추측해 본다.

만약 UX 훈련을 받지 못 한채 LeanUX를 해야한다면, solution 부분을 goal로만 대체해도 어느 정도 긍정적인 효과가 있지 않을까? 예를 들어 '매뉴얼'이 이러이러하니까 이러한 불편을 해결하기 위한 '전자 매뉴얼'이 solution이라면, goal은 어떻게 하면 고객이 제품에 대한 정보를 쉽게 얻을 수 있게 할 것인가?이다. 그러면 굳이 '현재 방식의' 매뉴얼이 필요없는 것도 하나의 solution이 될 수 있다.

예를 들어 p70에 이런 질문들을 추가해 보자.
-고객은 대체로 어떤 사람들인가?
-고객의 문제는 어떤 상황에서 생기는가? 그 상황에서 가장 중요한 것은 무엇인가?
-고객의 문제와 연결된 또 다른 문제들은 무엇인가?
-고객의 문제에 대한 해결은 얼마나 부분적인가? 전체적인가?
-고객이 최종적으로 얻고자 하는 바(Goal)는 무엇인가?

Bonus: C-P-S는 Elevator Pitch가 된다! (p69)

Brainstorm Business Model Hypotheses(2단계)

여기서는 크게 세 가지 가정(Business Assumptions, MVP Assumptions, Funnel Assumptions)을 점검하라고 제시하는데, 이 중 특히 사용자 연구 관점에서 흥미로운 것은 Funnel Assumptions이다. 기존 사용자 연구 프로젝트에서 사용자를 관찰하고 기술할 때, 흔히 빠트리기 쉬운 부분 중 하나가, 어떻게 사용자를 획득하고, 그 사람들이 우리 제품을 열심히 사용하도록 만들며, 또 전파하게 만들 것인가?라는 부분, 즉 사업적인 사용자 획득 전략 부분을 간과하기 쉽다.

사용자 자체에 대한 모델(Persona), 주변 환경에 대한 모델(Context Models), 그리고 시간의 흐름에 따른 모델(Customer Journey Map)에 추가하여 사용자 획득 모델(Customer Acquisition Model)이 필요하다. 이 역할을 린스타트업의 코호트 분석(cohort analysis)에서 사용자 행동(flow)을 통해 살펴 볼 수 있고, 이 책에서는 깔때기 가정(Funnel Assumptions)를 통해 알 수 있다.

깔때기 가정이란, 고객 변화 단계를 "Suspect->Lead->Prospect->Customer->Reference", 즉 제품을 사용할지 말지 고민하다가, 써 볼까? 생각하다가, 사용하게 되고, 또 다른 사람에게 추천까지 하는 단계로 나누었는데, 반드시 이렇게 구분할 필요는 없고, 점점 더 제품에 충성도가 높아지는 적절한 단계가 표시되면 된다. 위에 언급한 린스타트업 책(코호트 분석)에서는 "등록 후 로그인하지 않음->로그인->1회 대화->5회 대화->유료 고객" 등으로 구분하기도 했다.

고객 조사와 검증(3-6단계)

다음 세 단계는 누굴 만날지 정하고, 만나기 위해 연락하고, 또 만나서 물어보는 단계인데, 이 단계들은 기존 UX 방법에서 매우 잘 구축되어 있다. 다만 한 가지, 대부분의 사용자 조사에서는 Open Ended Question의 가치를 절대적으로 높게 평가하는데 반해, 여기서 주의 사항은, 가격에 관한한 'How much would you be willing to pay?' 같이 열린 질문을 하지 말라고 한다. 이 경우 고객은 매우 임의적으로 대답하게 될 것 같다. 가격에 관하여는 특정 가격을 집어서 물어보거나, free-trial이 있다면 해 보겠냐는 식으로 다른 중요한 자원을 쓸지 말지 판단을 물어봐야 한다고 한다.

또 한 가지, 지금 계획하는 신제품이 고객에게 nice to have 일지, must have 일지를 판단하는 일(p81)은 중요하다. 대개의 사업가들은 자신의 상품이 must have일 거라고 생각하다보니, 소비자들이 인터뷰에서 nice to have라는 대답을 우회적 혹은 직접적으로 했는데도 불구하고 must have로 착각하고 듣는 일이 흔하게 생긴다. 객관적으로 들어야 한다. (물론 제품이 nice to have라서 안 되는 건 아니지만 고객을 뚫기가 훨씬 어려워진다. 시장 자체는 사실 게임 같은 것이 훨씬 크기는 하니까, 꼭 어느 쪽이어야 한다기 보단 특징을 정확히 파악해야한다는 뜻이다.)

그 다음 한 단계(6단계)는 이러한 조사들을 종합한다.

Problem-Solution Fit/MVP와 검증 (7-8단계)

이제 좀 더 확고해진 고객-문제-해법 세트를 얻었다면 이것을 MVP로 만들어 계속하여 테스트하면서 MVP를 발전시키는 과정이 필요하다.

이제 이것으로 고객 개발의 1단계, 고객 발견(Customer Discovery)이 끝났다. 다음 단계는 고객 개발의 2단계, 즉 고객 검증(Customer Validation) 단계인데, 이 단계에서는 주로 Product-Market Fit, 즉 제품(서비스)의 시장성을 검증하는 단계인데, 아쉽게도 이 책은 여기에서 끝이 난다.

결론

이 책에서는 고객 개발을 이해/적용하는 세 가지 수준의 언급(p20)을 다시 인용하면서 요약한다. 첫 번째 철학 수준(Philosophy)에서는 사업 가정에 대해 항상 회의-의심하라(Be skeptical about your assumptions)라는 것이고, 두 번째 그것보다 더 필요하다면 원칙들(Principles)을 받아들이라는 것이다. 이러한 원칙들은 반드시 자신의 사업 환경에 맞게 적용되어야 한다. 마지막으로 절차들(Steps)은 책에서 제시한 방법을 그대로 따라하기 보다는 왜 하는지 이해하고 그에 맞게 적용하는 것이 중요하다고 강조한다.

LeanUX의 고객 개발 방법은 기존의 사용자 연구 관점에서 보면, 부족하고 허술해 보이는 부분이 매우 많다. 그러나 이러한 고객 개발 방법은 기존의 사용자 연구 방법론에서 제공하지 못 하고 있거나 혹은 불명확하게 제공하고 있는 많은 단점을 보완해 준다. 예를 들면 한 번의 완성으로 제출하고 끝나는 것이 아니라 진정한 반복의 틀을 제공한다든지(기존 사용자 연구 기법에서도 항상 반복하라고 하기는 하지만, 이 경우는 틀자체가 반복을 전제로 만들어졌다는 점이 다르다), 아니면 고객을 획득하는 단계까지, 다시 말하면 더 넓게 말해서 좀 더 사업적인 관점까지 방법론(모델링)을 확장시켰다는 점이 의미가 있다. 이렇게 보면, 이러한 새로운 방법을 쫓아서 실행해도 배울 것이 많고, 기존의 방법론을 보완하여 실행해도 배울 것이 많아 보인다. 

책 홈페이지: http://www.custdev.com/
[참고##Lean UX##]