[좋은 PM에 관하여] ep06. 실패한 제품(서비스)의 근본적인 원인

 

⚠
오늘은 할말이 많아서 좀 깁니다.

 

자. 이제 제품 얘기를 해보도록 하자. 성공한 제품을 알아보기 전에 어떻게 하면 실패하는가?에 대해 먼저 알아보도록 하겠다.

 

나는 어떤 규모이건, 어느 지역에 있건, 거의 모든 회사가 같은 방식으로 일하고 있음을 관찰했다. 그리고 이러한 방식은 실제로 최고의 회사가 일하는 방식과는 거리가 멀다는 것을 언급할 수 밖에 없다.

 

이 글을 쓰는 와중에도, 나는 무기력해지고 있다. 그리고 이 글을 읽는 당신도 어느 포인트에서 정곡이 찔려 그럴 수도 있다. 하지만 환부를 드러내고 마데카솔을 발라야 병이 낫듯, 이것도 잘되기 위한 과정 중 하나이니, 잘 참고 견뎌내길 바란다.

 

아래 그림은 우리 회사가 여전히 사용하고 있는 그리고 대부분의 회사가 사용하고 있는 제품 개발 프로세스다. 개인적인 의견을 설명하기 이전에, 먼저 이 프로세스를 그대로 설명하고자 한다.

 

대부분의 회사에서 채택하고 있는 기획 프로새스

 

 

그림에서 설명하는 것처럼 모든 것은 아이디어에서 출발한다. 대부분 아이디어는 내부인(임원, 핵심 이해관계자 또는 비즈니스 담당자) 혹은 외부(현재 또는 잠재 고객들)에서 유입된다. 아이디어가 어디에서 발생했건 간에, 항상 비즈니스의 각 분야에서 제품 관리자가 처리해 주기를 바라는 엄청난 양의 과제들이다.

 

이제 대부분의 회사들은 이러한 아이디어들의 우선순위를 매겨 로드맵으로 전환하기를 원한다. 그들은 두 가지 이유로 로드맵을 사용한다. 첫째는 가장 중요한 일을 먼제 수행해 주기를 원하기 때문이며, 둘째는 각 업무가 언제 준비 상태가 될지 예측하고 싶기 때문이다.

 

로드맵을 작성하기 위해 보통 분기 또는 연간 계획 세션과 같은 별도의 시간을 마련한다. 이때 리더들은 아이디어를 검토하면서 제품 로드맵에 대해 협의한다. 하지만 우선순위를 선정하기 위해 그들은 먼저 각 아이디어에 대한 비즈니스 케이스 정의가 필요하다. 어떤 회사들은 비즈니스 케이스에 대한 별도 양식이 있고, 없는 회사도 있다. 어쨌든 각 아이디어에 대하 두 가지를 분명하 알아야 한다는 것이 핵심이다.

 

 

1️⃣ 그게 돈이 됩니까?

(=얼마만큼의 매출이나 가치를 만들어 내는 것인가?)

 

 

2️⃣ 얼마면 됩니까?

(=얼마만큼의 비용이나 시간이 필요한가?)

 

 

이러한 정보는 다음 분기의 로드맵(때로는 1년의 로드맵)을 작성하는데 활용된다.

 

이때 제품과 기술 조직은 진격 명령(?)이 떨어지면 보통 가장 높은 우선순위의 아이디어부터 차례대로 실행하게 된다. 어떤 아이디어가 가장 높은 우선순위에 있으면 제품 관리자가 가장 먼저 해야 할 일은 해당 이해 관계자를 만나서 아이디어를 구체화하는 것이다. 이를 통해 일련의 '요구사항'을 정리한다.

 

이러한 요구사항은 사용자 스토리(user story) 형태이거나, 아마도 기능 명세와 같은 양식의 형태일 것이다. 요구사항은 디자이너와 엔지니어에게 무엇이 만들어져야 하는지를 커뮤니케이션하기 위함이다.

 

요구사항이 모두 수집되고 나면 사용자 경험 디자인팀(그 팀이 회사에 존재한다고 가정하고)은 상호작용 디자인, 시각 디자인, 물리적인 기기의 경우 산업 디자인에 대한 진행을 요청한다.

 

디자인팀의 검토가 끝나면 요구사항과 디자인 결과물은 엔지니어에게 전달된다. 대개 이 시점에서 "애자일"이 등장한다.

 

아무튼 엔지니어들은 보통 그 과제를 이터레이션(interation, 반복 업무 단위)으로 나눈다. 스크럼(scrum) 프로세스에서 말하는 '스프린트(sprint)'다. 아이디어를 구현하기 위해 한 번에서 세 번 정도의 스프린트가 걸린다.

 

QA 테스트가 스프린트 일부로 포함되어 있다면 다행이다. 혹은 별도 QA 팀이 있다면 그 신규 아이디어 과제가 예상대로 동작하는지, 다른 문제를 만들어 내지는 않는지(이런 것들을 회귀 테스트라고 한다!)를 검증한다.

 

QA 담당자로부터 이상이 없음을 확인하는 녹색 신호를 받으면, 그 신규 아이디어는 마침내 실제 고객에게 배포(deploy)된다.

 

