프로젝트보다 ‘프로덕트’ 중심 마인드셋이 중요한 이유

본문은 요즘 IT와 번역가 Yuna가 함께한 캐스퍼 마호니(Caspar Mahoney)의 글 <Moving From a Project to a Product Mindset>을 번역한 글입니다. 필자는 14년 이상 코칭과 멘토링을 통해 사람들의 성장과 변화를 지원해 왔습니다. 그는 고객들이 명확한 방향성을 찾고, 진정한 자신으로서 원하는 삶을 살 수 있도록 돕고 있으며, 이 글에서는 프로젝트 중심 사고방식에서 벗어나 ‘프로덕트 중심 사고방식’을 갖추는 방법과 그 중요성에 대해 설명합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

우선 ‘아이언 트라이앵글’에 대해 얘기하겠습니다. 이 개념은 1950년대에 탄생했습니다. 그 긴 역사와 다양한 발전 과정을 모두 설명하진 않겠지만, 전 세계의 프로젝트 관계자들에게는 너무나도 잘 알려져 있고, 그들의 일상에 깊이 스며들어 있는 개념이라고 할 수 있죠. 주로 이해관계자 회의에서 일정 연장을 정당화하거나, 추가 예산을 요청하거나, 범위를 축소해야 할 때 자주 사용됩니다.

시간이 지나면서 이 삼각형에 “품질”이라는 중심점을 추가하는 변형도 생겨났는데요. 이로써 시간, 범위, 비용/예산과 함께 중요한 요소로 자리 잡게 되었습니다.

품질을 추가하는 것은 혁신적인 변화였지만, 이러한 요소 중 어느 것도 우리가 애초에 프로젝트를 진행하는 근본적인 이유를 다루지 않았습니다. 그렇다면, 우리는 왜 프로젝트를 진행할까요?

결국 중요한 건 가치와 혜택

제품의 세계에서는 이것이 단순히 가치로 표현되며, 이는 투자 대비 수익, 매출, 이익, 절감 혹은 이와 유사한 지표로 측정될 수 있습니다. 그래서 저에게는 모든 프로젝트나, 제품 전달의 핵심은 그것을 수행함으로써 얻을 수 있는 가치라고 할 수 있습니다.

현재 전 세계 대부분의 프로젝트 매니저들, 특히 5~10년 전에 교육받은 사람들(즉, 전 세계 대기업에서 일하는 수천 명)은 여전히 그 아이언 트라이앵글의 관점에서 세상을 보고 있습니다. 그렇다면 이것이 실제로 무엇을 의미할까요? 제품 환경일 때 주로 걱정하는 것은 다음과 같습니다.

a) 주어진 시간 내에 일을 완료할 수 있을지

b) 충분한 자원(예산)이 있는지

c) (a)와 (b)에 맞춰 범위가 설정되어 있는지 확인합니다. 범위가 너무 작어서 고민하는 경우는 없을 겁니다. 오히려 범위가 과도한 경우가 더 흔하죠. 물론 이론적으로는 범위가 너무 작을 순 있습니다.

자, 여기서 바로 아이언 트라이앵글이 등장합니다. 프로젝트 매니저들은 이 삼각형이 작동하게 하려고 공식적인 의사결정(스티어링)을 활용해 각 요소의 위치를 조정합니다. 시간이 부족하면 예산을 늘리거나 범위를 줄이거나, 혹은 둘 다 조정합니다. 예산이 부족하면 시간을 늘리거나 범위를 줄이거나, 마찬가지로 둘 다 조정할 수 있습니다.

하지만 이러한 사고방식은 현대적인 제품 개발에서는 문제가 됩니다. 왜냐하면 각 요소를 크게 조정하더라도 가치 또는 혜택을 달성하지 못할 가능성이 매우 크기 때문입니다.

사실 문제는 그보다 더 심각합니다. 이런 방식에서는 실패할 가능성이 매우 높습니다. 주요 이해관계자와 개발팀이 시간, 범위, 예산이라는 제약에 초점을 맞추도록 유도되면, 정작 가장 중요한 요소인 가치 또는 혜택이 우선순위에서 밀려나기 때문입니다.

