인스파이어드

인스파이어드
북코스모스 회원이 되시면 오디오 듣기 이용이 가능합니다.
인스파이어드

마티 케이건 지음
제이펍

책소개

이 책은 최고의 기업과 최고의 제품팀이 어떻게 일하는지를 설명한다. 독자들은 필요한 정보를 습득하고 자신이 속한 조직에 바로 활용하여 문제점을 개선할 수 있고 세계 최고 수준의 팀처럼 업무 혁신을 통해 성과를 낼 수 있다.

요약본 본문

인스파이어드

마티 케이건 지음
제이펍 / 2018년 12월 / 382쪽 / 24,000원

PART Ⅰ 최고의 기술 기업에서 배운 것

실패한 제품의 근본 원인

수많은 제품이 실패하는 근본적인 원인이 무엇일까. 나는 그동안 많은 회사들이 같은 방식으로 일하고 있음을 관찰하였다. 그리고 이러한 방식은 실제로 최고의 회사가 일하는 방식과는 거리가 멀다.

모든 것은 아이디어에서 출발한다. 대부분의 아이디어는 내부(임원, 핵심 이해 관계자 또는 비즈니스 담당자) 혹은 외부(현재 또는 잠재 고객들)로부터 유입된다. 아이디어가 어디에서 발생했건 간에, 항상 비즈니스의 각 분야에서 제품 관리자가 처리해 주기를 바라는 엄청난 양의 과제들이다. 이제 대부분 회사는 이러한 아이디어들의 우선순위를 매겨 로드맵으로 전환하기를 원하는데 그들은 두 가지 이유로 로드맵을 사용한다. 첫째는 가장 중요한 일을 먼저 수행해 주기를 원하기 때문이며, 둘째는 각 업무가 언제 준비 상태가 될지 예측하고 싶기 때문이다. 로드맵을 작성하기 위해 보통 분기 또는 연간 계획 세션과 같은 일정표를 마련한다. 이때 리더들은 아이디어를 검토하면서 제품 로드맵에 대해 협의한다.

그리고 그들은 우선순위를 정하기 위해 먼저 각 아이디어에 대한 비즈니스 케이스 정의가 필요하다고 생각한다. 비즈니스 케이스 정의는 각 아이디어에 대해 두 가지를 분명히 알아야 한다는 것이 핵심이다. (1) 얼마만큼의 매출이나 가치를 만들어 낼 것인가? (2) 얼마만큼의 비용이나 시간이 필요한 것인가? 이러한 정보는 다음 분기의 로드맵(때로는 1년의 로드맵)을 작성하는 데 활용된다. 이때 제품과 기술 조직은 진격 명령이 떨어지면 보통 가장 높은 우선순위의 아이디어부터 차례대로 실행하게 된다. 어떤 아이디어가 가장 높은 우선순위에 있으면 제품 관리자가 가장 먼저 해야 할 일은 해당 이해 관계자를 만나서 아이디어를 구체화하는 것이다. 이를 통해 일련의 요구사항을 정리한다.

이러한 요구사항은 사용자 스토리(user story) 형태이거나, 아마도 기능 명세와 같은 양식의 형태일 것이다. 요구사항은 디자이너와 엔지니어에게 무엇이 만들어져야 하는지를 커뮤니케이션하기 위함이다. 요구사항이 모두 수집되고 나면 사용자 경험 디자인팀은 상호작용 디자인(interaction design), 시각 디자인(visual design), 물리적인 기기의 경우 산업 디자인(industrial design)에 대한 진행을 요청한다. 그리고 그 요구사항과 디자인 결과물은 엔지니어에게 전달된다. 대개 이 시점에서 애자일(agile; 소프트웨어를 일단 빠르게 출시한 다음에 사용자들의 의견과 통계를 바탕으로 업데이트를 배포하는 과정을 반복하는 순환식 개발 방식)이 등장한다. 애자일 모델은 적은 돈과 시간에 맞추기 위해 요구 사항을 끊임없이 수정하는 방식이다. 엔지니어들은 보통 그 과제를 이터레이션(interation, 반복 업무 단위)으로 나눈다. 마지막으로 QA 팀이 그 신규 아이디어 과제가 예상대로 동작하는지, 다른 문제는 없는지를 검증한다. QA 팀으로부터 이상이 없음을 확인하는 녹색 신호를 받으면, 그 신규 아이디어는 마침내 실제 고객에게 배포(deploy)된다.

대다수의 크고 작은 기업들은 위에서 설명한 프로세스를 필수적으로 이미 오랫동안 사용하고 있다. 그리고 이런 기업들은 일관된 불평불만을 제기한다. 혁신이 부족하고, 제품을 고객에게 전달하기까지 너무 오랜 시간이 걸린다는 것이다. 엔지니어들은 대부분 주어진 폭포수(waterfall; 위에서 설명한 프로세스응 통칭한다) 프로세스의 환경에서 할 수 있는 최대한의 애자일을 실천하고 있다. 그런데 왜 이것이 수많은 실패의 필연적인 이유인가? 그 이유를 찾기 위해 단편적인 내용의 조각들을 연결해 보자. 다음은 이러한 업무 방식이 가지는 가장 큰 문제 10가지이다.

