PM관련 책을 공부하기 전에 읽어야하는 글
도그냥이 알려드리는, 용어정리보다 중요한 개념입니다.
** 이 글은 현재 제가 클럽장으로 운영중인 트레바리 클럽 <본질을 아는 기획>의 2번째 모임을 진행하기 앞서 프로덕트관련 책들을 읽을 때 혼동하기 쉬운 개념들을 먼저 짚어드린 30분짜리 미니 토크를 정리한 내용입니다 :) 못오셨던 분들에게 요약해서 전달하기로 했었거든요. 줄글이라 이해하기 어려우실 수 있겠지만 최대한 당시에 이야기했던 대로 설명드려봅니다 :)
들어가기 전에
책을 보기 전에는 머리 속에 정보를 받아들일 일관된 틀이 있어야 하는데요. 이 틀이 없는 상태에서 책을 읽으면 책의 용어들의 함의를 이해하지 못하기 떄문에 뒤죽박죽이 되기도 하고요. 특히 다양성이 많은 직무이기 떄문에 먼저 읽은 책때문에 다른 책을 읽었을 때 차이점 때문에 굉장히 혼동스럽게 느껴지기도 합니다. 그래서 프로덕트매니지먼트나 PM/PO/서비스기획자에 일에 대한 책을 읽기 전에 전체 판을 한번 깔아두고 이 책이 어떤 사상의 어떤 쪽에 속했는지를 이해하는 것은 이후에 읽을 책들을 잘 이해하는 좋은 방법이더라고요.
그래서 독서모임에서 이에 대한 부분을 같이 전달드렸습니다.
먼저, 책에서 기술된 개념의 배경을 구분 해야한닷!
대부분의 실무에 관련된 책 중 외서의 경우는 프로덕트팀에서 애자일방법론으로 일하면서 B2C 서비스를 만드는 형태를 기본으로 생각해서 작성이 되는 경우가 많습니다. 그래서 암묵적으로 크로스펑셔널한 조직으로 기획,개발,디자인이 한 팀이 되어서 스크럼 또는 스쿼드라고 불리는 조직형태로 묶어서 스프린트 단위로 빠르게 가설을 실험검증하면서 성공을 만들어가며 일하는 것의 중요성을 강조하죠. 여기서 폭포수 방법론의 문제를 세차게 까내리는 것도 올드패션이 되었고요. 이제는 폭포수는 이야기도 하지 않고 애자일방법론을 어떻게 변종으로 만들어서 잘 활용해먹나를 이야기하는 편입니다.
문제는 국내의 업무 환경이 이렇지 않은 곳이 허다하다는 것인데요. 여전히 많은 기업에서 기능조직 형태로 기획, 개발, 디자인팀이 따로 구성되어 있고 프로젝트 단위로 일부가 모여서 이미 의사결정된 프로젝트를 진행하는 형태로 많이 진행을 하죠. 이럴 경우 애자일 방법론의 스프린트나 스크럼은 잘 작동하지 않기 떄문에 폭포수 방법론으로 회귀하거나, 겉으로는 스프린트인데 실제로는 쪽대본처럼 화면설계서를 그린다거나 하는 경우들이 발생합니다. 이런 배경에서 나오는 책들은 보통 '서비스 기획자'라는 명칭을 많이 쓰죠.
프로덕트매니저, PM, 프로덕트오너라는 단어를 쓰는 국내의 저자들의 책은 더 혼란스럽습니다. 조직구조와 프로젝트 방법론을 엮어서 설명하기도 하고, 실무라는 개념으로 내려오면 폭포수 방법론의 업무형태에서 문서만 바꾼 것이 기획자와의 차이라고 설명하기도 합니다. 그게 아니면 갑자기 데이터 지표에 대한 이야기가 나오기도 하죠. 국내의 일하는 환경이 이런 것들이 혼재되어 있기 때문이죠.
명확하게 구분해야하는 것은 3가지 입니다. 이 세가지는 독립적으로 선택이 가능합니다.
1) 프로덕트 매니지먼트(why, 로드맵, 정렬)
2) 조직구조(기능조직vs프로덕트팀)
3) 프로젝트방법론(폭포수vs애자일(스크럼))
1. 프로덕트매니지먼트(Why, 로드맵, 정렬)란?
프로덕트매니지먼트라는 개념은 프로덕트매니저가 하는 일로 단어부터 딱 떨어집니다. 여기서 프로덕트매니저란 프로덕트관리자의 개념이죠. 일부 외서에서 프로젝트 시 수행하는 소프트스킬의 역할까지 포함시키기도 하지만 대부분은 프로젝트가 수행되기 전에 무엇을 할지를 기획하는 과정에 포함됩니다.
이 활동의 핵심은 프로덕트매니지먼트란 기업의 미션(Why)를 바탕으로 만들어야할 프로덕트의 형태(비전)을 정하여 그것을 달성하기 위한 전략과 전술을 정의하고 이에 대한 로드맵을 구성하는 일련의 정렬(Alignment)로 이루어집니다.
Mission(why) - Vision(자사의 모습) - Starategy(전략 - 지표적 목표) - Tactics(전술 - 프로젝트화 할 수 있는 요구사항)
이 때 정확한 정렬을 위해서 사용되는 것이 전략을 움직이는 지표(metric)입니다. 모든 일의 근거이자 모든 일의 결과 지표에 해당하죠. 이 떄문에 PM은 데이터를 잘 다뤄야 한다 이런 이야기들이 나오는 것이죠.
그리고 이런 지표를 극대화한 평가 방식이 OKR입니다. objective는 이중에서 전략에 해당하고, Key result는 전략의 수치적인목표와 연결점이 닿아있습니다. 그래서 어떤 다양한 전술을 동원해서라도 전략의 지표를 달성했는가를 판단하는 것이죠.
이때 추가로 등장하는 표현이 비즈니스임팩트와 MVP입니다. 최소한의 개발로 비즈니스임팩트를 만들어낼 수 있다면 일단 그만큼 하자는 거죠. 이것은 애자일이라고 착각하기 쉬운데, 이 부분은 그저 프로덕트매니지먼트에서 Scop을 정하는 방식의 차이입니다. (실험-실패의 개념은 '린'학습의 개념이 더 적합하니까요)
무엇을 해야하는가에 대해서 아이디어를 짜내는 것이 아니라 기업적 미션부터 일관성있게 정렬되어 내려오는 과정이 프로덕트매니지먼트에 해당하고요. 국내에서는 사실 이 모습이 잘 퍼져있지 않습니다. 보통 내부의 요구사항이 사업부에서 오면 그것을 해결하는 사내 외주방식으로 일을 많이 하기 떄문이죠. 그래서 국내서에서는 이 부분을 '상위기획'이라거나 '전략기획'이라는 이름으로 아예 분리되어 있거나 마치 아이디어나 데이터기반 기획이라는 이름으로 작게 표현됩니다. 아예 이 내용 자체를 할지 말지 모르니 언급하지 않는 편이죠.
제가 처음으로 썼던 <서비스기획스쿨>은 입문자 주니어용으로 이런 내용이 거의 담겨있지 않습니다. 국내의 클래식한 조직에서 신입이 하는 일의 관점이기 떄문이죠.
반대로 외서를 읽을 때는 이 부분이 너무 당연해서 내용이 희석되어 있고 바로 조직구조로 넘어가는 일이 허다합니다. 왜냐면 경영에서 오래전부터 이 부분을 당연시 해왔기에 온라인 프로덕트가 생겨나기 전부터 정렬과정이 있었꺼든요. 그래서 외서는 어떻게 하면 저 활동을 잘 실천할 수 있을지 조직구조에 대한 이야기로 더 많이 들어갑니다. 국내는 이 부분에 대해서 더 필요한데 말이죠.
국내에서 이런 업무의 중요성이 도입되면서 PO라는 형태로 이름이 왜곡되서 이 업무에 대한 담당자를 표현하기 시작하면서 용어체계는 더 꼬였는데요. 그래서 더욱 머리 속에서 용어를 분리해서 볼 수 있어야 합니다.
2) 조직구조(기능조직vs프로덕트팀)
제가 서비스기획자에서 프로덕트오너로 불리는 조직으로 이직을 하면서 생각했던 키워드는 단 하나, '크로스펑셔널팀'에서 일하는 방법을 익히는 것이었는데요. 저 역시 크로스펑셔널팀 = 프로덕트팀 = 애자일 방법론 이렇게 착각을 했었습니다.
사실 프로덕트팀은 조직을 구성하는 목적조직의 형태로, 프로덕트팀으로 구성된 목적조직이 스크럼이나 애자일 프로잭트를 진행하기에 좀 더 용이한 조직의 형태일 뿐이지 꼭 애자일 방법론을 쓴느 조직이어야 하는 것은 아니거든요. 그리고 B2B 서비스를 하는 경우에는 가설과 실험보다는 안정적인 약속에 의해서 무결점 서비스를 요구에 따라서 제공하는 게 중요한 경우도 존재하고요.
그럼에도 이런 목적조직이 서비스기획자보다는 PM/PO와 어울리게 느껴지는 것은 바로 '스크럼'이라는 호칭 때문입니다. 프로덕트매니저라는 직무명이 애자일 방법론이 수입될 때 같이 됐고, 스크럼이라는 용어와 함께 PO가 수입됐기 때문입니다.
국내에서는 조직구조를 할 때, 프로덕트팀을 만들면 그 팀을 '스크럼' 또는 '스쿼드', '트라이브' 이런 식으로 부르는데요. 스크럼이란 대표적인 애자일개발 방법론 중 하나로 조직구조의 형태를 크로스펑셔널팀으로 가지고 가고 그안에 스프린트에서 할 일을 정리하고 빠르게 지원하는 '프로덕트오너'라는 개념과 스프린트라는 개념을 처음으로 정리한 방법론입니다. 스크럼이 데일리 회의명이거나 조직명인데 애자일방법론을 하고 있지 않다면 용어 자체가 왜곡되어 사용되는 상황인 거고요. 또 '스쿼드','트라이브'란 단어를 쓰는 경우는 크로스펑셔널 조직인 팀을 구성해서 각 팀의 자유도를 최고로 높여서 좋은 성과를 냈다고 소문이 자자했던 '스포티파이'의 영향을 받아서 이름이 지어진 경우입니다.
이름이 뭐가 됐든, 중요한건 크로스펑셔널팀이고 프로덕트팀이라는 사실이죠. 스크럼, 스쿼드, 트라이브 이런 이름이면 애자일 방법론도 선호할 확률이 높을 뿐이지 100% 그렇다고 볼 수는 없는 것이죠.
조직구조가 기능조직이냐 프로덕트팀으로 가느냐는 방법론보다는 그 팀의 책임범위와 전문성이 하나에 국한되어 있고 그 프로덕트의 방향을 함께 논의하느냐 아니냐에 따라서 달라집니다. 당연히 프로덕트팀일 때 개발자나 디자이너의 프로덕트에 대한 전문성과 이해도가 높아질 것이고, 기획을 하는 사람은 앞뒤의 사정을 파악해서 전후 로드맵이나 영향도를 이해하고 제안하기도 좋으니까요.
3) 프로젝트방법론(폭포수vs애자일)
이제 마지막으로 프로젝트 방법론입니다.
다시 말하지만 조직의 형태를 프로젝트 방법론과 독립적입니다.
프로덕트팀이라고 해도 폭포수 프로젝트로 진행해서 화면설계서를 쓸 수 있고, 기능조직이라도 애자일 방법론으로 PRD를 쓸 수 있습니다. 이 둘 사이의 가장 큰 차이는 실제 디자이너, 개발자의 참여에 대한 자유도를 얼마나 주느냐가 더 핵심입니다.
폭포수 프로젝트는 앞단계에서 완벽한 개발 설계를 해야하기 때문에 화면설계서는 생각할 수 있는 모든 케이스를 최대한 많이 기획하고 개발이 착수되기 전에 대부분의 케이스별 의도한 결과를 정리해낼 수 있어야 합니다. 개발자 리뷰를 통해서 모든 요소를 확실히 하고 가야하죠. 그래서 와이어프레임과 케이스, 디스크립션이 모두 고도로 정확할 수 있어야 합니다. 하지만 이런 경우 개발자의 더 기술적인 참여가 제한될 수 있어요. 기획자의 기술적 이해도는 상대적으로 낮을 수밖에 없고 점점 더 복잡한 프로젝트가 늘어나기 때문에 기획자가 로직을 이해조차 하지 못하는 프로덕트들도 있거든요. (로직이 없고 결과만 있는 머신러닝도 있고요)
물론 절대 오류가 나서는 안되는 금융로직이나 결제, 주문의 핵심 로직은 처음부터 설계가 잘 되어야 합니다. 하지만 그렇지 않은 화면이나 모듈이라면 오히려 메이커들의 자유도를 높이는 것이 더 좋은 결과를 가져올 수 있는 거죠.
PRD를 쓰고 유저스토리를 쓰는 방식은 화면설계서를 그릴 때보다 메이커들의 자유도가 높아지고 빠른 참여를 시작할 수 밖에 없게 만듭니다. 디테일한 설계부분을 화면설계서 하듯이 그리지 않으니까요. 폭포수 방법론은 앞단계에서 완벽한 설계를 해야되기 떄문에 화면설계서 방식을 더 추종하게 되고, 애자일방법론은 문제정의와 완료됐을 때의 조건을 나타내는 유저스토리를 바탕으로 메이커들의 창의성을 더 많이 반영할 수 있습니다. 애자일은 모든 관계자들의 적극적인 참여를 강조합니다. 그리고 설계를 오래 붙들고 있기 보다는 코딩을 빨리 해서 산출물을 나오도록 하는 것도 강조하죠.
스크럼은 그런 애자일 방법론종 하나로 스프린트라는 단위를 이야기합니다. 스프린트 단위로 빠르게 산출물을 만들어낼 수 있죠. 그래서 애자일 방법론은 린한 학습과 실험을 하기에 용이합니다. 용이하다고 했지 100% 그래야한다는 것은 아닌 것이죠. 스프린트는 아니더라도 MVP를 개발 후 단계별로 마일스톤을 쪼개서 진행하는 것은 폭포수프로젝트로도 가능합니다. 이건 프로젝트 형태가 아니라 조직과 프로덕트매니지먼트를 할 때 비즈니스 임팩트를 바탕으로 얼마나 개발할 것인지 scop을 정하는 행위에 따르는 일이니까요.
유저스토리를 쓰는 프로젝트에서 스프린트별로 개발할 수 있는 양으로 양을 줄여야 하는데요. 이 때 사용하게 되는 개념이 EPIC을 쪼개는 개념입니다. 일종의 프로젝트를 위한 소프트스킬의 영역이죠.
그리고 가장 많이 관심같은 실무가 대부분 이 프로젝트의 진행속에서 어떻게 행동하고 의견을 내야하고 무엇을 정리해야하고 이슈를 해결해야하는지에 달려 있습니다.
정리하자면, 책을 선택하고 읽어나갈 때
그 책의 배경(국내/해외)여부와 프로덕트리더십에 대한 포함여부
지향하는 조직구조, 지향하는 프로젝트방법론
더해서 그 책의 저자가 만드는 서비스의 성향(실험중심 or 안정성중심)을
먼저 파악해야 합니다.
머리 속에 이런 지형지도가 없이 몇권 안되는 책을 읽으면 더 혼란스럽거나 왜곡되서 읽기 쉽습니다. 이 직무는 스펙트럼이 다양하기 때문에 어떤 책을 읽으시더라도 이 부분에 대해서 머리 속에 틀을 만들어두고 읽어나가시면 책에서 좋은 점들을 객관적으로 보실 수 있을 거라고 생각합니다 :)
덧 :)
1월말 까지 진행하면 트레바리 클럽이 1기가 끝나요. 아마 이후에 2기를 모집할 것 같아요.
저와 같이 프로덕트관련 책들을 읽으면서 이런 머리 속의 지형지도를 그리고 지식을 올바르게 정리하고 싶으신 분들은 다음에 꼭 함께해주세요 :)
