속도광 PM과 비전중심의 PM 사이에서 발견한 '성과'의 역설
지난해 나는 서로 극명하게 다른 리더십 스타일을 가진 여러 팀과 동시에 협업하며 독특한 도전을 경험했다. PM-A는 저비용 실험(최소의 개발로 단기 효과 집중)에 집중하는 단기적 ‘스피드 레이서’였던 반면, PM-B는 완전히 정반대였다. 하나의 솔루션에 무려 반년을 투자했지만, 결국 비즈니스 가치를 증명하지 못한 채 고객들로부터 "우리가 원했던 건 이게 아니에요"라는 피드백을 들어야 했다.
우리 팀의 2025년 성과를 분석했을 때 놀라운 역설이 발견되었다. 성공적인 AB 테스트 결과 중 상당수(24개 중 약 17개)가 단기적인 솔루션(Quick win)에서 나왔지만, 정작 우리 프로덕트는 파편화된 기능들의 집합체처럼 느껴지기 시작한 것이다. 우리는 흔히 "다음 분기에 개선(Iteration)하자"라거나, "당면한 과제는 해결했으니 이제 다른 우선순위로 넘어가자"라고 약속하곤 한다. 하지만 늘 그렇듯 다음 분기에는 또 다른 우선순위가 끼어든다. 우리는 눈앞의 단기목표와 비즈니스 성과가 있었지만, 정작 우리가 가야 할 전략적 방향은 잃고 있었다.
이 글에서는 우리가 단기성과와 장기 비전사이에 중심을 되찾기 위해 사용한 두 가지 구체적인 방법론에 집중한다.
이번 세션에서는 ‘당장 해야 할 일’과 ‘나아가야 할 길’ 사이의 간극을 메우기 위한 4단계 프레임워크를 제안한다.
‘디자인 스프린트(Design Sprints)’와 ‘**워킹 백워드(Working Backwards)’를 결합하여, 프러덕트의 나침반 역할을 할 1~2년 치 로드맵과 큰 비전을 구축한다. 다시말해 디자인스프린트와 워킹백워드를 진행할때 먼미래가 이날 1-2년후의 우리 프러덕트가 사용자에게 어떻게 경험될지를 생각하고 임하는 것이 중요하다.
이 단계에서는 분기마다 짜는 로드맵보다는 구체적일 수는 없다. 하지만 큰 비전으로 대략적으로 그려준다는 점에 의미가 있다.
팀은 이 거대한 비전에 도달하기 위해 이를 소화 가능한 단위로 쪼개어 전략적인 분기 로드맵을 수립해야 합니다.
정기적으로 고객을 만나 단기적인 ‘노이즈(Noise)’와 장기적인 ‘시그널(Signal)’을 분리한다. 테레사 토레스(Teresa Torres)가 제안한 개념으로, 분기별로 한 번 크게 진행하는 전통적인 사용자 리서치 방식에서 벗어나 매주 고객을 만나 작은 질문과 가설을 검증하는 습관을 의미한다.
목적: 팀이 만든 솔루션이 실제 유효한지 상시 확인하며, 개발 도중 발생할 수 있는 잘못된 가정을 빠르게 바로잡습니다.
핵심: '어떤 기능을 만들까?'가 아니라 '어떤 고객 문제를 해결할까?'에 집중하는 기회 탐색 트리(Opportunity Solution Tree, 아래이미지 참고) 를 활용하여 단기적인 요구사항(노이즈)에 휩쓸리지 않고 진짜 문제(시그널)를 포착합니다.
작은 AB 테스트들이 단순한 임시방편이 아니라 미래의 비전으로 나아가는데 초석이 되도록 보장하는 전술적 방법이다. 팀은 상시적으로 기회 탐색 트리(Opportunity Solution Tree) 을 체크하여 중심을 잃지 않도록 해야 한다.
점진적(70%), 진화적(20%), 파괴적(10%) 업무에 팀의 에너지를 적절히 배분하여 리소스를 보호하는 모델.
구글(Google) 등 글로벌 테크 기업들이 리소스 배분 시 사용하는 가이드라인으로, 프로젝트의 성격에 따라 비중을 나누는 전략입니다.
70% (점진적 혁신, Incremental): 핵심 비즈니스를 최적화하고 유지하는 업무. (예: 현재 기능의 UI 개선, 성능 최적화)
20% (진화적 혁신, Evolutionary): 인접 영역으로 확장하거나 기존 기능을 대폭 개선하는 업무. (예: 새로운 타겟 유저를 위한 기능 확장)
10% (파괴적 혁신, Disruptive): 완전히 새로운 비즈니스 모델이나 미래 먹거리를 위한 실험적 업무. (예: 신규 프로토타입 개발)
이 규칙은 팀이 당장의 지표(70%)에만 함몰되지 않고, 미래의 성장 동력(20%, 10%)을 위한 시간을 확보할 수 있게 해줍니다.
이 프리엠을 통해 프러덕트팀들은 당장의 KPI와 지속 가능한 장기 비전 사이의 균형을 맞추는 법을 배우게 될 것이다.
**워킹 백워드(Working Backwards): 아마존(Amazon)의 혁신을 이끈 핵심 방법론으로, 제품 개발 전 고객의 입장에서 결과물을 먼저 정의하는 방식입니다. 실제 개발에 착수하기 전, 제품 출시를 알리는 가상의'보도자료(Press Release)'와 고객이 궁금해할 'FAQ'를 먼저 작성합니다. 이를 통해 팀 전체가 '우리가 왜 이 기능을 만드는지', '고객에게 어떤 가치를 주는지'를 완벽히 정렬한 후 비로소 첫 줄의 코드를 작성하기 시작합니다.