① 아이디어의 출처. 이 모델을 사용하면 판매 확대를 위한 기능이나 이해관계자 위주로 제품이 끌려가게 된다. 가장 큰 문제는 이 방식이 뛰어난 제품 아이디어를 가져오지는 못한다는 것이다. 또한 이러한 접근 방법은 팀에게 필요한 권한 위임이 안 된다. 이 모델을 따르면 제품팀은 마치 외부 용병처럼 그저 열심히 실행할 뿐이다.

② 비즈니스 케이스의 치명적인 결함. 물론 큰 규모의 투자가 필요한 아이디어일 경우 비즈니스 케이스가 필요할 수 있다. 하지만 많은 회사가 로드맵 단계에서 비즈니스 케이스를 작성하는 것은 말도 안 된다. 앞에서 말한 대로 모든 비즈니스 케이스의 핵심적인 두 가지 요소는 ‘얼마만큼의 돈을 벌 수 있는가’와 ‘얼마만큼의 비용이 드는가’다. 그런데 냉정히 말해 현재 시점에서 이 두 가지 수치를 알 방법이 없다. 얼마만큼의 돈을 벌 수 있을지는 결국 얼마나 좋은 솔루션을 만들어 낼지에 달려 있기 때문이다. 만일 팀이 환상적으로 일을 해냈다면 큰 성공을 만들어 낼 수도 있다. 하지만 현실은 많은 제품 아이디어가 결국 아무것도 이루어 내지 못한다는 것이다. 마찬가지로 제품을 만드는 데 얼마만큼의 비용이 들어갈지도 알 수 없다. 실제 어떤 솔루션을 만들지도 모르는 상태에서 엔지니어가 비용을 예측하는 것은 불가능에 가까운 일이다.

③ 회사가 제품 로드맵에 대해 빠져들기 시작하면 더 큰 이슈가 발생하기 시작한다. 대부분의 로드맵은 우선순위가 정해진 기능과 프로젝트들의 목록으로 구성되어 있었다. 예를 들어 마케팅은 특정 캠페인을 위해 이런 기능을 원하고, 영업은 새로운 고객 확보를 위해 저 기능을 원할 수 있다. 하지만 여기에 가장 큰 문제가 있다. 소위 제품에 관한 두 가지 불편한 진실이다. 첫 번째 진실은 당신의 아이디어 중 최소 절반 이상은 유효하지 않을 것이라는 사실이다.

아이디어가 기대한 효과를 얻지 못하는 데는 여러 이유가 있다. 가장 흔한 이유는 이 아이디어에 대해 우리만큼 고객이 관심을 갖지 않는다는 것이다. 그래서 고객은 그 제품을 사용하지 않기로 선택한다. 그리고 가끔은 사람들이 좋아하는 제품이지만 당초 예상했던 것보다 더 큰 비용이 드는 상황도 발생한다. 그래서 나는 제품 로드맵에 있는 최소 절반 이상의 아이디어는 기대했던 효과를 만들어 내지 못한다고 장담한다. 두 번째 불편한 진실은 아이디어가 충분히 잠재적인 가치가 있는 것으로 파악되었더라도 필요한 비즈니스 가치를 만들어 내는 수준에 도달하려면 최소 몇 번의 이터레이션을 반복해야 한다는 것이다. 우리는 이것을 돈을 버는 데 필요한 시간(time to money)이라고 한다. 내가 제품을 만들면서 깨달은 가장 중요한 교훈은 이 두 가지 불편한 진실에서 벗어나는 경우는 없다는 것이다. 다행히 나는 정말 뛰어난 팀들과 일을 해왔고, 이들의 다른 점은 이러한 불편한 진실에 대처하는 방법에 있다는 사실을 알 수 있었다.

④ 이 모델에서 제품 관리의 주요 업무는 엔지니어를 위해 요구사항을 수집하고 문서화해 주는 것이 다. 하지만 이는 내가 실제 기술 제품 관리라고 하는 일과는 180도 다르다는 것을 지적하고 싶다.

⑤ 디자인의 역할도 상황이 비슷하다. 디자인의 진정한 가치를 담기에는 너무 늦은 상황이라서 대부분은 이른바 ‘돼지 입술에 립스틱 바르기’를 하게 된다.

이미 상황은 더 나빠졌으므로 엉망인 제품에 페인트 코팅이라도 씌우려고 시도한다. 사용자 경험(UX, User Experience) 디자이너도 이것이 바람직하지 않다는 것을 잘 알고 있지만, 이렇게라도 그들의 방식대로 보기 좋고 일관된 디자인을 해나간다.

