들어가며
프로덕트 팀에서 일하다 보면 결과(Outcome)와 산출물(Output)의 차이를 이해하는 게 생각보다 어렵다는 걸 느낀다. 로드맵에 기능을 나열하고, 그걸 기한 내에 출시하는 것이 성공이라고 생각하기 쉽다. 그런데 정작 그 기능이 비즈니스에 어떤 영향을 미쳤는지는 잘 모른다.
이번 장에서는 결과 중심 사고로 전환할 때 부딪히는 현실적인 어려움과, 이를 해결하기 위한 구체적인 방법을 정리했다.
tails.com 사례로 보는 결과 중심 사고
tails.com 팀은 고객 리텐션 개선이라는 과제를 받았다. 분석 결과, 서비스 초기 90일간의 고객 유지율이 장기 유지율을 결정하는 핵심 지표라는 것을 발견했다.
그런데 90일은 너무 길었다. 빠른 실험을 위해 5일로 단축했지만, 이게 정말 장기 유지율의 선행 지표인지 확신이 없었다. 유지율을 5일로 줄이면서 실험 속도는 빨라졌지만, 비즈니스 성과는 모호해졌다.
그래서 팀은 고객 인터뷰를 진행했다. 고객이 왜 이탈하는지 직접 물어본 것이다. 결과는 두 가지로 압축됐다. 첫째, 모든 고객이 맞춤형 사료의 가치를 제대로 이해하고 있지 않았다. 둘째, 일부 개들은 단순히 이 사료를 좋아하지 않았다.
여기서 중요한 전환이 일어났다. 고객 인터뷰를 통해 당장 측정 가능하고 실행 가능한 두 가지 **제품 결과(Product Outcome)**를 도출한 것이다. 맞춤형 사료의 인지 가치를 높이고, 더 많은 개들이 사료를 좋아하게 만드는 것. 이 두 가지가 팀이 집중해야 할 진짜 목표가 됐다.
결과 중심 사고로 전환할 때의 어려움
이 사례에서 볼 수 있듯이, 하나의 지표를 선택하는 것만으로는 충분하지 않다. 결과 목표가 주어지더라도, 어떻게 측정해야 할지, 어떻게 영향을 미칠지, 심지어 그것이 올바른 결과인지조차 모를 때가 많다.
90일 유지율처럼 시간이 오래 걸리는 지표를 사용하면 빠른 실험 사이클을 운영하기 어렵다. 결국 프로덕트 팀은 비즈니스 결과와 제품 결과 사이의 연결고리를 찾기 위해 어느 정도의 사전 조사(Discovery)가 필요하다. 비즈니스 결과를 실제 실행 가능한 제품 결과로 전환하는 과정이 핵심이다.
왜 결과(Outcomes)인가?
결과로 관리한다는 것은 팀에게 자율성, 책임감, 그리고 주도성을 부여하는 것이다.
전통적인 로드맵 방식은 정해진 기능들을 특정 시점까지 개발하라고 요구한다. 반면 결과 중심 관리는 고객 문제를 해결하거나 비즈니스 니즈를 해결하라는 문제 정의가 주어진다. 어떻게 해결할지는 팀이 결정한다.
진정한 Continuous Discovery Team이라면, 프로덕트 트리오는 고객과 기술에 대한 깊은 이해를 갖추고 있다. 그래서 특정 문제를 해결하는 데 있어서 의사결정 우위를 가진다. 결과 관리 전략은 이런 불확실성을 허용한다.
고정된 로드맵은 마치 우리가 무엇을 만들어야 하는지 완벽히 알고 있는 듯한 거짓된 확신을 전달한다. 반면, 결과는 **“이 문제를 해결해야 한다는 것은 알지만, 어떻게 해결하는지가 확실치 않다”**는 점을 강조한다. 솔직히 대부분의 제품 개발 상황에서 이게 현실에 더 가깝다.
그리고 결과로 관리한다는 것은 성공을 어떻게 측정해야 하는지가 명확해진다는 의미이기도 하다. 그렇다면 과연, 결과 주도가 정말 좋은 것인가?
세 가지 유형의 결과
결과 중심 관리는 결과 자체의 질에 따라 달라진다. 모든 결과가 같은 게 아니다. 세 가지 유형을 구분해야 한다.
비즈니스 결과 (Business Outcomes)
비즈니스 결과는 주로 재무적 지표다. 매출 증가, 비용 절감 같은 것들. 대부분 후행 지표라서 측정까지 시간이 걸린다. 앞서 본 90일 유지율이나 한 달 후 연장율이 여기에 해당한다.
제품 결과 (Product Outcomes)
제품 결과는 제품이 비즈니스를 전진시키는 정도를 나타낸다. 가장 중요한 특징은 프로덕트 트리오가 통제할 수 있는 범위 내에 있다는 점이다.
비즈니스 결과는 마케팅, 영업, 고객 지원 등 여러 부서의 협업이 필요하다. 다만 제품 결과는 제품 팀이 직접적으로 영향을 미칠 수 있다. tails.com 사례에서 “개들이 사료를 좋아하게 하는 것”이 바로 제품 결과다. 제품 자체의 만족도나 관련 지표를 의미한다.
트랙션 지표 (Traction Metrics)
트랙션 지표는 특정 기능이나 작업 흐름에 대한 사용량 측정이다. 결과보다 더 한정적인 범위를 가지며, 종종 제품 결과 대신 특정 기능 활용도를 최적화하는 데 사용된다.
예를 들어, “개들이 사료를 좋아하도록 하는 것” 대신 “전환 캘린더 사용량 증가”라는 트랙션 지표를 목표로 잡으면 어떻게 될까? 고객이 캘린더를 원하지 않더라도 팀은 다른 해결책을 모색할 자유가 없다. 트랙션 지표를 결과처럼 설정하면 사실상 산출물에 집착하는 셈이다.
그렇다고 트랙션 지표가 쓸모없다는 건 아니다. 주니어 팀에게 활용하거나, 성숙한 제품에서 이미 유용성이 입증된 기능을 최적화할 때는 트랙션 지표가 유용하다.
결과는 양방향 협상의 산물이다
팀의 결과 설정은 프로덕트 리더(C레벨, 팀/부서장)와 프로덕트 트리오 간의 양방향 협상이 되어야 한다. 한쪽에서 일방적으로 정하면 안 된다.
프로덕트 리더의 역할
프로덕트 리더는 조직 전반의 시각을 제공한다. 비즈니스 차원에서 지금 무엇이 가장 중요한지 전달하는 것이다.
다만 리더가 솔루션을 강제해서는 안 된다. 대신, 트리오가 집중할 적절한 제품 결과를 제안해야 한다. 이게 리더의 전략적 의도를 전달하는 좋은 방식이다. “개들이 사료를 더 좋아하게 만드는 것”처럼 제안하면, 팀은 그대로 집중하거나 비즈니스 전략적 필요에 따라 세그먼트를 좁힐 수 있다.
프로덕트 트리오의 역할
프로덕트 트리오는 고객과 기술에 대한 지식을 바탕으로 현실적인 제안을 해야 한다. 주어진 기간 안에 해당 지표를 얼마나 개선할 수 있는지 말이다. 이 시점에 어떤 솔루션을 만들지 결정할 필요는 없다.
세그먼트가 있다면 이전 히스토리를 파악해서 몇 퍼센트 목표를 달성할 수 있을지 제안한다. 비즈니스가 더 큰 임팩트를 요구할 경우 팀은 더 야심찬 전략을 세워야 하며, 리더는 이런 높은 목표가 더 큰 실패 가능성을 수반함을 이해해야 한다.
협상이 중요한 이유
프로덕트 팀에 필요한 것은 결과에 대한 전략 학습 시간과 안정적으로 집중하는 팀 구조다. 리더와 트리오가 협력해 결과를 설정하면 조직적 지식을 최대한 활용하는 동시에, 팀이 목표 설정에 참여하게 되어 주도성과 성과가 높아진다.
연구에 따르면 결과 설정에 참여한 팀이 그렇지 않은 팀보다 더 많은 주도성과 성과를 보인다고 한다.
SMART 목표가 필요한가?
SMART 목표는 많이들 알고 있을 것이다. Specific(구체적), Measurable(측정 가능), Achievable(달성 가능), Relevant/Realistic(현실적이고 관련된), Time-bound(기한이 있는)의 약자다. (참고)
연구에 따르면 구체적이고 도전적인 목표를 세운 팀은 그렇지 않은 팀보다 뛰어난 성과를 보인다. 도전적인 목표는 집중력을 강화하고, 노력과 지속성을 이끌어내며, 조직에 숨겨진 관련 지식을 이끌어낸다. 다만 전제 조건이 있다. 팀은 목표 달성 가능성을 믿어야 하고, 목표에 몰입해야 하며, 진척도를 지속적으로 피드백받아야 한다. 이는 팀이 결과 정의에 참여해야 하고, 목표는 측정 가능해야 한다는 점을 뒷받침한다.
SMART의 한계
그런데 SMART 목표의 효과성 연구 대부분이 단순한 과업에 기반하고 있다는 점이 문제다. 도전적인 목표는 팀이 이를 달성할 전략을 갖추지 못했을 때 오히려 성과를 떨어뜨릴 수 있다.
그래서 적절한 전략이 식별되기 전에는 성과 목표 대신 학습 목표를 설정하는 것이 더 효과적일 수 있다. 새로운 결과에 직면한 프로덕트 트리오라면 먼저 학습 목표부터 시작해야 한다는 점을 시사한다.
예를 들어, 성과 목표가 “참여율 10% 증가”라면, 학습 목표는 “참여를 높일 수 있는 기회를 발견하기”가 될 수 있다. 결과를 측정하는 최적의 방법을 모를 때 여기서부터 시작하면 된다.
결국 처음부터 완벽한 지표를 정의하려고 애쓰기보다, 우선 고객 이탈 원인을 파악하고 그 후에 결과 지표를 조정하는 접근이 더 효과적이다. 익숙한 결과 지표를 다룰 때 SMART는 여전히 유용하며, 상황에 따라 먼저 학습 목표를 설정한 후 SMART 성과 목표로 발전시켜 나가는 것도 좋은 방법이다.
프로덕트 트리오를 위한 가이드
프로덕트 트리오가 실제로 마주하는 상황은 다양하다. 아예 결과 없이 산출물만 전달하라는 요청을 받는 경우가 가장 흔하다. 프로덕트 리더가 팀의 의견 없이 결과를 정해주는 경우도 있고, 반대로 프로덕트 트리오가 리더 의견 없이 독자적으로 결과를 정하는 경우도 있다. 이상적으로는 프로덕트 리더와 트리오가 결과를 협상해야 한다.
상황별 대응 방법
산출물만 전달하라는 요청을 받는 경우
이 상황이 가장 흔하다. 프로덕트 리더가 새로운 솔루션을 지시할 때, 비즈니스 맥락에 대해 더 물어봐야 한다. “이 솔루션의 대상 고객은 누구인가?”, “이 솔루션으로 달성하려는 비즈니스 결과는 무엇인가?”, “왜 이 솔루션이 해당 결과를 이끌 것이라 생각하는가?” 다만 ‘왜’라는 질문은 리더에 따라 방어적으로 느낄 수 있으니 주의가 필요하다.
그리고 이 비즈니스 결과와 연결될 수 있는 제품 결과가 있는지 점검해야 한다. 해당 솔루션이 어떤 제품 결과를 개선하며, 그 제품 결과가 비즈니스 결과의 선행 지표로 작용하는지 확인해보자.
프로덕트 리더가 팀의 의견 없이 결과를 정해주는 경우
비즈니스 결과를 요구받았다면, 그 결과를 이끌어낼 수 있는 제품 결과를 제안하고 리더에게 피드백을 구하자. 제품 결과를 요구받았다면, 비즈니스 맥락을 더 물어보자. “우리가 이 제품 결과로 달성하려는 비즈니스 결과는 무엇인가요?”와 같이 묻는다. 양측이 합의된 기간 안에 어느 정도 성과를 낼 수 있을지 명확히 전달하는 것이 중요하다.
프로덕트 트리오가 리더 의견 없이 독자적으로 결과를 정하는 경우
결과를 정하기 전 프로덕트 리더에게 비즈니스 맥락을 더 물어봐야 한다. “지금 비즈니스에 가장 중요한 것은 무엇인가?” 이 대화를 비즈니스 결과 관점에서 진행해보자. “다른 고객 세그먼트보다 중요도가 높은 세그먼트가 있는가?”, “우리가 알아야 할 전략적 이니셔티브가 있는가?”
이 정보를 토대로 가장 중요한 비즈니스 결과와 이를 뒷받침할 제품 결과를 매핑하고 리더의 피드백을 받는다. 그리고 팀이 가장 크게 기여할 수 있는 제품 결과를 선택한다.
체크리스트
스스로 점검해볼 항목들이다. 팀은 비즈니스 결과나 트랙션 지표가 아니라, 제품 결과를 받고 있는가? 트랙션 지표를 할당받았다면, 그 지표가 고객이 원하는 행동을 반영하는지, 이미 검증되었는지 확인하자. 새로운 지표를 처음 다루는 경우라면, 도전적인 성과 목표 전에 학습 목표를 먼저 설정하는 게 어떨까? 해당 지표에 대한 경험이 있다면, 구체적이고 도전적인 목표를 설정했는지 확인하자.
흔한 안티 패턴 피하기
결과 중심으로 일하려고 할 때 흔히 빠지는 함정들이 있다.
너무 많은 결과를 한 번에 추구하기. 한 번에 하나의 결과에 집중해야 한다. 여러 개를 동시에 쫓으면 어느 것도 제대로 달성하기 어렵다.
결과 사이를 핑퐁하듯 왔다갔다 하기. 하나의 결과에 장기간 집중해야 한다. 이번 주는 이거, 다음 주는 저거 하면 결국 아무것도 안 된다.
프로덕트 트리오가 아닌 개인별 결과 설정. 포지션별로 다른 목표를 주면 안 된다. 목표는 팀 단위로 설정해야 한다.
산출물을 결과로 설정하기. 의도는 결과인데 산출물을 결과로 착각하는 경우가 많다. 숫자로 표현한다고 해서 결과가 되는 게 아니다. 숫자 표현이 의무도 아니고, 숫자 표현이 무조건 참도 아니다. 예를 들어 “플랫폼상의 강좌 리뷰 수 증가”는 산출물에 가깝고, “리뷰가 포함된 강좌 조회 수 증가”가 더 결과에 가깝다.
한 가지 결과에만 집중하고 나머지를 무시하기. 웰스 파고 사례가 유명하다. 주 목표 외에 Health Metric 모니터링이 필요하다. 고객 획득에 집중한다면, 동시에 고객 만족도 지표를 감시해야 한다. 한 지표를 극단적으로 최적화하면 다른 곳에서 문제가 생긴다.
나가며
결과 중심 사고로 전환하는 건 단순히 KPI를 바꾸는 게 아니다. 팀에게 자율성과 책임을 부여하고, 리더와 팀이 함께 목표를 협상하는 문화를 만드는 것이다.
비즈니스 결과, 제품 결과, 트랙션 지표의 차이를 이해하고, 팀이 직접 영향을 미칠 수 있는 제품 결과에 집중하는 것. SMART 목표의 한계를 알고, 새로운 영역에서는 학습 목표부터 시작하는 것. 이런 작은 전환들이 모여서 진짜 결과 중심 조직이 된다.
Discovering Opportunities
다음 글에서는 기회를 발견하고 구조화하는 방법을 다룬다.
고객에 대해 현재 알고 있는 바를 시각화한 경험 지도(Experience Map)를 만든다 (4장). 경험 지도에 따라 고객 인터뷰를 진행하고, 각 인터뷰에서 얻은 통찰을 인터뷰 스냅샷(Interview Snapshot)에 기록한다 (5장). 발견한 기회들을 기회-솔루션 트리(Opportunity Solution Tree)에 구조화하고, 이 트리를 활용해 기회 공간을 평가하고 우선순위를 정한다 (6장, 7장).
댓글