내가 지금 속해있는 회사(?)는 이러한 방식을 필수적으로, 이미 오랫동안 사용하고 있었다.(사실 이마저도 지켜지면 다행이라고 생각한다.) 우리 회사가 아니더라도 유사한 업무 프로세스 구조를 갖고 있는 회사들은 일관된 불평불만을 제기한다. 혁신이 부족하고 제품을 고개게에게 전달하기까지 너무 오랜 시간이 걸린다는 것이다.

 

아마 눈치챘겠지만, 요즘 거의 모든 사람이 하고자 하는 "애자일"을 잠깐 언급했다. 반면에 방금 설명했던 상황은 완전히 폭포수(waterfall) 프로세스에 대한 것이었다. 엔지니어 관점에서 말하자면 그들은 보통 주어진 폭포수 프로세스의 환경에서 할 수 있는 최대한의 애자일을 실천하고 있다.

 

자, 앞서 설명한 것이 대부분의 회사가 채택한 방식인 것은 알겠다. 그런데 왜 이것이 수많은 실패의 필연적인 이유인가? 그 이유를 찾기 위해 단편적인 내용의 조각들을 연결해 보자. 그래서 우리는 왜 이 보편적인 업무 방식이 많은 제품 실패에 대한 책임인지 보다 분명하게 알 수 있을 것이다.

 

다음의 목록을 통해 이러한 업무 방식이 가지는 가장 큰 문제 10가지를 공유할 것이다. 이 10가지 문제는 팀을 망칠 수도 있는 매우 심각한 이슈라는 것을 명심하자. 많은 회사에서 한 개 이상, 심지어는 모든 문제를 갖고 있다.

 

 

1️⃣ 아이디어 단계

 

아무래도 아이디어 제안 단계부터 잘못된 것 같다. 맨 윗단계였던 '아이디어 출처'부터 짚고 넘어가보자. 이 모델(Waterfall)을 사용하면 판매 확대를 기능이나 이해 관계자 위주로 제품이 끌려가게 된다. 이 주제에 대해서도 할 이야기가 많다. 하지만 지금 딱 한가지만 말하라면 이 방식이 뛰어난 제품 아이디어를 가져오지는 못한다는 것이다. 또한, 이러한 접근 방법은 팀에게 필요한 권한 위임이 안된다. 이 모델을 따르면 제품팀은 마치 외부 용병처럼 그저 열심히 실행할 뿐이다.

 

 

2️⃣ 비즈니스 케이스

 

다음으로, 비즈니스 케이스의 치명적인 결함에 관해 이야기해 보자. 솔직히 나는 개인적으로 큰 규모의 투자가 필요한 아이디어일 경우에 한해서는 비즈니스 케이스가 필요하다는 데 찬성한다. 하지만 많은 회사가 로드맵을 작성하는 단계에서 비즈니스 케이스를 작성하는 것은 정말 말도 안된다. 그 이유를 설명해 보겠다. 모든 비즈니스 케이스의 핵심적인 두 가지 요소를 기억하는가? "그게 돈이 됩니까?"와 "얼마면 됩니까?"였다. 자, 냉업한 진실은 현재 시점에서 우리는 이 두 가지 수치에 대한 근거가 전무하다는 것이다. 솔직히 우리는 이 단계에서 알 재간이 없다.

 

우리가 만드는 것으로 얼마만큼의 돈을 벌 수 있을지는 결국 얼마나 좋은 솔루션을 만들어 낼지에 달려 있기 때문이다. 만일 팀이 환상적으로 일을 해냈다면 큰 성공을 만들어 낼 수도 있다. 말하자면 비즈니스 전체의 추세에 영향을 줄 수도 있다. 하지만 현실은, 많은 제품 아이디어가 결국 아무것도 이루어 내지 못한다는 것이다. 효과가 없었다는 것을 과장하는 표현이 아니다. 말 그대로 아무것도 모른다(A/B 테스트를 통해서 알 수 있다).

 

어떤 경우에도 제품 개발의 가장 중요한 교훈 중 하나는 우리가 모르는 것을 알아간다는 것이다. 그리고 단지 이 단계에서는 우리가 얼마만큼의 돈을 벌 수 있는지 알 수 없다.

 

하지만 많은 회사가 우선순위 로드맵을 정말 원하고 있고, 일단 활용이 되면 아이디어를 평가하는 시스템이 필요하다. 그래서 사람들은 비즈니스 케이스 게임을 하게 된다.

 

 

3️⃣ 제품에 관한 두 가지 불편한 진실

 

회사가 제품 로드맵에 대해 빠져들기 시작하면 더 큰 이슈가 발생하기 시작한다. 지난 수년간 셀 수 없을 정도로 많은 로드맵을 보아왔으며, 대부분은 우선순위가 정해진 기능과 프로젝트들의 목록이 구성되어 있었다. 예를 들어 마케팅은 특정 캠페인을 위해 이런 기능을 원하고, 영업은 새로운 고객을 확보하기 위해 저 기능을 원하며, 또 누구는 카카오페이 연동을 원할 수도 있다.

 

