Linear가 제품 개발하는 방법

아래는 Lenny's newsletter의 글을 읽고 요약 번역 및 개인 생각을 정리한 내용입니다.

리니어팀 소개

• 이슈 관리 툴을 만듬

• 역대 투자 받음 금액보다 훨씬 더 많은 현금 보유. BEP 넘긴지 2년 넘음.

• 유료 광고에 35k 달러 밖에 쓰지 않음.

• 현재 팀규모 50명

리니어팀이 일하는 방식

1. 리니어는 PM이 Head of product 한명 밖에 없다. PM의 일이 엔지니어링과 디자인 팀에 분산되어 잇다.

2. 기능별 팀이 없다. 예를 들어 Issue 관리 팀, Cycle 관리 팀이 따로 있지 않다. 프로젝트별로 팀이 형성 되었다가 끝나면 팀이 해체된다.

3. 지표 기반으로 목표를 세우지 않는다. 북극성 지표 하나만 있다.

4. A/B 테스트를 하지 않는다. Taste와 의견에 기반한 결정을 내린다.

5. 채용할때 1-5일 정도 팀에 합류해서 실제 프로젝트를 하는 기간을 갖는다.

6. 팀은 리모트로 일한다.

PM과 계획 세우는 과정

• 초기 파운더 3명만 일할때는 매주 계획을 세웠다. 유저 숫자를 늘리는데 가장 막히는 것이 무엇인지 파악하고 이를 해결했다.

• 현재는 50명이다. 프로덕트 팀은 한개만 있고 로드맵 또한 한개이다. 이렇게 하나로 유지하면서 모두가 전체 프로덕트에 대한 책임감을 갖고 어떻게 작동하는지 이해하고 있다.

• 계획은 파운더 및 소수 리더쉽 팀이 12개월 방향성을 세운다. 병렬적으로 전체 팀원들에게 설문과 투표를 받는다: 1) 현재 잘되고 있는 것, 2) 잘해야 되는데 못하고 있는 것, 3) 게임을 뒤엎을 정도의 일인데 안하고 있는 것, 4) 우리가 집착해야 되는 것, 왜?

• “ 큰 회사의 니즈에 집중“과 같은 전체 전략이 서면 개발 범위와 개발 순서를 정한다. 따로 우선순위를 세우기 위한 복잡한 랭킹 방식이나 투표 방식이 있지는 않다. 제품을 자주 사용하고 고객들과 시간을 많이 보내면 자연스럽게 우선순위가 떠오른다. 개발 순서는 최적의 길인지를 따진다.

• 프로젝트 계획을 세운 후 각 프로젝트 팀은 이에 대한 스펙을 짠다. 스펙은 로드맵에 추가된다.

• PM은 한명 밖에 없다. 팀 규모가 25명일때 채용 하였고 PM을 채용한 이유는 프로덕트 개발 전체를 관리할 사람이 필요해서였다.

• OKR을 쓰지는 않는다. “스타트업들의 기본 툴이 되자”, “xx개의 고객을 유치하자” 등의 전체 목표 하나 있다. 심플해서 팀을 더 하나로 얼라인 시키는데 도움이 된다.

• 각 프로젝트에 대한 지표적인 목표도 없다. 우리 같은 B2B 회사의 기능은 유저들이 받아들이는데 시간이 걸리기 때문에 지표적인 목표를 세우는 것이 도움이 안된다.

• Taste와 의견에 기반한 결정을 내린다. 인사이트를 얻기 위해 지표를 보긴 하지만 A/B 테스트를 하는 등 지표를 기반으로한 결정을 내리지는 않는다.

프로젝트 단위 팀

• 프로젝트 별로 팀이 만들어진다. 최대한 개개인의 강점을 살린 형태로 팀을 만든다. 예를 들어 프론트엔드가 정말 중요한 프로젝트 일경우 프론트엔드를 가장 잘하는 팀원을 프로젝트 리드로 설정하여 프로젝트를 진행한다.

• 보통 디자이너 1명과 개발자 2명이 하나의 팀을 이룬다. 현재 팀규모에서는 6개 정도의 프로젝트 팀이 있다.

피드백

• CEO인 Karri, 개발 파운더인 Jori, 그리고 head of product인 Tuomas가 프로젝트 미팅에 참여하며 피드백을 주거나 방향성을 정해준다. 셋 중 한명이 최종 결과에 총 책임을 진다.

• 디자인이나 제품에 대한 피드백 세션이 따로 있지는 않고 개발 과정에서 자연스럽게 이루어진다. 개발 중간에 어떻게 되고 있는지 보여주고 이에 대해서 피드백을 준다.

• Feature flag 시스템이 잘 구축되어 있다. Feature flag로 프로젝트 시작 후 몇일 혹은 몇주 후에 바로 내부 팀원들이 기능을 사용해볼 수 있으며 이상한 것이 있으면 바로 수정할 수 있다. Feature flag 시스템이 있기 때문에 배포가 늦어질 일이 없다.

• Linear Origin이라는 베타 테스트 프로그램 또한 운영되고 있다. 몇몇 고객들에게 기능을 보여주고 피드백을 받은 후 정식 런칭 한다. 모든 기능들이 베타 테스트 프로그램을 거쳐가지는 않는다.

흥미로웠던 점

리니어가 일하는 방식은 내가 디자인 컨설팅 회사를 다녔을때와 유사한 점이 몇가지 있다. 가장 유사한 점은 기능별 팀이 없이 디자이너와 엔지니어가 있고 프로젝트 별로 팀이 생성되었다가 다시 없어진다는 점이다. 많은 디자인 스튜디오들이 이와 같은 방식으로 일한다. 지표 중심 결정이 아닌 Taste를 기반으로 내리는 결정도 디자인 스튜디오와 비슷하다. 그렇다고 데이터가 중요하지 않다는 것은 아니다. 데이터를 인사이트를 얻기 위한 수단으로 사용하고 Taste를 기반으로 결정을 내린다. 고객이 문제를 알려줄 수는 있지만 이에 대한 해결책은 제품을 만드는 사람들이 더 잘 안다는 말과 맞닿아 있다.

조직 구조, 개발 프로세스, 지표, 결정 방식 등 모든 것이 굉장히 단순한 것도 다른 스타트업 조직과 많이 다른 것 같다. B2B SaaS라서 할 수 있는 것도 일부 있는 것 같고 Linear 창업진들과 팀원들이 이미 Airbnb, Coinbase 및 여러 빅테크 회사들에서 일해보기도 하고 엑싯한 경험을 갖고 있는 뛰어난 인재들로 구성되어 있는 것 또한 크게 작용하는 것 같다.

원문: https://www.lennysnewsletter.com/p/how-linear-builds-product