[요즘우린] 에이전시냐 인하우스냐 (feat.박봉&퇴사)

by. 더오픈프로덕트 요즘 무슨일 하세요? 저는 서비스 기획…. PM…. PO..? 현업에서 같이 일하고 있는 지인들게 “요즘 무슨 일 하세요?” 라는 질문에 저는“ 00 산업군에서 서비스 기획일을 하고 있습니다.”라고 답변을 하고 지인은 저는 지금 “00서비스에서 PM 일을 하고 있어요” 라는 이야기를 하는 상황이 종종 있습니다. 채용 사이트의 구인 구직 글을 보면 비지니스 경형 카테고리에서 PM, PO, 서비스 기획이라는 항목을 확인 할 수 있습니다. 하지만 PM, PO 카테고리를 선택해도 서비스 기획자 채용 목록이 포함이 되어 필터링이 되고 서비스 기획 카테고리를 선택해도 PM, PO 채용 목록이 같이 포함이 되어 나타납니다. 같이 기획 일을 하다가 어느 순간 서로에 대한 소개가 달라지는 상황과 채용공고는 같이 노출되는데 왜 PM, PO, 서비스 기획이 구분 지어 항목이 생기는 걸까요? 이러한 궁금증을 업계에서 동료들의 이야기, 책, 에세이의 글을 보고 이해한 저의 생각을 좀 정리해 보려 합니다 먼저 서비스 기획자란 무슨일을 하는 사람일까요? 서비스를 기획하는 직무는 다양한 분야의 산업과 직무에서 많이 쓰이고 있는데요 이를테면 사업 기획, IT 기획, 마케팅 기획, 이벤트 기획, 공공정책 기획 등 많은곳에서 다양한 이름으로 불리우고 있다는 것을 알 수 있습니다. 그중 IT 산업에서 서비스를 기획한다는건 새로운 제품 또는 서비스를 계획, 개발 및 관리하는 역할을 수행한다고 볼 수 있습니다. 비즈니스, 디자인, 기술, 사용자 경험(UX), 마케팅 등 다양한 영역에서의 지식과 기술을 활용하여 효과적인 서비스를 구현하고 관리 하면서 다양한 측면을 고려하여 제품 또는 서비스를 성공적으로 계획, 개발하고 지속적으로 향상시키는 역할을 담당합니다. 그렇다면 PM,PO의 역할 차이는 무엇일까요? 서비스 기획이라는 큰 틀에서 각자의 소속이나 업무의 성격에 맞게 불리어지는 단어는 이런 것들이 있습니다. 프로젝트 매니저 PMO = Project Management Office PL = Project Leader PM = Project Manager 프로덕트 매니저/오너 CPO = Chief Product Officer PM = Product Manager PO = Product Owner ※ 그 외 PM = Program Manager라는 타이틀도 있지만 저와 연결점이 없어 생략하겠습니다. PM - PROJECT MANAGER 프로젝트 매니저는 주로 SI(Service Integrator)기반으로 기업에서 진행하는 한시적인 일들을 프로젝트 단위로 받아서 주어진 기간 내에 문제 없이 완수하는 역할을 목표로 합니다 프로젝트의 규모에 따라 주어지는 역할군도 달라질 수 있는데 규모가 대형 프로젝트의 경우 관리의 체계가 많아짐으로 인해서 PM의 역활과 PM을 관리하는 PL 그리고 전체 프로젝트를 관리하는 PMO 역할을 생각해 볼 수 있습니다. 프로젝트를 하다보면 우리는 기획 PM, 개발 PM, 디자인 PM 등 PM 앞에 직무를 붙여서 이야기 하는걸 자주 볼 수 있는데 이는 프로젝트가 커짐으로 인하여 직무별로 프로젝트를 관리하는데 있어 도메인 지식이 다르기에 각각의 PM을 두기도 한다. 즉 기획 PM은 서비스 기획자들이 프로젝트를 성공적으로 완수 할 수 있도록 프로젝트의 전반적인 기획 가이드와, 일정 등을 관리해주는 역할이라고 볼 수 있습니다. 프로젝트 매니저의 주요 역할 리스크 관리 자원 관리 일정 및 범위 관리 PM - Product Manager 프로덕트 매니저는 제품을 기반으로 서비스를 제공하는 기업에서 주 역할을 하고 있으며 기서비스를 기획하는 다양한 측면에서 제품 또는 서비스의 전략을 수립하고 실행하여 비즈니스 목표를 달성하는 데 중요한 역할을 합니다. 이들은 비즈니스, 기술, 디자인, 마케팅 등 다양한 분야와 협력하여 제품의 라이프사이클을 관리하고 지속적인 성장을 추진하도록 합니다. 프로덕트 매니저의 주요 역할 사업 목표와 비전에 맞춰 전략적인 비지니스 목표치 정의 VOC를 수렴해 부합하는 솔루션을 제공하고 프로덕트에 반영 우선순위를 정리하고 프로덕트의 라이프 사이클을 정의 경쟁사 분석을 통해 프로덕트의 지속 가능한 장점을 구축 책임자의 역할로서 제품의 탄생부터 유지보수, EOS까지 관여하며 프로덕트를 개선 PO - Product owner 프로덕트 오너는 말그대로 제품의 주인으로서 오너십을 가지고 Scrum이나 다른 Agile 프로세스에서 제품 개발 팀과 협력하여 제품을 효과적으로 관리하고 전략을 수립하는 역할을 이야기 합니다. 주로 프로덕트 매니저와 혼동되는 경우가 많지만, 프로덕트 오너는 개발 팀과 직접적인 상호작용을 통해 제품의 요구 사항을 정의하고 우선순위를 결정하는 데 중점을 둡니다 프로덕트 오너의 주요 역할 프로덕트의 요구사항, 기능, 작업등 백로그 관리 백로그 우선순위 결정을 통한 팀의 핵짐적인 기능과 가치있는 일을 할 수 있도록 관리 스프린트 계획 수립, 리뷰, 회고 팀과 사용자의 중개자 역할을 통한 사용자의 의견과 피드백을 효과적으로 팀에게 전달 제품의 성공을 촉진하기 위한 지속적인 프로덕트, VOC, 팀 관리 그래서 서비스 기획, PM, PO 는 무슨 차이가 있을까요? 프로젝트 매니저를 제외한 서비스 기획, 프로덕트 매니저, 프로덕트 오너의 역할을 보면 세부적으로는 조금씩 다를 순 있겠지만 결국 프로덕트, 서비스를 성장 시키기 위해 전략을 수립하고 요구사항을 분석하고 이해관계자를 설득하며 팀이 제품 개발을 집중할 수 있도록 제시하여 비지니스 목표 달성에 기여할 수 있도록 하는 역할은 같아 보입니다. (해외에서는 PO가 PM의 부분 집합이라고 설명하고 있지만 국내에서는 그렇게 받아 들여지는 부분은 적어 보입니다.. ) 필자의 회사에서는 서비스 기획자 포지션으로 있으며 기업에서 요구하는 역할은 서비스 전략을 수립하고 이해관계자를 설득하며 IA및 WBS를 정리하고 화면설계서를 작성하여 디자인 팀과의 협업을 통해 디자인 검토를 진행 후 퍼블리싱팀과 협업 후 완료가 되면 개발팀 과의 협업을 통해 제품을 만들어 냅니다 이후 QA팀과 같이 서비스 품질 관리를 진행하고 서비스를 릴리즈 합니다. 릴리즈 후에는 영업팀과 논의 후 제품을 기업에 판매하며 판매 이후 사용자들의 제품 이용 현황 분석(amplitude) 및 VOC 관리를 통한 제품 개선을 진행합니다. 이렇듯 저희 회사가 정의한 서비스 기획자의 역할은 앞에 설명한 서비스 기획자, PM, PO 구분 없이 제품에 성장을 위해서 필요한 일을 진행하는 역할을 하고 있습니다. 서비스 기획, PM, PO의 역할은 기업에서 정의하는 것에 따라 하는 역할이 정의가 되고 있다고 보여집니다. 회사마다 일하는 방식은 다르지만, 결국 제품의 성공을 위해 일이 되게 만드는 사람이라는 공통점을 가지고 다들 화이팅 입니다! 참고 자료 https://www.codestates.com/blog/content/pm-po-%EC%B0%A8%EC%9D%B4 https://brunch.co.kr/@jidesign/81 https://www.google.co.kr/books/edition/%ED%94%84%EB%A1%9C%EB%8D%95%ED%8A%B8_%EB%A7%A4%EB%8B%88%EC%A7%80%EB%A8%BC%ED%8A%B8/673QEAAAQBAJ?hl=ko&gbpv=0 이 글의 원문은 더오픈프로덕트에서 확인할 수 있습니다. https://brunch.co.kr/@theopenproduct/ 좋은 프로덕트를 만들고자 하는 기획자, 디자이너, 마케터, 개발자가 모여 서로의 인사이트를 전합니다.

