프로덕트 팀과 개발방법론

프로덕트 팀과 개발방법론

PM은 팀을 이해하고 커뮤니케이션하며, 고객의 문제를 해결하는 사람이다.

말하자면 '무엇'을 '누구'와 '어떻게' 만들어야 할 지 고민하는 사람이라고 할 수 있겠다.

따라서 '누구'에 해당하는 프로덕트 팀에 대해 이해할 필요가 있고,

'무엇'을 만들어야 하는 지 알아내고 '어떻게' 만들어야 할 지 방향을 제시해주는

개발방법론에 대해서도 알아야 할 필요가 있다.

 

PM에 대한 개념을 조금 더 생각해본뒤 프로덕트 팀과 개발방법론에 대해서 알아보자.

 

PM의 동음이의어

우리가 이야기하는 PM은 Product Manager의 준말이다.

그러나 세상에는 PM이라고 표기되는 많은 준말들이 있다.

심지어 역할도 어느정도는 겹쳐서 구분하기 어렵거나, 다르다는 것을 인지하지 못하는 경우도 있다.

과연 다른 PM들과 Product Manager는 어떻게 구분되는지 알아보자.

 

Project Manager

팀이 기한 안에 일을 끝내도록 하고, 팀의 방향성이 선로를 벗어나지 않도록 관리하는 역할이다.

오케스트라 공연이라는 상황에 비유하면,

스케쥴 마스터로서 예정된 시간에 리허설과 공연이 진행되도록 관리하는 사람이라고 할 수 있다.

 

Program Manager

'생산'이라는 키워드에 더 집중하여 제조와 같은 엔지니어링 영역에 더 긴밀하게 운영업무를 수행한다.

오케스트라 공연이라는 상황에 비유하면,

현장감독으로서 조명이나 화면, 카메라 등의 장비를 관리하고 체크하는 사람이라고 할 수 있다.

 

Product Manager

고객의 문제, 니즈를 이해하고 구축하려는 솔루션이 고객에게 적합한가 확인하는 업무를 수행한다.

또한 이해관계자들을 활용해 구축하는 일 자체를 돕기도 한다.

오케스트라 공연이라는 상황에 비유하면,

지휘자로서 오케스트라의 모든 사람들에 대한 이해를 바탕으로 공통 목표 달성을 위해 조율하는 사람이다.

 

PM = mini CEO?

PM은

제품지지자이면서(팀과 사용자에게 비전을 믿게 만들어야 한다.)

문제해결사이면서(고객문제를 발견하고 해결하는 일이 제일 중요하다.)

협상가이다.(팀 내의 커뮤니케이션, 외부 미팅 등)

또한 팀 전체의 신뢰를 받아야 한다.

 

그래서 PM을 mini CEO라고 하며,

제품의 비전을 해친다거나 우리 팀이 가야할 방향성에 어긋나는 의견이 제시된다면,

책임감있고 카리스마 있는 자세로(오너쉽) NO라고 말할 줄 알아야한다.

 

프로덕트 팀

프로덕트 팀은 크게

PM, 엔지니어, 디자이너로 이루어진다.

 

엔지니어

기획, 디자인이 완료된 것을 구현하는 역할이다.

PM이 엔지니어와 소통하기 위해선 기술의 큰 그림을 이해하고 있어야 한다.

 

디자이너

기획, 사용성에 대한 고민을 함께하며 프로덕트의 화면을 구상하는 역할이다.

PM이 디자이너와 소통하기 위해선 UI/UX에 대해 이해할 필요가 있다.

프로덕트 팀의 협업 방식

IT 프로덕트 팀의 협업 방식 중 대표적으로 2가지가 있다.

워터폴(WaterFall)

워터폴 방식은 단계를 확실히 마무리하고 지나가는 것으로,

이전 단계로 돌아가는 일이 최대한 없도록 해야한다.

따라서 최초의 요구사항 정의단계에서 세밀하고 섬세한 요구사항을 위해 많은 시간을 들여야 한다.

