훌륭한 제품 관리자는 솔루션에 시간을 쓰지 않습니다.

Great PMs don't spend their time on solutions by Paul Adams

·

5 min read

훌륭한 제품 관리자는 솔루션에 시간을 쓰지 않습니다.

인터컴의 제품 수석 부사장인 Paul Adams의 원문 아티클 을 번역한 내용입니다.

Main illustration: Geoff Kim


생각보다 문제에 깊이 파고 들어갈 수 있는 기회를 갖는게 쉽지는 않습니다. 대게 높은 사람이 원하는걸 만드는데 거의 모든 시간을 사용하기 때문입니다.

지난 몇 년 동안 우리는 Intercom에서 제품을 만드는 것에 대해 많은 것을 배웠습니다.

어떤 것들을 정말 잘 작동했고 어떤 것들은 그렇지 못했습니다. 우리의 성장에 기여한 성공적인 방법을 재현해내고 새로운 동료에게 전파하기 위해 우리는 '우리가 일하는 방식'에 대해 많은 관심을 기울여왔습니다.

Intercom이 지금껏 성장하는데 기여한 중요한 요소 중 하나는 '각 프로젝트가 해결하려는 문제를 깊이 있게 이해하는 것' 입니다.

사실 당연하게 들리기도 하고 다른 많은 사람이 하는 말과 다른 게 뭐가 있나 싶겠지만. 우리는 조금 다르게 이것을 실천합니다.

아래는 상당수의 회사가 따르는 매우 표준적인 제품 개발 프로세스입니다.

image.png

만약 당신의 팀이 '폭포수 모델' 보다는 좀 더 '애자일'한 방식을 지향한다면 아래와 같은 모습일 겁니다.

image.png

그리고 이런 것들을 수행하겠죠.

image.png

아마도 당신 팀의 프로세스가 위의 모습과 완전히 일치하진 않을 수 있겠죠, 베타 출시 후 디자인 작업으로 돌아간다거나 말이죠. 하지만 이런 차이가 중요한 것은 아닙니다.

우선, 이 글은 애자일/린/스크럼/기타 등등의 프로세스에 대한 완벽한 그림을 말하고자 하는 게 아니라는 점을 강조합니다. 이 글을 통해 우리는 당신의 시간이 어디에 어떻게 사용되고 있는지 살펴볼 예정입니다.

만약 프로젝트에 드는 전체 시간을 100으로 나눈다고 상상해보세요. 그러면 PM, 디자이너, 리서처, 분석가, 엔지니어 등이 사용하는 리소스가 어떻게 분배될까요?

대부분의 제품 팀들은 아래와 같지 않을까 싶습니다.

image.png

문제의 우선순위를 정하기로 하고 문제를 정의한 다음에 디자인에 좀 더 많은 시간을 사용하고 그것을 구현하는데 가장 많은 시간을 할애하지 않나요?

게다가 가끔은 이런 경우도 있습니다.

image.png

이 모습은 상위의 포지션의 중요한 사람이 뭔가 아이디어를 갖거나 만들기를 원할 때의 모습입니다. 이 '엄청 중요한 아이디어'는 대체로 운전 중에 떠올랐거나, 샤워하다가, 혹은 그들의 이웃('그들 기준에 자신과 비슷한 보통 사람들')으로 부터 얻는 경우가 많죠.

이러한 아이디어가 공식화되어버리면 낭비할 틈이 없습니다. 실무자들은 빠르게 디자인하고 구현하기 시작해야 합니다. 이 '중요한 사람'의 아이디어는 클 때도 작을 때도 있는데. 정말 최악의 시나리오는 이 중요한 사람의 아이디어가 심지어 끊임없이 변하면서 로드맵을 가득 채우는 것입니다.

지금 일하는 방식은, 이전 경험에서 비롯합니다. 저에게 위 '중요한 사람의 아이디어' 시나리오는 구글에서 일할 때 가장 많이 발생했습니다. 저런 아이디어를 내는 많은 사람이 존재했고 대부분의 프로젝트는 실패했습니다. 물론 다른 좋은 팀도 많았지만 아쉽게도 제 경험은 그렇지 못했습니다.

이것은 실패하는 스타트업에서도 많이 보이는 현상입니다. 이러한 스타트업 종사자들과 이야기를 나누고 그들이 어떻게 일하는지 물어보면, 어김없이 리서치하고 고객과 이야기한다고 말하지만 대체로 자세히 들어보면 형식적으로 이뤄지는 립서비스에 가까운 느낌을 받았습니다.

내가 페이스북에서 경험한 방식은 이렇습니다.

image.png

구글에서의 경험보다는 나았지만, 페이스북에서는 아래의 두 가지가 특히 강조되었습니다.

우선순위에 시간을 할애하되 최대한 빨리 코드를 작성하는 것입니다. 사실 나는 이 방식에 완전히 동의하진 않습니다. Code Wins Arguments는 솔루션을 뜻합니다. 하지만 이 솔루션의 성공 여부는 문제를 제대로 이해하는 것에 달려있습니다.