애자일 이전 시대를 떠올려보세요. 이 문제는 훨씬 더 심각했습니다. IT 프로젝트의 실패율은 매우 높았고, 그 역사는 끔찍할 정도였죠. (자세한 내용은 여기에서 확인할 수 있습니다.) 반면, 혜택(가치)은 제품 방법론의 핵심입니다. 제품 매니저들은 무엇보다도 가치를 발견하고, 이를 전달할 전략을 설계하는 데 가장 많은 시간을 투자합니다.

오해하지 마세요. 제품 담당자들도 리스크, 일정, 범위, 예산을 고려합니다. 하지만 이 모든 요소는 가치에 비하면 부차적인 것들입니다. 

예를 들어, 대기업에서 내부 제품 관리를 담당하고 있다고 가정해 봅시다. 주요 고객팀에서 간단한 대화를 빠르게 텍스트로 기록하는 데 문제가 있다며, 이를 해결할 수 있게 도와달라는 요청이 왔습니다. 고객팀은 자신들이 요청한 이 기능이 현재 여러분이 개발 중인 제품에 추가되는 게 가장 적절하다고 생각합니다.

기존의 프로젝트 사고방식에서는 이렇게 접근할 수도 있습니다.

“좋아요, 이 프로젝트는 이미 진행 중이고 1년 동안 운영될 예정이라 예산이 확보되어 있습니다. 지금 우리가 개발 중인 기능에 추가될 새로운 요구사항이군요. 현재 구축 중인 기능들과 연관성이 있어 보이니, 일정 내에 마무리하면서 이 범위를 포함할 수 있을 것 같습니다.”

눈치 빠른 사람들은 이 사고방식이 범위, 시간, 예산이라는 기존의 규칙을 그대로 따르고 있음을 알아챌 겁니다. 이 기준만 충족한다면, 프로젝트 매니저는 이 요청을 승인할 가능성이 높습니다. 만약 백로그 관리 프로세스를 운영하고 있다면, 이 요구사항을 백로그에 추가한 뒤, 기본적으로 이 기능이 최종적으로 개발될 것이라는 가정하에 사양을 작성하기 시작할 것입니다.

반면, 제품 사고방식에서는 이렇게 접근해야 합니다.

• 이 기능 아이디어가 해결하려는 문제는 무엇인가?
• 그 문제가 지금 개발 중인 제품과 실제로 연관이 있는가?
• 더 빠르거나 더 효율적인 해결 방법은 없는가?
• 지금 당장 해결해야 할 가장 가치 있는 문제인가?
• 이 문제의 해결이 현재 또는 미래 전략과 일치하는가? 만약 그렇지 않다면, 전략을 수정하거나 업데이트해야 하는가?

위 질문에 대한 답이 명확해지기 전까지는, 제품 사고방식에서는 세부 사항(일정, 리소스/비용, 기술적 타당성, 기능 구현 방식 등) 논의로 넘어가지 않습니다. 하지만 이것도 사실 지나치게 단순화된 설명입니다. 그 이유는 다음에서 살펴보겠습니다.

발견 과정의 리더십

프로젝트 매니저는 아이디어의 조율자입니다. 보통 그들이 아이디어 영역에서 담당하는 역할은 여기까지입니다. 전통적인 프로젝트 전달 방식에서는 비즈니스 요구사항 수집을 통해 이를 수행하며, 이 과정에서 대규모의 사전 문서화가 이루어집니다.

반면, 현대적인 프로젝트 전달 방식에서는 애자일 방법론을 적용하여 요구사항을 반복적으로 분석하고, 더 자주 검토합니다. 그러나 프로젝트 매니저가 활동하는 모든 방식(워터폴이든 애자일이든)에서 변하지 않는 핵심은 그들이 우선적으로 조율자이며 플래너라는 점입니다. 따라서 프로젝트 매니저가 해당 도메인에 대한 깊은 전문 지식을 갖추어야 한다는 기대는 상대적으로 낮습니다.

여기서 말하는 도메인이란, 반드시 기술적인 것을 의미하는 것은 아닙니다. 대부분의 경우 비즈니스 도메인을 의미합니다. (다만, 일부 상황에서는 기술 도메인과 비즈니스 도메인이 모두 중요한 경우도 있습니다.)

