지극히 개인적인 제품 전략과 제품 관리 체계
제품 관리
※ 주의 ※ 이 글은 스크럼, 애자일과 같은 프레임워크나 방법론에 대한 글이 아닙니다. 간접적으로 언급은 되겠지만, 본 내용은 오히려 마인드셋에 가까운 글입니다.
[서문]
3년 가까이 이런저런 프로젝트도 경험해보면서, 제품 관리 과정에서 비효율이나 비생산적인 논의를 너무 많이 느꼈었습니다. 그렇게 '이러한 문제들을 어떻게 해결해야 하지?', '어떻게 해결책을 내야 생산적일 뿐만 아니라 서로 커리어적으로도 도움이 되고 일할 맛 날 수 있을까?'라는 고민이 시작됐습니다.
검색하면 나오는 수많은 프레임워크는 약간의 도움은 되긴 한 것 같지만, 삐걱거림의 본질적인 부분을 해소하기에는 역부족이었습니다. 기본적인 원인도 밝혀내지 않은 채 그저 남들이 한다는 이유로 억지로 무언가를 쑤셔박는다는 건 더 큰 갈등을 초래하는 경우가 더 많았으니까요. 그렇게 갈등 속에서 속이 메스껍기도 하고, 난청도 겪고, 공황같은 것도 겪기도 했습니다. 하지만 도망친 곳에는 낙원은 없었습니다. 매번 그랬구요.
그렇게 1~2년 전부터 제품 관리에 대한 책과 아티클을 읽고, 동시에 책의 내용과 회사 상황을 고려하여 여러 시도를 해본 결과 공통적으로 적용할 수 있는 부분들이 보이기 시작한 것 같습니다. 아직 저도 짧은 경력이지만, 모두들 비슷한 상황이나 어려움 겪을 것이란 걸 알기에, 조금이라도 도움이 될까 싶어 제가 내린 소결들에 대해 정리하여 공유드려봅니다.
잘 굴러가는 제품 관리를 위한 '대전제'
(1) 우리의 모든 전략은 증거에 기반해야 합니다.
증거는 논리로 시작되지 않습니다.
User Story Mapping, Jeff Patton- 우리가 타겟으로 삼고 있는 고객의 실제 삶의 맥락과 행동 패턴을 파악하는 것이 제품 개발의 근본적인 시작점입니다.
- 아무리 좋은 논리더라도, 고객의 실제 삶과 동떨어진 생각이라면 제품에 녹여내봤자 고객에게도, 우리에게도 아무런 의미를 갖지 못 합니다. 그렇기에 '우리의 머리에서만 나온 생각과 그럴듯한 이야기'로만 제품 개발을 시작하는 것은 매우 위험합니다.
- 고객의 삶의 맥락과 패턴은 여러 업무/작업 단계들의 연속선상에 있지, 분리된 단계들로 구성되어 있지 않습니다.
- 그렇기 때문에 이 맥락의 흐름과 단계의 근본적인 이유를 물으며 끊임없이 ‘왜(why)’를 밝혀나가야 합니다. 어떤 이유로 그 행동을 했는지, 그 행동이 다수에게 나타나는 특성인지, 개별적 특성이라면 왜 그 특이성이 나왔는지에 대한 호기심을 가져야 합니다.
(2) 우리는 공동의 이해를 이룩해야 합니다.
머리에만 들어있는 형상은 서로 다를 수 밖에 없습니다.
User Story Mapping, Jeff Patton- 언어적 전달은 정확한 정보 전달에 한계를 가지고 있습니다. 아무리 많은 요구사항과 정보를 글과 말로 적더라도, 이를 이해하는 바는 사람마다 다를 위험성을 매우 크게 내포하고 있습니다.
- 공동의 이해가 이뤄지지 않고 제품을 만들기 시작하면, 생각한대로 결과물이 나오지 않을 뿐더러, 아무도 쓰지 않을 무언가가 나올 위험성을 더욱 커질 것입니다.
- 그렇기 때문에 우리의 논리는 문서화뿐만 아니라 시각화되어야 하며, 재논의하고, 공동의 이해를 더욱 확실하게 이룩할 수 있어야 합니다.
- 공동의 이해를 이루기 위해 전달해야하는 업무 산출물의 양식을 이해관계자마다 다름을 인지해야 합니다.
- 디자이너에게는 요구사항이나 와이어프레임을 전달하고, 임원진에게는 사업적 의사결정을 위해 필요한 제반사항이나 중요 리스크들에 대한 문서를 전달하는 것처럼, 각 이해관계자가 업무적 맥락에 맞는 공동의 이해를 이룰 수 있도록 어떤 것을 전달해야하는지에 대한 고민이 필요합니다.
(3) 우리는 근거와 논리를 인지해야 합니다.
우리의 말과 논리는 검증되지 않은 수많은 가설들을 포함하고 있을 확률이 매우 큽니다.
- 이 가설들은 우리의 사고 실험에서 맞을 것이다라는 은연중의 상상을 통해 참이라고 인지될 가능성이 큽니다.
- 우리는 메타인지를 통해 우리가 당연시 생각하고 있던 것들을 적어내고, 사실 여부를 밝혀야할 필요성이 있는지 확인해야 합니다.
- 또한, 우리 생각은 생각보다 결과론적이거나 피상적인 경향이 있습니다. 정말 자신이 근본적으로 해결하고자 하는 물음이 무엇인지 심사숙고하고 이를 표현해봐야 합니다.
- 나의 삶에서 당연했던 것들은 타인의 삶에서는 당연치 못할 가능성이 큽니다. 성공적인 제품은 타인(고객)으로부터 시작됩니다.
(4) 기획자가 제품에 대해 책임져야합니다. 책임자가 없다면, 그리고 성공하길 바란다면 스스로를 자처해보는 것도 좋을겁니다.
생각보다 많은 사람들은 그저 그렇게 일하려 하며, 책임지려 하지 않습니다. 특히 체계가 없고 건강하지 않은 조직은 더더욱요.
- 위의 모든 과정을 제대로 거치고 성과를 내기 위해서는 책임을 질 사람이 필요합니다.
- 프로덕트 매니저는 '제품을 성공으로 이끄는 사람'이라고도 말합니다. 프로덕트 매니저라는 직무가 나온 이유는, 프로젝트의 복잡성이 증가함에 따라 실패할 확률이 기하급수적으로 증가하기 때문입니다.
- 프로젝트가 가진 위험성은, 다음 단계로 넘어갈 때마다, 기획에서 디자인으로, 디자인에서 개발로 책임 소지를 전가하기 너무 쉽다는 점입니다. 각 직무자들은 책임 소지를 피하기 위해, 직장에서 생존하기 위해 더더욱 자신의 직무 영역을 좁게 규정하고 회피하게 됩니다.
- 조직에 프로덕트 매니저가 없더라도, 프로젝트의 성공을 바란다면 프로덕트 매니저의 역할을 자처해 프로젝트의 전반에 대해 지독하게 관심을 갖고 개선시켜 나가야 합니다.
- 그러한 지독한 관심과 제품의 성공에 대한 열망은, 생각보다 엄청난 마법을 이뤄줄 때가 있습니다. 하지만 조직의 독성이 너무나 치명적이어서 그 열망을 짓밟아버릴 때도 있죠. 그래도 시도는 해보고 실패해봐야, 적어도 후회는 하지 않을겁니다. (저도 여러 번 꺾인 경험이 있지만, 그래도 아직도 도전 중입니다!)
제품 전략 = 리스크 최소화 + 협력 과정
우리의 시간과 에너지는 소중하며, 돈은 유한합니다.
그렇기 때문에 우리의 결정들은 실질적 가치를 가지고 있어야 합니다. 실질적 가치란, 고객이 기꺼이 지불할 만한 효용이 있다라는 것과 동시에, 제품을 통해 지속적인 사업 지속을 할 수 있도록 한다는 두 가지 의미를 지닌 개념입니다. 실질적 가치는 조직 내에서만 나온 생각으로는 성립되지 않습니다. 적극적으로 우리의 고객들에게 찾아가 공감하고 학습하며 기회를 탐색할 수 있어야 합니다.
대개 인터뷰가 주가 된 고객 조사(a.k.a 사용자 조사)를 기반으로 우리는 정보를 끊임없이 쌓아나가고, 이를 전략 선정의 근거로 삼을 수 있어야 합니다. 고객 및 사용자의 니즈, 고통, 문제가 무엇인지 밝혀나가고, 이 니즈, 고통, 문제들의 빈도와 강도를 체계적으로 분석하며 충분한 시장성이 있는지 전략적으로 판단해 나가야 합니다.
이 과정의 근본적인 기반은, 우리의 (1) 고객에 대한 이해가 우수하고, 그 수준이 일치하며 (2) 우리의 의견이 어디서 파생됐는지 파악할 수 있어야 한다는 점입니다. 우리의 제품은 브레인스토밍처럼 아무렇게 나온 상태의 생각으로 결정되지 않습니다. 우리의 해결책 아이디어는 고객의 맥락을 충분히 반영하고 다루려는 기회를 충분히 발현시킬 수 있는 레퍼런스가 있어야합니다. 제품/솔루션 단위의 결정뿐만 아니라 제품 기능을 결정하는 데에 있어서도 마찬가지입니다.
각 단계들의 위의 그림처럼 나뉘며, 각 단계에 나와야할 산출물이나 결정들은 우측에 적힌 내용과 같습니다. 꼭 적힌 형태의 산출물이어야만 하는 것은 아니며, 조직에 의미있는 내용을 확실하게 공유하기 위해서는 나름대로 정리해서 공유해야한다는 것이 핵심입니다.
이 과정에서 프로덕트 매니저가 해야할 행동들
(1) 상위 의사결정자(ex. 리더, 임원)에게 해야할 것
- 현재 어떤 사업적 목표를 위해 어떤 프로젝트를 기획 중인지에 대해 정리하여 공유
- 프로젝트가 승인되어 시작된 경우, 현재 수행한 업무에 대한 핵심 내용 공유 및 의사결정에 영향을 미칠 주요 요인들에 대해 정리하여 공유
(2) 직무가 다른 팀원들에게 해야할 것
- 리서치를 통해 나온 사실, 해석, 통찰들을 보기쉬운 형태로 정리하여 공유한 뒤 제품의 방향성에 대해 논의
- 본인이 '탁월하게' 해결할 수 없는 부분은 해당 직무자에게 도움을 요청하여 해결
제품 관리의 과정
제품은 유기체와 같습니다.
기획/개발/마케팅/운영은 각 영역의 부족한 부분을 채워주기도 하며, 시너지를 내 더 큰 가치를 만들어내기도 합니다. 절차상 혹은 업무 구분상 페이지는 나눠지겠지만, 각 제품 관리의 영역의 협응성이 충분히 이뤄지지 않으면 아무리 고객 가치가 크더라도 제대로 작동되기 어려워집니다.
모든 영역의 업무를 다 알아야 한다는 것이 아닙니다. 제품의 유기체적 흐름을 고려하지 않고 한 영역이 독주하면 문제가 생긴다는 것을 인지해야 하는 것입니다. 우리의 인체의 장기가 하나하나 홀로 존재했을 때 작동하지 않듯, 제품 또한 마찬가지입니다.
그렇기 때문에 제품 개발 전반의 논의에서는 모든 담당자들이 열띠게 논의하며, 제품 전반의 과정에 대해 모두가 인지하고 있는 것이 이상적입니다. 제품 기획 단계에서 사용자의 행동에 대해 디자이너와 같이 논의하며 제대로된 UX를 구현할 기능을 기획하고, 개발시에 예상치 못한 리스크로 인해 기획이나 디자인을 수정하는 상황을 자연스레 대처하듯 말이죠.
물론 이러한 논의가 생산적으로 흘러가기 위해선 각 담당자의 지식이 깊이와, 상대 직무에 대한 지식 깊이 등 다양한 요인들이 잘 맞아떨어져야 합니다. 현실은 본인 직무도 잘 몰라 헤매는 것이 부지기수입니다. 그렇기에 이를 미연에 방지할 최소한의 가드레일을 제공해야합니다. 그게 담당자들이 작성해야 하는 최소한의 산출물입니다.
- 기획자: PRD(제품 요구사항 문서), 제품 상세 기획, 저품질 와이어프레임, 배포시 필요한 문서(ex. 패치노트) 작성 등
- 디자이너: 고품질 와이어프레임, 인터랙션 정의 등
- 개발자: 개발물, 개발물에 대한 주석 혹은 문서 등
(위의 산출물의 구체적인 형태와 내용은 조직의 사업 및 제품 형태, 일하는 방식에 따라 필요에 맞게 작성해야 합니다.)
제품 관리 과정에서 나오는 논의들은 대부분 자칫하면 책임 소지를 물으며 기분만 상하고 일의 진도는 안 나가는 경우가 많습니다. 그렇기에 이러한 최소한의 산출물이나 체계는 그러한 소지를 줄일 수 있도록 돕기 때문에, 웬만하면 만드는 것을 추천드립니다. 그래야 누가 그걸 놓쳤는지 파악하고, 지금 빨리 작업해서 고치고, 다음부턴 안 그러면 되니까요!
또한, 끊임없이 폭격되는 뜬금없는 업무와, 직무 자체의 업무만으로도 숨이 막히는 경우가 많습니다. 인력은 한 명인데, 마치 위에서는 인력이 10명 있는 것마냥 일을 자꾸 던지는 경우처럼 말이죠. 이 상황을 타개하기 위해 프로덕트 매니저의 역량이 필요한 것이라 생각합니다. 그 안건들이 긴급한 것들인지, 사업적으로 유의미한 것인지, 공수는 얼마나 드는지, 본인이 그냥 도움을 주면 빠르게 해결할 수 있는지 등의 '우선순위'를 판단하여 제품 관리상의 혼란을 최소화 시켜주는 것이죠.
왜 이렇게 추상적인 얘기만 늘어놓게 됐냐면요
'어떤 프레임워크를 사용해봐야 해서', '어떤 SaaS를 사용하고 있지 않아서', '높은 연차의 인력이 없어서'라는 등의 이야기를 거의 모든 조직에서 들은 것 같습니다. 하지만 조직문화와 제품 관리 체계라는 것은 이미 기존의 인력이 가진 역량의 평균 이상의 형태로 절대로 나올 수 없습니다. 프레임워크, 소프트웨어, 연차 높은 인력은 기존의 하드한 관성을 깨기에 너무나도 소프트하거든요.
그렇기에 지금 있는 인력들이, 노력으로써 최선의 업무 방식을 택하지 않으면 기적이 발생하지 않는 이상 누가 오든지, 무엇을 사용하든지 조직의 권태, 부조화, 긴장, 시기는 극복할 수 없다라는 생각을 하게 됐습니다. 관성을 깰 수 있는 것은 결국 내부 인력의 굳세고 탁월한 업무 방식, 그리고 개선할 수 있다는 희망이라는 결론에 다다랐습니다.
제가 위에 적은 이야기들은 제 짧은 경험과 식견으로 나온 것들이지만, 비슷한 고민을 가져 이 글에 들어오신 분이라면 해결의 실마리를 얻길 바랍니다.
2024.11.03
꾸준히 성장할 수 있는 스타트업 업계를 바라며
