Intercom이 프로덕트 팀을 확장하며 배운 것들
의사결정 가이드라인, 책임 리스트, 로드맵 관리, 목표 설정 문화
비즈니스 메신저 소프트웨어는 기업이 고객과의 더욱 효율적인 채팅 상담을 할 수 있게 돕는 B2B SaaS 제품이다. B2B SaaS (Software as a Service)란 사업을 운영하는 기업을 고객으로 한 서비스형 소프트웨어를 말한다.
2014년에 설립된 국내 기업 '채널코페레이션'의 비즈니스 메신저 프로덕트로는 '채널톡'이 있다. 국내의 웹사이트 우측 하단에 채팅 상담 기능이 있는 저런 인터페이스를 본 적이 있다면, 채널톡을 사용하는 기업일 확률이 높다.
채널톡 홈페이지미국 샌프란시스코에 본사가 있는 'Intercom'은 2011년에 창립해서, 해외에서 비즈니스 메신저 소프트웨어를 제공하는 기업이다. 인터컴의 비즈니스 메신저에 대한 여러 프로덕트들은 홈페이지에서 더 확인할 수 있다.
Intercom 홈페이지 - Products예전에 부트캠프를 통해 접한 글을 이제야 읽게 돼서 배울 점을 정리하고 싶었다. Intercom이 어떤 프로덕트를 만드는 팀인지 대략 알면, 글에 몰입이 더 잘 되지 않을까 싶어서 찾아봤다. 한국의 기업이 해외의 프로덕트에서 좋은 영향을 받아, 한국 시장과 고객사의 특성, 니즈에 맞는 더 나은 서비스를 제공한다 점이 좋아서 두 기업에 대해 간단히 소개했다.
WHAT
Intercom이 프로덕트 팀을 확장하며 배운 점 4가지
1. 의사결정 가이드라인
2. 명확한 책임 리스트
3. 가볍고 명확하며 종합적인 로드맵
4. 목표 설정 문화
HOW
Intercom에서 2015년 11월에 게시한 블로그 포스팅 "What we learned from scaling a product team"을 요약했다. 중복된 내용은 최대한 줄이고, 원본을 읽고 이해한 만큼 의역했다.
WHY
인터컴이라는 기업이 2015년 당시에 어느 정도 궤도에 올라 확장하는 단계에서 직접 겪으며 배운 점을 답습하고, 배우고 적용해 볼 점을 찾아보자.
린 스타트업 같은 책과 구글 벤처스의 포스팅에는 소프트웨어 구축 방법이 많이 소개되어 있지만, 스타트업이 실제 어떻게 프로세스를 진행했는지 공개한 사례는 2015년 당시에는 많지 않았다. 2013년 스포티파이의 예시가 있긴 하다. 이런 공개된 실제 사례가 부족했기에, 인터컴은 초기 기업이 빠르게 성장하고 확장하는데 도움을 주기 위해 일하는 방식을 공유했다. 12~18개월 동안 점진적인 개선과 대규모 개편으로 수십 차례 배포하는 과정에서 배웠던 제품을 가능한 한 빨리 출시하는 방법 4가지를 소개한다.
소개하기 앞서, 이런 점을 고려하자.
이 프로세스가 모든 회사에 적합하진 않다. 회사의 문화가 모두 다르기에 일하는 방식도 다를 것이다. 완벽한 과정을 소개한 것이 아니며, 어떤 방법이든 지속적으로 반복하며 개선해 간다.
초창기 팀이나, 안정적인 큰 규모의 팀과 같이 규모에 따라 적절한 방법이 아닐 수 있다.
그럼에도 불구하고 일하는 방식을 공유함으로써, 어떤 시행착오를 겪고 배웠는지 개선해 가는 것과 과정이 중요하다.
1. 의사결정 가이드라인
1-1. 프로덕트 팀의 성장을 위해서 구성원의 일치된 생각과 결정을 돕는 가이드라인이 필요하다.
작은 단계의 잦은 릴리즈가 큰 규모의 적은 릴리즈보다 낫다. 목표 달성 과정에 무엇이 작동하는지 배우기 위해, 가장 빠르고, 작게, 그리고 간단하게 전달하기 위해 항상 최적화한다. 모든 프로젝트는 고객 가치를 전하며, 작고 독립적인 릴리즈에 초점이 맞춰져 있다. 모두들 더 빨리 시도하고, 중요하지 않은 것에 시간을 덜 쓰기 위해 구성원들이 범위를 줄이고 간단하게 만든다.
1-2. 일일 목표와 주간 목표를 세운다.
인터컴은 놀라운 기회를 발견했지만, 이는 시간과의 싸움이었다. 하루하루가 중요하다. 팀에는 일일 목표와 일일 목표로 세분화된 주간 목표가 있다. 모든 구성원은 하루를 시작할 때 그날의 목표가 무엇인지, 팀의 주간 목표와 어떤 관련이 있는지, 그리고 무엇이 릴리즈 되는지 알아야 한다.
1-3. 대면 협업을 위해 최적화한다
대면이 더 빠르다고 믿는다. 화이트보드에 있는 두 사람은 어떤 환경보다 더 빠르게 더 많은 아이디어를 내고 합의에 도달한다. 원격 작업은 많은 일에 유용하긴 하지만 의사결정 속도와 효율성에는 적합하지 않다. 그런 이유로 프로덕트 팀은 모두 하나의 사무실에 함께 앉아 있고, 직접 대화할 수 있으면 그렇게 해야 한다는 원칙이 있다.
1-4. 일을 위한 일에 맞서 싸운다.
소프트웨어를 사용하여 소프트웨어를 구축하는 것은 종종 화이트보드와 포스트잇, 노트를 사용하는 것보다 느리다. 가벼운 프로세스를 넘어서, 작업 완료를 위해 최소한의 소프트웨어 툴을 사용한다. 비슷한 기능의 여러 서비스를 모두 사용하고 관리하는 건 무언가 잘못된 것이다.
1-5. 계획보다 결과가 훨씬 중요하다.
계획을 세우는 건 성공에 매우 중요하지만, 계획대로 되는 건 없다. 계획은 계획을 세우는 당시에 활용 가능한 정보로 만들어지지만, 계획을 실행할 때 완전히 명확해진다. 최고의 팀은 새로운 정보를 흡수하고 반응을 확인한다. 이는 끊임없이 변화하는 환경에서 계획을 실행하는데 창의적이고, 같은 시간에 같은 결과에 도달하기 위해 싸운다.
2. 명확한 책임
인터컴은 프로덕트 매니저, 프로덕트 디자이너, 엔지니어링 리드와 2~4명의 엔지니어로 구성된 프로덕트 팀으로 일한다. 그렇기에 각자의 책임이 명확해야 하기 때문에, 어떤 경우에 누가 책임을 져야 하는지, 어떻게 책임을 다해야 하는지 리스트가 있다. 프로덕트 팀으로 일할 때 책임의 영역이 불분명한 상황이 있는데, 이는 각자가 스스로 해결하기 위해 노력하기 때문에 협업으로 더 나은 결과를 이끌기도 한다.
프로덕트 매니저 (PM)
해결해야 할 문제의 분석이 틀렸으면, 적절한 조사가 되었는지 다시 확인한다.
너무 많은 버그나 잘못된 사용 사례가 있는 경우, 세부적인 테스트 케이스를 세우고 현실적인 사용 테스트를 한다.
프로덕트 팀에서 일이 어떻게 진행되고 있는지 모른다면, 성공 기준이 어떻게 정의되고 구성됐는지 확인한다.
문제가 해결되지 않으면, 문제를 완전히 해결하지 못하는 제품 변경 사항을 개선할 계획이 있는지 확인한다.
프로덕트 디자이너
디자인 문제를 해결하지 못한 경우, 이해와 리서치, 문제를 다시 확인한다.
디자인 문제를 해결하지만 인터컴에 적합하지 않은 경우, 신념과 원칙, 패턴을 이해했는지 확인한다.
엔지니어
엔지니어링 설계가 늦게 제공될 경우, 코드 작성 전에 해결하려는 문제를 먼저 이해하고 나서 정확하게 설계한다.
로드맵에 따른 새로운 가치를 주지 않는 버그 수정에 팀이 너무 많은 시간을 할애할 경우, 각 프로젝트에서 전반적으로 코드 품질을 개선하고 있는지 확인한다.
3. 가볍고 명확하며 종합적인 로드맵
로드맵은 앞으로 몇 달간 진행할 계획이고, 세 가지 기간이 있다.
4-6주는 계획된 확실한 배포를 한다.
다음 단계의 문제와 기회를 바탕으로, 이어지는 몇 달을 계획한다.
몇 달 후에는 미션에 대략 일치하는 아이디어를 낸다.
3-1. 팀에서 나온 모든 아이디어는 PM이 관리하고 팀이 정식으로 검토하는 목록에 넣는다. 로드맵은 세 가지 주요 소스에서 가져온다. 팀이 신뢰하는 것은 프로덕트 리드 팀의 특정 의견에서 나온 자료보다 프로덕트 팀을 기반으로 한 아이디어이다.
3-2. 양질의 고객 피드백은 세 가지이다.
3-2-1. 리서치 팀의 연구와 PM과 고객의 대화로부터 나온 요청된 피드백으로, 인터컴의 PM은 고객과 대화한다.
3-2-2. 프로덕트를 통해 받은 요청되지 않은 피드백이 있다. 매주 수백 개의 의견에 고객 전담 팀이 태그를 지정하고, PM이 검토해서 향후 개발할 계획 리스트에 추가하고, 일부는 로드맵에 추가한다.
3-2-3. 영업 팀에서 기록한 대화 노트를 PM에게 공유하여, 영업에서 만난 사람들이 전달한 문제를 공유한다. 전달받은 문제가 해결됐는지 확인하기 위해 영업 팀과 제품 리더가 매월 로드맵을 검토한다.
3-3. 현재 제품의 퍼포먼스에 기반한 정략적 데이터
모든 프로젝트에 정의된 성공 지표
프로덕트 팀 단계의 성공 지표
프로덕트 전략 테마
인터컴에는 그 당시 8가지 테마가 있었다. 주제를 전달하기 위해 각각의 게시판을 만들어 사무실 벽에 걸었다. 각 게시판에는 제목과 왜 그것을 중요하다고 생각하는지 설명하는 섹션, 우리가 다루고 있는 문제, 문제가 우리에게 제공하는 기회, 예시 개념 스케치가 있다.
팀 목표
각 프로덕트 팀에는 달성하는 데 몇 달이 걸리는 전략적 목표가 있고, 제품 전략을 형성하는 것들에 큰 배팅을 한다.
프로젝트 브리프 (인터미션)
인터미션은 프로젝트 브리핑 문서 이름이고, 이는 PM의 책임이다. 한 페이지 미만으로 제한되며 우리가 해결하고 있는 문제, 성공을 측정하는 방법, 프로젝트 범위를 간단하게 다뤄야 한다. 솔루션은 나중에 나오므로 솔루션을 포함하지는 않는다. 인터미션 문서의 목표는 우리가 만들고 있는 것과 그 이유를 공유하는 것이다.
로드맵 (트렐로)
짧은 릴리즈 주기(1일~2주)로 매우 빠르게 움직이기 때문에 최대 5~6개의 인터미션을 진행하고 10개 이상의 릴리즈를 한 번에 작업할 수 있다. 로드맵 정리는 트렐로를 사용하고 PM의 책임이다. 트렐로 카드에는 디자인 작업 링크가 포함되어 있다. 5개의 프로덕트 팀 카드 색상은 담당 팀을 나타낸다. 책임을 묻기 위해 한 카드에 한 팀만 릴리즈를 소유할 수 있다는 규칙이 있다. 과정 중 실패하면 빨간색 라벨을 추가해서 실패 패턴을 추적할 수 있다.
인터미션 카드 (트렐로)
각 인터미션은 트렐로 카드 안에 있다. 해당 카드는 인터미션 문서 및 해당 프로젝트 내의 릴리즈로 연결된다. 잊은 건 없는지 확인하기 위한 체크 리스트도 포함되어 있다. 때때로 일을 하지 않고 일부러 확인하는데, 체크리스트 확인을 위한 것이지 의무적인 건 아니다.
릴리즈 카드 (트렐로)
릴리즈에는 디자인 작업에 연결되는 트렐로 카드와 제품 및 디자인 결정을 설명하는 모든 지원 문서가 있다. 각 릴리즈 카드에는 디자인, 빌드, QA , 베타, 전체 릴리즈, 사후 릴리즈, 6개의 섹션으로 분류된 체크리스트도 있다.
'트렐로'라는 협업 소프트웨어에 대해 잘 알지 못하고, 너무 예전 버전이라는 점을 고려해서 이미지를 따로 첨부하지는 않았다. 이후에 트렐로라는 소프트웨어를 쓸 상황이 생길 때 이 부분을 다시 참고해야겠다.
4. 목표 설정 문화
주간 목표 태블로
집중력과 궤도를 유지하기 위해 각 프로덕트의 주간 목표를 설정한다. 로드맵으로부터의 배포를 위한 목표 매핑은 향후에 버그를 줄이고, 시스템 개선을 더 빨리 가능하도록 한다. 목표를 추적하기 위해 '허슬'이라는 내부 툴을 만들었다. 목표뿐만 아니라 트렐로 API를 통해 로드맵을 가져오고, 깃허브의 API를 통해 공개 버그 요약을 가져온다. 프로덕트 팀이 주간 목표를 설정하고 이에 대한 책임을 진다는 것이 중요하다.
일일 목표 화이트보드
주간 목표 달성을 위해 개인은 일일 하위 목표를 갖고 있다. 매일의 목표가 중요하다는 생각을 강화하고, 각 프로덕트 팀의 일일 목표를 추적하기 위해 화이트보드를 사용해서 매일 아침 스탠드업 미팅을 한다.
주간 데모
매주 금요일 오후 5시에 구성원들은 식당 큰 화면 앞에 맥주를 들고 모두 모여, 엔지니어들은 그 주에 작업한 내용을 시연하며 팀의 믿음을 강화한다. 팀은 시간과 경쟁하고 있으며, 모든 것이 일주일 이내에 구축할 수 있는 단계로 세분화되어야 한다.
지금까지 정리한 4가지 프로세스는 현재 바뀌었을 것이다. 프로덕트 팀은 지속적으로 프로세스를 검토하고 반복하며 매주 새로운 걸 배운다. 프로세스는 팀이 지금까지 실패하고 시도하며 어렵게 배운 교훈의 결과다. 빠른 변화의 시대에 빠르게 성장하는 회사에서 제품을 구축하는 것은 아주 어렵다. 이런 과정은 일하는 방식에 반영하고 개선하는 데 도움이 될 것이다.
원본을 읽고 무려 8년 전의 글임에도 배울 점이 많다고 느꼈다. 코로나 이전의 글에서 대면 협업의 중요성을 언급한 부분이 기억에 남는다. 코로나 시기에는 이 팀이 어떤 방식으로 일했을지 궁금하다. 현재 온라인 협업에 도움을 주는 소프트웨어 툴이 많이 나오고 발전했지만, 그럼에도 코로나 이후 국내 많은 IT 기업들이 다시 대면 업무로 돌아오고 있는 걸 보고 그런 생각이 들었다.
원본의 글에서 전반적으로 인상적이었던 점은 프로덕트 팀이 실제로 적용해 볼 수 있는 구체적인 방법을 설명해 줬다는 것이다. 마지막으로, 배운 점을 한 문장으로 적어보면, 프로덕트 팀에서의 혁신은 깊이 있는 단순화에 기반한 반복적이고 빠른 계획과 실행이다.
참고 자료