반면, 제품 관리에서 제품 매니저(PM)는 도메인 전문가입니다. 만약 신입이거나 훈련 중인 경우라면, 도메인 전문가가 되기 위한 과정을 거치고 있을 것입니다. 따라서 제품 매니저는 발견 과정에서 리더십을 발휘합니다. 그리고 제품 매니저가 주도하는 발견은 단순한 요구사항 수집과는 완전히 다른 차원의 작업입니다. 요구사항 수집이란, 보통 비즈니스 분석가가 이해관계자들과 대화를 나누며 어떤 기능이 필요한지 묻고, 이를 문서화하는 과정입니다.

요구사항이 정리되면, 프로젝트 매니저는 머릿속에서 아이언 트라이앵글을 떠올리며 무엇을 포함할 수 있고, 무엇을 제외해야 하는지 계산합니다. 그리고 이를 경영진에게 업데이트로 보고합니다.

그렇다면, 만약 프로젝트 매니저가 요구사항을 명확하게 파악하지 못하거나, 요구사항과 프로젝트 범위가 충돌하는 상황이 발생하면 어떻게 할까요? 그들은 경영진에 상황을 보고하며, 비즈니스 SME(특정 분야 전문가)나 비즈니스 리더의 지원이 필요하다고 보고합니다. 또는 해당 전문가들이 프로젝트에 더 많은 시간을 할애해야 한다고 요청하겠죠.

그러나 제품 관리에서 진행되는 발견 과정은 이와는 완전히 다른 사고방식을 필요로 합니다. 이 과정에서는 제품 매니저의 도메인 지식이 핵심 역할을 합니다. 그렇다면 제품 매니저는 요구사항이 명확하지 않을 때 어떻게 대응할까요? 제품 매니저는 자신의 기술, 역량, 그리고 도구를 활용해 이러한 상황을 해결합니다. 때로는 자신의 지식을 바탕으로 모호한 부분을 메우기도 하지만, 그와 동시에 이러한 가정을 엄격히 검증하는 과정을 거칩니다.

제품 매니저는 문제의 본질을 파악하기 위해 정성적 또는 정량적 연구를 포함한 1차 연구를 직접 수행할 수도 있습니다. 또한 UX 디자이너와 엔지니어와 함께 화이트보드 앞에서 브레인스토밍 세션을 진행하며 새로운 아이디어를 도출한 뒤, 가정이나 가설을 테스트하며 이를 검증하기도 합니다.

그렇다면 제품 매니저가 명확하지 않은 요구사항을 가지고 경영진이나 상위 리더들에게 보고할까요? 그렇지 않습니다. 제품 매니저는 이러한 문제를 해결하는 방법을 알고 있으며, 독립적으로 이를 해결하는 역할을 합니다. 하지만 명확하지 않은 전략이나 불확실한 결과에 대해서는 상위 리더들과 논의합니다. 이 과정에서 개방적인 토론과 소프트 스킬을 활용하며, 철저한 데이터를 바탕으로 설득력을 높입니다. 그러나 요구사항과 같은 세부적인 사항들은 자주 보고하지 않습니다. 제품 매니저는 상위 리더의 개입 없이도 이러한 문제를 자체적으로 해결할 역량을 갖추고 있기 때문입니다.

발견은 완전히 창의적이고 혁신적인 과정입니다. 이는 새로운 환경에서의 탐구와 연구 중심의 접근 방식을 포함하며, 고차원적인 이해관계자 관리 역량, 사용자 조사, UX에 대한 깊은 이해가 요구됩니다.

제품 매니저는 발견 과정에 단순히 참여하거나, 이를 조율하는 역할에 그치지 않습니다. 그들은 이 과정을 주도하며, 발견을 이끄는 핵심 리더입니다. 제품 매니저는 고객이나 사용자와의 직접적인 소통을 비즈니스 분석가에게 전적으로 맡기지 않습니다. 비즈니스 분석가는 일부 지원할 수 있지만, 주로 행정적인 보조 역할에 가깝습니다. 