by. 더오픈프로덕트 어떤 금액이어도 괜찮아요. Figma에 대한 비용을 지불하고 싶습니다. Microsoft가 초창기 Figma에게 했던 얘기입니다. 이 얘기를 들었던 딜런(Dylan)은 처음으로 피그마가 성공할 수 있을 거라는 느낌을 받았다고 해요. 심지어 MS 직원 모두가 피그마를 애정하여 Microsoft Teams에서 지원하도록 개발했다는 사실, 알고 계셨나요? 이제는 Microsoft를 넘어 전 세계 디자이너, 개발자 모두에게 유일무이한 도구로 자리매김했는데요. 어떻게 무명의 피그마가 5년 만에 수십억 달러 규모의 Adobe로의 인수까지 이어질 수 있었는지 성장 과정과 전략 그리고 얻었던 인사이트를 이야기해 보려 합니다. 피그마의 성장 전략 Lenny’s Letter에서 Figma의 첫 마케터이자 현재 시니어 디렉터인 클래어 버틀러(Claire Butler)와의 인터뷰 내용을 가지고 왔습니다. 고객과 신뢰 쌓기 Figma는 광고와 같은 전통적인 마케팅 전략을 통해 성장하기보다는 초기 고객인 디자이너들과 신뢰를 쌓는 것을 우선으로 했습니다. 디자이너들은 스스로가 마케팅 수단의 대상이 되는 것을 싫어했고 홍보 내용을 들으려 하지도 않았죠. 단지 기술적 특징을 듣고 싶어 했다고 합니다. 그래서 클레어 초기에 한 일 중 하나는 마케팅하지 않으려 노력한 것이었습니다. 사용자들과 진정성 있는 신뢰를 쌓는데 시간을 많이 들였고, 이 과정에서 내부 디자인팀과 기능적인 구축 방법에 대해 많은 이야기를 나누어 피그마를 벡터 환경으로 구축했다고 합니다. 이후 마케팅팀에 새로 영입했던 팀원도 역시 디자이너였습니다. 실제 디자이너의 입장에서 피그마를 써보며 콘텐츠를 만들고 공유하여 다른 동종업계의 디자이너들이 “오 Figma에 새로운 아이디어 주목할 만한데?”라고 느낄 수 있도록 하는 효과가 있었죠. 또한 새로운 기능업데이트를 할 때마다 사용자들에게 다시 피그마를 사용해야 할 이유를 직접적으로 제공했다고 합니다. 사용자와 함께 제품 구축하기 피그마 초기에는 사용자가 몇 명 안 됐음에도 불구하고 딜런(Dylan)과 클레어(Claire)는 당시 CODA라는 회사를 찾아가 제품을 시연했고 업무에 사용해 보는 것을 승인받았다고 합니다. 하지만 곧 문제가 발생했는데요. CODA 측에서 “내부 엔지니어가 피그마 파일을 열 수 없어서 못 쓸 것 같아”라고 연락을 취해온 것이죠. 딜런은 직원들에게 “모두 하던 일은 두고 이 문제를 먼저 해결해야 해”라고 하였고, 즉각 피그마 서버와 제품 모두를 체크했지만 특별한 문제는 없었습니다. 결과적으로 해당 엔지니어의 맥북이 문제라는 것을 알게 되었고 곧장 CODA로 달려가 제품을 사용할 수 있도록 수리했다고 합니다. 계속 제품을 사용하게끔 하기 위해 문제에 즉각 대응을 한 것이죠. 그래서 사용자가 적었던 시기에는 *Intercom을 항상 열어두고 직원 모두가 실시간으로 대응했습니다. 가령, 사용자가 “이 버그가 있어요”라고 말하면 엔지니어는 “바로 QA를 진행하겠습니다”라고 답하는 식이었죠. 문제를 해결한 뒤에는 고객에게 다시 전달했는데 이는 고객 입장에서 “내가 요청했더니 반영이 되네?”라고 생각하면서 스스로 제품에 대한 소유권을 느끼게 하는 계기가 되었죠. 물론 이는 초창기 때의 예일뿐이고 시간이 지나 더 많은 사람과 대화함에 따라 규모가 커지기 시작했을 때는 VOC가 들어오면 마케팅팀에서 먼저 테스트해 본 뒤 엔지니어에게 전달하는 방식으로 변화했습니다. *intercom : 메시징을 전문으로 하는 소프트웨어 회사로 기업이 고객과 채팅할 수 있는 환경 제공 커뮤니티 환경 구축하기 여러분의 서비스(제품)를 사용하는 사람들이 생기면 어떻게 생각하는지가 궁금할 겁니다. 클레어 또한 마찬가지였죠. 그는 사용자가 서비스로 오게 하는 방법과 반대로 고객이 있는 곳으로 찾아가는 2가지 방법에 대해서 고민했다고 합니다. 지금은 피그마로 사람들이 유입되는 환경이 되어있지만, 초기에는 사람들은 피그마에 대해 모르고 관심이 없었기 때문이죠. 딜런은 트위터가 바로 피그마를 알리기에 좋은 수단이라고 생각했는데, 이유는 트위터는 이미 디자인 커뮤니티가 존재했고, 인플루언서들로 구성된 대규모 네트워크에서 사람들이 디자인 리소스를 공유하고 배우며 일종의 보금자리 역할을 하는 곳이기 때문이었습니다. 그래서 피그마는 트위터 한 채널에 올인했습니다. 디자인 커뮤니티에서 영향력 있는 사람들을 식별하여 다양한 디자이너의 대규모 노드 그래프를 만들었습니다. 아이콘 작가, 그래픽 디자이너, 제품 관리자들을 팔로우하고 진정성 있는 관계를 구축하려고 노력했죠. 이들이 바로 초창기 피그마가 피드백을 요청했던 사람들이기도 합니다. 처음에는 출시와 관련된 내용들이었지만 점차 기술적인 콘텐츠나 무엇이든 사람들의 피드백을 받고 사용자가 직접 제품을 만드는 데 참여하는 움직임을 만들어 나갔습니다. 그리고 공유했죠. 양질의 콘텐츠가 사람들을 끌어모으게 된 것입니다. 글을 마치며 누군가 서비스를 이용하는 중이라면 그게 한 명 일지라도 옆에 딱 붙어 이탈하지 않도록 신경 쓸 수 있는 고객 집착이 피그마를 성공의 길로 이끈 방법이 아닐지 하는 생각이 듭니다. 도움을 줄 수 있는 직접적인 사용자를 찾고 대화를 나누고 공유하며 진정성 있는 신뢰 관계 쌓는 것. 그리고 사용자의 피드백을 통해 직접 제품을 만드는 데 참여하는 움직임을 만들고 애착을 갖게 만든 점 또한 깊게 와닿습니다. 결국 “모든 것의 핵심은 사용자에게 있다”라는 생각이 드네요. Claire의 인터뷰를 통해 배운 점 사용자에게 집중하고, 만나고 배우고, 공유하는 것. 하나의 기능을 만들 때에도 사용자와 대화를 많이 나누는 것 사용자가 이탈하지 않고 계속 제품에 머물게 하기 위해 문제는 즉각 대응하기 (feat.Coda 사건) 핵심 문제를 찾고 집중하는 것 양보다는 양질의 콘텐츠를 만드는 것 참고자료 https://youtu.be/UmirRfy-gzA 글쓴이_무드조이 이 글의 원문은 더오픈프로덕트에서 확인하실 수 있습니다. https://brunch.co.kr/@theopenproduct/10 좋은 프로덕트를 만들고자 하는 기획자, 디자이너, 마케터, 개발자가 모여 서로의 인사이트를 전합니다.