프로덕트 매니저를 위한 의사결정 가이드
더 나은 의사결정을 위한 프레임워크
프로덕트 매니저의 일은 하루에도 수십 번씩 크고 작은 선택을 하는 일의 연속입니다.
다음에 출시할 기능 범위를 어디까지 포함할 것인가?
지금 고객 정책을 변경해야 하는가?
A/B 테스트 결과가 애매한데, 이 기능을 그대로 론칭해도 되는가?
이러한 결정들을 원칙이나 의사 결정 프레임워크 없이 진행하다가는
우선순위가 꼬여 팀은 혼란에 빠지거나, PM 본인도 자신의 결정에 자신감을 가질 수 없는 경우가 발생합니다.
이 글에서는 좋은 의사결정을 도와주기 위해 필요한 원칙들을 소개해 보려고 합니다.
좋은 의사결정을 위한 3가지 원칙
PM으로서 더 나은 의사결정을 하기 위해 기억해야 할 세 가지 원칙이 있습니다.
1. 문제의 크기, 결과를 되돌릴 수 있는지 여부에 따라 분류하기
모든 결정을 똑같이 다룰 필요는 없습니다. 어떤 결정에 많은 시간을 쓸지, 어떤 결정을 빠르게 처리할지 구분하는 기준이 필요합니다.
2. 의사결정을 위한 이해관계자 그룹 분류하기
모든 이해관계자를 똑같이 참여시킬 수는 없습니다. 어떤 사람은 적극적으로 토론에 참여해야 하고, 어떤 사람은 의견만 주면 되고, 또 어떤 사람은 결과만 알면 됩니다.
3. 의사결정을 끝까지 마무리하기
결정은 선택에서 끝나면 안 됩니다. 실행 → 공유 → 피드백 → 학습까지 이어져야 합니다. 그래야 팀이 신뢰하고, PM 자신도 점점 더 나은 판단을 내릴 수 있습니다.
의사결정을 네 가지로 나누는 법
모든 결정을 두 가지 축으로 나누어 생각할 수 있습니다.
임팩트 크기: 이 결정이 회사와 사용자에게 얼마나 큰 영향을 주는가?
되돌릴 수 있는가: 결정을 내린 뒤 방향을 바꾸는 것이 쉬운가, 아니면 거의 불가능한가?
아마존 제프 베조스도 이 기준으로 구분하여 결정한다고 합니다.
되돌리기 어려운 결정은 “One-way door” → 느리고 신중하게 진행해야 합니다.
되돌릴 수 있는 결정은 “Two-way door” → 빠르고 기민하게 내려야 합니다.
제프 베조스는 한 인터뷰에서 One-way door/ Two-way door에 대해 다음과 같이 설명을 했습니다.
"어떤 결정은 결과가 심각하고 되돌릴 수 없거나 거의 불가능한, One-way door과 같습니다. 이러한 결정은 많은 검토와 협의를 거쳐 철저하고 신중하게 내려야 합니다. 만약 반대편에서 보고 마음에 들지 않는다고 하더라도, 다시 돌아올 수 없습니다.
하지만 대부분의 결정은 변경 가능하고, 되돌릴 수 있습니다, 이것을 Two-way door라고 합니다. 만약 잘못된 결정을 내렸다면, 그 결과에 오래 머물 필요 없이 문을 다시 열고 돌아올 수 있습니다. 이러한 판단력을 가진 소수의 사람들이 모여 빠르게 내려야 합니다.
조직이 커질수록 많은 결정을 One‑Way Door 방식으로 처리하려는 경향이 있습니다. 그 결과는 느리고, 성급하게 위험을 회피하는 경향이 있거나, 충분한 실험을 거치지 못한, 결국은 혁신이 저하되는 결과를 낳을 수 있습니다.”
1. 큰 임팩트 & 되돌릴 수 없는 결정
예시: 가격 정책, 장기 비전, 기능 종료 결정
특징: 회사 전체에 큰 파급력이 있으며, 한 번 정하면 돌이키기 어렵습니다.
전략: 충분한 시간과 자원을 투입해야 합니다. A/B 테스트, 일부 사용자 한정 적용, 특정 지역 한정 출시 등으로 리스크를 줄일 수 있습니다.
2. 작은 임팩트 & 되돌릴 수 없는 결정
예시: 초기 기술 아키텍처, 신제품 이름, API 규격
특징: 당장은 영향이 작아 보이지만, 장기적으로 큰 기술적 부채로 이어질 수 있습니다.
전략: 과도하게 고민할 필요는 없지만, 업계 베스트 프랙티스나 경험 많은 리더의 판단을 적극 활용해야 합니다. 다만 되돌릴 수 없다는 점은 반드시 고려해야 합니다.
3. 큰 임팩트 & 되돌릴 수 있는 결정
예시: 로드맵, 분기별 OKR, 핵심 UX 디자인, 전략적 파트너십
특징: 중요하지만 중간에 방향 전환이 가능합니다.
실수 패턴: 초기 의사결정에 과도하게 힘을 쏟고, 사후 점검에 소홀한 경우가 많습니다.
전략: 빠르게 결정하고, 실행 이후 학습에 더 많은 투자를 해야 합니다.
4. 작은 임팩트 & 되돌릴 수 있는 결정
예시: 버그 우선순위, 작은 디자인 선택, 기능 세부 범위
특징: 회사 차원에서는 작은 결정이며, 언제든 쉽게 수정할 수 있습니다.
전략: PM이 직접 개입하기보다는 팀에 위임하는 것이 바람직합니다. 직접 해야 한다면 빠르고 단순하게 처리해야 합니다.
세 개의 이해관계자 그룹
모든 이해관계자를 의사 결정에 똑같이 참여시킬 수는 없습니다. 이해관계자를 세 가지 그룹으로 분류해보면 의사 결정 과정이 단순해집니다.
1. 의사결정 핵심 참여 그룹
반드시 토론과 합의 과정에 참여해야 하는 핵심 그룹입니다. (예: 엔지니어링 리드, 디자인 리드, PM 등)
→ 회의 중에는 의견이 갈리더라도 "한번 결정한 사항에 대해서는 따른다"는 문화를 만들어야 합니다.
2. 의견 제공 그룹
의견을 들어볼 필요는 있지만 최종 의사결정까지는 가지 않는 그룹입니다. (예: 디자이너, 리서처, CS, 데이터 분석팀 등)
→ 다양한 시각을 얻되, 모든 사람을 만족시킬 필요는 없습니다.
3. 정보 공유 대상 그룹
단순히 의사결정 결과를 알아야 하는 그룹입니다. (예: 세일즈, 법무, 마케팅 등)
→ 불필요한 논의보다는 결과와 이유를 투명하게 공유하는 것이 핵심입니다.
의사결정은 끝까지 마무리할 수 있어야 합니다.
많은 PM이 결정을 내린 뒤 단순히 결과만 공유하고 끝내는 경우가 많습니다.
그러나 진정한 가치는 결정을 실행하고, 공유하고, 재검토하고, 배우는 과정에서 나옵니다.
이를 위해 활용할 수 있는 네 가지 방법이 있습니다.
결정 기록하기 – 위키나 공유 문서에 공개 기록을 작성합니다.
재검토 시점 정하기 – 언제, 어떤 조건에서 결정을 다시 검토해 볼지 미리 정해 봅니다.
결정 이유 공유하기 – 단순히 결과만 말하지 말고, 왜 그런 결정을 했는지도 설명합니다.
패턴 학습하기 – 과거 결정을 돌아보며, 어떤 판단이 좋았고 어디서 실수했는지 패턴을 확인합니다.
마무리
모든 결정을 동일하게 다룰 수는 없습니다. "임팩트 정도 X 되돌릴 수 있는지 여부"에 따라 네 가지로 분류해 접근하면 좋습니다.
모든 이해관계자가 동일하게 참여할 필요는 없습니다. 오히려 불필요하게 시간을 허비하거나 의사결정에 잡음이 생길 수 있습니다. 핵심 참여/ 의견 제공/ 정보대상 그룹으로 구분해 운영하면 효율적입니다.
의사 결정에서 끝나지 않습니다. 의사 결정 과정과 이유를 기록하고 → 필요시 재검토도 필요하고 → 관련자들에게 공유 → 학습까지 이어져야 다음 의사 결정에 도움이 됩니다.
이런 과정을 통해 더 나은 결정을 더 빠르게 내릴 수 있을 것이고, 팀원들이 좀 더 신뢰하고 업무 시 같은 방향성을 유지할 수 있을 것입니다.