All high functioning teams must prioritize. Not once a month, not once a week — but rigorously, and ruthlessly.
1. 들어가기 앞서
우선순위를 정한다는 것은 가장 중요한 일을 먼저 하는 것을 의미합니다. 제품을 만든다는 것은 고객 가치를 가장 많이 창출하는 일을 먼저 하는 것을 의미합니다.
제 경험에 따르면, 우선순위 결정을 내리는 기술은 매우 복잡하기 때문에 팀에게 전수하기 어려운 스킬 중 하나입니다. 프로덕트 매니저가 핵심 역할을 담당하는 경우가 많지만, 제가 보았던 최고의 팀들은 모두가 동일한 목표를 향해 집요하게 우선순위를 정하며, 서로 일관된 방식을 유지하는 팀입니다.
이 글은 우선순위 결정을 생각하는 하나의 프레임워크에 관한 것입니다.
2. 우선순위 결정을 위한 프레임워크
제품 관리에서의 우선순위 설정은 두 가지 범위로 나눌 수 있습니다:
1.
프로젝트 간 우선순위 결정 - 팀이 다음에 어떤 프로젝트에 투자할지를 결정하는 것.
2.
프로젝트 내 작업 우선순위 결정 - 프로젝트를 얼마나 효율적으로 실행할 수 있는지에 관한 것.
각각의 범위는 매우 다른 종류의 결정을 내리게 합니다.
프로젝트 간 우선순위 결정은, “우리 팀은 다음에 무엇에 투자할 것인가”라는 큰 결정을 내려야 합니다. 이를 해결하는 올바른 방법은 퍼즐을 맞추는 것과 같습니다. 모든 조각을 찾기 위해 엄격한 과정을 적용하면, 결국 모든 조각이 어떻게 맞물리는지에 따라 답이 보입니다.
프로젝트 내 작업의 우선순위 결정은 같은 결정을 수백 번 내리는 과정입니다: “이 작업을 정말 꼭 해야 하는가?” 제품을 만드는 데에는 혼돈이 따르므로, 이 경우에는 필수적인 작업을 신속하게 결정할 수 있는 무자비한 사고방식을 갖추어야 합니다.
3. 프로젝트 간 우선순위 결정
다음에 팀이 투자할 프로젝트를 결정하는 퍼즐을 맞추기 위한 엄격한 과정
이 질문에 답하기 위해서는 엄격한 과정이 필요하지만, 과정 자체는 복잡하지 않습니다:
1.
각 프로젝트의 투자 대비 수익(ROI)을 추정한다.
2.
세 가지 제약 조건(의존성, 일정, 팀 구성)을 적용한다.
3.
ROI와 제약 조건을 고려해 프로젝트를 순서대로 배치한다.
대부분의 독자에게 익숙한 개념이라고 가정하고, 각각을 간략히 살펴보겠습니다.
3.1. 투자 대비 수익 추정
프로젝트 간 우선순위 결정의 기초는 ROI로, 이는 단위 시간 당 팀이 창출하는 고객 가치입니다. 우선순위 결정의 목표는 항상 시간 고객 가치 창출을 극대화할 수 있는 작업을 수행하는 것입니다.
프로젝트 간의 우선순위를 정하려면 두 가지 데이터를 추정해야 합니다:
•
프로젝트가 만들어낼 고객 가치의 양
•
프로젝트를 완료하는 데 걸리는 시간
이 데이터를 바탕으로 모든 프로젝트를 비교하면, 자연스럽게 우선순위가 결정됩니다.
기계적으로 이렇게 설정하면 됩니다.
물론 영향력과 노력을 모두 추정하는 것은 아주아주 어렵습니다. 하지만 매번 추정할 때 틀릴 확률이 동일하다고 가정한다면, 비교 차원에서 투자 대비 수익을 계산하는 것은 프로젝트 우선순위를 결정하는 정당한 방법입니다
(프로 팁: 모든 추정치에 대해 작업 시간은 두 배, 고객 가치는 절반으로 계산해보면 현실에 더 가까운 결과를 얻을 수 있습니다)
3.2. 제약 조건 적용
현실은 엑셀 시트처럼 정돈되어 있지 않기 때문에, 우선순위 결정에는 제약 조건도 고려해야 합니다. 핵심 제약 조건은 의존성, 일정, 팀 구성입니다.
3.2.1. 의존성
의존성이란 어떤 작업 단위가 진행되기 위해 다른 작업 단위가 완료되어야 하는 관계를 의미합니다.
예를 들어, 모바일 팀에서 고객이 한 번의 탭으로 결제하고 싶은 기능을 만들고 싶다고 가정해 보겠습니다. 당신은 이 프로젝트가 ROI가 가장 높은 프로젝트라는 것을 확인하였기에, 최대한 빨리 프로젝트를 완료 하고 싶을 것입니다.
하지만, 실제로 결제를 받기 위한 기능이 다른 팀에 의해 개발되고 있다면, 해당 의존성 때문에 원탭 개발을 바로 진행할 수 없습니다.이 경우, 우선순위는 높은 ROI를 가진 프로젝트라도 의존성이 해결되지 않으면 대기해야 하므로, 다음으로 높은 ROI를 가진 프로젝트를 진행해야 합니다.
제품을 개발할 때 의존성은 어디에나 존재하며, 제품이 성공할수록 규모가 커지면서 더욱 복잡한 시스템이 형성되어 상황은 악화됩니다. 대기업에서는 의존성을 이해하고 이를 해결하는 것이 우선순위 결정을 내릴 때 가장 중요한 요소 중 하나입니다.
참고로, 대부분 사람들은 스타트업이 빠른 이유가 열심히 일하고 야망이 크기 때문이라고 생각합니다. 하지만 실제로 속도의 차이는 대부분 의존성이 훨씬 적기 때문이며, 뭔가 잘못되어도 불만을 가질 고객이 적어 일이 훨씬 수월하게 진행되기 때문입니다.
3.2.2. 역의존성
어떤 프로젝트는 다른 팀이 목표를 달성하는 데 큰 도움을 줄 때가 있습니다. 이런 경우, 당신의 팀이 바로 그 '의존성'이 되는 것입니다.
만약 제품보다 회사의 ROI를 우선시한다면—당연히 그래야 합니다—이제 여러분은 단지 자신의 프로젝트 뿐만 아니라, 여러분이 해소해주는 의존 프로젝트들까지 포함한 누적 ROI를 평가해야 합니다. 이를 통해 팀에 맞는 올바른 우선순위 결정을 내릴 수 있습니다.
다른 팀의 장애물을 제거하기 위해 노력하는 팀을 볼 때마다 저는 큰 존경심을 느낍니다. 이는 그들의 제품에 대한 성숙한 사고를 보여주며, 이 팀들이 바로 제품 회사의 이름 없는 영웅들이자, 회사에 가장 큰 레버리지를 제공하는 존재임을 의미합니다.
3.2.3. 일정
일정은 우리가 모두 경험해 본 전형적인 제약 조건입니다. 특히 심각한 경우는, 스타트업이 자금이 고갈되어 최고 ROI 기능이 출시되기 전에 문을 닫아야 할 때입니다.
이런 상황에서는, 당연히 정해진 일정 내에 달성 가능한 최고 ROI 프로젝트를 수행하는 것이 올바른 우선순위 결정입니다.
3.2.4. 팀 구성
모든 팀이 똑같지는 않습니다. 때때로 팀 구성원의 특성 때문에 어떤 프로젝트를 선택할지에 대해 다른 우선순위 결정을 내려야 할 때가 있습니다.
예를 들어, 회사에 새로 입사한 사람들이 모여 있는 팀, 예를 들어 인턴들로 가득 찬 팀(인턴들에 대한 경의를 표하며, 실제로 소프트웨어의 50%가 인턴들에 의해 개발됩니다)이 그렇습니다.
이러한 상황에서는, 설령 최고 ROI 프로젝트라 하더라도 고객에게 큰 위험을 초래할 가능성이 있는 프로젝트를 우선하는 것을 경계해야 합니다. 대신, 중요한 코드나 사용자 경험 경로에 영향을 주지 않는 프로젝트를 우선하는 것이 좋습니다. 이렇게 하면 부정적인 결과의 규모를 줄일 수 있습니다.
신입 팀이 먼저 작은 성공을 경험할 수 있도록 도와주세요. 몇 가지 생산 환경에 적용된 기능을 성공적으로 출시한 후에는, 보다 복잡한 프로젝트로 진행할 수 있습니다.
3.3. 프로젝트 간 우선순위 결정: 퍼즐을 완성하고 실행하라
위에서 언급한 모든 정보를 모으는 데 드는 노력을 경시하는 듯 보일 수 있지만, 일단 모든 정보를 갖추게 되면 단지 조각들을 맞추기만 하면 되는 것입니다.
4. 프로젝트 내 작업의 우선순위 결정
“이 작업이 정말 꼭 필요한가?”를 판단하기 위한 무자비한 사고방식
프로젝트 실행 단계에서는 우선순위 결정의 성격이 달라집니다. 매일매일 빠른 결정이 필요하며, 프로젝트 간 우선순위 결정을 내릴 때처럼 모든 결정을 깊이 분석할 시간이 없습니다. 또한, 실제 고객에게 영향을 주기 때문에 팀에게는 감정적으로도 어려운 시기입니다. 고객이 영향을 받으며, 팀의 평판마저 위태롭게 느껴질 수 있습니다.
제품을 만드는 속도와 혼란을 극복할 수 있는 유일한 방법은, 팀이 수행하는 작업에 대해 끊임없이 인식하고 그 작업이 과연 필요 여부를 무자비하게 질문할 수 있는 사고방식을 개발하는 것입니다.
무자비한 사고방식을 가진다는 것은 현실을 받아들이는 것을 의미합니다. 집중해야 할 방향에 대해 매일 어려운 선택을 해야 한다는 것, 그리고 완벽한 제품을 출시하는 것은 환상에 불과하며, 출시를 위해서는 항상 타협이 필요하다는 것을 깨닫는 것입니다.
무자비한 사고방식은 출시하려는 의지와도 같습니다. 이해관계자와 고객의 기대가 팀에 엄청난 압박을 가하다 보니, 종종 출시를 두려워하게 됩니다. 작은 문제에 지나치게 신경을 써서 마치 얼어붙은 것처럼 행동하게 되고, 결국 시간이 지남에 따라 고객에게 창출되는 가치에 집중하지 못하고 완벽을 추구하게 됩니다.
“런치 시점에 버그가 전혀 없는 팀을 보여줘. 그러면 이미 오래전에 출시했어야 할 팀임을 알게 될 것이다.”
Show me a team that has no bugs at launch, and I’ll show you one that should have shipped a long time ago.
실제로, 프로젝트 내 작업의 우선순위를 결정하는 데 있어 혼돈스러운 상황을 고려할 때, 이에 대한 프로세스를 체계적으로 정의하는 것은 오히려 어리석은 짓입니다. 대신, 팀이 ‘이 작업이 정말 꼭 필요한가?’라는 질문에 무자비하게 답할 수 있도록 제품 개발 개념들을 내면화하도록 돕는 것이 더 생산적인 전략입니다.
나머지 글에서는 다음과 같은 주제들을 다룰 것입니다:
•
우선순위 결정 시스템 구축
•
제품 가정을 통한 품질 대 속도 트레이드오프
•
출시의 시간 가치(Time Value of Shipping)
4.1. 우선순위 결정 시스템 구축
모든 소프트웨어는 부채 그 자체라고 볼 수 있습니다. 지금도 버그가 존재하고, 시간이 지나면서 더 많은 버그가 발생할 것입니다. 새로운 버그가 발생했을 때, 팀이 그 버그를 신속하게 수정할지 말지를 판단하지 못한다면, 가장 중요한 작업에 집중할 수 있는 능력이 계속 방해받게 될 것입니다.
버그가 발생할 때마다 우선순위 회의를 열 여유는 없으므로, 버그를 언제 수정하고 언제 넘어갈지를 결정하는 시스템을 만드는 것이 가장 효과적인 방법 중 하나입니다.
다음은 제가 팀에 적용하여 효과적이라고 판단한 시스템의 한 예시입니다:
•
X축: 버그가 사용자에게 영향을 주는 빈도
•
Y축: 버그의 심각도
•
빨간 점: 버그
이 시스템을 사용하기 위해, 팀과 함께 어느 정도의 심각도가 너무 심각한지(예를 들어, 사용자가 결제를 할 수 없게 되는 경우)와 어느 정도의 빈도가 너무 잦은지(예를 들어, 사용자 중 5% 이상이 영향을 받는 경우)를 정의합니다. 그런 다음, 버그가 어느 영역에 속하는지에 따라 취할 행동들을 합의합니다. 이 행동들 중 하나는 해당 버그를 백로그에 넣고 당장은 처리하지 않는 것입니다.
이 시스템에 투자한다면, 팀은 버그 분류 및 처리에 있어 기계처럼 효율적으로 작동하게 되어, 낮은 가치의 버그에 누군가가 시간을 낭비하는 상황을 체계적으로 제거할 수 있습니다.
4.2. 제품 가정을 통한 품질 대 속도 트레이드오프
초기 제품 시절 창업자들이 작성한 형편없는 코드에 관한 이야기를 자주 듣게 됩니다. 회사가 성공함에 따라, 이 코드는 새로 합류하는 엔지니어들에게 악몽이 되곤 했습니다.
창업자들이 프로그래밍 실력이 부족했을까요? 어쩌면 그럴지도 모릅니다. 그러나 대부분의 경우, 당시에는 제품이 성공할 가능성이 낮았기 때문에 코드 품질보다는 속도와 아이디어 검증에 더 신경을 썼던 것입니다.
출시를 위해서는 모든 팀이 어느 정도 품질을 희생하게 마련입니다. 팀은 언제 ‘충분하다’고 판단할지를 선택해야 하며, 이는 제품의 품질에 필수적인 요소가 무엇인지를 우선순위로 결정하는 문제로 귀결됩니다.
속도와 품질 사이의 올바른 균형점을 찾는 유용한 방법은 바로 제품 가정(product assumption)에 기반하는 것입니다. 제품 가정이란 고객 문제나 고객을 위해 구축하는 솔루션에 대해 갖는 근본적인 믿음을 의미합니다.
예를 들어, 페이스북 초창기에는 사람들이 온라인에서 서로 연결되기를 원한다는 문제 가정이 있었습니다. 그 문제 가정이 검증되자, 그들은 친구 추가와 같은 기능이라는 해결책 가정을 내세우게 된 것입니다.
자신의 제품을 생각해본다면, 제품 가정에 관해 다음 세 가지 상황을 고려할 수 있습니다:
•
해결하려는 문제가 아직 가정에 불과한 경우
•
검증된 문제에 대해 제시하는 해결책이 가정인 경우
•
문제와 해결책 모두 확실히 검증되어 더 이상 가정이 아닌 경우
만약 스펙트럼의 왼쪽에 위치한다면, 고객 문제에 대한 가정은 있지만 그 문제가 실제로 존재하는지 확신할 수 없습니다. 이 상황에서는 가능한 한 빠르게 출시할 수 있도록 품질을 다소 희생하는 편이, 존재하지 않는 문제를 해결하려고 시간과 자원을 낭비할 위험을 줄일 수 있습니다.
반대로 스펙트럼의 오른쪽에 있다면, 해결하려는 문제와 올바른 솔루션에 대해 높은 신뢰를 가지고 있는 상태입니다. 이때는 해당 기능이 성공할 것이며 미래에 확장도 잘 될 것이므로, 품질을 최대한 보장해야 합니다.
많은 회사들이 팀을 ‘실험팀’과 ‘핵심 기능팀’으로 나누는 것을 종종 볼 수 있습니다. 제 생각에는, 이러한 조직 구조는 대부분의 팀이 제품 가정 스펙트럼을 이해하지 못하고, 상황에 따라 속도와 품질 사이의 전환을 원활하게 할 수 없음을 반영한다고 봅니다.
4.3. 출시의 시간 가치
소프트웨어는 출시되어야만 고객에게 가치를 제공합니다.
예를 들어, 제품 팀이 자주 직면하는 어려운 선택 중 하나는 기능을 고객의 80%에게 먼저 출시하고, 나머지 20%에게는 기능 출시를 지연시킬 것인지 결정하는 문제입니다. 이 선택은 보통 마지막 20%를 위한 기능 개발이 많은 틈새 기능을 필요로 하여, 처음 80%를 개발하는 것보다 두 배의 시간이 걸릴 때 발생합니다.
이 선택을 자세히 살펴봅시다.
다이어그램을 보면 80%의 고객은 1번 옵션에서 추가적으로 가치를 얻을 수 있는 기간을 누리는 반면, 2번 옵션에서는 기다려야 한다는 것을 알 수 있습니다. 그렇다면 1번을 선택하는 것이 당연할까요? 정확히 그렇지는 않습니다. 왜냐하면 팀에게는 여전히 어려운 선택이기 때문입니다:
•
해당 기능이 지원되지 않는 20%의 고객은 여러분이 그들을 지원하지 않기로 선택했다는 것을 분명히 인식하고 크게 화를 낼 것입니다. 이들에게는 아무것도 제공하지 않는 것보다 훨씬 더 나쁜 선택으로 보입니다.
•
해당 기능이 작동하는 80%의 고객은 기능을 더 빨리 받았다고 해서 그 추가 가치를 크게 체감하지 못할 수 있습니다.
이 두 효과의 아이러니는, 시간이 지남에 따라 고객에게 더 많은 가치를 제공하기 위해 내린 결정이 오히려 더 많은 불만을 초래할 수 있다는 점입니다. 참 이상한 시대를 살고 있습니다.
그럼에도 불구하고, 저는 이와 같은 선택에 직면했을 때 팀에게 과감하게 먼저 출시할 것을 권장합니다. 그 이유는 다음과 같습니다:
•
만약 고객이 전체 맥락을 알고 우리 대신 결정을 내릴 수 있다면, 대다수의 고객은 기능을 미리 출시해달라고 요구할 것입니다.
•
장기적으로, 만약 한 팀이 지속적으로 이 전략을 따른다면, 고객이 80%/20% 상황에서 혜택을 받는 횟수가 결국 균형을 이루게 되고, 항상 100%를 기다리는 회사에 비해 고객은 기능을 더 빨리 받음으로써 누적된 효과로 인해 기하급수적으로 더 많은 가치를 얻게 됩니다.
고객에게 더 빠르게 기능을 출시하는 것에 가치를 부여하는 개념은 이해하기는 쉽지만, 그에 따른 고통 때문에 실행하기 어려운 개념 중 하나입니다. 그러나 무자비하게 우선순위를 결정하는 사람들은 이 점을 명확히 인식하고 고객의 최선의 이익을 위해 행동할 것입니다.
4.4. 프로젝트 내 작업의 우선순위 결정: 무자비한 사고방식은 자연스럽지 않다.
지금까지 다룬 개념들은 제 경험에 비추어 내면화할 가치가 있다고 느낀 것들입니다. 물론 이 외에도 더 많은 개념들이 있으며, 여러분의 경험에 따라 이를 조정할 수 있습니다.
안타깝게도, 제품 회사의 핵심 문화임에도 불구하고 업계의 대부분 팀은 무자비하게 우선순위를 결정하도록 장려받지 못합니다.
예를 들어, 대기업에서는 팀들이 끊임없이 기능을 출시하고, 대부분의 직원들은 고객이 기능을 경험하기 전까지는 출시 소식을 듣지 못합니다. 그런 환경에서는 팀원들이 동료가 다른 사람보다 3배나 빠르게 출시했다는 사실을 알아차리기 어렵습니다. 대신, 그들은 팀이 의식적으로 수용한 모든 단점을 제외하고는 제품에서 빠진 부분만 보게 됩니다.
반면에, 완벽하게 다듬어진 제품은 내부적으로 많은 칭찬을 받지만, 출시까지 2년이나 걸렸다면 어쩔 수 없는 일이죠. 고객이 결국 오지 않아서 이 제품을 기다리지 않았던 사례들을 우리는 거의 기억하지 못합니다.
여러분의 팀이 더 나아지도록 도전하세요. 무자비함을 발휘하라고 격려하세요.
5. 끝 마치며
우선순위 결정은 하나의 기술이다
팀의 시간은 회사가 가진 가장 소중한 자원이며, 그 시간을 효과적으로 관리하는 것이 여러분의 역할이라면, 그 기술을 반드시 연마해야 합니다. 우선순위 결정은 하나의 기술이며, 연습을 통해 의도적으로 향상시킬 수 있는 기술입니다.
마지막으로 우선순위 결정에 관한 한 가지 진실을 남기고 싶습니다. 현재 계획보다 항상 목표를 더 빠르게 달성할 방법이 존재한다는 것입니다.
항상 그렇습니다. 단지 그것을 찾아내기만 하면 됩니다. 계획 회의가 끝날 때 “이 작업을 절반의 시간에 할 수 있는 방법은 무엇일까?”라고 물어보세요. 그러면 기적처럼 팀이 방법을 찾아낼 것입니다.
수년간 제품을 출시해온 경험에서, 한 팀이 투자 시간을 줄이면서도 동일한 고객 가치를 창출할 방법을 찾지 못한 경우는 한 번도 본 적이 없습니다. 또한, 팀이 완벽하게 우선순위를 결정한 경우도 한 번도 본 적이 없는데, 이는 바로 항상 더 빠른 방법이 존재한다는 아이디어를 강화시켜 줍니다.
만약 항상 방법이 있다는 사실을 받아들인다면, 현재 프로젝트를 실행하든 다음 프로젝트를 선택하든 상관없이, 무자비하고 철저하게 우선순위를 결정하는 것이 유일한 논리적 선택입니다.
심지어 여러분의 프로젝트가 한 국가 전체일지라도 말입니다.