⑥ 아마 이 모델에서 놓치는 가장 큰 기회는 엔지니어들이 너무 늦게 참여한다는 것이다. 엔지니어들이 단지 코드를 짜는 일만 한다면 그들이 가진 가치의 절반밖에 활용하지 못하는 것이다. 제품 개발에서 작은 비밀이 있다면 엔지니어가 보통 혁신을 하는 데 가장 훌륭한 원천이라는 것이다. 그러나 이 모델에서 그들은 회의에 초대조차 받지 못한다.

⑦ 엔지니어팀을 너무 늦게 참여시키는 것뿐 아니라 애자일의 원칙과 핵심적인 장점이 너무 늦게 작동된다. 이러한 방식으로 업무를 하면 팀은 애자일 방법론의 실질적인 가치와 잠재성을 단지 20%만 활용하게 된다. 이는 제품 구현과 전달에만 애자일이 적용되는 것이며, 다른 모든 조직과 업무 상황에는 해당하지 않는다.

⑧ 이 모든 프로세스는 다분히 프로젝트 중심적이다. 회사는 프로젝트에 투자하고, 프로젝트에 인력을 지원하며, 조직에 프로젝트 단위로 압박하며, 결국 프로젝트를 출시하게 된다. 불행하게도 프로젝트는 결과물에 대한 것이고, 제품은 비즈니스 성과에 대한 것이다. 이 프로세스는 프로젝트들을 고아와 같은 신세로 만든다. 결과적으로 무언가 출시되었지만, 처음에 생각한 목표에 부합하지 못했다고 하자. 그렇다면 애초에 무엇이 중요했던 것일까? 어떤 경우에도 이것은 매우 치명적인 문제이며, 우리에게 필요한 제품 개발 방식과는 거리가 멀다.

⑨ 전통적인 폭포수 방식이 여전히 가지고 있는 가장 큰 문제는 위험이 가장 마지막에 발견된다는 것이다. 고객에 대한 검증이 너무 늦게 일어난다는 의미다. 린 방식(Lean method)의 핵심적인 원칙은 낭비를 줄이는 것이다. 가장 큰 낭비의 형태는 결국 원하지도 않는 기능이나 제품을 발견하기 위해 디자인-구현-테스트-배포해 나가는 것이다. 아이러니한 사실은 많은 팀이 내가 설명한 폭포수 프로세스를 적용하고 있으면서도 스스로 린의 원칙을 적용하고 있다고 착각한다는 것이다. 그러면 나는 그들이 가장 값비싸고 느린 방법으로 아이디어를 실행하고 있다고 지적한다.

⑩ 끝으로, 우리가 이 프로세스로 시간과 비용을 낭비하느라 정신없을 때 발생하는 가장 큰 손실은 따로 있다. 바로 그 시간에 조직이 할 수 있었던 혹은 해야만 했던 것에 대한 기회비용이다. 많은 기업이 엄청난 시간과 비용을 들이고도 매우 허망한 성과를 거두는 현상은 그리 놀라운 일도 아니다. 우리는 시간과 돈을 다시 돌릴 수 없다. 최고의 팀들은 절대 앞서 설명한 방식처럼 일하지 않는다.

PART Ⅱ 사람

강한 제품팀의 원칙

제품팀은 각기 다른 전문적인 능력과 책임을 진 사람들의 집단이며, 단일 제품 또는 큰 제품의 주요 영역에 대해 실질적인 주인 의식을 느낀다. 뛰어난 제품 회사에서 발견되는 다음과 같은 몇 가지 중요한 유사점들이 있다.

▲ 미션팀: 제품팀은 많은 장점이 있다. 그중에서도 실리콘밸리의 유명한 벤처 캐피털리스 존 도어의 말이 제품팀의 목표를 가장 잘 표현한다. “우리가 원하는 것은 용병팀(team of mercenary)이 아닌 미션팀(team of missionary)이다.” 용병팀은 지시한 것만을 만든다. 반면 미션팀은 진심으로 비전을 믿고 그들의 고객 문제 해결을 위해 최선을 다한다. 제품 전담팀은 마치 사내 스타트업처럼 행동하고 느낀다. 그것이 제품팀에 바라는 모습이다.

▲ 팀의 구성: 일반적인 제품팀은 한 명의 제품 관리자, 한 명의 디자이너 그리고 두 명부터 최대 10~12명의 엔지니어로 구성된다. 제품이 사용자 접점의 경험을 다루는 것이 아니라면 제품 디자이너는 필요 없을 수도 있지만 그 외 많은 제품팀은 제품 디자이너가 꼭 필요하다. 상황에 따라 제품 마케팅 매니저, 테스트 자동화 엔지니어, 사용자 경험 연구원, 데이터 분석가들도 포함될 수 있다.

