by
Oct 08. 2023
#18 Airbnb에서 PM을 없애버렸다고는 하지만
2023년 40주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/60
다음 회고 ☞ https://brunch.co.kr/@327roy/67
노트
#1 Airbnb에서 PM을 없애버렸다고는 하지만
#PM #기획자 #역할 #제품
9월 중순에 PM/기획자 커뮤니티에서 꽤나 핫했던 아티클이 있다. 제목은 '브라이언 체스키가 Airbnb에서 PM을 없애버린 이유’. Airbnb에서 PM 직무를 없애고 조직을 재편성한 것과 관련된 얘기다.
‘기획자-디자이너-개발자’로 구성된 팀 형태가 IT 제품 개발을 위해 가장 보편적인 조합으로 사용되고 있는데, 그중 기획자 역할을 함께 수행하는 PM을 없앤다니!
하지만 실제로 아티클을 읽으면 아래 두 가지 내용을 알 수 있다.
1. PM이라는 직무를 없앤 것뿐, PM이 맡고 있던 역할은 재분배되었다.
2. 디자이너 출신의 CEO와 ‘디자인 중심 제품 경영’이라는 특성이 크게 작용했다.
결국 제품이 만들어지고, 운영되는 것에 필요한 역할의 총량은 변하지 않는다는 것을 다시 한번 생각할 수 있다.
애자일/워터폴 개발 방법론을 막론하고, 제품이 만들어지고 운영되기 위한 공통 과정을 말하면, 대표적으로 ‘제품 컨셉/로드맵 설계’, ‘화면 설계’, ‘세부 정책 설계’, ‘화면 디자인’, ‘프론트엔드/백엔드 개발’, ‘마케팅’, ‘영업’, ‘고객 관리’가 있다.
더 세분화하면 개발에서 ‘퍼블리셔, 데브옵스’가 떨어져 나올 수 있고, 마케팅에서 ‘브랜딩, 퍼포먼스 마케팅, 콘텐츠 마케팅 등’이 파생되어 나올 수 있으며, 영업에서는 ‘인바운드, 아운바운드 영업’, 디자인의 경우 ‘그래픽 디자인, 콘텐츠 디자인, 웹/모바일 디자인’이 파생될 수 있다. 이후 축적되는 데이터를 만지며 혹은 만지기 위해 ‘그로쓰 마케팅, 그로쓰 해킹, 데이터 엔지니어링, 애널리스틱’ 등이 파생되어 나오며, 언젠가는 보안을 위한 ‘정보보호’ 역할이 따로 생길 수 있다.
결국 서비스 기획자, 디자이너, 개발자 등의 직무는 이미 제품을 만들고 운영하기 위한 역할이 ‘그룹핑’된 것일뿐이지, 직무가 사라지거나 통폐합된다고 그 직무를 구성하던 역할 자체가 사라지는 것은 아니다.
즉, 역할의 총량은 변하지 않는다는 것. 누군가는 결국 기존 PM이 수행하던 기획을 할 것이고, 제품을 만드는 과정 속 디자이너의 여러 권한이 강화된 것이다.
결국 우리는 제품을 잘 만들기 위해 모인 사람들이며, 이 때문에 정성 직군들(특히 PM)은 간학문적인 지식을 쌓아야 한다고 생각한다.
하지만 언젠가는 개발이나 데이터 분야처럼 학문적으로 디깅Digging할 필요도 있을 것이다.
https://maily.so/josh/posts/104733c1
https://maily.so/josh/posts/0f2f4229
#2 기획의 추상화 과정
#추상화 #귀납 #연역
개발자와 협업을 할 때 자주 듣는 단어 중 ‘추상화'라는 것이 있다.
이전에 개발 리더분과 얘기하며 개발 업계에서 사용하는 이 단어의 의미를 들은 적이 있지만, 그땐 느낌만 알뿐 개념을 내재화하지는 못한 터여서 이번에 따로 정리했다.
일단 원래 내가 알고 있던 추상화는 예술계에서 ‘특정 사물, 개념을 인지할 수 있을 정도의 본질만 놔두고 덜어내는 것 혹은 표현하는 것’이다.
위키피디아에서는 추상화를 ‘여러 가지 사물이나 개념에서 공통되는 특성이나 속성 따위를 추출하여 파악하는 작용, 구체적인 것을 감추고 보고 싶어 하는 전체적인 특성을 드러내는 것’이라고 설명하고 있다.
개발자들이 말하는 추상화도 이와 비슷한 맥락인데, 그들에게 추상화란 ‘현실 세계에서 존재하는 모든 사물의 공통점(공통 기능 등)을 유추해서 그룹(Class를 만들어내는) 일련의 과정’을 의미한다.
예를 들면 [토끼, 치타]와 같은 각 ‘객체’를 ‘동물’이라는 공통 특징으로 추상화(그룹핑)하는 것이 있다.
추상화 예시 ⓒ 위키피디아그러면 기획 관점의 추상화는 뭘까? 이 또한 결국 ‘어떤 현상, 상황, 개념 등의 본질을 기준으로 재정의하는 것'이라고 할 수 있다. 책 줄거리를 요약하는 것부터, 기획으로 해결하기 위한 문제를 정의하는 과정까지. 본질을 남겨두고 정제하는 모든 과정이 추상화인 것이다.
이때 추상화에 어떻게 접근할 수 있을까? 우리가 일반적으로 문제나 개념을 정의하는 것을 생각해 보자. 크게 1) 귀납적으로 접근하는 방법과 2) 연역적으로 접근하는 방법이 있을 것이다.
1. 귀납적 접근 방법: 관찰된 사실, 경험을 통해 공통된 개념(패턴)을 도출한다.
2. 연역적 접근 방법: 특정 사실, 경험을 기준으로 여러 개의 개념(패턴)을 도출한다.
예를 들어 사용자가 서비스 내 멤버십 구독을 위한 일련의 프로세스를 모두 펼쳐놓고 이탈률과 같은 데이터를 확인해 봤을 때, 프로세스의 모든 단계(퍼널)에서 ‘빠르게 결제 정보를 등록하기 힘들다’는 문제를 정의했다고 하자. 이것은 귀납적으로 접근하여 문제를 추상화한 것이라고 할 수 있다.
이후에 우리는 연역적으로 접근하여 ‘간편결제 도입’, ‘결제 정보 입력까지의 프로세스 개선’ 등, 해당 문제를 개선할 수 있는 과제(백로그)들을 도출하며 사고를 확장할 수 있다.
결국 추상화는 다양한 분야에서 중요한 역할을 한다. 복잡한 현상, 문제를 본질적인 요소로 단순화하는 것을 통해 우리는 더 효과적인 의사결정이나 실행, 소통을 할 수 있을 것이다.
▼ 레퍼런스
https://brunch.co.kr/@mobiinside/5546
https://brunch.co.kr/@exdesign/50
https://gzipblog.com/25
http://wiki.hash.kr/index.php/추상화_(프로그래밍)
#3 제품을 테스트하면서 확인하고 싶은 것
#테스터 #제품 #고객가치
HRD와 관련된 사내 프로젝트에 참여하게 되었다. 그룹 리더와의 목표 얼라인, 임원 심사 등 꽤 긴 과정을 거쳤고, 결국 나를 포함해 약 50명 정도의 구성원이 선발되었다. 참여자들 모두 성장의지가 가득한 것은 물론이고, 이후 자신들이 만들어야 하는 성과에 대해 진지한 사람들만 모인 상황이다. (나 또한 성과에 대한 고민을 함께 안고 참여했다.)
하루는 프로젝트와 관련한 여러 세션이 존재하는 워크숍을 진행했는데, 그중 기억에 남는 것이 있다. 바로 사내 버전으로 먼저 출시하는 제품을 소개하는 세션.
제품을 통해서 다른 기획자가 전달하려는 가치와 의도, 산출물을 확인하는 것도 좋았고, 내부 테스터로 참여하는 경험을 갖게 될 예정이어서 기대가 된다.
제품을 테스트하면서 추적하고 싶은 과정은 두 가지다.
1. 내부 구성원들로부터 인입된 VOC를 어떻게 처리하고, VOC 발의자에게 어떻게 피드백을 줄 것인가?
- 좋은 UX에서 항상 강조되는 말 중에는 '사용자 행위에 대한 피드백'이 존재한다.
- 당장 우리도 설문을 진행하거나 혹은 어떤 개선 의견을 낼 때, 내 의견이 수용되었는지와 같은 의문을 갖게 되고, 이 의문이 해소되지 않을 때 제품에 팬이 되기를 포기하게 되는 경우가 있다.
- 나 또한 곧 출시를 앞둔 제품이 존재하는 터여서 다른 기획자는 이 프로세스를 어떻게 처리할지 궁금하다.
2. 테스트 이후, 외부 고객들에게 가치를 '어떻게 잘' 전달할 것인가?
- 구성원들에게 제품의 가치를 전달하는 것은 외부 고객에게 가치를 전달하는 것보다는 쉬울 것이다. 필요하다면 밀착해서 알려줄 수도 있고, 강제로 쓰게 할 수도 있으니 말이다.
- 그렇다면 외부 고객에게 정말로 제품을 팔아야 할 때는 제품의 가치를 어떻게 잘 전달할 수 있을까? 테스트하는 제품이 내가 맡고 있는 제품의 성격과 다소 다르지만, 고객에게 가치를 전달한다는 맥락으로 놓고 보면 이 또한 좋은 선행학습이 될 듯하다.
#4 B2B SaaS 솔루션의 기획자로 지낸다는 것
#B2B #SaaS #기획자
나는 현재 B2B SaaS 솔루션을 제공하는 제품의 서비스 기획을 하고 있다.
이전 회사도 엄밀히 따지면 B2B였지만 SaaS까지는 아니었고, 수익 구조가 다각화되어 있던 만큼 지금 제품과는 성격이 많이 달랐다.
그래도 같은 B2B라는 맥락에서 비슷한 점은 세일즈팀의 목소리가 강하다는 것. 세일즈팀의 목소리는 고객의 목소리를 대변한다는 전제가 있기 때문이다.
SaaS 제품이기에 가지고 있는 특징도 있다. 대표적으로 '전용개발'. SaaS 제품들이 나오기 전에는 고객(기업)들이 ERP를 맞춤 외주개발하여 사용했기 때문이다. 특히 HR과 관련된 제품들이 그러하다. (인사관리 시스템, 채용 시스템, 평가 시스템, 회계 시스템 등)
ERP는 전사적 지원 관리 시스템을 의미한다. 자세한 것은 세계 1위 ERP 구축 업체, SAP에서 설명한 문서를 참고하는 것을 추천한다.
고객이 원하는 형상에 맞춰 주문제작을 하는 ERP와 달리 SaaS 제품은 다수의 고객을 대상으로 해야 하는 만큼 보편적인 기능을 제공한다. 그래서 제품이 고객의 니즈를 충족하지 못하는 경우가 등장하고, 이로 인해 고객으로부터 전용개발을 요청받게 된다.
예를 들어, 대기업을 상대할 때 따라오는 보편적인 이슈로는 보안이슈가 있다. 대기업의 보안 환경에 맞게 제품의 데이터를 처리하거나, 특정 기능에 제한을 두는 것 등.
전용개발의 장점은 고객의 니즈를 충족시킨다는 것(고객을 확보하는 것)이지만, 단점은 1) 전용개발을 요청하는 기업이 많아질수록 관리해야 하는 코드의 형상이 많아지고, 2) 요구가 많아질수록 메이커들에게 스트레스가 가해진다는 점이다. 관리해야 하는 중복 코드가 많아질수록 중복 작업이 많아지기 때문. 이는 개발자들의 동기를 저하시키기에 충분하다.
예전 외주 기획을 진행했을 때도 마찬가지만, 그래서 느낀 점은 계약서를 철저히 써야 한다는 것. 전용개발로 커버해 줄 수 있는 범위 등 전용개발에 대한 딜을 할 수 있어야 한다. 하지만 고객을 유치해 제품과 기업의 생존을 이어가는 것도 중요하기 때문에, 전용개발을 무작정 쳐내는 것도 불가능한 것이 현실이다.
고객이 전용개발을 요구하는 것도, 세일즈팀에서 전용개발 요청을 전달하는 것도 모두 이해하며, 마땅히 사용자를 위해 할 필요가 있는 것은 맞지만 그 적정선에 대한 고민은 항상 따라온다.
#5 개선의 재미(Ft. 토스)
#개선 #UX #토스
과거의 토스가 가입률을 향상하기 위해 '가입 과정의 UX'를 개선한 사례를 다룬 아티클을 읽었다.
인트로 메뉴를 없애도 보고, 권한 요구를 줄여도 보고, 갖가지 방법을 통해 해당 프로세스의 퍼널을 줄여보며 가설을 검증하던 것이 기억에 남는다.
특히 재밌었던 부분은 1) 고의적으로 사용자의 매몰비용을 빠르게 만드는 것과 2) UT를 통해 문제의 원인에 가깝게 접근한 것이었는데, 매몰비용을 전략적으로 사용하는 모습이 정말 인상 깊었다.
언젠가 사용해 볼 수 있는 전략을 하나 배웠다.
ⓒ Toss