최근 스타트업부터 대기업에 이르기까지, 정말 많은 분들이 그로스 해킹과 프로덕트 분석 및 개선에 관심을 가지고 계신 것 같습니다.
저 또한 많은 고객분들과 만나면서 어떻게하면 좀 더 좋은 제품을 만들 수 있는가에 대해 많은 이야기들을 나누게 되는데요. 이때 가장 많이 받는 질문 중에 하나가 "어떻게 하면 좋은 프로덕트 팀, 그로스 팀을 만들 수 있을까요?" 입니다.
이에 대한 좋은 답변을 고민하던 중 개인적으로 정말 좋은 영감을 받았던, 현재 Amplitude의 VP of Product 으로 재직 중인 Justin Bauer의 글, "Good Product Team/Bad Product Team" 을 소개합니다. (글의 원문은 이 곳에서 보실 수 있습니다.)
Amplitude의 VP of Product로서, 저는 소수의 엔지니어만 있는 스타트업에서부터 수천 명의 Product Manager를 보유한 대기업에 이르기까지, 매년 수백의 프로덕트 팀과 함께 일할 기회를 얻습니다. 그들은 결국 Amplitude가 더 나은 프로덕트를 만드는 데 있어 도움이 된다고 믿기 때문에 저희와 협업합니다.
하지만 전 자연스럽게 이런 의문을 가지게 되었습니다. 왜 기업들은 더 나은 프로덕트를 만드는 데 누군가의 도움을 필요로 하는 것일까요?
여기에는 여러 가지 이유가 있겠지만, 그 핵심에는 좋은 프로덕트를 만든다는 것은 생각보다 어려운 작업이고, 대부분의 회사들이 실제로 그 방법을 잘 알지 못한다는 것이 있습니다. 그리고 전통적인 빌드-배포 방식은 오늘날의 product-led era(제품 주도 시대)에 적합하지 않습니다. 그래서 Ben Horowitz의 고전적인 에세이 "Good PM/Bad PM"의 방식으로, 좋은 프로덕트 팀과 나쁜 프로덕트 팀에 대한 생각을 써봤습니다.
좋은 프로덕트 팀은 고객에 집중합니다. 그들은 고객과 직접 의사소통하여 직접 피드백을 받아냅니다. 그들은 모든 프로세스의 핵심적인 의사 결정에 고객의 의견을 반영합니다. 그들은 프로덕트 개발과 연관된 모든 사람들(PM, 디자이너, 엔지니어)이 고객 전문가임을 보장합니다.
나쁜 프로덕트 팀은 고객을 스스로 이해하려 하지 않고 남의 도움을 받으려 합니다. 그들은 간접 피드백에 의존하고 MRD(Market requirements document)와 같은 오래된 방법을 통해 요구 사항을 수집하면서 고객 대신 "사업"에 집중합니다. 그들은 사용자 행동에 관한 모든 질문에 대답하기 위해 며칠, 심지어 몇 주간 결정을 지연시키는 분석가들에게만 의지합니다. PM은 더 많은 대시보드를 요구하겠지만 지표가 왜 그렇게 바뀌었는지 설명해야 할 때마다 "이건 다음 회의때 얘기합시다."라고 말합니다. (그리곤 절대 다시 얘기하지 않죠.)
좋은 프로덕트 팀은 고객의 문제를 해결함에 있어 확실한 의도를 가지고 접근합니다.
좋은 프로덕트 팀은 그들 대신 물고기를 잡아주는 전문가를 찾는 대신 물고기를 잡는 방법을 배웁니다. 나쁜 프로덕트 팀은 최근의 ~카더라 통신 중 제일 좋아 보이는 것을 기반으로 의사 결정을 내리고 그들이 당면한 '미션 크리티컬 (mission critical)'문제에 대해서만 분석하려 합니다. 그들은 매출, 고객 지원이나 앱 리뷰 같은 가장 눈에 띄는 이슈들에만 의존하기 때문에 나무만 보고 숲을 볼 수 없습니다.
좋은 프로덕트 팀은 현재의 고객만을 위해 제품을 만드는 것이 아니라 앞으로 고객이 될 사람들을 위해 제품을 구축합니다. 그들은 제품의 주요 의사 결정의 기반으로 데이터를 사용하며, 이미 내린 결정의 유효성을 확인하기 위해 사용하지 않습니다. 그들은 사용자가 실제로 제품을 사용하는 방법을 파악하기 위해 제품 분석을 사용하며, 추측 할 수있는 가정에만 의존하지 않습니다. 그들은 의미없는 측정을 넘어 제품 분석 솔루션을 통해 제품 내 고객의 여정을 이해하기 위해 데이터를 깊이 파고들 수 있습니다.
나쁜 프로덕트 팀은 제품 전략이 부족하거나 전략이 있더라도 조직 전체에 명확하게 전달되지 않습니다. 그들은 기업가 정신을 져 버리고 제멋대로 행동하는 고위 관리자들의 변덕에 매우 민감한 문화를 가지고 있습니다. 그들은 의존성과 밥그릇 싸움 때문에 뭔가 진행하기에 앞서 모든 의사 결정에 매우 많은 단계의 검토가 필요합니다.
좋은 프로덕트 팀은 프로덕트의 핵심 가치를 이해합니다. 그들은 프로덕트 전략을 가지고 있다는 것이 "예"라고 말하는 것보다 훨씬 더 자주 "아니오"라고 말하는 것이란 걸 이해합니다. 그들의 모든 행동엔 해결해야 할 문제에 대한 핵심적인 이해에 기초하는 의도를 가지고 있습니다. 그들은 공격적으로 10배의 목표를 설정하지만, 목표를 성취하는 방법을 자발적으로 해결하기 위해 팀에게 거의 고객과 마찬가지의 자율성을 부여합니다.
나쁜 프로덕트 팀은 비전이 없으므로 변명의 수단으로 Agile(애자일)을 사용합니다.
좋은 프로덕트 팀은 그들의 비전을 지속적으로 테스트하고 개선하는 것에 집중합니다.
좋은 프로덕트 팀은 그들의 목표를 공격적으로 증가 시킵니다. 목표를 데이터로 대체 할 수는 없지만 고객의 요구를 더 잘 이해하고 데이터를 활용하여 고객이 원하는 것에 대한 가설을 테스트 할 수 있음을 알고 있습니다. 그들은 가장 위험한 가설을 확인하고 그러한 가설을 시험하기 위한 실험을 만듭니다. 그들은 완벽하지는 않지만 스토리가 완성된 핵심 기능(MVP)을 만듭니다. 그들은 현재 집중하고 있는 것이 비즈니스에 가장 큰 영향을 미칠 수 있는 지 지속적으로 자문합니다.
나쁜 프로덕트 팀은 그들이 애자일하게 일하며 더 빠르게 움직이지만 기능을 출시하는 데는 여전히 오랜 기간이 필요하다고 주장합니다. 그들은 스프린트를 하지만 스프린트가 끝날 때 고객에게 보여줄 수 있는 건 아무것도 없습니다. 그들은 스스로 Lean 하다고 하지만, 스케이트 보드를 만드는 대신 핸들이 없는 자동차를 만듭니다.
좋은 프로덕트 팀은 학습에 최적화되어 있습니다. 그들은 첫 번째 시도의 결과가 항상 좋지만은 않을 수 있다는 것을 이해하며, 고객에게 어떤 기능 혹은 실험이 영향을 주거나 그렇지 않은 지 파악하기 위해 데이터를 분석하기 때문에 빠르게 다시 시도 할 수 있습니다. 그들은 프로덕트를 혁신한다는 것은 현재 가지고 있는 것들을 박살 낼 수 있는 위험을 감수해야 한다는 것임을 인식하고 있습니다. 나쁜 프로덕트 팀은 현재 가지고 있는 것을 잃어버릴 것 같아 두려워합니다.
나쁜 프로덕트 팀은 빠르게 릴리즈하려 하지 않습니다. 대신 한 번에 올바르게 가려고 합니다. 그들은 실패를 축하한다고 얘기하면서 실패를 통해 배워나갈 여지 따윈 주지 않습니다. 좋은 프로덕트 팀은 참을성 있게 실험하고, 실패를 받아들이며 고객의 기쁨을 확인할 때 두 배로 노력합니다.
좋은 프로덕트 팀은 성과; engagement, stickiness and retention(고객들의 참여, 충성도와 리텐션)에 따라 스스로를 평가합니다. 그리고 궁극적으로 성과를 매출과 연결합니다. 나쁜 프로덕트 팀은 산출물로 스스로를 평가합니다. (스토리 포인트와 속도, 배포한 코드 라인 수, 릴리즈한 기능들). 그들은 비용, 스케줄 그리고 범위에 대해 온 종일 얘기합니다.
나쁜 프로덕트 팀은 엄격한 릴리스 일정을 따르며 항상 뒤떨어져 있습니다. 그들의 PM은 철저히 문서화된 사용자 스토리로 업무의 중요도를 봅니다. 그리고 마침내 프로젝트가 완료되면 다음 업무를 진행하며 절대 되돌아 보지 않습니다. "이미 끝났으니까요."
좋은 프로덕트 팀은 고객 성과에 따라 성공과 실패를 측정합니다.
좋은 프로덕트 팀은 프로덕트가 항상 개선되고 있으며 학습은 결코 끝나지 않는다는 것을 알고 있습니다. 그리고 심지어 프로덕트의 개선이 기능이나 사용 중단을 의미할지라도 다시 중요한 일로 돌아갈 수 있도록 프로세스를 갖추고 있습니다. 나쁜 프로덕트 팀은 기능들을 찍어내며(feature factories), 그들의 프로덕트를 구제해 줄 은총알(silver bullet, 만능 열쇠)을 찾을 수 있다는 희망을 품고 또 다른 새로운 것을 계속 찾아 나섭니다.
좋은 프로덕트 팀은 프로덕트가 납으로 만든 총알(만능 열쇠의 반대 의미)로 만들어져 있음을 이해합니다. 모든 것을 해결할 수 있는 공식은 없으며, 다른 사람들보다 더 뛰어나야 하는 어떤 것들이 있을 뿐이죠.
나쁜 프로덕트 팀은 기능적 사일로로 조직되어 있으며 '뒤에서' 서로 손가락질 합니다. 나쁜 프로덕트 팀은 역할 정의에 대한 명확성이 부족합니다. PM 및 디자이너는 "개발자를 놀리면 안된다."고 생각합니다. 좋은 프로덕트 팀은 고객에 대한 공감대와 성공에 대한 상식적인 정의와 더불어 조직됩니다. 고객과 성공의 공통된 정의. 그들은 PM, 디자이너와 엔지니어들 사이에 누가 어떤 책임을 가지고 있는지를 명확하게 정의합니다.
좋은 프로덕트 팀은 목표를 사전에 명확히 밝히고 그들의 일이 전체 회사의 목표와 관련하여 어떤 영향을 끼쳤는지(좋건, 나쁘건) 공유합니다. 나쁜 프로덕트 팀은 일을 완료한 것만 축하하며 영향을 명확히 알리는 데 시간을 들이진 않습니다. 그들은 프로덕트를 분석하는 것은 PM만의 의무이며, 전체 팀의 의무는 아니라고 믿습니다.
좋은 프로덕트 팀은 고객 중심의 핵심 지표들을 정의할 시간을 갖습니다. 누구나 자신의 업무가 회사의 전체 목표에 어떻게 영향을 미치는지, 달성해야 할 가장 중요한 것이 무엇 인지를 이해합니다. 나쁜 프로덕트 팀은 모든 측정 항목을 KPI로 정의 하므로 아무 것도 중요하지 않게 만듭니다.
아무리 오랜 시간을 공들여 많은 데이터를 분석하고 멋진 가설을 얻었다고 할지라도, 정말 그 가설이 고객들에게 가치를 제공하고 여러분들의 비즈니스에 긍정적인 영향을 가져다 줄 수 있는지 빠르게 실험하고, 측정하고 또 결과에서 배움을 얻어나가는 과정정을 반복할 수 있는 프로덕트 팀이 없다면 좋은 프로덕트를 만드는 일은 너무나도 어려운 일이 될 것 같습니다.
오늘 소개해드린 이 글이 멋진 프로덕트, 그로스 팀을 만들기 위해 고민하고 계신 모든 분들께 도움이 되었으면 좋겠습니다.