▲ 팀의 권한과 책임: 제품팀의 콘셉트에서 이야기하는 중요한 사실은 그들이 비즈니스의 매우 어려운 문제를 해결한다는 것이다. 그들은 분명한 목표를 가지고 그 목표에 맞추어 실행한다. 목표 달성을 위한 최상의 방법을 찾아내는 권한이 있으며, 동시에 그 결과에 대한 책임도 진다.

▲ 팀의 크기: 제품팀을 구성하는 최소 조건은 보통 한 명의 제품 관리자, 한 명의 디자이너, 두 명의 엔지니어다. 실질적으로 팀의 규모는 대개 8~12명의 엔지니어까지 가능하다. 아마도 당신은 ‘피자 두 판의 법칙’을 들어 본 적이 있을 것이다. 팀의 규모를 두 판의 피자를 먹을 만한 사람 수 이내로 유지하라는 의미다. 팀의 절대적인 규모보다 더 중요한 것은 팀이 올바른 제품을 올바르게 만드는 데 필요한 고른 역량을 갖추고 있느냐는 것이다.

▲ 팀의 보고 체계: 제품팀은 보고하고 보고 받는 관계가 아니다. 의도적으로 수평 구조를 지향한다. 많은 경우 제품팀의 각 구성원은 독립적이며, 관리자가 별도로 존재하지 않는다. 팀의 구성원들은 보통 그들의 직무 관리자와 지속적으로 상황을 공유한다. 분명히 말하지만 제품 관리자는 제품팀 구성원의 상사가 아니다.

▲ 팀 협업: 제품팀은 어려운 비즈니스 문제를 해결하기 위해 장기간 함께 일하는 숙련된 기술을 가진 구성원들의 조합이다. 이들 관계의 본질은 진정한 협업이다. 여기서 ‘협업(collaboration)’이란 단순히 함께 일한다는 것만을 의미하지는 않고, 제품 관리, 디자인, 기술 구현이 함께 솔루션을 만드는 데 집중한다는 뜻이다.

▲ 팀의 위치: 제품팀은 가능하면 같은 장소에서 함께하기 위해 최선을 다해야 한다. 같은 장소에 있다는 것은 팀 구성원들이 바로 옆에 붙어 앉아서 일한다는 것이다. 서로의 컴퓨터 화면을 쉽게 볼 수 있을 정도로 가까운 거리여야 한다. 최고의 기업들은 팀으로서 같이 앉아서 일하는 것의 가치를 절실히 느끼고 있다. 같이 앉아 일하고, 함께 점심을 먹고, 서로 개인적인 신뢰를 쌓아가는 과정에서 발생하는 특별한 역동성이 있다. 다른 모든 조건이 같다면 같은 장소에서 근무하는 팀이 흩어져 있는 팀 보다 훨씬 더 높은 성과를 낸다. 마찬가지 이유로 계약직이나 외주 업체보다는 정규 직원으로 제품팀을 구성하는 것이 훨씬 효과적이다.

▲ 팀의 자율성: 충분한 권한을 가졌다고 느끼면서 고객 문제를 해결하기 위한 열정으로 뭉친 팀을 원한다면 그들에게 높은 수준의 자율성을 제공해야 한다. 그래야만 팀이 주어진 문제를 해결하는 데 가장 적절하다고 발견한 최고의 방법을 시도해 볼 수 있다. 또한, 자율성은 팀 간의 의존성을 최소화할 수 있다. 확장하는 상황에서는 모든 의존성을 지속적으로 최소화하기 위해 노력해야 한다.

▲ 제품팀이 왜 효과적인가: 제품팀 모델이 왜 그토록 효과적인지에 대한 몇 가지 이유가 있다. 첫째, 협업에서는 관계가 중요한 역할을 하는데, 제품팀은 특히 같은 장소에서 일하는 경우 이러한 관계를 잘 살리는 형태다. 둘째, 전문성이 필요한 혁신을 하는 경우 오래 지속되는 제품팀은 구성원들이 전문성을 충분히 확보할 수 있을 만큼 깊이 업무를 수행한다. 셋째, 제품팀은 다른 사람들이 가치 있을 것으로 예상해서 결정한 것을 만드는 것이 아니다. 팀 전체가 비즈니스 목표와 상황을 잘 이해하고 있으며, 가장 중요한 점은 팀 전체가 주인 의식과 성과에 대해 책임감을 느낀다는 것이다. 프로젝트 중심의 전통적인 모델은 프로세스에 따라 할당된 업무를 수행하고 나면 끝이다. 반면에 전담팀 모델은 출시가 되었다고 문제가 다 해결된 것이 아니다. 사용자와 비즈니스 입장에서 원하는 결과가 나올 때까지 끈을 놓지 않는다. 당신의 회사가 아직 제품 전담팀을 구성하지 않았다면 당신이 해야 할 가장 중요한 일은 제품 전담팀으로 전환하는 일이며, 이는 다른 모든 것에 영향을 준다.