하지만 여기에 가장 큰 문제가 있다. 내 표현으로 하자면 제품에 관한 두 가지 불편한 진실이 있다.

 

첫 번째, 진실은, 당신의 아이디어 중 최소 절반 이상은 유효하지 않을 것이라는 사실이다. 아이디어가 기대한 효과를 만들지 못하는 데는 여러 이유가 있다. 가장 흔한 이유는, 이 아이디어에 대해 우리만큼이나 고객이 관심을 가지지 않는다는 것이다.

 

그래서 그들은 사용하지 않는 것을 선택한다. 때로는 그들이 사용하기 원하고 실제 사용해 보기도 한다. 하지만 제품이 지나치게 복잡해서 쓰임새보다 오히려 골칫거리가 더 많아진다. 그래서 사람들은 다시 사용하지 않게 된다. 그리고 가끔은 사람들이 좋아하는 제품을 생각해 냈지만, 우리가 예상했던 것보다 더 큰 비용이 드는 상황이 발생한다. 결국 고객에게 그 제품을 전달하는 데 필요한 시간과 비용을 감당하지 못하겠다는 결정을 하게 된다.

 

그래서 나는 제품 로드맵에 있는 최소 절반 이상의 아이디어는 기대했던 효과를 만들어 내지 못한다고 장담한다.

 

첫 번째가 충분하지 않다면 두 번째 불편한 진실이 여기 있다. 아이디어가 충분히 잠재적인 가치가 있는 것으로 파악되었더라도 필요한 비즈니스 가치를 만들어 내는 수준에 도달하려면 최소 몇 번의 이터레이션을 반복해야 한다는 것이다. 우리는 이것을 돈을 버는 데 필요한 시간이라고 한다. 내가 제품을 만들면서 깨달은 가장 주요한 교훈은 이 두 가지 불편한 진실에서 벗어나는 경우는 없다는 것이다. 당신이 엄청 똑똑하다고 해도 마찬가지다.

 

 

4️⃣ 제품 관리의 역할

 

사실 이러한 상황에서는 제품 관리라고 하는 것보다 프로젝트 관리라고 부르는 것이 더 맞을 것 같다. 이 모델에서는 엔지니어를 위해 요구사항을 수집하고 문서화해 주는 것이 주요 업무다. 이는 내가 실제 기술 제품 관리라고 하는 일과는 180도 다르다는 것을 짚고 넘어가고 싶다.

 

디자인의 역할도 상황이 비슷하다. 디자인의 진정한 가치를 담기에는 너무 늦은 상황이라서 대부분은 이른바 돼지 입술에 립스틱 바르기를 하게 된다. 이미 상황은 더 나빠졌으므로 엉망인 제품에 페인트 코팅이라도 씌우려고 시도한다. UX 디자이너도 이것이 바람직하지 않다는 것을 잘 알고있지만 이렇게라도 그들이 할 수 있는 방법으로 보기 좋고 일관된 디자인을 해나간다.

 

 

5️⃣ 너무 늦게 참여하는 엔지니어들

 

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

 

 

6️⃣ 프로젝트 중심적인 프로세스

 

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

 

 

7️⃣ 늦은 고객검증

 

이 모델이 여전히 갖고 있는 가장 큰 문제는 위험이 가장 마지막에 발견된다는 것이다. 고객에 대한 검증이 너무 늦게 일어난다는 의미다.

 

린 방법(Lean Method)의 핵심적인 원칙은 낭비를 줄이는 것이다. 가장 큰 낭비의 형태는 결국 원하지도 않는 기능이나 제품을 발견하기 위해 디자인-구현-테스트-배포해 나가는 것이다. 아이러니한 사실은 많은 팀이 내가 설명한 폭포수 프로세스를 적용하고 있으면서도 스스로 린의 원칙을 적용하고 있다고 착각한다는 것이다. 그러면 나는 그들이 가장 값비싸고 느린 방법으로 아이디어를 실행하고 있다고 지적한다.

 

 

8️⃣ 잊어버린 기회비용

 

끝으로, 우리가 이 프로세스로 시간과 비용을 낭비하느라 정신없을 때 발생하는 가장 큰 손실은 따로 있다. 바로 그 시간에 조직이 할 수 있었던 혹은 해야만 했던 것에 대한 기회비용이다. 우리는 시간과 돈을 다시는 돌릴 수 없다.

 

 

💡 결론

 

많은 기업이 엄청난 시간과 비용을 들이고도 매우 허망한 성과를 거두는 현상은 그리 놀라운 일도 아니다. 나는 이 사실이 당신을 매우 우울하게 만든다고 미리 경고했다. 하지만 중요한 것은 이제 당신은 회사기 일하는 방식을 어떻게 바꿔야 하는지 깊이 이해하고 있다는 사실이다. 당신의 회사기 위에서 설명한 방식으로 일을 하고 있다면 말이다.

 

한 가지 반가운 소식은 최고의 팀들은 앞서 설명한 방식처럼 일하지 않는다고 약속할 수 있다는 것이다.