에릭 리즈 - 린스타트업: Part 2. 조정하라 (Steer)

Part Two. Steer

린스타트업은 지난 포스팅(http://blog.daum.net/orange/1728)에서 설명한 가치가설, 성장가설 이를 기반으로 MVP(minimal viable product, 최소한의 스펙으로 가설을 증명할 수 있는 제품)을 테스트하면서 사용자 피드백을 기반으로 제품을 진화한다. 그리고 경우에 따라 제품을 전혀 다른 방향으로 Pivot하기도 한다. 

페이스북을 예로 가치가설, 성장가설을 설명해보자. 페이스북은 초창기 15만 가입자가 보유하고 있음에도 불구하고 벤쳐캐피털로부터 50만불을 펀딩 받았다. 물론 당시 페이스북은 수익도 거의 없었다. 그럼에도 벤쳐캐피탈리스트로부터 주목받았던 부분은 가입자의 절반 이상이 매일 페이스북을 방문한다는 지표였다. 이는 분명히 이 서비스가 가입자에게 가치를 제공하고 있음을 나타내는 지표였던 것이다.

다음은 페이스북의 성장성이었다. 페이스북이 런칭한 2004년 2월 4일부터 2월 말까지 하버드 재학생의 2/3이 서비스에 가입했다. 그 과정에서 마크 주커버그와 그의 친구 2명은 어떠한 마케팅, 광고도 집행하지 않았다. 그 이후 페이스북의 성장은 잘 알다시피 엄청난 고속 이는 성장가설 측면에서 벤쳐캐피털리스트에게 충분히 어필한만한 현상이었던 것이다.

이와 같은 가설을 검증하기 위해 기업가들은 리서치를 하고 고객과 대화를 나눈다. 이과정에서  2가지 문제가 자주 발생한다. 많은 경우 기업가들은 일단 해보자(just-do-it)로 임하는 경우가 많다.  이들은  일부 고객들과  피상적인  대화를 나눈 다음에 일단 제품부터 만들려고 한다. 다른 케이스는  너무 신중한 케이스이다. 어떤  기업가는  계획을  정교화하는데 너무 많은 시간을 할당한 나머지 프로젝트를 시작해보지도 못한다. 여기서 설명한 두 케이스 모두 스타트업 경영에 있어 위험하다. 언제까지 분석을 하고, 제품 개발 시점을 결정하는 것은 어려운 이슈이다. 이에 대한 답을 린스타트업은 MVP(minimal viable product)를 통해 제공하고자 한다.

MVP는 최소한 노력과 개발 공수로 완성할 수 있는 제품이다. 그리고 핵심은 위에서 설명한 Build-Measure-Learn Loop 과정을 실현할 수 있는 최초 버전이라는 것이다. 즉, 쉽게 말하는 최소한의 리소스로 고객의 피드백을 얻고, 쉽게 이를 제품 개발에 반영할 수 있도록 설계된 제품/서비스를 말하는 것이다.

물론 MVP(minimal viable product)에는 후에 필요하다고 여겨지는 많은 기능들이 빠져있을 수 있다. 하지만 기능 추가하는 것 이상으로 MVP에게 요구되는 것이 많다는 것을 명심해야 한다. 우리는 MVP를 통해 제품/서비스가 고객들에게 미치는 영향력을 살펴봐야한다. 이는 단순히 엔지니어/디자이너가 서비스 내부 안정성, 디자인 퀄리티를 따지는 것과 다른 차원인 것이다. 우리는 실제 고객들에게 MVP를 보여주고, 그들로부터 진짜 리액션/피드백을 얻어내야 하는 것이다. 때론 우리는 MVP를 가지고 영업을 뛰고, 또는 무언가를 팔기 위해 노력해야할지도 모른다.

minimal viable product는 entrepreneurs로 하여금 빠른 시일내 학습(learning)의 단계를 제공한다. 물론 간단한 제품의 경우, MVP가 필요하지 않을 것이다. 그건 차지하고, 어쨌든 MVP는 최소한의 리소스로 Build-Measure-Learn 피드백 루프를 실현하는 방법이라고 말할 수 있다. 과거 전통적인 제품 개발 과정-긴시간의 인큐베이션 기간과 완성도를 위해 고군분투 했던 단계가 제품 출시 전에 필수였던-과 대조적으로 MVP의 목표는 학습에 이르는 시간을 가능한 빠르게 얻고자 함에 있다. MVP는 프로토타입 또는 컨셉 테스트와 다르게 단순히 제품 디자인 또는 기술적인 이슈에 대한 답을 얻고자 하는 것이 아닌, 궁금적으로 비즈니스의 가설을 테스트함에 그 목표가 있는 것이다. 

실제로 제품을 개발하고 사용자의 피드백을 살펴보는 과정은 힘들다. 대다수의 사람들은 이와 같은 과정이 낭비가 될 것이라고 말한다. 하지만 기업가가 아무도 원하지 않는 제품을 만드는 것보다 이와 같은 과정이 훨씬 많은 시간과 리소스를 절약시켜 줄것이다. MVP가 사용자에게 이용되는 순간부터 학습이 시작되며 기업가의 가설과 추측은 어느순간 검증될 것이다.

MVP 사례는 다음 링크("린스타트업이 말한는 MVP")를 확인하면 된다. 

MVP 관련해서 다수의 기업가들은 다음과 같은 점들을 걱정하지만 모든 이슈가 MVP가 얻는 가치 보다 낮다. 1) 법률적 이슈(특허 관련 이슈는 법적 카운셀링 통해 해결해라), 2) 경쟁자의 아이디어 도용(어차피 경쟁해야할 상대이고 이겨야할 적들이다), 3) 브랜딩 리스크(다른 브랜드 네이밍을 이용한다. 그리고 추후에 PR을 활용해라)