리더십의 역할

모든 기술 조직에서 리더십의 가장 중요한 업무는 훌륭한 인재를 영입하고 성장시키고 유지하는 것이다. 하지만 제품 회사에서 리더십의 역할은 인재 육성을 넘어 이른바 제품의 총체적인 시각을 요구한다. 스타트업에서는 한두 개의 제품팀으로 구성이 되어 있어서 제품 전체의 시야를 모두가 유지하는 것이 그리 어려운 일이 아니지만 회사가 다수의 제품을 다루는 조직으로 성장하게 되면 곧 어려움을 느끼게 된다. 전체 제품이 어떻게 엮여 있는지 이해하는 것은 성장하면서 겪는 큰 도전이다. 제품 전체의 관점을 갖는 것에 있어서 세 가지 중요한 요소들을 살펴보자.

▲ 제품 관리 리더: 전체 제품의 체계(제품 비전, 전략, 기능 정책, 로직 등)가 비즈니스 관점에서 어떻게 맞물려 돌아가는지에 대한 총체적인 시각을 가지려면 제품 관리 조직의 임원 또는 제품 관리자 리더가 있어야 한다. 이 사람들은 정기적으로 다양한 제품 관리자의 업무를 검토하고, 갈등 사항을 발견하고, 해결을 돕는다. 제품 관리자 전담 리더는 제품 자체에 집중하고, 모든 제품 관리자, 제품 디자이너, 엔지니어, 테스트 자동화 엔지니어들이 언제든 문제 해결에 필요한 도움을 얻을 수 있도록 준비되어 있어야 한다. 만일 제품 관리자 리더에게 이 역할을 맡긴다면 제품 총괄에 직접 보고하는 관계가 되어야 한다. 그래야 모두가 이 역할의 중요성과 책임을 이해할 수 있다.

▲ 총체적인 시각의 리더십 역할: 회사가 커질수록 점점 제품 관리 리더, 제품 디자인 리더, 기술 조직의 리더의 역할이 중요하게 된다. 이 역할이 제대로 이뤄지지 않으면 문제가 곧바로 드러난다. 만약 제품이나 사이트가 상충하는 사용자 모델과 부실한 사용성을 보인다면, 아마도 디자인 총괄이나 디자인 리더가 없다는 증거일 것이다. 제품 관리자가 그들의 의사결정이 미치는 영향을 잘 이해하지 못하면 프로젝트의 진행이 계속 막히게 된다. 소프트웨어가 마치 큰 스파게티 덩어리처럼 엉켜 있고, 간단한 수정을 위해서도 오랜 시간이 소요된다면 심각한 기술 부채(technical debt; 장기적인 해법 대신 당장 편한 해법을 택함으로써 발생하는 추가적 비용)를 안고 있다는 이야기다.

따라서 이러한 리더들이 절대로 회사를 떠나게 하지 마라. 나아가 이러한 리더들을 더 많이 육성하라. 각 리더는 든든한 2인자로 키우는 사람이 한 명 이상은 있어야 한다. 이러한 리더들은 결코 하루아침에 만들어지는 것이 아니다. 그렇기 때문에 매우 소중하고 중요한 존재다. 어떤 회사는 그 해결 방법으로 리더 부재에 대비하여 시스템에 대한 문서화를 시도하기도 한다. 하지만 이러한 문서화가 성공적인 경우는 한 번도 본 적이 없다. 시스템은 복잡성과 규모가 증가하는 것이, 누군가가 그것을 문서로 정리하는 속도보다 항상 더 빠르다. 그리고 소프트웨어에서 절대적인 답은 항상 소스 코드에서만 찾을 수 있다. 세 명의 총체적인 시각을 가진 리더들(제품 총괄, 디자인 총괄, 기술 총괄)은 개개인으로서도 매우 가치가 있는 사람들이지만, 셋의 조합이 실제로 강력한 힘을 발휘한다.

PART Ⅲ 제품

제품 비전과 제품 전략

