Linear는 왜 PM 없이 더 잘 만드나
제품팀을 운영하다 보면 프레임워크에 기대고 싶은 순간이 온다. RICE, OKR, A/B 테스트로 의사결정을 객관화하면 마음이 편하다. 그런데 협업 도구 Linear는 이 거의 전부를 버렸다. PM은 단 한 명(Head of Product)뿐이고, 프로젝트 리드는 엔지니어·디자이너 중에서 나온다. 그럼에도 제품 완성도와 출시 속도는 업계가 부러워하는 수준이다. 무엇이 이걸 가능하게 하나.
"Product goals should be about how we add value for our existing customers or expand to a new customer base."Lenny's Newsletter
무슨 일인가
Linear는 12개월 방향만 리더십이 잡고, 향후 2개 분기만 구체화한다. 작업은 로드맵·이슈 발굴·고객 요청·유지보수의 네 갈래로 흐르고, 프로젝트마다 팀이 모였다 해산한다. 복잡한 점수 랭킹 대신 고객 몰입과 리더의 판단으로 우선순위를 정하고, OKR과 A/B 테스트는 쓰지 않는다. 대신 피처 플래그로 며칠 만에 내부 검증을 돌리고 베타 고객(Linear Origins)에게서 선택적 피드백을 받는다. 즉 프로세스를 줄인 자리를 '취향(taste)'과 오너십으로 채운 것이다.
여러 시각
같은 PM 크래프트를 세 글이 다른 각도에서 본다.
- Lenny's Newsletter (Linear) — 프레임워크를 최소화하고 소수의 판단·취향으로 빠르게 출시하는 게 더 높은 완성도를 낳을 수 있다는 실증.
- a16z (Ben Horowitz) — "좋은 PM은 제품의 CEO"이며 결과에 전적인 책임을 진다. Linear가 PM 수를 줄여도 굴러가는 이유는 오너십이 팀 전체에 분산됐기 때문.
- Mind the Product (C. Todd Lombardo) — 로드맵은 기능 목록이 아니라 "전략의 프로토타입"이며 산출물(output)이 아닌 성과(outcome)로 그려야 한다. Linear의 2분기 구체화·12개월 방향이 정확히 이 형태다.
왜 중요한가
세 글을 겹쳐 보면 결론이 모인다. 프로세스는 판단을 대체하지 못하고, 오너십과 고객 이해라는 토대 위에서만 의미를 가진다. Horowitz의 책임 윤리, Lombardo의 성과 중심 로드맵, Linear의 취향 기반 실행은 모두 "무엇을 만들지"를 외부 점수표가 아니라 팀의 명확한 관점에서 끌어낸다. 프레임워크가 약한 팀이 도구를 더 쌓으면 오히려 결정이 느려진다. 진짜 레버는 누가 책임지고, 어떤 고객 문제를 풀지에 대한 합의다.
실무 적용
- 로드맵을 기능·날짜표가 아니라 분기별 성과(outcome) 테마로 다시 그리고, 12개월 방향과 2분기 상세를 분리한다.
- 우선순위 점수 산식을 맹신하기 전에 "이게 어떤 고객 문제를 더 잘 푸는가"를 한 문장으로 먼저 답하게 한다.
- 모든 프로젝트에 명시적 리드(오너)를 세워 책임 소재를 분명히 하고, 피처 플래그로 작게 빨리 검증한다.
Kenny의 관점
프론트엔드와 PM을 오가며 느끼는 건, 출시 속도의 병목은 대개 코드가 아니라 결정이라는 점이다. Linear가 피처 플래그로 며칠 만에 프로토타입을 붙이는 건 엔지니어링 역량인 동시에 "빨리 보고 빨리 판단한다"는 PM 문화의 산물이다. AX 관점에서도 마찬가지다. 좋은 UI는 점수표가 아니라 팀의 취향과 고객 맥락에서 나온다. 결국 프레임워크는 판단을 돕는 보조선일 뿐, 오너십과 고객 이해라는 본질을 대신할 수 없다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Lenny's Newsletter ↗