MVP가 초기에 실패했을 때 기존 표준회계(standard accounting)은 이에 대한 해법을 제안하기 힘들다. 이와 관련해서 린스타트업은 혁신회계 (Innovation accounting)라는 개념을 제안한다.

기존 표준 회계(standard accounting)는 스타트업이 measure하는데 도움이 되지 않는다. 왜냐하면 스타트업의 향후 방향과 마일스톤은 예측이 힘들기 때문에 기존 표준 회계로 측정하기 어려운 면이 많다고 한다. 기존 회계는 마일스톤과 KPI를 미리 셋팅하고 이를 수행하지 못하면 실패로 간주한다. 이는 실패에 대한 학습을 중요시 여기는 스타트업의 생리와 맞지 않는 부분이 있다. 혁신 회계는 스타트업이 행하고 있는 일련의 마일스톤, 개선사항이 어떻게 고객 또는 매출에 영향을 미치는지 확인할 수 있을까에 대한 물음을 해결해주고자 한다. 

린스타트업이 말하는 혁신 회계는 다음과 같은 단계를 거친다.

Step 1. 현재 상태를 데이터로 명확하게 보여줄 수 있도록 MVP를 이용해라. 

Step 2. MVP를 튜닝해서 지속적인 개선을 시도해라. 개선작업은 여러번 반복될 수도 있다. 그리고 decision point에 이를 때까지 진행한다.

Step 3. decision point를 만날때 현재 제품을 유지할지 혹은 Pivot할지 결정한다.

즉, 혁신회계는 회사가 ideal 상태에 이르지 못하고 계속 답보 상태에 이르렀을때 Pivot이 필요하다는 신호를 제공해줄 것이다. 즉 현재 자신의 스타트업이 지속가능한 비즈니스 수익을 창출할 것인지 혹은 다른 무엇인가를 해야할지를 알려줄 것이다.

그럼 우리는 MVP를 통해 현재 제품의 상태를 나타낼 수 있는 베이스라인 메트릭스를 정의하고, 해당 메트릭스를 향상시키기 위한 제품의 튜닝 작업을 반복하게 될 것이다. 하지만 만일에 쓸모없는 메트릭스 (vanity metrics)를 설정하고 이에 맞추어 제품 튜닝의 로드맵을 설정하면 무의미한 업무만 반복하게 될 것이다. 이와 같은 vanity metrics는 제품이 올바른 방향으로 진화하고 있는지 여부와 기능의 우선순위를 정하는 것에 대한 어떠한 길도 알려주지 않는다.

쓸모없는 메트릭스의 대표적인 예시로는 가입자수, UV와 같은 성장 지표(gross metrics)들이 있다. 이와 같은 지표가 증가하는 것을 그래프로 그려보면 그럴싸해보인다. 하지만 sustainable business 관점에서 이와 같은 지표는 실제 우리에게 수익을 가져다주는 고객수에 비하면 중요하지 않다. 이런 지표는 기업가에게 성공하고 있다는 착각만을 가져다 줄뿐이고 실제 비즈니스 인사이트에 아무런 도움을 제공하지 않는다.