물론 누군가가 문제를 이해하는 데 도움이 되는 코드를 작성할 수도 있지만, 이는 대체로 고객의 문제라기보단 기술 구현의 문제를 이해하는 용도이므로 고객의 문제를 이해하는 것과 큰 관계는 없습니다. 심지어 뭔가 되는 것 같다고 느끼게 하는 것이 매력적이라 문제 정의는 까마득하게 잊게 될 가능성이 큽니다.

Intercom에서 우리가 시간을 활용하는 방식은 아래와 같습니다.

image.png

100중 40은 디자인에 들어가기 전에 사용합니다. 우리는 문제의 우선순위와 제대로 된 문제 정의에 집착합니다. 저는 종종 우리가 해결하려는 문제를 정말 깊이 이해하고 있는지 확인하기 위해 동료들을 미치게 만들 때도 있습니다. 저는 PM들이 이제 막 고민하기 시작한 문제들을 공개적으로 공유하고 토론의 장에 내놓는 것을 좋아합니다.

왜 이게 필요할까요? 그것은 현재 다루고 있는 문제를 제대로 이해하는 것만이 좋은 솔루션을 찾을 수 있는 유일한 방법이기 때문입니다. 이것은 반박할 수 없는 사실입니다. 하지만 대부분의 소프트웨어 팀은 이 문제 정의 부분을 무시하고 지나가는 경우가 많습니다.

Intercom에서는 이 문제 정의 과정을 정교하게 만들기 위해 큰 노력을 기울입니다.

  • 고객 지원팀은 PM이 검토할 수 있도록 고객과의 모든 대화에 태그를 지정합니다. 우리의 경우 자연스레 우리 앱을 사용하여 이 작업을 수행하죠.
  • 영업 팀 및 마케팅팀은 현장의 의견을 기반으로 Product/Market Metrics를 만듭니다.
  • 리서치 팀은 이 과정을 위해 존재한다고 봐야겠죠? 우리는 초기부터 리서치에 많은 투자를 해왔습니다.
  • 분석팀은 최근 우리가 집중적으로 투자하고 있습니다.

우리는 때때로 우리가 여전히 문제를 충분히 이해하지 못한다는 것을 깨닫고 그것을 확인하기 위해 베타 버전을 출시할 때도 있습니다. 아래처럼요.

image.png

그렇다면 왜 당신의 팀은 문제를 제대로 이해하기 위한 투자를 하지 않는 걸까요? 나는 여기에 세 가지 큰 이유가 있다고 생각합니다.

  1. '제대로' 하는 것은 정말 힘든 일입니다. 많은 고객과 계속해서 이야기하고 새로운 궁금증을 파헤쳐야 합니다. 이것은 당신이 고객의 머릿속에 들어간다는 뜻과 같습니다. 그들이 말하는 게 아니라 진심으로 원하는 것을 찾아내는 것은 어렵습니다. 대부분의 팀은 고객들이 요구하는 솔루션을 그대로 구축합니다. 하지만 진짜 문제는 그 밑바닥 깊숙히 묻혀있기 때문에 쉽게 놓칠 수 있습니다. 좋은 제품팀은 계속해서 묻고 또 묻습니다. 그리고 이 과정은 고단하고 많은 시간이 필요합니다.

  2. 매력적인 포트폴리오가 되지 않는 경우가 많습니다. 연구보고서, 새로운 UI 시안, 프로토타입과 달리 질문과 답변은 포장이 없습니다. 요즘의 많은 팀에게 깊은 이해를 위해 성찰하고 탐구하는 것은 흥미롭거나 중요한 것으로 여겨지지 않습니다. 이건 최악입니다. 중요하고 매력적이지 않은 일을 하는 게 필요합니다.

  3. 결과물은 눈에 보이는 성과입니다. 경영진은 깊은 탐구와 관찰을 성과로 평가하기가 어렵습니다. 분명 여러 명이 몇 주에 걸쳐 수행한 결과라고 해도 정의된 문제가 단 몇 줄이니 말이죠.

이게 많은 회사가 우리처럼 이라기 어려운 이유입니다. 고객을 이해하기 위한 탐구 과정은 힘들고, 흥미롭지 않을 수도 있고 그 노력이 눈에 띄지 않을 수도 있습니다.

하지만 저는 이런 노력이야말로 우리가 해야 하는 가장 중요한 일 중 하나이며 프로젝트의 성공에 가장 큰 영향을 미치는 요소라고 믿습니다. 엄청난 양의 디자인과 코드 작업을 하고 나서야 잘못 정의된 문제를 다루고 있음을 깨닫는 것보다 훨씬 리스크가 작습니다.

시간을 사용하는 방식을 바꿔보세요. 궂은일을 하고 문제 정의에 집착하세요. 고객이 진정으로 필요로하는 게 무엇인지 제대로 이해한 다음 무엇을 어떻게 만들어야 할지 고민한다면 고객이 자신이 원하던 가치를 전달받을 수 있을 것입니다.


잘 읽으셨나요? 혹시 이 글이 도움이 되셨다면 아래 버튼을 눌러 커피 한 잔 어떠세요? 여러분의 작은 후원이 창작자에게 큰 힘이 됩니다! 😁