▲ 제품 비전: 제품 비전은 통상적으로 2년에서 5년 정도의 기간에 우리가 만들어 내고자 하는 미래를 나타낸다. 하드웨어나 디바이스 제품 기업들의 경우는 대개 5년에서 10년 정도의 기간을 설정한다. 제품 비전은 회사의 사명선언문(mission statement)과는 다르다. 사명은 예를 들어 ‘세상의 정보를 정리한다’ 또는 ‘더 열려 있고 연결된 세상을 만든다’처럼 그 자체로 유용하지만 우리가 그것을 달성하기 위해 어떻게 계획할 것인지 설명해 주지는 못한다. 바로 그것이 제품 비전이 존재하는 이유다. 비전은 또한 설명서가 아니다. 스토리보드나 백서와 같은 이야기 형태이거나 ‘비전타입(visiontype)’이라고 불리는 특별한 프로토타입과 같은 설득력 있는 작품에 가깝다. 제품 비전의 주요한 목적은 비전을 잘 전달하고, 직원을 포함하여 이해 관계자, 투자자, 제휴사, 잠재고객들의 비전 실현을 돕기 위해 영감을 불어넣는 것이다. 제품 비전이 잘 수립되면 인력을 채용하는 데 가장 효과적인 도구가 된다. 또한 직원들이 매일 출근해서 업무를 하는 동기부여를 제공한다. 뛰어난 엔지니어들은 무언가 의미 있는 것을 만들고 싶어 하므로 영감 있는 비전에 마음이 끌린다.

▲ 제품 전략: 제품과 관련한 모든 깨달음 중 가장 기본적인 것은 바로 모두를 만족시키려고 하면 그 누구도 만족하지 못한다는 사실이다. 제품 전략은 우리가 제품 비전을 실현하기 위한 과정을 통해 계획하는 일련의 제품 또는 출시를 말한다. 대부분의 비즈니스 형태에서 나는 일련의 제품/시장 궁합들로 제품 전략을 구성하도록 팀에 권장한다. 여기에는 많은 다양한 접근 방법이 있을 것이다. 사업 중심 회사의 경우 당신은 아마 개별 시장(재무 서비스, 제조, 자동차 등)에 집중하는 각기 다른 제품/시장 궁합을 가지고 있을 것이다. 고객 중심의 회사는 다른 그룹의 고객이나 ‘사용자 페르소나(persona; 특정 제품이나 서비스를 이용하는 하나의 사용자 유형)’를 기준으로 제품/시장 궁합을 구성할 것이다. 예를 들어 교육 관련 서비스에서 고등학생을 먼저 목표로 하고, 그 다음은 대학생, 그리고 그 다음은 직장인을 목표로 하는 전략을 가질 수 있다. 때로는 제품 전략이 지리적인 위치를 기반으로 수립되기도 한다. 의도된 순서로 세계의 각 지역에 진출하는 것이다.

어떤 경우에는 제품 전략이 논리적이고 중요한 순서를 담은 핵심적인 단계들을 달성하는 것으로 수립되기도 한다. 예를 들어, 첫 번째는 전자상거래 응용 프로그램을 만드는 개발자들에게 핵심적인 평가와 후기 기능을 제공하고, 다음에는 이로부터 생성된 데이터를 활용하여 고객 반응에 대한 데이터베이스를 만든다. 끝으로 이러한 데이터를 더 훌륭한 제품을 추천하는 데 활용한다.

누구에게나 이상적인 제품 전략에 대한 접근 방법은 없다. 그리고 실제 실행을 다르게 했다면 일이 어떻게 진행되었을지 예측할 수 없다. 나는 제품을 한 번에 하나의 목표 시장에 집중하는 선택이 가장 유리하다고 생각한다. 제품 전략은 당신의 사업을 강화할 수 있는 무언가를 전달하는 기회를 엄청나게 늘려주면서 영업 및 마케팅 조직과 제품 업무를 잘 맞추는 도구를 제공한다. 우리는 영업 조직이 제품/시장 궁합이 증명된 시장을 대상으로 판매를 실행하기를 원한다. 새로운 시장에 대한 제품/시장 궁합이 검증되면 우리는 영업팀이 그 시장에서 가능한 한 많은 추가 고객들을 찾아 나서기를 원한다. 제품팀이 충분한 권한을 부여받고, 자율성을 가지고 행동하기 위해서는 넓은 맥락에서 팀에 대한 깊이 있는 이해가 무조건 필요하다. 이것은 분명하고 확실한 제품 비전과 그 비전을 달성하는 제품 전략으로부터 시작된다.

PART Ⅳ 프로세스

제품 발견의 원칙

제품 발견의 목적은 다음 네 가지 중요한 위험에 대응하는 것이다.

ㆍ고객이 과연 이 제품을 구매하거나 사용할 것인가? – 가치 위험(value risk)
ㆍ사용자가 이 제품의 사용 방법을 이해할 수 있는가? – 사용성 위험 (usability risk)
ㆍ우리가 만들 수 있는 것인가? – 실현 가능성 위험(feasibility risk)
ㆍ우리 사업에 효과가 있는 솔루션인가? – 사업 유효성 위험(business viability risk)

위 질문들에 대해 제품 관리자의 의견만으로는 충분하지 않다. 우리는 증거를 수집해야 한다. 제품 발견 방안과 관련해서 다음과 같은 핵심적인 원칙들이 있다. 만일 당신이 이것들을 이해한다면 현재 시점에서 효과적으로 업무를 수행하는 방법뿐만 아니라 미래에 발생할 최신 기법들을 쉽게 흡수하는 방법에 대해서도 알게 될 것이다.

