좋은 프로덕트 팀과 나쁜 프로덕트 팀 17가지
프로덕트 팀의 지향점을 찾아가자
본론이 가장 궁금하다면 맨 밑으로! "앞으로 계속 말하게 될 '프로덕트'는 무엇일까?"와 "'프로덕트'와 '제품' 두 단어를 왜 혼용해서 사용하고 있을까?"는 서론인데, 서론이 길어서 지칠 수도 있으니 무시하고 아래로 넘겨도 괜찮다.
앞으로 계속 말하게 될 '프로덕트'는 무엇일까?
채용 공고나 블로그 글을 보면 프로덕트 팀, 프로덕트 디자이너, 프로덕트 매니저 등 프로덕트라는 단어를 흔하게 볼 수 있다. ‘product’는 생산물, 상품, 제품, 결과물 등의 뜻을 갖고 있다. 보통, ‘제품’이라는 단어를 이미지로 먼저 떠올리면, 손으로 만질 수 있는 가전제품, 전자제품과 같은 하드웨어 제품이 먼저 생각날 수도 있다. 반면, IT 기업에서의 제품은 우리가 온라인에서 이용하는 서비스, 웹, 앱, 컴퓨터 프로그램 등과 같은 소프트웨어 제품을 말한다. 앞으로 주로 다룰 내용에서는 후자의 개념을 떠올리면 의미가 잘 와닿을 것이다.
개인적으로 이해한 IT 기업의 프로덕트 개념을 토스를 예시로 생각해 보자. 초창기의 송금 기능만 있을 때부터 지금의 수많은 서비스가 하나의 앱에서 제공되기까지, 토스 앱 자체를 하나의 프로덕트로 볼 수 있다. 앱에 들어가 좀 더 나눠보면 은행, 주식, 페이 등 핵심 서비스들을 각각 하나의 프로덕트로 보기도 한다. 더 세부적으로 들어가서 토스 앱 우측 하단에 ‘전체’를 보면, 수 십 가지의 기능, 서비스를 각각의 프로덕트로 볼 수도 있다.
IT 스타트업부터 토스처럼 커진 기업까지 여러 프로덕트(기능, 서비스)들이 실험되고 성장하거나, 실패해서 사라지기도 한다. 그렇다고 해서 토스라는 프로덕트 자체가 실패하는 건 아니다. 실패는 가설-실험-검증을 통해 프로덕트가 성장하는 과정이다. 잠깐 다른 주제로 이야기가 셌는데, 실제로 프로덕트를 성장시키는 과정에 대해서는 앞으로 실제 일을 하며 더 깊이 있게 배워야겠다.
'프로덕트'와 '제품' 두 단어를 왜 혼용해서 사용하고 있을까?
이번 글에 인용한 '인스파이어드'는 테크 기업들의 제품 개발에 관한 교과서 같은 책이다. 기획자에게 필독서로 알려져 있다. 정석적으로 도움 되는 내용이 많아서 좋았지만, 읽으면서 왠지 모르게 약간 재미 없어지고 지치게 돼서 교과서 같다고 하는 건 아닐까?
이 책에서는 프로덕트를 ‘제품’으로 번역해서 사용했다. 반면에, 인터넷 해외 자료를 통해 용어와 개념을 접해서 일에 적용하는 경우도 점점 많아졌다. 그렇다 보니, 자연스럽게 팀 내에서의 영어를 많이 쓰게 된 것 같다. 외국인 팀원이나 사용자가 있다면, 기본적으로 영어로 통일하는 게 더 효율적일 것 같아서, 개인적으로는 영어를 더 선호한다.
글에서 의미가 중복되는 여러 단어를 써서 올 수 있는 독자의 혼란을 줄이기 위해, 최대한 용어의 통일성을 지키려고 노력했다. 예를 들어, 프로덕트 매니저와 제품 관리자는 같은 의미인데, 처음 개념이 시작된 용어인 프로덕트 매니저로의 사용을 지향했다. 혹은, 용어나 맥락에 따라 한국어로 사용하는 경향이 있다면 그에 따르거나, 가독성이 더 좋은 걸 선택할 것이다. 갑자기 든 생각인데, 축구에서 공격수, 수비수는 한국어고, 미드필더, 골키퍼는 왜 외래어로 쓰이는 걸까?
서론이 정말 길었는데 이제 본론을 시작하면, 이 글에서는 축구팀이 아니라 프로덕트 팀에 대해 얘기하려고 했다. 프로덕트를 만드는 팀은 어떤 사람들로 구성되어 있을까? 좋은 프로덕트 팀과 나쁜 프로덕트 팀의 차이는 무엇일까? 좋은 프로덕트를 만들기 위해, 좋은 프로덕트 팀은 어떻게 만들 수 있을까?
WHAT
프로덕트 팀의 구성원
좋은 프로덕트 팀과 나쁜 프로덕트 팀 17가지
HOW
프로덕트 팀의 구성원은 블로그 글을 인용해서 간단히 요약했다.
좋은 프로덕트 팀과 나쁜 프로덕트 팀은 책 ‘인스파이어드’로부터 내용을 얻고 정리했다.
WHY
좋은 프로덕트 팀을 만들기 위한 방향성을 공유하고, 팀이 최소한의 룰을 정해야 되는 상황에서, 이를 바탕으로 논의해 보면 어떨까.
프로덕트 팀의 구성원
프로덕트 팀의 구성원은 기본적으로 기획자, 디자이너, 개발자로 되어있다. 디자이너, 개발자가 기획을 잘한다면, 기획자가 필요 없게 되는 걸까? 팀마다 사람마다 생각이 다를 것 같은데, 의견이 궁금하다. 그렇게 되지 않기 위해서, 당연한 얘기지만 디자이너, 개발자 보다 기획을 잘하려고 노력해야겠다. 팀 내에서 자신의 차별점과 강점을 꾸준히 보여주고 실력을 키워야겠다.
기획자는 디자이너, 개발자가 각 역할에 몰입할 있도록, 주로 사용자 관점에서 기능을 기획하고, 일의 우선순위를 정한다.
디자이너는 사용자 경험(UX)을 고려하여 사용자가 앱을 편하게 사용할 수 있도록, 화면에 시각적으로 보이는 UI를 디자인한다.
개발자는 기획과 디자인을 바탕으로 실제 작동하는 앱이나 웹 등으로 서비스를 구현하고, 안정적으로 운영될 수 있도록 기술적인 유지, 보수를 한다.
이외에도 더 많은 일들이 프로덕트 팀에서 서로 유기적으로 이뤄진다. 기업, 혹은 팀에 따라 애자일, 워터폴 무엇이든 팀의 일하는 방식은 세부적으로 다 다를 것이다. 아래 이미지는 일반적으로 프로덕트 팀의 두 가지 형태와 이를 합쳐서 활용한 형태를 소개한다.
역할 중심의 조직 구조, 주로 워터폴 방식으로 일한다.
제품 중심의 조직 구조, 주로 애자일 방식으로 일한다.에이블리의 프로덕트 팀은 제품 중심의 '스쿼드' 팀으로 주로 제품을 개선하면서, 같은 직군의 동료들과 노하우를 공유하거나 교류하며 성장할 수 있는 '챕터'를 동시에 활용하고 있다.
기획자, 디자이너, 개발자가 함께 어떻게 일하는지, 애자일, 워터폴이 구체적으로 어떤 방식인지는 이 글에서 다루지 않았다. 그보다 더 근본적으로 프로덕트 팀이 추구해야 할 지향점을 찾아보자. 이번 글에서는 아래와 같이 용어를 통일했다. 개인적으로 후자의 표현을 더 선호하는데, 가독성을 고려해 전자로 썼다.
기획자 = 프로덕트 매니저, 디자이너 = 프로덕트 디자이너, 개발자 = 엔지니어, 제품 = 프로덕트
우리 팀이 좋다, 나쁘다 흑백논리로 따지기 위해 이 글을 쓴 게 아니다. 아직 프로덕트 팀에서 일한 경험이 없는 입장에서 앞으로 만약 프로덕트 팀에서 일한다면, 구성원들과 우리 팀이 이런 점은 잘 되고 있고, 이런 점은 아쉽다는 걸 서로 얘기해서 좋은 건 강화하고, 부족한 건 개선하자는 목적이 가장 크다. 아마도 가장 좋지 않은 프로덕트 팀은 이런 주제에 대해 냉소적이거나 대화할 의지가 없는 팀이지 않을까 생각이 든다. 매일 이런 주제로 얘기할 순 없지만, 팀이 주기적으로 함께 돌아보는 과정이 있다면 팀으로 성장할 것이다.
에이블리 팀의 프로덕트 조직좋은 프로덕트 팀과 나쁜 프로덕트 팀 17가지
파랑, 빨강으로 쓴 내용은 책 '인스파이어드'에서 인용했다.
- 좋은 프로덕트 팀
- 나쁜 프로덕트 팀
- 개인적인 의견 : 어떠한 노력을 하면 좋을지 고민하며 적었는데, 잘 못 이해했을 수도 있다. 경험 많은 분들의 다른 의견이 정말 궁금하다.
1
좋은 팀은 강렬한 제품 비전에 열정을 갖고 있다.
나쁜 팀은 용병 같은 팀이다.
팀이 제품으로 달성하고자 하는 비전과 미션에 공감하고 있는지 확인해 보자.
2
좋은 팀은 비전과 목표, 고객 불편 관찰, 제품을 사용한 고객들의 데이터 분석, 문제를 해결하기 위해 새로운 기술을 끊임없이 탐색하는 과정을 통해 영감과 제품 아이디어를 얻는다.
나쁜 팀은 영업과 고객으로부터 요구사항을 수집한다.
고객이 원하는 걸 그대로 만들어주는 팀인지, 고객의 문제를 파악해서 근원적으로 해결해 주는 걸 만드는 팀인지 고민해 보자.
3
좋은 팀은 핵심 이해관계자들과 제약 사항을 잘 알고 있다. 이를 통해 사용자와 고객에게만 효과적인 솔루션이 아닌, 비즈니스 제약 조건 속에서도 유효한 솔루션을 찾아내는 데 최선을 다한다.
나쁜 팀은 이해관계자로부터 요구사항을 수집한다.
특정 사람에게만 유효한 방안인지, 특정 상황에 처한 사람들에게 유효한 방안인지 고민해 보자.
4
좋은 팀은 어떤 아이디어가 진정으로 만들 만한 가치가 있는지를 결정하기 위해 빠르게 제품 아이디어를 시도해 볼 수 있는 많은 기법에 능숙하다.
나쁜 팀은 우선순위 로드맵을 만들기 위해 미팅을 진행한다.
빠르게 만들고, 시도하고, 개선하며 로드맵을 그리자.
5
좋은 팀은 회사 전반에 걸쳐 현명하고 사려 깊은 리더들과 브레인스토밍 토론을 즐긴다.
나쁜 팀은 외부의 누군가가 팀에 제안할 때 방어적인 자세를 취한다.
아이디어가 좋든지, 별로든지, 내부의 아이디어든지, 외부의 아이디어든지 잘 듣고, 기록하고, 시도해 보자.
6
좋은 팀은 기획자, 디자이너, 개발자가 함께 모여 앉아서, 기능성, 사용자 경험, 가용 기술에 대해 서로 주고받으며 포용한다.
나쁜 팀은 각자의 소속 자리에 앉아서, 문서를 통해 업무를 요청하고 미팅을 잡아달라고 다른 사람에게 요청한다.
서로 다른 역할이더라도 같은 목적을 갖고 제품에 대한 고민을 허울 없이 이야기하자.
7
좋은 팀은 혁신을 위한 새로운 아이디어를 끊임없이 시도하면서도 매출과 브랜드를 지키는 방법을 늘 고려한다.
나쁜 팀은 아직 테스트를 실행하기 위한 권한을 기다리고 있다.
빠른 시도와 성장을 위해 팀의 매출과 브랜드를 고려해서 개인이 많은 권한과 책임을 갖고 시도하자.
8
좋은 팀은 이기는 제품을 만드는 데 필요한 능력을 팀 스스로 갖추기를 고집한다. 예를 들어, 뛰어난 디자이너를 보유하는 것이다.
나쁜 팀은 디자이너가 무슨 일을 하는 사람인지조차 모른다.
좋은 팀원이 되기 위해 능력을 갖추고 꾸준히 배우자. 그리고 팀원이 무엇을 잘하는지 알고 시너지를 내자.
9
좋은 팀은 개발자가 제품 발견을 위한 프로토타입을 만들어 볼 수 있는 시간이 있는지 매일 확인한다. 그래서 제품을 만드는 더 나은 방법을 생각하고, 그들의 생각을 실행해 볼 수 있다.
나쁜 팀은 스프린트 미팅에서 개발자에게 프로토타입을 보여 주며 추정하려고 한다.
프로토타입을 미팅에서 언제까지 만들 수 있는지 추정하기보다, 꾸준히 진행 과정을 확인하고 조율해서 만들어 가자.
10
좋은 팀은 최종 사용자 및 고객과 매주 직접 만난다. 그리고 최신 아이디어에 대한 고객들의 반응을 확인한다.
나쁜 팀은 그들 자신이 고객이라고 생각한다.
내가 고객이었다면 어땠을까 가정만으로 판단하지 말고, 실제 고객의 의견과 반응으로 판단하자.
11
좋은 팀은 기대했던 아이디어들이 결국 고객에게 효과가 없을 수도 있다는 것을 알고 있다. 심지어 검증된 아이디어조차도 희망하는 성과가 나오는 수준이 되려면 여러 번의 반복이 필요하다는 것도 잘 알고 있다.
나쁜 팀은 그저 로드맵에 있는 것들을 만들면서 품질을 만족하고 일정을 준수하는 것에 만족한다.
기대한 아이디어가 실패할 수도 있다고 마음먹자. 검증된 아이디어라도 꾸준히 개선하자.
12
좋은 팀은 속도의 중요성과 빠른 반복이 혁신의 핵심임을 이해하고 있다. 그리고 이러한 속도는 일의 양이 아닌 올바른 기법을 사용하는 것에서부터 시작되는 것임을 안다.
나쁜 팀은 그들의 동료가 충분히 최선을 다하지 않는 것이 속도가 느린 원인이라고 불평한다.
빠른 속도와 반복적인 개선이 혁신에서 중요하다. 팀의 속도가 느려졌다면, 사람의 문제를 찾기보다, 방법에서 문제의 원인을 찾자.
13
좋은 팀은 요청된 업무를 진단하고 고객과 비즈니스에 유효한 솔루션을 가지고 있다고 확신했을 때 높은 신뢰 수준의 약속을 한다.
나쁜 팀은 영업 중심의 회사라고 불평한다.
비즈니스 솔루션에 확신을 갖고, 고객에게 높은 신뢰를 주자.
14
좋은 팀은 분석 도구를 업무에 활용한다. 데이터를 근거로 그들의 제품이 어떻게 사용되는지를 즉시 이해하고 필요한 경우 수정을 진행한다.
나쁜 팀은 분석 정보와 리포트를 있으면 좋은 것 정도로 여긴다.
데이터 분석 도구를 활용하고 이를 근거로 제품을 개선하자.
15
좋은 팀은 연속적인 소스 코드 통합과 출시를 실행한다. 지속적으로 작게 출시하는 흐름이 고객들을 위해 훨씬 더 안정적인 솔루션을 제공한다는 것을 알고 있다.
나쁜 팀은 고통스러운 통합 단계의 마지막에서야 수동으로 테스트하고 한꺼번에 출시한다.
작은 규모더라도 짧은 주기로 지속적으로 출시하자.
16
좋은 팀은 그들의 고객에 집착한다.
나쁜 팀은 경쟁자에 집착한다.
경쟁자를 파악하는 것도 중요하지만, 제품을 사용하는 고객에 더 집중하자.
17
좋은 팀은 비즈니스 성과에 유의미한 영향을 만들어 냈을 때 서로 축하한다.
나쁜 팀은 마침내 뭔가를 출시했을 때 서로 축하한다.
기능을 출시하고 유의미한 비즈니스 성과가 생겼을 때 축하하자.
개인적인 의견은 팀이 더 좋아지기 위해 어떻게 생각하고 행동하면 좋을지, 어떻게 하면 쉽게 생각하고 적용할 수 있을지 고민해서 간단히 적었다. 같은 글을 읽더라도 상황과 맥락에 따라 다르게 받아들여지거나, 다른 생각이 들어도 좋다. 좋은 팀이 되기 위한 목적과 의도를 명확하게 하고 소통해야겠다.
앞으로 글의 주제와 방향성은 좋은 팀을 만들어가기 위해 어떤 기법들을 활용하면 좋을지, 실제 사례나 케이스 스터디와 같이 방향으로 다루려고 한다. 좋은 팀을 만드는 좋은 기획자가 되기 위해 필요한 실제로 쓸모 있는 역량과 기술을 쌓아가자. 자신과 팀의 장단점을 스스로 고민하고, 공감을 이끌어 개선할 수 있도록 먼저 노력하자.
이미지 출처
참고 자료
마티 케이건 - 인스파이어드 | 357-360p | 제이펍 - 2018년
