회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
AWS 이용 중이라면 월 최대 15% 할인받으세요
본문은 요즘 IT와 번역가 Yuna가 함께한 미겔 카루에고(Miguel Carruego)의 글 <Symptoms of a broken product culture — Part 2>을 번역한 글입니다. 필자인 미겔 카루에고는 바르셀로나를 기반으로 활동하며, 비즈니스 목표와 사용자 요구를 연결하는 데 탁월한 전문성을 가진 COO입니다. 1부 ‘급한 불 끄기 바쁜 프로덕트의 문제점’에서는 잘못된 프로덕트 문화의 증상을 살펴보았는데요. 이어지는 2부에서는 이러한 문제를 해결하기 위한 전략을 제시합니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!
확인
본문은 요즘 IT와 번역가 Yuna가 함께한 미겔 카루에고(Miguel Carruego)의 글 <Symptoms of a broken product culture — Part 2>을 번역한 글입니다. 필자인 미겔 카루에고는 바르셀로나를 기반으로 활동하며, 비즈니스 목표와 사용자 요구를 연결하는 데 탁월한 전문성을 가진 COO입니다. 1부 ‘급한 불 끄기 바쁜 프로덕트의 문제점’에서는 잘못된 프로덕트 문화의 증상을 살펴보았는데요. 이어지는 2부에서는 이러한 문제를 해결하기 위한 전략을 제시합니다.
필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.
잘못된 프로덕트 문화의 증상 2부
1부 ‘급한 불 끄기 바쁜 프로덕트의 문제점’에서는 프로덕트 조직에서 나타나는 위험 신호에 대해 이야기하며, 주로 문제점에 초점을 맞췄습니다. 이번 글에서는 이러한 문제를 해결하기 위한 전략과 전술에 대해 다루고자 합니다.
1부에서 제가 강조했던 주요 문제들은 다음과 같습니다.
이번 글은 주로 프로덕트 및 소프트웨어 개발 리더를 대상으로 작성되었지만, 이 과정에 관여하는 모든 분들에게 유용한 내용이 될 겁니다.
말은 쉽지만, 막상 실행하자니 어렵게 느껴지죠?
급한 불을 끄기식 해결을 줄이는 방법에는 여러 가지가 있지만, 다른 문제들과 마찬가지로 첫 번째 단계는 문제를 인지하는 것입니다. 회사의 경영진이 이 문제를 인정하고 이를 우선순위로 삼기로 결정하는 순간이 중요한 첫걸음입니다. 당연한 이야기처럼 들릴 수 있지만, 실제로 급한 불부터 끄는 해결은 경영진이 중요한 것보다 시급한 것에 집착하면서 발생합니다. 그러므로 내부에서든 외부에서든, 누군가가 이 문제를 지적하는 것이 필요합니다.
여기서부터는 로저 본이 쓴 ‘급한 불 끄기는 그만(Stop Fighting Fires)’라는 하버드 비즈니스 리뷰(HBR) 기사에서 몇 가지 아이디어를 정리했습니다.
우버(Uber)는 “기술 회사”일까요, 아니면 “프로덕트 회사”일까요? 꽤 어려운 질문일 수 있습니다. 가장 쉽게 답하면, “기술 중심의 프로덕트 회사”라고 말할 수 있겠지만, 그렇게 말하는 사람은 거의 없습니다. 이 질문이 별거 아닌 것 같지만, 회사에서 많은 사람들의 공통 대답이 그 조직의 문화와 사고방식임을 담고 있습니다.
명확한 데이터는 없지만 많은 회사가 엔지니어들에 의해 설립되었고, 일반적으로 CTO보다 CPO의 수가 더 적다고 생각합니다. 이로 인해 시장에서는 IT 사고방식이 지배적이 되었고, 고객 경험은 이보다 뒤로 밀려나는 경우가 많습니다.
기술은 필수적이라 부담이 되거나, 그 자체가 목적이 되어서는 안 됩니다. 기술은 가치를 제안하는 데 일부가 될 수 있으며, 반드시 그렇게 되어야 합니다. 창업자들이 회사를 설립하는 이유는 다양하지만, 기술은 그중 하나일 뿐입니다. 결국 모든 회사는 어떤 방식으로든 인간의 삶을 진보시키기 위해 존재합니다. 그리고 핵심 목표가 사람들을 돕는 것이라면, 기술은 자연스럽게 부차적인 수단이 됩니다.
이제 각자 우리 회사 사람들은 어떤 배경을 가지고 있을지 생각해 봅시다. 99%의 대부분은 금융, 마케팅, 엔지니어링, 디자인, 경영학, 인사관리 등을 전공한 사람들이 있을 것입니다. “사람들의 삶이 더 나아지도록 돕는 방법”을 전공한 사람은 거의 없을 겁니다. 결국 프로덕트 회사란 기술을 만드는 방법을 아는 사람들과 이를 통해 돈을 버는 방법을 아는 사람들이 모인 곳입니다. 이 모든 설명은 왜 “IT 중심 사고”가 일반적이고, “제품 중심 사고”는 낯설어하는지를 설명하기 위함입니다.
이것이 리서처를 채용하는 것이 제품 중심 사고로 전환하는 데 있어 가장 혁신적인 이유입니다. 리서처들은 고객 경험과 사람들이 더 나아갈 수 있도록 돕는 일에 열정적이며, 프로덕트 조직에 이들을 두지 않는 것은 큰 손실입니다. 보통 리서처는 심리학이나 커뮤니케이션과 같은 배경을 가진 경우가 많습니다. 물론 PM, 디자이너도 리서치를 수행할 수 있고 또 그렇게 해야 하지만, 전문 리서처가 있는 것과는 문화적으로 큰 차이가 있습니다.
또 다른 문제는 프로덕트 기술을 IT 기술처럼 취급할 때 나타납니다. 즉, 고객 중심의 가치를 창출하기보다는 내부 운영 효율성이나 기술적 구현에만 초점을 맞추는 이러한 상황에서 나타납니다. 이를 해결하기 위해 제품 관리 분야의 선구자인 ‘마티 케이건’은 몇 가지 행동 방안을 제안했으며, 여기에 제 의견을 더해 소개하려 합니다.
제프 고덜프의 훌륭한 강연 중에 애자일이 무엇인지 설명합니다. 그는 애자일이란 단순히 계획을 따르게 아니라, 변화에 대응하는 것이라고 이야기합니다. 그러나 현실은 많은 조직이 애자일을 학습이나 민첩성, 방향 수정보다는, 단순히 소프트웨어를 만들고 좋은 코드 몇 줄을 작성하는 데 집중하는 도구로 오해하고 있습니다. (참고 : 애자일이란 무엇인가)
여러분도 아마 CEO가 엔지니어들이 아무것도 하지 않을 때 놀라는 장면을 본 적이 있을 겁니다. 그 반응을 이해하지 못하는 것은 아닙니다. 회사는 인건비를 회수해야 하기 때문이죠. 하지만 소프트웨어를 마구 생산하는 건 해결책이 아닙니다.
해결책은 고객 가치를 창출하는 것입니다. 고객 가치는 한 줄의 코드에서 나올 수도 있고, 심지어 코드를 삭제할 때 나올 수도 있습니다. 이를 체계적으로 해결하는 방법 중 하나는 개발 과정에 ‘정리 기간(cool-down period)’을 도입하는 것입니다. 이 기간 동안 엔지니어들은 버그 수정, 새로운 아이디어 탐색, 새로운 기술 가능성 실험 등 원하는 일에 집중할 수 있습니다.
‘Shape up’이라는 제품 방법론에서는 6주의 개발 기간과 2주의 정리 기간을 가질 것을 권장합니다. 이 기간 동안에는 작업 없이 숨을 고르고, 필요할 때 회의를 열며, 다음에 무엇을 할지 고민할 수 있습니다.
스타트업 프로덕트 회사들은 지속적인 혁신과 현상 유지 사이에서 균형을 맞추는 데 어려움을 겪곤 합니다. 혁신이 정말 필요하지만, 현실적으로 필요한 실험을 위해 시간과 자원을 확보해야 합니다. 그러나 자원은 항상 부족하고, 운영을 유지하면서 동시에 혁신을 추구하는 일은 달리면서 신발 끈을 묶는 것과 같죠.
이 난제를 해결하는 한 가지 방법은 간단한 규칙을 따르는 것입니다. 오늘 수익을 가져다주는 일에 80%의 시간을 사용하고, 미래 수익을 가져다줄 일에 20%의 시간을 투자하는 것입니다. 이 규칙은 에릭 슈미트(전 구글 CEO)가 빌 게이츠로부터 들은 조언이며, 그의 저서 ‘구글은 어떻게 일하는가’에 자세히 설명되어 있습니다.
책에서도 설명되었듯, 이 규칙을 실제로 따르는 것은 보기보다 어려울 수 있습니다. 리더들은 새로운 제품이 수익을 내기까지 걸리는 시간을 종종 과소평가합니다. 새롭고 반짝이는 아이템은 기존의 핵심 비즈니스보다 매력적으로 보일 수 있지만, 지루해 보이는 기존 사업이 회사의 고정비를 책임지고 있습니다. 이 핵심 사업에서 실수를 저지르면 회복하기가 매우 어려울 수 있습니다.
그럼에도 불구하고, 핵심 80%에 집중하는 것만큼 중요한 것은 20%의 시간을 혁신에 할애하는 것입니다. 여기서 말하는 것은 구글의 유명한 ‘20% 룰’이 아닙니다. 제가 말하는 것은 리더십에서 시작되는 명확하고 전략적인 혁신입니다. 이를 간과하면 새로운 경쟁자가 비즈니스를 위협할 뿐만 아니라, 팀원들이 혁신할 기회를 잃고 동기 부여를 상실할 위험이 있습니다.
혁신을 멈춘 기존 회사들은 보통 하루아침에 무너지지는 않습니다. 브랜드에 의존해 몇 년간 생존할 수도 있죠. 하지만 오늘날 좋은 회사가 빠르게 성장할 수 있는 동력이, 동시에 그 회사를 빠르게 몰락하게 만드는 원인이 될 수 있다는 사실을 인식하는 것도 중요합니다.
두 제품은 요구사항도 다르고, 필요한 기술과 역량도 다르며, 프로세스와 자원도 각각 다릅니다. 둘 다 중요하지만, 이 둘은 성격이 다르고 대부분은 유저용 제품에 맞춰져야 합니다.
내부 운영 제품은 아웃소싱하거나 상용 소프트웨어를 활용하세요. 그래야 최고의 인재와 자원을 고객을 위한 제품에 집중할 수 있습니다.
저를 아는 동료라면 누구나 제 가장 강력한 무기가 무엇인지 알고 있을 겁니다. 바로 제품 개발 주기입니다. 그리고 제품 개발 주기를 경험해 본 사람이라면, 그 비결이 작업 시간 분배에 있다는 것도 알 것입니다. 제품 개발 주기에 대해서는 여기서 깊이 다루지 않겠습니다. 이미 관련된 많은 글과 문헌이 있으니까요. 특히 Basecamp 팀의 ‘제품 개발 방법론(Shape Up)’은 현재까지 가장 좋은 자료로 손꼽힙니다. 대신, 작업 시간 분배가 왜 그렇게 중요한지를 설명해 보겠습니다.
IT 사고방식이나 기술 중심의 회사에서는 흔히 추정 기반 개발이라는 패러다임이 존재합니다. 여기서는 회사가 엔지니어들의 속도에 맞춰 움직이며, 특정 기능이 배포되기까지 걸리는 시간을 엔지니어들이 결정합니다. 그러나 이 방식의 문제는 소프트웨어 개발에서 추정 자체가 매우 어렵다는 데 있습니다. 특히 레거시 코드에 의존하는 회사에서는 엔지니어들이 기존 시스템의 작동 방식을 끊임없이 파악해야 하는 경우가 많습니다. 만약 모든 추정이 빗나가고 마감 기한을 지속적으로 놓치고 있다면, 멈춰서 이를 고민해 볼 필요가 있습니다.
작업 시간 분배는 조직 전체를 한 단계 끌어올립니다. 리더들이 어떤 계획의 목표를 결정하게 하고, 제품 팀이 모든 작업을 개발 주기에 맞추도록 만듭니다. 이 방식은 어떻게 소프트웨어를 가장 잘 만들고, 얼마나 오래 걸릴지라는 논의에서 벗어나, 고객 가치와 가장 중요한 것이 무엇인지에 초점을 맞추게 합니다. 고객 가치와 출시 시기를 중심으로 논의하는 것은 진정한 제품 중심 조직으로 거듭나는 가장 중요한 요소입니다. 이를 실현하기 위해 제품 개발 주기나 다른 작업 시간 분배 기법을 활용할 수 있습니다.
최근 밀라노에서 열린 Product Heroes 커뮤니티에서 발표할 기회가 있었는데, Q&A 시간에 누군가 이런 질문을 했습니다.
“우리는 발견 단계에 시간을 할애할 여유가 없으면 어떻게 해야 하나요?”
저는 이렇게 답했습니다.
“시간을 할애하시든가, 아니면 새로운 직장을 찾으세요.”
지금 돌아보면 약간 과한 표현이지만, 전달하려고 했던 메시지는 이겁니다. 조직은 제품 관리를 신뢰하거나 그렇지 않거나 둘 중 하나라는 것입니다. 여기서 ‘조직’이란 회사의 리더십을 의미합니다. 만약 리더가 리서치, 과학적 실험, 지속적인 반복의 중요성을 진정으로 믿지 않는다면, 문제를 해결할 방법은 없습니다. 이 문제를 해결해 줄 마법 같은 프로세스나 방법론은 존재하지 않습니다.
이러한 상황에서 싸워야 하는 책임은 리더(CPO, VP, Head of Product)에게 있습니다. 하지만 조직이 제품 관리의 중요성을 제대로 이해하거나 이를 위한 환경을 조성하지 않기 때문에, 많은 PM이 전략적인 역할을 수행하기보다는, 단순히 기능 요청을 정리하고 전달하는 ‘백로그 관리자’ 역할에 머무는 경우가 흔합니다.
이 문제를 해결하기 위해 다음 규칙들을 추천합니다.
이러한 규칙은 프로세스를 통해 실행할 수 있습니다. 하지만 이것만으로 충분하지 않을 수 있습니다. 규칙은 깨지기 마련이니까요. 이때 필요한 것이 진정한 리더십입니다. 제품 리더로서 PM을 조직의 중심에 세워야 합니다. 이를 달성하기 위해 추천하는 전략은 다음과 같습니다.
이 문제를 해결할 단 하나의 정답은 없으며, 마법 같은 해결책도 없습니다. 다만 분명한 사실은 이 문제는 조직 문화와 깊이 연결되어 있다는 점입니다. 이를 해결하려면 진정한 리더십이 필요합니다. 여기서 ‘진정한’ 리더십이란, 문제가 발생했을 때 침묵하지 않고, 이를 과감히 지적하며 실제로 행동에 나설 수 있는 리더를 말합니다.
잘못된 프로덕트 문화는 결국 비즈니스 실패로 이어집니다. 제품-시장 적합성을 달성하지 못하면, 자금이 고갈되거나 경쟁사에 밀려 시장에서 사라지게 됩니다. 이는 단순히 PM만의 문제가 아니라, 조직 전체가 함께 고민하고 해결해야 할 과제입니다.
부서 간 소통이 단절된 회사들은 프로덕트 문화를 받아들이는 데 어려움을 겪습니다. 프로덕트 문화란 고객을 조직의 중심에 두는 것을 의미합니다. 고객이 중심이 된다면, 마케팅 목표, 재무 목표, 채용 목표 등 다른 모든 것은 부차적인 문제가 됩니다. 중요한 것은 오직 제품-시장 적합성을 달성하는 것입니다.
<참고>
<원문>
Symptoms of a broken product culture — Part 2
위 번역글의 원 저작권은 Miguel Carruego에게 있으며, 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다