복잡하고 규모가 큰 프로젝트에 주로 이용된다.

 

애자일(agile)

애자일 방식은 업무를 최대한 쪼개서 동시다발적으로 진행한다.

스크럼, 칸반, 스프린트, 유저스토리와 같은 툴을 이용하며

개발단계를 반복해서 진행한다.

따라서 고객의 요구를 즉시 반영할 수 있다.

협업과 학습을 동시에 진행하며 스타트업들이 주로 이 방법을 지향한다.

 

Intercom의 칼럼을 참고하면,

그들은 의사결정에 대한 가이드라인 설정, 어떤 업무에 대한 책임자를 분명히하기,

명료하고 점진적인 로드맵 설정, 목표 설정의 문화 설립을

팀의 업무에 가장 중요하게 생각한다고 한다.

또한 그들에 의하면, 업무 방식은 계속 변해간다고 한다.

 

따라서 어떤 방식이 더 좋고 나쁜 것이 아니라 팀과 기획에 맞는 방식을 고르고

일하는 방식/업무를 맞춰 나가는 것이 중요하다.

 

Product Life Cycle

앞서 PM은 '무엇'을 '누구'와 '어떻게' 만들어야 하는지 고민하는 사람이라고 말했다.

'무엇'을 만들어야 하고, '어떻게' 만들어야 하는지 구체적인 과정을 제시해주는

Product Life Cycle이라는 개념을 알아보자.

 

1. 서비스에서 추구할 기회를 발견, 명확하게 정의

우리팀의 비전과 미션을 정의한다.

우리가 만들고자 하는 것이 무엇이며 다른 프로덕트와 차별점이 무엇인지,

핵심고객은 누구이고 어떻게 문제를 해결할 수 있는지 명료하게 정의해야한다.

 

2. 솔루션 디자인

디자인 팀과의 협업을 통해 프로토타입을 만들고 테스트해야한다.

 

3. 솔루션 구축

앞선 디자인을 바탕으로 프로덕트를 제작한다.

엔지니어팀에게 프로토타입을 효과적으로 공유해야한다.

MVP 범위를 찾아 개발해야한다.

 

4. 솔루션 공유

고객에게 제품을 알리는 단계이다.(마케팅)

제품이 어떻게 문제를 해결하는지를 명확하게 전달하고

고객의 반응을 수집할 방법을 고민해야 한다.

 

5. 솔루션 평가

앞선 사이클이 잘 돌아갔는지 평가하는 단계이다.

내부적으로는 개발이 잘 되었는지, 앞선 단계들에 개선할 점은 없는지를 돌아봐야 한다.

외부적으로는 데이터를 기반으로 사용자의 반응을 확인해야한다.

 

정리하자면, Product Life Cycle은

문제/기회 발견 -> 솔루션 디자인 -> 솔루션 구축 -> 고객 테스트

라고 할 수 있다.

 

+ 7단계로 구성된 Product Development Process도 있고

   IT 프로덕트에 초점이 맞춰진 Software Development Life cycle(SDLC)라는 것도 있다.

 

MVP

Product Life Cycle의 최초 목표로서, MVP를 만들어야한다.

MVP(Minimally Viable Product)란 핵심 기능을 가진 프로덕트를 의미한다.

최소 단위라는 점에 집중하여 기획 중 욕심을 부리지 않도록 유의해야한다.

 

MVP의 종류

Testable : 피드백을 받을 수 있는 최소 단위의 MVP

Usable : 고객의 가치를 파악하고 사업가치 파악을 시작할 수 있는 MVP

Lovable : 고객이 사랑하고 큰 사업가치를 창출할 수 있는 MVP

 

결과적으로 MVP를 활용하여

PMF(Product/Market Fit)에 도달할 수 있는 Product를 탐색해야한다.

 

MVP라는 개념에서 말하는 최소 단위는,