① 우리가 무엇을 만들어야 하는지는 우리의 고객, 임원, 이해 관계자들이 말해 주지 않는다. 고객은 무엇이 가능한지 모른다. 기술 제품은 어느 누구도 실제로 보기 전에는 우리가 정말 원하는 것이 무엇인지 알지 못한다. 우리가 전달하는 솔루션이 근본적인 문제를 해결하는지 확인하는 것은 우리의 역할이다. 이것은 오늘날 모든 제품에 적용되는 가장 근본적인 원칙이다. 역사적으로 업계에서 발생한 대부분의 혁신에 대해 고객들은 알지 못했다. 지금 열광하는 것은 이전에는 단지 하나의 가능성에 불과했을 뿐이다.

② 무엇보다 중요한 것은 강력한 가치를 구축하는 것이다. 물론 모든 것이 어렵지만 그중에서도 가장 어려운 일은 고객이 궁극적으로 구매 혹은 사용을 선택하게 하는 데 필요한 가치를 만들어 내는 것이다. 제품은 사용성 이슈나 성능 이슈가 다소 있더라도 한동안 생존할 수 있지만, 핵심 가치가 없으면 아무것도 이룰 수 없다. 따라서 제품 발견 단계에서 가치 발견에 가장 많은 시간을 들여야 한다.

③ 기술 구현이 어렵고 중요한 만큼이나 훌륭한 사용자 경험을 제공하는 것은 보통 그 이상으로 어렵고 성공에 더 중요한 요소다. 모든 제품팀에 엔지니어가 있지만 그렇다고 모든 팀이 필요한 제품 디자이너를 가지고 있는 것은 아니다. 그리고 제품 디자이너가 있더라도 우리가 생각하는 방향으로 실제 업무를 진행하는 경우는 드물다.

④ 기능과 디자인과 기술은 본질적으로 함께 얽혀 있다. 전통적인 폭포수 모델에서는 시장이 기능(요구사항이라고도 알려진)과 디자인과 실행을 끌어낸다. 그러나 요즘은 반대로 기술이 기능을 가능하게 한다는 것을 우리가 잘 알고 있다. 그리고 기술이 디자인을 이끌며, 디자인이 또한 기능을 만들어 낸다. 당신이 가지고 있는 휴대전화를 보면 이러한 접근 방법의 수많은 사례를 곧 확인할 수 있다. 중요한 점은 이 세 가지 모두 완전히 얽혀 있다는 것이다. 이러한 이유로 우리는 제품 관리자와 제품 디자이너와 기술 리더가 물리적으로 서로 가까운 곳에서 근무하도록 강하게 독려한다.

⑤ 우리는 아이디어 중 다수가 효과를 내지 못할 것이며, 검증된 아이디어도 몇 번의 이터레이션이 필요하다는 것을 알고 있다. 마크 앤드리슨의 말을 참고하자. “가장 중요한 것은 당신이 알 수 없는 것을 알아내야 한다는 것이다.” 그리고 우리의 아이디어 중 어느 것이 고객에게 효과적이고 어느 것이 그렇지 않은지 사전에 알 수가 없다. 따라서 우리는 아이디어 대부분이 소용없을 것이라는 마음으로 제품 발견에 접근해야 한다. 가장 흔한 이유는 그 솔루션이 가치가 없어서이고, 때로는 디자인이 너무 복잡하거나 구현하는 데 너무 오래 걸리거나, 법적인 혹은 개인정보 문제가 있을 수도 있다. 근본적인 문제를 해결하기 위해서는 다양한 방법을 시도할 수 있도록 항상 열려 있어야 한다.

⑥ 우리는 실제 사용자와 고객을 대상으로 아이디어를 검증해야 한다. 제품 발견에서 가장 흔히 발생하는 함정은 우리 제품에 대한 사용자의 실제 반응을 우리가 예측할 수 있다고 믿는 것이다. 어떤 경우에도 반드시 실제 사용자와 고객에게 우리의 실제 아이디어를 검증해야만 한다. 실제 제품을 만들기 위한 시간과 비용을 낭비하기 전에 검증을 진행해야 한다.

⑦ 제품 발견의 목적은 아이디어를 가능한 한 더 빠르고 적은 비용으로 검증해 내는 것이다. 제품 발견은 속도를 원한다. 이것은 많은 아이디어를 시도할 수 있게 해 주고, 유망한 아이디어를 찾기 위한 여러 방법을 시도할 수 있게 해 준다. 여러 가지 아이디어 유형과 제품이 존재하고, 또한 가치 위험, 사용성 위험, 실현 가능성 위험, 사업 위험과 같이 우리가 확인해야 하는 다양한 종류의 위험이 있다. 그래서 우리는 각 상황에 맞게 활용할 수 있도록 폭넓은 범위의 기법들을 활용해야 한다.