사실 많은 제품 조직에서는 비즈니스 분석가를 활용하는 것이 바람직하지 않다고 여깁니다. 대신 제품 매니저, UX 디자이너, 엔지니어가 직접 최종 사용자와 소통하며, 비즈니스 분석가가 제공할 수 있는 정보를 대체하는 방식으로 접근합니다. 이처럼 제품 매니저에게 기대되는 리더십은 단순한 조율을 넘어섭니다. 제품 전문가는 다양한 역량을 갖추어야 하며, 사용자 참여, 연구, 아이디어 도출, 문제 분석에서 독립적으로 행동할 자신감을 보여주어야 합니다.

받아들이는 자세에서 만들어내는 자세로

제품 관리에 처음 입문한 사람들과 프로젝트 배경이 있는 사람들은 큰 그림을 보기보다는 세부 사항에 더 집중하는 경향이 있습니다. 또한 프로젝트 중심의 사람들은 전략을 화이트보드에 그리거나, 비전을 구체적으로 설명하는 것보다 엑셀 스프레드시트를 다루는 데 더 익숙하죠.

이러한 경향은 그들이 상사나 고위 이해관계자들에게 “우리가 무엇을 해야 할까요?”와 같은 형태의 질문을 자주 하는 모습으로 나타납니다. 그리고 그 답을 얻으면, 이를 Jira, Excel, Confluence 같은 도구를 사용해 세부 계획으로 전환합니다. 사실 이들은 계획을 최대한 빨리 작성하고 싶어 합니다. 왜냐하면 계획이 세워지면 무엇이 진행 중인지, 누가 무엇을 해야 하는지 명확해져 불확실성이 줄어들고, 그만큼 자신감이 생기기 때문이죠.

하지만 능숙한 제품 매니저는 “우리가 무엇을 해야 할까요?”라는 질문을 주로 하지 않습니다. 대신 그들은 고위 이해관계자들에게 “우리는 이걸 해야 합니다”, 또는 최소한 “다음과 같은 옵션들이 있습니다”라고 말하죠. 그리고 이러한 결론을 내리기 전에 반드시 질문과 연구를 통해 세 가지를 먼저 이해합니다.

• 이 제품이 어떤 가치를 더할 수 있는가?
• 이 제품이 해결하는 문제는 무엇인가?
• 이 제품이 바꾸는 사용자의 행동은 무엇인가?

따라서 제품 관리 분야로 전환하기 위해서는 시야를 넓히고, 아이디어를 발견하며, 통찰력 있는 정보를 찾아 이를 실질적인 실행 계획으로 만들어낼 수 있는 자신감이 필요합니다. 다시 말해, ROI를 정의하고 비즈니스 케이스를 만드는 것이 일상적인 업무가 되어, 더 이상 ‘비즈니스 케이스’라는 별도의 문서를 작성할 필요 없이 지표와 데이터, 인사이트를 통해 자연스럽게 업무에 녹여낼 수 있어야 합니다. 제품 관리자가 되려면, 모든 것이 준비되어 있을 거라는 기대는 버려야 합니다.

차려진 상은 없습니다. 여러분이 직접 상을 차리고, 그 위에 다른 사람들이 활용할 수 있는 것들을 올려놓아야 합니다.

요약하자면, 뛰어난 제품 관리자가 되기 위해서는 다음 세 가지 핵심적인 사고방식의 전환이 필요합니다.

• 가치를 최우선으로 생각해야 합니다. 시간, 예산, 범위는 그다음이죠. 가치를 이해하는 게 먼저입니다.
• 도메인에 대한 자신감을 가지고 탐색합니다. 조율도 하지만, 그것만 하는 데 그치지 않습니다. 도메인 전문성을 제한받는다면 답답할 정도로 전문가가 되어야 합니다.
• 아이디어와 전략, 비전을 만들어 냅니다. 다른 사람의 의견을 듣고 정리만 하는 게 아닙니다. 웨이터처럼 주문을 받거나, 아이디어를 담는 우편함이 되어선 안 됩니다. 대신 모호하게 표현되거나, 정리되지 않은 것들을 구체적인 형태로 만들어내는 능력이 탁월해야 합니다.

이번 글을 통해 프로젝트 중심 사고에서 벗어나, 가치 중심의 제품 마인드셋으로 전환하는 것에 대해 고려해 볼 수 있길 바랍니다.

<원문>

Moving From a Project to a Product Mindset

©위 번역글의 원 저작권은 Caspar Mahoney에게 있으며, 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다