완성품이 정해져 있고 이를 위한 부품을 하나하나 만들라는 뜻이 아니다.

사용자의 핵심 문제/니즈를 해결할 수 있는 최소 기능을 만들라는 뜻이다.

따라서 최소기능의 형태가 발전되거나 바뀌기도 한다.

 

개발방법론

기획을 하면서 중요한 점은 고객이 만들어 달라는 것을 만들어야 하는 것이 아니다.

왜냐하면 고객도 자기 자신의 문제와 니즈를 명료하게 파악하고 있지 못할 수 있기 때문이다.

따라서 '고객집착'을 통해 고객이 가진 문제와 니즈를 확실하게 파악하고 이를 해결하는 방법을 생각해내야 한다.

이 과정을 도우면서 Product Life Cycle을 따라가기 위한 개발방법론들이 있다.

 

Design Thinking

비즈니스적 문제를 디자이너적인 사고방식으로 접근해 해결하는 방법론이다.

공감 -> 문제정의 -> 아이디어 도출 -> 시제품 제작 -> 사용자 테스트

라는 과정으로 이루어진다.

 

PM이 뭔지 전혀 모르던 19년도 필자도 접해봤던 개념일 정도로,

오늘 소개하는 개발방법론 중 가장 유명하다.

 

Design Thinking 과정

1. 공감

타겟에 대한 이해와 분석을 진행한다.

대표 타겟을 선정하여 페르소나를 만든다.

 

2. 문제 발견

유저 저니 맵을 제작한다

인터뷰, 관찰을 통해 문제를 리스트업한다.

 

3. 문제 정의

감정 다이어그램으로 문제를 그룹화 한 뒤, 핵심 문제를 도출한다,.

핵심 문제를 정의하고 원인을 분석한다.

 

4. 아이디어 도출

정의한 문제 해결을 위해 브레인 스토밍을 진행한다.

가장 합리적인 솔루션을 제시한다.

 

5. 아이디어 구체화

솔루션을 구체화한다.

기능을 정의하고, 화면을 설계한다.

화면설계를 위한 와이어프레임을 제작하고 이를 바탕으로 회의를 한다.

 

6. 시제품

프로토타이핑을 한다.

시제품이 실제로 문제를 해결하고 있는지 평가를 해본다.

 

7. 사용자 테스트

사용자 테스트를 진행한다.

 

Design Thinking 예시

스탠포드 공대 학생들의 미얀마 농부들의 물 공급 문제 해결

JTBD

특정 상황에서 고객이 해결하고자 하는 문제에 집중한, 고객 문제 접근 방법이다.

고객은 '특정한 상황'에서 '현실적인 제약' 때문에 '자신이 원하는 바'를 이루지 못할 수 있고,

그로 인해 '특정한 감정'을 느낀다.를 정의하는 방법론이다.

 

JTBD 예시

맥도날드의 밀크쉐이크

Lean Thinking

추후에 다뤄보겠다.

 

단계별 고객/프로덕트팀과의 핵심 내용

프로토타입 이전

고객 - 이런 서비스를 기획하고 있는데, 관심 있으신가요?

프로덕트팀 - 이런 서비스를 기획하고 있는데, 잘 만들어 줄 수 있나요?

 

프로토타입

고객 - 제가 서비스를 소개해드렸을 때, 기대한 것들이 이게 맞나요?

프로덕트팀 - 어떤 디자인이 좋을까요? 개발하는데 무리는 없을까요?

 

MVP

고객 - 실제로 사용해보니 어떤가요? 문제가 해결되었나요? 돈을 지불할만큼 가치가 있나요?

프로덕트팀 - 일단 핵심페이지/기능만 디자인/개발합시다.

 

MVP 이후

고객 - 피드백 해주신 사항을 반영했어요. 좋아해줄만한 기능을 추가했어요.

프로덕트팀 - wow 포인트 위주로 디벨롭합시다. 점점 고도화시켜봅시다!