그럼 어떤 방법론이 혁신 회계에 적합할까? 그 중에서 몇가지 방법론을 확인해보자.

1. funnel metrics (참고링크: Jason's blog)

funnel metrics는 제품을 이용하는 flow 각 단계별로 존재하는 유저의 행동을 추적할 수 있도록 도움을 주는 지표를 가리킨다. 제품 이용 각 단계를 체크함으로써 어떤 단계에서 conversion 비율이 낮은지를 분석함에 있어 매우 유용하다.  예를 들면 다음과 같은 단계로 funnel 분석이 가능할 것이다. 

:: 가입->애플리케이션 다운로드->trial->제품의 반복 이용->구매

2. cohort analysis (참고링크: 지미림's 블로그)

코호트 분석은 한 제품 내부에서 사용자를 몇개 그룹으로 분리해서 시간이 지남에 따라 해당 그룹의 변동성을 분석하는 방법론이다. 개인적으로 통계를 많이 공부 안해서 모르겠지만 만일 코호트 분석을 사용한다면 한 제품의 사용자를 몇개 코호트 단위로 나눌 것이다. 이때 각 그룹은 독립적이어야하고 겹침이 없어야할 것이다. 코호트를 단위를 나누는 방법은 제품의 특징에 따라 다를 것이다. 

아래 그래프는 IMVU 케이스이다. funnel metrics를 기반으로 코호트 단위를 만들었다. 가입자(하지만 로그인 경험이 없는), 로그인 경험이 있는 가입자, 가입하고 한번 대화한 유저, 가입하고 5번 이상 대화한 유저, 유료 가입자 단계로 구분했다. 

여기서 특이한 점은 5번 이상 IMVU를 사용한 신규 가입 유저가 5%에서 20% 성장했음에도 불구하고 유료 가입자는 7개월 동안 1%대에 머물렀다는 점이다. 아래 그래프에 없지만 7개월 동안 IMVU는 누적 가입자수는 지속적으로 증가했다고 한다. 누적 가입자 지표만 본다면 이는 긍정적인 지표이다. 하지만 내실은 그렇게 신규 가입자가 늘어났음에도 불구하고 유료 가입자의 비중은 해당 성장률을 따라가지 못한다는 점이다. 7개월 동안 IMVU는 다양한 기능 개선을 했음에도 불구하고, 이 모두 개선이 유료 가입자에게는 어떠한 메리트를 주지 못했다는 것을 의미한다. 

하지만 어쨌든 이와 같은 분석을 통해 IMVU는 무엇에 집중해야할지 파악하게 된 것은 긍정적인 점이다. 앞서 말하는 누적 가입자와 같은 vanity metrics에 집착했다면 계속 이와 같은 인사이트를 얻지 못했을 것이다. 

3. A/B 테스트(split-test)

A/B 테스트는 흔히 버킷 테스트라고도 한다. 사실 다수의 레거시 웹 서비스들이 이와 같은 버킷 테스트를 실시하기 위한 환경을 갖추지 못한 경우가 많다. 어쨌든 지금 시작하는 스타트업의 경우 이와 같은 테스트를 통해 점진적으로 제품을 개선할 수 있는 설계를 염두해야하는 것은 기본일 것 같다.

A/B 테스트는 간단하다. 두가지 버전의 제품을 다른 그룹에 테스트해보는 것이다. 두 그룹 사이에 발생하는 사용자 이용행태의 변화를 관찰함으로써 제품의 베리에이션이 미치는 영향을 예측할 수 있다. 

A/B 테스트는 전통적으로 DM 광고업자들에 의해 많이 애용되었다. 예를 들면 제품 카탈로그 디자인 개편이 미치는 영향을 확인하고 싶다면 50% 유저에게는 변경된 카탈로그를 우편으로 보내고, 나머지 유저에게는 기존 버전의 카탈로그를 보내면 된다. 단 정교한 테스트를 하기 위해서는 카탈로그에 담기는 콘텐츠 내용은 동일해야한다. 

흔히 A/B 테스트는 마케팅 기법으로 알려져있지만 린스타트업에서는 이를 제품 개발에 응용한다. 비록 A/B 테스트는 단기적으로 개발 공수와 지표 측정을 위한 별도의 개발 리소스가 투여된다. 하지만 장기적인 관점에서는 잘못될 길로 가는 것을 사전에 방지하고, 유저가 원하는 바가 무엇인지를 확인하는데 효과적이다. 앞서 설명한 코호트 분석과 결합하면 A/B 테스트에 따른 특정 그룹의 변화를 효과적으로 확인할 수 있다.

4. 칸반(Kanban)

칸반은 토요타의 린생산에서 활용된 개념이다(칸반 시스템 검색결과). 린스타트업에서는 이를 제품 개발의 우선순위를 결정할 때 활용했다. 칸반 기반의 제품개발 과정에서 각 유저 스토리들은 검증되지 못하면 제품의 기능으로써 배포되지 못한다. 린스타트업은 칸반 시스템을 응용해서 유저 스토리를 다음 네 단계, 아이디어 단계(backlog), 개발단계(in progress), 기술적 관점에서 완료된 상태(built), 검증단계(validated) 중에 한 곳에 포함시킨다. 검증단계는 아래와 같이 정의할 수 있으며,  A/B 테스트 및 서베이/인터뷰를 통해 확인할 수 있다.

"검증단계(Validated)란 특정 유저 스토리가 좋은 아이디어인지 아닌지를 초기에 확인하는 것이다"  

칸반 시스템의 룰은 각 유저 스토리를 아래 그림에서 보여지는 4단계에서 처음부터 한 단계씩 이동할 수 있다. 그리고 특정 단계가 유저 스토리로 꽉 차 있으면 더이상 앞 단계로부터 추가로 유저 스토리를 받지 않는다. 특정 유저스토리는 Validated 단계를 마쳐야 칸반 보드에서 빠질 수 있다. Validated 단계를 넘지 못한 유저스토리는 bad idea로 간주되며 관련 기능은 제품에서 제거된다. 

각 단계는 3개 이상의 유저 스토리를 받을 수 없다. A는 개발 대기중이며, D, E는 개발중인 유저스토리이다.

F는 개발이 완료되어 검증을 기다리는 아이템이다.

F가 검증이 완료되었다. D,E는 검증을 기다리고 있다. G,H,I는 개발 대기중인 아이템들이다. B,C는 개발중인 유저스토리이다.

앞서 설명한 A는 개발완료 상태인 아이템이다.

칸반시스템 아래서 B,C는 개발완료되어도 Built 단계로 이동할 수 없다. 왜냐하면 Built 단계가 3개 유저스토리로 꽉차있다.

D,E,A는 여전히 검증상태인 것이다. 당연히 Backlog 상태인 H,I도 다음 단계인 개발 단계로 이동할 수 없다.

칸반 시스템은 단순히 개발 생산성은 개발완료한 기능으로 측정하는 방식의 비생산성을 해결해준다. 스타트업에게 필요한 것은 검증이 필요한 유저 스토리에 맞는 기능 및 시스템을 개발하는 것이다. 이와 같은 칸반 시스템은 엔지니어링의 스킬만 요구되는 것이 아니다. 고객과 대화도 필요하며, A/B 테스트 결과 데이터를 해석할 수 있는 분석 능력도 요구된다.

따라서 이와같은 칸반 시스템에서 막힘 현상(모든 단계가 꽉 차버리고 진척이 없는 것처럼 보이는 이슈)을 해결하기 위해서는 제품 개발진 모두 초기부터 검증단계에 대한 고민이 필요할 것이다. 각 개발자가 검증단계에서 생산성을 높이기 위한 노력을 기울인다면 스타트업 팀 전반적으로 해당 프로세스를 수행함에 있어 장기적인 관점에서 낭비를 줄일 수 있다 (단기적으로 A/B 테스트를 고려하지 않으면 한 개인 개발자의 개발 시간을 단축시킬 것이다. 하지만 장기적인 관점에서 검증을 위한 별도의 개발을 거쳐야하기 때문에 비생산성을 유발시킬 수 있다)

그럼 스타트업은 지표를 측정할때 어떤 부분을 신경써야할까? 린스타트업은 3A를 제안하고 있다.

(1) Actionable: 측정 결과가 actionable하기 위해서는 측정지표가 인과관계를 명확히 나타낼 수 있어야 한다. 만약 그렇지 않다면 vanity metrics가 되고 말 것이다.

(2) Accesible: 지표 리포트 결과는 모든 직원과 임원이 쉽게 이해할 수 있어 의사결정을 내릴때 도움이 되되어야한다. 마치 "metrics are people, too"라는 생각으로 누구나 쉽게 이해할 수 있도록 지표를 설정해야한다. 특히 제품이 성장함에 따라 데이터 규모도 그만큼 커질 것이다. 이때 많은 구성원들이 지표 변동의 스케일을 직관적으로 이해하지 못하는 경우가 많다. 이에 대한 추가적인 커뮤니케이션 노력이 요구되는만큼 지표는 누구나 쉽게 이용하고 이해할 수 있도록 accessible해야한다.

(3) Auditable: 모든 구성원들이 지표에 대해 신뢰할수 있도록 투명한 데이터 수집 시스템이 필요하다. 사실 지표분석이란 것은 제품을만드는 개발진에게 우선순위가 떨어지는 항목이다. 대부분 프로덕트 매니저의 요구에 따라 만들어지게 된다. 하지만 지표와 실제 사용자 행동 사이에 괴리가 발생한다면 데이터가 가리키는 사용자 행동에 대해 구성원들이 신뢰하지 못하게 될 것이다. 결과적으로 당연한 이야기지만 적절한 측정을 수행할 수 없게 될 것이다.

따라서 지표가 auditable하기 위해서는 앞서 설명했듯이 지표=사용자라는 마음으로 측정된 지표를 바탕으로 직접 사용자 패턴을 확인해서 데이터의 정확성을 검증해야한다. 그리고 가능하면 데이터 집계 과정이 복잡하지 않도록 intermediate system이 아닌 마스터 데이터로부터 직접 추출하도록 하는 편이 좋다.

린스타트업 방법론은 제품의 존속과 Pivot에 대한 과학적 결정을 내릴 수 있도록 도와준다. 단순히 스타트업이 열심히 일한다고 자신들이 원하는 것을 얻을 수 없다. 이제는 스마트하게 사용자와 제품을 바라봐야하는 것이다. 자신들이 설정한 맹신적 가설(leap-of-faith)를 검증할 수 있도록 MVP를 만들어야 한다. 그리고 혁신 회계의 평가 지표를 바탕으로 현재 상태를 측정해야한다. 

A/B 테스트와 같은 방법론을 통해 다양한 버전의 제품을 사용자에게 테스트하다보면 초기에 스타트업 기업가들이 믿었던 맹신적 가설의 일부가 옳지 않은 경우를 확인할 수도 있다. 예를 들면 가입자, 액티베이션 지표는 높지만 리텐션, 레퍼러 지표가 낮게 측정될 수 있다. 아무리 테스트해보아도 해당 지표가 계속 정체되었다는 것을 발견한다면 기업가는 제품의 존속에 대해 심각하게 고민하게 될 것이다. 이때 Pivot을 결정할 수 있다. 특정 기능에 포커싱(zoom-in pivot)하여 제품 개편을 진행할 수 있다. 경우에 따라 제품에 대한 성장 엔진을 사용자 참여가 아닌 유료 결재로 변동할 수도 있다. 그리고 지속적으로 가설을 테스트하면서 유료결재 부문에서 변동이 없으면 특정 고객측에 타겟팅하여 제품 개편(customer segment pivot)을 단행할 수도 있다.

어쨌든 린스타트업은 과학적으로 제품의 개발을 바라본다. 테스트를 통해 다양한 버전의 MVP, 기능을 시장에 보이고 사용자로부터 데이터를 확보한다. 다양한 버전이 테스트를 거치면서 가설에 부합하는 여부를 확인하게 될 것이다. 테스트 결과 가설이 옳다고 판단하면 지금의 제품 개발과정을 존속하면 될 것이다. Path는 초기 50명에 한정된 소셜네트워크를 개발한다고 했을때 언론 및 블로거로부터 많은 뭇배를 맞았다. 50명이라는 제한이 매우 인위적이라는 평이 많았다. 당연히 이들 블로거들은 그 유명세만큼 많은 네트워크를 유지했기 때문에 Path의 비전에 대해 동의할 수 없었다. 하지만 Path는 이와 같은 비평을 두려와하지 않고 초기 유저들의 피드백에 집중했다. 의외로 많은 유저들이 기존 소셜네트워크의 많은 인맥에 피로감을 가지고 있었고, Path를 그 대안으로 여겼다. 사용자들은 Path가 제공하는 친밀감을 사용했고, 초기 Path 로드맵에 없던 다양한 기능을 제안했다. 예를 들면 친구들의 사진에 자신의 감정을 표현하거나, video moments와 같은 기능이 이에 해당할 것이다. 

Path같이 사용자 피드백에 귀기울이며 제품을 존속하는 케이스도 있지만 만일에 현재 지표가 맹신적 가설을 부정한다면 가능한 빨리 전략을 전환해야한다. 린스타트업은 이와 같은 전략 전환(Pivot)에 대해 아래와 같은 방향성을 제시하고 있다.

(1) Zoom-in  pivot

제품의 특정 기능을 집중하여 이를 중심으로 제품 개편을 진행한다.

(2) Zoom-out pivot

한 기능이 전체 제품을 충분히 지원하지 못할때 내리는 Pivot이다. Pivot 이전에 제품 전체로 간주되던 것이 Pivot후에 개편된 버전에서 한 기능으로 재편되는 것을 의미한다.

(3) Customer Segment Pivot

기존 고객이 아닌 다른 고객군을 타겟팅하여 제품을 개발한다.

(4) Customer Need Pivot 

기존에 해결하고자 했던 고객의 문제점이 사실은 중요한 것이 아니란 것을 깨닫고 더욱 중요한 문제를 해결하기 위해 Pivot하는 케이스다. 팟벨리 샌드위치는 1977년에 앤티크 샵으로 오픈했다고 한다. 당시만해도 샌드위치를 고객 방문을 위한 유인책에 불과했다. 하지만 가게 샌드위치 반응이 좋아지자 샌드위치 중심으로 비즈니스 라인을 정비했고, 지금은 미국 전역에 200개가 넘는 체인점을 보유하고 있다.

(5) Platform Pivot

플랫폼 피벗은 어플리케이션에서 플랫폼으로 전환하거나 혹은 그 반대의 케이스를 가리킨다. 소위 말하는 킬러 애플리케이션을 개발하고 API를 통해 서드파티의 참여를 유도하여 플랫폼으로 진화하는 방향이 이에 해당한다.

(6) Business Architecture Pivot  

제프리 무어의 비즈니스 아키텍쳐에서 개념을 빌려온 것이다(소량&높은 마진-대부분 소비자 제품, 대량&낮은 마진-대부분 B2B). 

소량&높은 마진에서  매스 마켓으로 혹은  매스 마켓에서 소량&높은 마진으로 전환하는 케이스다.

(7) Value Capture Pivot 

 monetization, revenue model 전환에 대한 케이스이다.

(8) Engine of Growth Pivot

스타트업을 성장시키는 수단에는 다양한 방법론이 있다. 바이럴, 스티키, 유료 성장 모델 등이 있다. 이와 같은 성장 동력을 전환하는 케이스를 가리킨다. Engine of Growth Pivot이 발생할때 수익화 모델에 대한 전환도 같이 요구하는 경우가 많다.

(9) Channel Pivot

제품 유통 채널에 대한 전환을 의미한다. 이미 IT에서는 기존 제품 판매, 유통과 차별화된 다양한 채널이 제안되기도 했다.

(10) Technology Pivot

기존에 보유하고 있는 고객에게 가치를 줄 수 있는 인프라를 구축하기 위해 기술의 전환을 진행한다. 대부분 경우 비용 절감을 위해 Technology Pivot을 진행한다.

Pivot은  성장하는 기업이라면 항상 끌어안고 있어야하는 현실이다. 비록 기업이 초창기에 성공했을지라도 외부변화에 적응하기 위해서는 Pivot을 지속해야한다. 린스타트업 관점에서 새로운 가설을 설정하거나 MVP를 테스트할 때마다 Pivot이 발생할 수 있다. Pivot은 린스타트업의 사실상 핵심이라고 할 수 있는데, 린스타트업을 수용한다면 Pivot을 단순히 제품 변화에 대한 권고사항으로 나이브하게 받아들여선 안된다. Pivot은 새로운 MVP, 비즈니스 모델, 성장 엔진을 테스트하기 위해서 지금의 상황이 만든 특별한 변화로 받아들여야한다. Pivot은 린스타트업을 따르는 기업에게 잘못된 방향설정을 유연하게 바로잡을 수 있는 도구를 제공해주는 것이다.