[내일배움캠프(PM2기_본캠프)]/온보딩

[캠프 Day 5] 프로덕트 매니지먼트 개론 Chapter 2

semi0 2025. 4. 4. 19:58

● Intro

 어느덧 본캠프 첫 주도 마무리되어간다. 100% 열심했다고 스스로 자부할 수는 없던 한 주였다. 불안한 마음에 안일하게 군 적도 많았다. 주말 동안 잘 게워내고 다음 주는 더 알차게 보내보고자 한다. 당장은 포트폴리오 준비보다도 프로덕트 아이템과 자격증 공부 계획 세우기에 집중하고자 한다. 그럼 PM개론 마지막 챕터 바로 정리해 보겠다.


PM과 함께 일하는 사람들

 

▶ Not Only 개발자, 디자이너

PM과 협업하는 주요부서

 

: 가장 가깝게 지내는 부서는 개발자와 디자이너가 맞다. 허나, 대기업일수록 분업화가 잘 되어 있다. 따라서 각 분야마다 전문가가 존재하고, PM은 그들과 모두 긴밀히 협업한다. 이 중 기존에는 잘 알지 못했던 부서 몇 가지만 다루겠다.


▷ UX Researcher

: 사용자 경험(UX)을 개선하기 위해 사용자 인터뷰, 설문조사, 사용성 테스트 등 다양한 방법론을 통해 사용자에 대한 인사이트를 수집하고 분석하는 역할

 

토스 채용공고 내 UX Researcher JD 예시


▷ UX Writer

: 프로덕트에서 만날 수 있는 모든 텍스트를 담당한다. 사용자가 쉽게 이해하고 원하는 행동을 유도할 수 있도록 텍스트를 작성한다.

※ UX Writing 관련 아티클: https://blog.toss.im/article/uxwriter-interview

 

 


애자일(Agile) 방법론의 이해

 

▶ 워터풀(Waterfall)과 애자일(Agile)

: 대표적인 프로젝트 방법론은 2가지가 있다. 워터풀과 애자일이 그것이다.

 

프로젝트 방법론: 워터풀과 애자일

▷ 애자일 vs 워터풀

애자일과 워터풀 방식 비교표


▷ MVP란?

: 애자일의 큰 특징 중 하나는 MVP를 출시한다는 것인데, 이때 MVP란, '최소 가능 제품(Minimal Viable Product)'으로 제품 개발 초기 단계에서 가장 기본적인 기능만 포함한 제품을 신속히 시장에 출시하는 것을 말한다. 아래 예시가 MVP를 잘 보여주는 예시이다(어떤 형태든 일단 '탈 수 있다')

애자일의 MVP 특징 예시


 왜 애자일이 떠오르는가?

: 일단 빠르다. 무엇이 빠르냐면 시장의 반응을 살피는 시기가 빠르다. 본격적인 출시 이전에도 MVP를 통해 시장(고객) 피드백을 빨리 접수할 수 있다. 따라서, 요구가 다소 불명확하고 고객피드백이 중요한 프로덕트의 경우에 적합한 프로젝트 방법론이 될 수 있다. 시장에서 고객과의 소통이 활발한 요즘 시기에 알맞은 방법이라 생각된다.


애자일(Agile) Practice

: 애자일 방식으로 프로젝트를 진행하기 위한 구체적인 행동지침 및 프레임워크들을 알아본다. 근데 진짜 솔직하게 말해서, 내 개인적인 생각으로는 이 용어나 구체적 매뉴얼 등에 집착할 필요가 없을 것 같다. 모든 툴과 방법들은 근본적으로 효율적인 협업을 통해 진행되고, 각 팀마다 스타일은 다를 것이다. 따라서 용어나 개념 이해에 집착하거나, 특정 방식을 고수해서 학습하다 보면, 결국 툴이 틀을 지배해서 협업이 지체되기만 할 것 같다. 따라서, 이번 소 챕터에서는 스크럼 개념만 간단히 짚고 넘어가겠다.

 

▶ 스크럼(Scrum)

: 애자일 진행 방법 중 하나로, 팀이 협업하고 목표를 달성하기 위한 효율적인 관리 프레임워크이다. 짧은 단위 기간인 스프린트(Sprint)로 진행된다.

스크럼 방식의 구성과 설명


Product 단계별 PM 역할

: 대게 PM은 위의 스프린트 단위로 스크럼을 진행하며 프로덕트를 개선해 나간다. 허나, 각 주기 내에서도 단계별 PM의 역할을 알아보기 위해, Product의 단계를 [기획-디자인-개발-QA-출시]로 정의하고 각 단계별 역할을 살펴보자.


기획

: 프로젝트의 배경, 목표 설정, 문제정의, 해결방안 도출, 가설수립 및 검증방법 등을 구체화

기획 단계에서 PM의 역할

 

 디자인

: 기획안을 바탕으로 디자이너가 UI/UX를 디자인. 목적이나 배경만을 파악한 상태에서 디자이너가 프로토타입을 먼저 설계하기도 함.

디자인 단계에서 PM의 역할

 개발

: 개발자가 기획, 디자인을 바탕으로 프로덕트를 개발. 마찬가지로 앞 단계가 구체화되지 않아도 진행하기도 함

개발 단계에서 PM의 역할

QA

: 개발한 것을 개발 환경에 배포. 사용자가 사용해도 문제가 없는지 품질을 테스트합니다. 문제를 발견한 경우, 수정함

출시 단계에서 PM의 역할

 출시

: 출시 직후 문제가 없는지 모니터링하고, 사용자 반응을 분석해 다음 과제를 백로그에 추가

QA 단계에서 PM의 역할

 


여러 줄 코멘트: PM이 누구와 일하고, 어떻게 일하고, 무엇을 이용해 일하는지를 알아봤다. 토스나 배민 등의 각 전문가들이 쓴 사례들도 같이 읽어보니 좋은 인사이트도 많았다. 좋은 참고사례도 아래에 하나 남겨놓는다. 다만, '무엇'을 이용해 협업하는지 즉, 협업툴이나 협업방식 이론을 배울 때에 솔직히 말해 좀 이해가 안 가는 부분이 있었다. 노션이나 지라 등등 각종 협업 툴이 과연 사용자 친화적인가?에 대한 의문이었다. 정확히 말하면, 불필요한 기능들이 너무 많은 건 아닌가 싶었다. 이것도 하나의 Pain Point가 될 수 있겠다. 언제나 수단이 목적보다 앞서서는 안 된다고 생각한다.

 

참고 글: https://techblog.woowahan.com/12417/

 

PM이 사용자가 아닌 서비스는 어떻게 만들까? : 배민외식업광장 ‘장사캘린더’ 오픈부터 개선까

안녕하세요. 배민외식업광장 Product Manager 권자경입니다. 배민외식업광장팀은 외식업 사장님들을 위한 서비스인 '배민외식업광장'(a.k.a.배외광)을 담당하고 있습니다. 외식업 사장님에 대해서 잘

techblog.woowahan.com