⑧ 제품 발견 단계를 진행하며 아이디어의 실현 가능성에 대해 검증해야 한다. 당신의 개발자가 스프린트 계획 미팅에서 아이디어를 처음 봤다면 당신은 실패한 것이다. 구현을 결정하기 전에 실현 가능성을 분명히 확인해야 한다. 이는 결국 상당한 시간 낭비를 막아준다. 또한 엔지니어의 관점을 더 일찍 수용하는 것은 솔루션 자체를 더 발전시키게 되고, 공유 학습에도 결정적인 영향을 준다.

⑨ 사업 유효성은 제품 발견 단계에서 검증해야 한다. 마찬가지로 우리가 제품을 만드는 시간과 비용을 쓰기 전에 우리가 만드는 솔루션이 우리가 원하는 것이 맞는지를 확인하는 것이 절대적으로 중요하다. 사업 유효성은 재무적인 고려사항, 마케팅, 영업, 법무, 사업 개발 등을 포함한다. 제품 관리자가 미처 이해하지 못했던 필수적인 사업 내용을 제품이 만들어진 이후에 알게 되었다고 해보자. 이보다 제품 관리자의 사기와 자신감을 파괴하는 경우는 드물 것이다.

⑩ 공유 학습을 해야 한다. 조직이 용병팀 대신 미션팀을 가져야만 하는 핵심적인 이유는 바로 팀이 함께 배운다는 것이다. 고객의 불편함을 함께 관찰하고, 어떤 아이디어가 실패하고 성공하는지 함께 확인하며, 왜 이 일이 중요하고, 진행되어야 하는지에 대한 맥락을 함께 이해해야 한다.

PART Ⅴ 문화

좋은 제품팀 / 나쁜 제품팀

나는 전 세계 최고의 기술 제품 기업들과 일을 할 수 있는 엄청난 축복을 누려 왔다. 당신이 매일 사용하고 사랑하는 제품들을 만든 그야말로 세상을 바꾸고 있는 기업들이다. 기술 제품을 만드는 데 최고의 제품 회사와 다른 회사들 사이에 심오한 차이가 있다. 그리고 뛰어난 제품팀과 그렇지 않은 제품팀, 즉 좋은 팀과 나쁜 팀 간에는 다음과 같은 중요한 차이가 있다.

ㆍ좋은 팀은 강렬한 제품 비전이 있고, 그들은 마치 선교사와 같은 열정을 추구한다. 반면 나쁜 팀은 용병들이다.
ㆍ좋은 팀은 그들의 비전과 목표, 고객 불편의 관찰, 제품을 사용하면서 고객들이 만들어 낸 분석 데이터 문제를 해결하기 위해 새로운 기술을 끊임없이 탐색하는 과정을 통해 영감과 제품 아이디어를 얻는다. 나쁜 팀은 영업과 고객으로부터 요구사항을 수집한다.
ㆍ좋은 팀은 그들의 핵심 이해 관계자들을 이해하고 있으며, 그들이 겪고 있는 제약사항을 잘 알고 있다. 이를 통해 사용자와 고객에게만 효과적인 솔루션이 아닌 비즈니스 제약 조건 속에서도 유효한 솔루션을 찾아내는 데 최선을 다한다. 나쁜 팀은 이해 관계자로부터 요구사항을 수집한다.
ㆍ좋은 팀은 어떤 아이디어가 진정으로 만들 만한 가치가 있는지를 결정하기 위해 빠르게 제품 아이디어들을 시도해 볼 수 있는 많은 기법에 능숙하다. 나쁜 팀은 우선순위 로드맵을 만들기 위해 미팅을 진행한다.
ㆍ좋은 팀은 회사 전반에 걸쳐 현명하고 사려 깊은 리더들과 브레인스토밍 토론을 즐긴다. 나쁜 팀은 외부의 누군가가 팀에 제안할 때 방어적인 자세를 취한다.
ㆍ좋은 팀은 최종 사용자 및 고객과 매주 직접 만난다. 그리고 최신 아이디어에 대한 고객들의 반응을 확인한다. 나쁜 팀은 그들 자신이 고객이라고 생각한다.
ㆍ좋은 팀은 그들이 기대했던 아이디어들이 결국 고객에게 효과가 없을 수도 있다는 것과 심지어 검증된 아이디어조차도 희망하는 성과가 나오는 수준이 되려면 여러 번의 이터레이션이 필요하다는 것을 잘 알고 있다. 나쁜 팀은 그저 로드맵에 있는 것들을 만들면서 품질에 만족하고 일정을 준수하는 것에 만족한다.

0 댓글
본문 피드백
모든 댓글보기