테크 스타트업에서 제품전략팀 만들기
마케팅-개발 조직 구조 개편을 위한 제안서
Mindset
첫 부분에 마인드셋을 적은 이유는 마인드셋이 가장 중요하기 때문이다. 수학의 정석(공통)을 구입하여 공부한 사람이면 알 수 있듯이 우리는 1단원 ‘집합과 명제’를 여러번 공부하여 지겨울 정도로 잘 알고 있다. 조직을 운영하는데 있어서 가장 중요한건 팀원들의 마인드셋이라고 감히 말할 수 있다. 따라서 이 부분을 가장 앞에 배치하여 읽기 지겨운 사람이라도 이 부분 만큼은 주의깊게 여러번 읽기 바란다.
마인드셋이라는 단어는 스타트업에서 많이 쓰이는데 예를들면 Startup mindset, Growth mindset 등이 있다. 이런 세부 용어들에 대해서 설명하진 않을 것이고 직접 찾아보면 팀 운영에 도움이 될 것이다.
우리가 추구하는 여러 마인드셋에서 가장 주의깊게 봐야할 것은 목적지향성 마인드셋이다. 프로이트의 인과론에 젖어있는 현대의 사고방식은 목적지향적 사고에 메말라있다.
일단 회사를 성공적으로 성장시키고 싶다면 내가 하는 일이 맞다라는 생각을 버리고 나는 99.99% 틀리다 또는 모른다라는 사고방식을 고수해야한다. 이미 내가 맞고, 내가 알고있다면 왜 아직도 성공하지 못했는가?
회사라는 큰 단위보다는 프로젝트라는 작은 단위부터 생각해보자. 여러 프로젝트의 성공적인 결과가 회사를 성공으로 이끌것임은 확실하다. 우리의 목적은 프로젝트를 성공적으로 달성하는 것이다. 그렇다면 나의 의견은 그다지 중요하지 않을 수도 있다. 왜냐하면 나는 이 프로젝트에서 만드는 결과물이 제대로 만들어질지, 고객이 이 제품을 살지, 얼마나 잘 팔릴지 99% 모르기 때문이다. 따라서 “나는 이걸 하고 싶다”, “난 꼭 이걸 해서 성공할 것이다”, “고객이 이렇게 하면 산다고했으니까 우린 이걸 한다"라는 마음가짐이 있다면 1인 창업을 추천한다.
“고객이 이렇게 만들어주면 산다고 했으니까 우린 이걸 만든다"라는 부분이 이해가 가지 않는 분들을 위해 자동차 회사 Ford를 창업한 헨리 포드가 따끔하게 한마디 한다.
사람들에게 무엇을 원하냐고 물었다면
더 빠른 말을 원한다고 이야기했을 것이다
더 빠른 말을 만들기 위해서 이 팀을 꾸렸는가 아니면 자동차를 만들기 위해 모였는가. 우리 팀에게 성공이란 (내가 하고싶은 일을 하기위해) 나의 주장을 강요하여 내 생각을 실현시키는 것인가.
따라서 우리는 내가 하고싶은 일을 다른 사람에게 설득하여 하게 하기 보다는, 효과적인 일을 선정하여 효율적으로 하는 것이 중요하다. (선택과 집중)
대부분의 기업문화가 그렇지만 효율성을 중요시하고 우리는 효율성에 대해 잘 이해하고 있다. 그러나 효과적인 일을 하는 것에 대해선 모르는 경우가 많다. 피터 드러커는 다음과 같이 이야기했다. (The Essential Drucker 요약)
효율적(efficiency)으로 일하는 것은 일을 적절히(the thing right) 하는 것,
효과적으로(effectiveness) 일하는 것은 적절한 일을(the right thing) 하는 것
효과적으로 사는 방법은 배워야 한다(Effectiveness must be learned)라고 책에서 이야기한다. 적절한 일을 찾는 것이 정말 중요하다. 불필요한 일을 효율적으로 해내는 것은 어리석은 일이다. 즉, 성공적인 프로젝트를 위해서는 일을 효율적으로 처리하는 것도 중요하지만 어떤 일을 할 것인지 효과적으로 선택하는 것이 더 중요하다는 것을 알 수 있다.
우리는 목적지향적으로 효과적인 선택을 하여 효율적으로 일을 처리할 때 최고의 성과를 낼 수 있을 것이다.
Lean Startup
요즘 2000년생 세대에서는 “요즘도 린 스타트업이라고 외치는 꼰대가 있습니까"라고 비꼬는 경우가 많지만(왜 이런 이야기가 떠도는지도 스타트업에 먼저 발을 담근 우리의 잘못이 크다) 기업에서 Product Market Fit (이하 PMF)을 찾기에는 이보다 더 적절한 방법이 없다고 생각한다. 기존의 회사는 누군가가 제품을 기획하고 개발팀이 제품을 만들고 운영팀이 운영하며 마케팅팀이 수익화하는 구조였다. 그러나 이 경우에는 많은 위험이 따르는데 바로 PMF가 맞지 않을 경우이다.
PMF를 찾지 못했을때 위험한 이유는, 막상 돈과 시간을 들여 제품을 만들어도 시장에서 아무 반응이 없거나, 시장의 요구에 맞춰 제품을 변화시킬 수 없기 때문이다. 따라서 우리는 제품, 운영, 개발, 마케팅이 함께 유동적으로 움직이며 제품을 진화시켜 나가야한다. (개발하지 말고 제품하세요 글 참고)
이는 누구 한 사람이 할 일도 아니며(스티브 잡스와 같은 천재나 하는것) 우리 모두가 위에서 말한 마인드셋을 가지고 함께 참여해야한다.
Lean Startup이라는 우상의 함정
가끔 대표들과 이야기하다보면 린스타트업이라는 말을 빠른 프로토타입 제작으로 착각하는 경우가 많다. 빠른 프로토타입 제작이 린스타트업의 프로세스중 하나이긴 하지만 프로토타입 이후의 프로세스가 더 중요하다고 말하고 싶다.
우리가 어떤 실험을 할때 실험의 설계과 실행, 검증의 단계를 거치듯이 우리는 PMF를 증명하기 위해 어떤 가설을 세우고 가설을 실험하기위한 Minimum Viable Product(MVP)을 만들고, MVP에 대한 반응을 분석하고 정리하여 새로운 제품으로 진화시킨다. 새로운 제품으로 진화시킬때도 또한 가설을 세우고 MVF(Minimum Viable Feature)를 적용하고, 해당 Feature에 대한 반응을 분석하고 다음 제품에 반영시킨다. 이 같은 과정을 반복하다보면 고객의 니즈를 충분히 데이터로 파악할 수 있게 되는데 이 시점에 오면 제품의 Pivot을 실행하게 된다.
단순히 어떤 고객이 이걸 원해라고 내가 가정하고 제품을 만들라고 시키는것은 린스타트업과 거리가 멀다. 또한 모든 결과는 정량적으로 분석이 가능해야하며 왜 이런 제품을 만들어야하는지 데이터로 증명할 수 있어야한다. 가설 - MVP - 분석 - 진화의 단계를 거칠 수 있어야만 진정한 린스타트업이라 할 수 있을 것이다.
그런 의미에서의 제품전략팀
특히 테크 스타트업에서 제품팀의 기능이 강조되고 있는 지금, 우리는 어떤 목적으로 어떻게 제품전략팀을 꾸려나가야 할 것인지 진지하게 이야기해보도록 하자. 그전에 하나, 제품전략팀은 필요에 의해 생긴것이지 다른 회사에 이미 존재하고 있기때문에 따라하자고 주장한것이 아니다.
마케팅팀과 개발팀의 고질적인 문제는 커뮤니케이션이다. 아니, 인간 사회의 고질적인 문제는 커뮤니케이션이다. 모든 인간의 고민은 인간관계에서 비롯된다. (세계 3대 심리학자 알프레드 아들러 왈)
같은 일을 하는 같은 팀 내부에서도 의사소통때문에 골머리를 썩는데, 다른 백그라운드를 가진 다른 팀원들끼리는 오죽하겠는가. 커뮤니케이션의 문제는 회사의 규모가 커질수록 팀의 역할이 세분화될수록 더욱 골이 깊어질 수 밖에 없다.
제품전략팀이 첫번째로 해결해야하는 이슈는 커뮤니케이션이다. 마케팅팀은 개발팀에게 어떤 제품을 만들어달라고 요청하고 싶지만 그 제품의 세부 기능이 무엇인지 어떤 기술을 가지고 만들어야하는지 모를 것이다. 누구에게 이 말을 해야하는지 조차 모를때가 많다.
또한 마케팅팀은 마케팅(Marketing)을 하는 팀이다. 마켓에 우리 기술의 우수성과 제품을 널리 알리는 일에 집중해야한다. 어떤 제품을 만들것인지 고민할 시간에 인스타그램에 홍보 게시글 하나 올리는게 더 효과적이라는 것은 누구나 인정할 것이다.
두 번째로 해결해야할 이슈는 제품 라인업 결정에 있어 효과적인 선택과 집중을 위한 근거마련이다. 우리가 제품을 만드는 이유는 위에서 설명했듯이 우리가 원하는 제품을 만들기 위한 제품개발이 아니라 PMF를 찾기위한 제품개발이다. 따라서 어떤 제품 라인업을 출시해야 우리가 돈을 (더) 많이 벌 수 있는지 고민해야하는 팀이다. 우리는 PMF를 찾지 못했기 때문에 아직 스타트업인 것이고, 그 Fit을 찾기위해 가설 - MVP - 분석 - 진화의 단계를 반복해야한다. 가설, 분석은 고객과의 접점이 있기때문에 마케팅쪽의 정보가 필요하고 실험(MVP 제작), 진화는 개발쪽의 정보가 필요하다.
제품전략팀은 마케팅팀의 정보와 개발팀의 정보를 취합분석하여 고객이 원하는 제품의 컨셉을 실험하고 진화시켜 시장이 원하는 제품을 데이터 주도하에 뽑아내는 일을 진행해야 한다.
기술 자체가 마케팅이 될 수는 없다. 그러나 제품 자체가 최고의 마케팅이 될수는 있다. 보통 테크 스타트업에서는 기술과 제품을 혼용하는 경우가 많은데, 우리는 기술과 제품을 철저히 분리하여 사고하는 방식을 길러야한다. 특히 제품전략팀은 더욱 더 그래야한다.
시장의 성숙도
시장의 성숙도를 바라보는 관점은 다양하지만 Justyna Piotrowska가 제시한 기준으로 보았을때 우리는 2단계에서 3단계사이의 성숙도를 가지고 있는 것으로 보인다. (원문
THE GUIDE TO GROWTH HACKING YOUR STARTUP의 4장 Market sophistication 참고)
시장성숙도는 마케팅팀에서 잘 분석하여 제품 기획 및 마케팅에 반영하도록 한다. 제품군에 따라 성숙도가 다르기 때문이다.
2단계: “무엇인고(What is it)”
시나리오: 경쟁자가 나타난 경우. 고객들이 다른 구매 옵션도 고려하는 순간부터 타 제품과 비교해서 어떠한 차별점을 가지고 있는지 보여줘야 한다. 고객들이 제품을 선호하지 않는 이유들을 정리해서 이를 품을 수 있는 메시지를 전달할 것.
예시: 시장에 타 면도기 경쟁사들이 나타나자 질레트는 본인 제품의 차별점인 안전성을 강조하기 위해 아기가 면도칼을 들고 있는 모습을 보여주며 ‘아기가 들어도 다치지 않는 안전한 면도기’라는 메시지를 전달했다.
3단계: “어떻게 다른가(How does it work)”
시나리오: 드디어 시장에 경쟁자들이 늘어나는 단계이다. 다들 똑같은 메시지를 전달하고, 동일한 기능을 셀링하는 프로덕트 혹은 서비스를 보여준다. 이 단계에서는 나의 서비스는 어떻게 다른지, 어떠한 메커니즘을 기반으로 경쟁제품 대비 차별점을 가지는지 등을 명확하게 알리는 것이 중요하다.
예시: 시장에 경쟁자들이 많아지면서 질레트는 양날 면도기의 안전성을 강조하면서 기타 일회용 면도기들과 차별을 두었다.
우리는 경쟁사와 비교해서 어떤 차별성이 있는지 어떤 메커니즘을 가지고 있는지 자세하게 설명해야할 시기로 보인다. 우리 제품은 경쟁사와 비교해서 무엇이 다른가. 차별점을 명확하게 알릴 수 있는가…
마켓-제품-개발 효율적인 커뮤니케이션
공통
말/메일/메신저보다는 문서로 전달한다
자신이 중요하다고 판단한 경우 문서를 먼저 전달하고 문서를 보면서 말로 다시 전달한다
커뮤니케이션 히스토리를 한눈에 볼 수 있는 프레임워크를 만든다
마케팅팀
고객들의 생생한 목소리를 담은 User story를 정리하여 문서화하여 전사에 공유한다
고객의 순수한 니즈가 무엇인지 파악하여 역으로 질문한다 (고객은 분명 빠른 말을 원한다고 할 것이기 때문)
고객의 제품을 미리 조사하여 그들이 요구하지 않더라도 우리가 먼저 제안한다
고객군을 세부적으로 Segmentation하여 User story를 정리한다
제품팀
마케팅팀으로부터 전달받은 User story 바탕으로 고객의 핵심 니즈를 추출하고 정리하여 문서화한다
핵심 니즈로부터 핵심 기능을 뽑아 정리한다
핵심 기능에 점수를 매겨 정량화/점수화하여 시장이 원하는 기능의 우선순위를 정리한다
내부적으로 보유한 기술 리스트 및 기술 로드맵을 관리한다
고객이 말한 기능 리스트와 우리가 보유한 기술 리스트를 비교 분석하여 기술개발 우선순위를 결정한다
기술개발 우선순위를 결정할때는 가설 - MVP - 분석 - 진화의 단계를 지켜 개발팀과 의사소통 하도록 한다
제품을 기획할때는 하드웨어/알고리즘/분석이 함께 고려되어야 한다
개발팀
각 프로젝트별 기술개발 히스토리를 정리하도록 한다 (제품팀에게 공유할 용도)
회사 내부 아무나 쉽게 이용할 수 있는 QA툴 및 문서를 정리한다 (문서만 보고도 따라할 수 있게)
각 프로젝트별, 태스크별 예상 개발 시간을 추정하는 능력을 키우고 커뮤니케이션시 정량적으로 측정가능한 수치로 이야기하는 습관을 들인다
운영팀
각 팀의 문서를 용도에 맞게 일목요연하게 관리될 수 있는 툴을 만든다
마케팅팀과 제품전략팀을 대하는 개발팀의 자세
하나만 기억하면 된다. 애자일 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
기타: 효율적인 미팅에 대하여
프로젝트 관리 요소가 늘어나면서 미팅과 매니지먼트에 대한 이야기가 많이 나오고 있다. 킥오프 미팅, 개발 미팅, 스크럼 미팅 등… 결론부터 이야기하자면 미팅과 매니지먼트는 없을수록 좋다. (The Two Biggest Drags On Productivity: Meetings And Managers (Or, As We Call Them, M&Ms) - By Jason Fried Co-founder of Basecamp 참고)
만약 미팅을 해야한다면 미팅 아젠다를 확실히하고 그걸 미리 공유하여 사람들이 미리 생각해오게 하는것이 좋다. 미팅에는 크게 2가지의 미팅이 있는데 하나는 상황공유 및 지시를 위한 미팅과 아이디에이션 미팅으로 나눌 수 있겠다.
1. 상황공유 및 지시가 목적인 미팅의 경우는 내가 가지고 있는 정보를 전부 사실 그대로 공유하고 내가 생각하는대로 다른 팀원들도 이해해야 하는 목적성을 지니고 있다. 이런 경우는 메일이나 메신저를 통해 회의할 내용을 미리 공유한 후에 미팅이 필요한지 아닌지 결정하는 것이 좋다. 왜냐하면 말로 전달하는 것보다 글로 전달하는 것이 미스커뮤니케이션을 줄일 수 있는 방법이기 때문이다. 물론 뉘앙스를 전달하기위해 말로 하는 경우가 있지만 극히 드물다고 생각한다.
대부분의 오프라인 미팅이 안좋은 이유는 말하는 사람의 잘못보다는 듣는 사람의 착오 또는 오해로 생기는 경우가 많다. 누구의 잘못이라기보다는 방식의 잘못이라고 말하고 싶다. 왜냐하면 나는 말로 잘 전달했는데 그 사람이 노트에 잘못 적어서 생기는 오류, 기억을 잘못해서 생기는 오류가 너무나 많기 때문이다.
누군가의 말을 듣고 내 노트에 적었다. 미팅 내용이 기억이 나지 않아 다시 내 노트를 보았다. 노트의 적힌 내용이 미팅의 내용의 전부라고 확신할 수 있는가.
나는 말을 잘 전달했는데 팀원들이 잘못 알아들었다면 이를 해결하는 방법은 미팅이 답이 아니라는 이야기다. 미팅의 목적은 내가 하고 싶은 말을 하려는 자리가 아니라 내가 가지고 있는 생각과 팀원들의 생각의 차이를 최소화하려는 것이 목적임을 잊지말자.
2. 아이디에이션 미팅의 경우 이런 문제가 더 심각해지는데 미리 아젠다를 공유하고 “이 날까지 다른 서비스를 벤치마크하고 아이디에이션 해오세요"라고 직접적으로 말해야한다. 그러지 않고 무작정 회의를 잡아 “빨리 아이디어 내놔봐"라고 하면 팀원들은 꿀먹은 벙어리가 된다. 이런 상황이 내 아이디어를 정당화하기 가장 좋은 때이다. 왜냐면 아무도 아이디어가 없고 내 아이디어만 있으니까. 아이디에이션 회의에서는 더 많은 아이디어를 내는 것이 목적이기 때문에 미리 조사하고 생각하여 아이디어를 정리해서 미팅에 참석하게끔 하는것이 좋다.
기타: 왜 우리는 실패를 원하는가 (부정적 의미)
예를 들어 어떤 프로젝트가 잘못 진행되어 실패했을 때를 가정해보자. 이럴 때 우리는 프로젝트가 잘못된 원인을 찾기에 바쁘다. 즉, 누가 잘못해서 이렇게 되었다, 시스템에 허점이 있다 등등. 그러나 목적지향적으로 생각하면 다음과 같다.
우리는 실패하려는 목적을 가졌기 때문에 실패했다.
일단 위의 가정이 맞다고 생각해보자. 그러면 “우리는 왜 실패하기를 원했나”라는 질문으로 이어지게 된다. 많은 사람들이 여기서 부정하고 자기합리화를 시전하는데 우리는 이 부분을 꼼꼼히 살펴볼 필요가 있다. 일단 쉽게 이해하기 위해 아래와 같은 가정을 세운다.
팀 내의 모든 구성원들은 프로젝트가 성공하기를 원하는 사람들로 이루어져 있다.
팀원들은 자신의 마음을 거짓으로 말하지 않는다.
위의 가정을 바탕으로 추론해보면 팀원들의 생각은 [프로젝트의 성공]이라는 같은 목표를 가지고 있지만 뭔가 허점이 있었다고 생각할 수 있다. 프로젝트를 진행하면서 뭔가 걸림돌이 있었을 것이다. 그렇다면 아래와 같은 예상을 해 볼 수 있다.
프로젝트가 잘못 진행되고 있다고 느꼈지만 어떤 부분이 잘못되었는지 몰랐다.
프로젝트가 잘못 진행되고 있다고 확신했지만 개선점을 말할 수 있는 기회가 없었다.
프로젝트가 잘못 진행되고 있다고 확신했지만 개선하기 귀찮았다.
프로젝트가 잘못 진행되고 있다고 느꼈지만 아무 생각이 없었다.
1번의 경우는 노력이 부족한 경우이다. 난 경험이 부족해서 모른다, 이런 경우에 대한 해답지가 없다, 내 오랜 회사생활 경험상 이런 경우는 없었다라고 말하는 사람은 과감히 내치자. 잘못되었다고 느꼈을때는 무엇이 잘못되었을까라는 가정을 세우고 그 가정이 맞는지 틀린지 실험해야한다. 잘못되었다고 있다는 느낌을 팀원들에게 알리는 것이 우리가 첫번째로 해야할 프로세스이다. 정말 문제가 있다면 팀원들은 위의 1, 2, 3, 4번 중에 한 케이스를 선택할 것이다. 만약 대부분의 팀원들이 위의 케이스 중 하나에 해당한다면 정말로 이 프로젝트는 산으로 가고 있을 가능성이 높다.
이 때 우리는 가설을 세우고 무엇이 잘못 되었는지 검증한다. 커뮤니케이션이 문제인지, 조직 구조의 문제인지 테스트하고 검증한다. 해결하고자하는 의지가 있는 사람이라면 실험 프로세스를 알려주지 않아도 그 상황이 닥치면 스스로 실험할 수 있을것이다.
실험 검증의 과정을 거치면 이제 무엇이 문제인지 확실하게 파악되었다. 그러면 문제에 대한 해결책을 머리를 맞대고 고민해본다. 조직 내부의 문제는 생각보다 간단한 경우가 많고 해결책은 쉽게 나온다.
그럼에도 불구하고 우리는 왜 실패했는가라고 묻는 사람들을 위해 요약해서 말하자면, 결국은 우리가 감으로 때려맞추고 오해하였으며, 실험하여 풀려고 하지 않았던 마인드셋 자체가 프로젝트를 실패의 길로 이끈 것이다. 결국 우리의 귀차니즘이, 나의 마음의 결계가 그렇게 만든것이다. 나머지 2, 3, 4번의 케이스도 마찬가지다.
우리는 왜 실패하려고 하는가? 귀찮기 때문이다. 감정소모하고 싶지 않기 때문이다. 윗사람에게 찍히고 싶지 않기 때문이다. 나의 권한(나의 바운더리)을 더욱 견고하게 만들고 싶어서이다. 간섭받지 않고 편안하게 살고 싶어서이다.
다시 한번 말하지만 실험에 의해 더 나은 내일을 맞이하려는 마인드셋이 정말 중요하다.
이 세상에 버그없는 프로그램은 존재하지 않는것처럼 완벽한 시스템은 존재하지 않고 완벽한 사람도 존재하지 않고 완벽한 팀(장)도 존재하지 않는다. 그렇다면 우리가 해야할 일은 가설을 세우고 실험하고 검증하고 고쳐나가는 수 밖에 없다.
