지난 편에서는 프로덕트 매니저에게 의사결정 원칙과 기준이 왜 필요한지에 대해 알아봤어요. 이번 편에서는 5가지 의사결정 원칙에 대해서 살펴볼게요.
원칙 1: 해결책이 아닌, 문제를 소유하라
1) 해결책이 아니라 문제를 소유한다는 것
PM의 책임은 기능이 아니에요. 해결할 가치가 있는 고객의 문제, 니즈, 또는 욕망이에요.
“해결을 소유”하면 이런 일을 하게 돼요.
- 너무 이른 단계에 상세한 스펙을 작성한다
- 제약 조건을 이해하기 전에 UI 패턴을 지정한다
- 사전 정의했다는 이유로 로드맵을 밀어붙인다
- 최선의 솔루션을 탐색하는 대신 자기 아이디어를 무작정 방어한다
“문제를 소유”하면 기본 행동이 달라져요.
- 사용자의 고통, 니즈, 욕망을 명확히 꿰뚫어 본다
- 성공을 정의한다
- 맥락과 제약 조건을 공유한다
- 팀이 선택지를 탐색하도록 돕는다
- 실험을 통해 빠르게 학습한다
이것이 요청된 것을 만드는 팀과 중요한 것을 해결하는 팀의 차이예요.
(1) 기능팀 vs 프로덕트팀
- 기능팀(Feature Team)
누군가 요청한 것을 출시했느냐로 평가 - 프로덕트팀(Product Team)
실제 문제, 니즈, 욕망을 해결하여 성과를 개선했느냐로 평가
간단한 신호가 있어요. PM의 주요 산출물이 “요구사항”이면 피처 팀에 가깝고, “문제 프레이밍 + 성공 지표”이면 프로덕트팀에 가까운 거예요.
(2) 실무에서 바로 쓸 수 있는 질문들
미팅에서 이미 패키징된 솔루션으로 요청이 들어올 때 이런 질문을 시도해보세요.
- “이것으로 어떤 문제를 해결하려는 건가요?”
- “누가, 언제 이 고통을 겪고 있나요?”
- “측정 가능한 관점에서, 이것이 효과가 있었다는 걸 어떻게 알 수 있나요?”
- “아무것도 하지 않으면 어떻게 되나요?”
(3) 문제 정의 미니 템플릿
문서나 Slack 스레드에서 이 간단한 형식을 활용해보세요.
- 사용자/고객: 누구인가?
- 문제/니즈/바람: 오늘 무엇이 고통스럽거나 비효율적인가?
- 왜 지금: 무엇이 바뀌었거나, 긴급성은 무엇인가?
- 임팩트: 비용이 얼마인가 (시간, 매출, 신뢰, 리스크)?
- 성공 지표: 무엇이 개선되어야 하고, 얼마나?
- 제약 조건: 시간, 기술, 정책, 디펜던시
솔루션 대신 문제를 소유하는 것을 비유하면, 의사가 환자를 진료하는 방식과 같아요. 환자가 “MRI 찍어주세요”라고 말해도, 좋은 의사는 먼저 “어디가 아프세요? 언제부터요?”라고 물어보죠. 환자가 원하는 건 MRI가 아니라 통증 해결이거든요. PM도 마찬가지로, 이해관계자가 원하는 기능이 아니라 그 뒤에 있는 문제를 먼저 진단해야 해요.
원칙 2: “무엇”이 아니라 “왜”에 집착하라
1) “왜”를 파고드는 것의 의미
고객은 종종 자신의 니즈를 해결책의 형태로 표현해요.
- “내보내기 버튼을 추가해주세요.”
- “SSO가 필요합니다.”
- “대시보드를 커스터마이징할 수 있게 해주세요.”
대부분의 요청은 해결해야 할 문제를 가리고 있는 표지에 불과해요. PM의 역할은 그 아래에 있는 “왜”를 밝혀내는 거예요.
- 무엇을 달성하려는 것인가?
- 어디에서 마찰이 생기는가?
- 리스크는 무엇인가?
- 진짜 제약 조건은 무엇인가?
(1) 제품 발견(Product Discovery) 과정에서 유용한 질문
누군가 기능을 요청하면, 이 질문들을 순차적으로 따라 내려가보세요.
- “사용자가 무엇을 달성하려고 하나요?”
- “그것이 왜 중요한가요?”
- “사용자가 할 수 없을 때 오늘 무슨 일이 일어나나요?”
- “사용자가 지금은 어떻게 해결하고 있나요?”
- “구체적으로 ‘더 나은’ 모습은 어떤 건가요?”
(2) “더 빠른 말” 함정과 피하는 법
말의 세상에 사는 사람들에게 물어보면, 많은 사람이 “더 빠른 말”을 요청할 거예요. 즉, 상상할 수 있는 범위에 제약이 있을 뿐이죠.
PM의 역할은 표면적인 요청에 치우치지 않고 그 속의 본질적인 이유를 파악하는 거예요.
- “더 빠른 말”은 고객이 표면적으로 요청하는 무엇(What)이에요
- “A에서 B로 더 빠르고 저렴하게 이동하기”는 그 요청에 본질적인 이유를 나타내는 왜(Why)예요
- 그렇기 때문에 “빠른 말”이나 “자동차”는 가능한 솔루션들 중 하나일 뿐이에요
(3) 이해관계자 미팅에서의 실무 팁
임원이 “X를 만들어야 합니다”라고 말할 때, 방어적으로 들리지 않도록 하면서 대응할 수 있어요.
- “어떤 부분에서 그렇게 말씀하시는지 충분히 이해합니다. X에 착수하기 전에, 어떠한 결과를 목표로 하고 계시는지, 그리고 또 저희가 놓치고 있는 문제는 없는지에 대해 함께 더 자세하게 얘기해 볼 수 있을까요?”
이렇게 하면 대화가 “내 아이디어 vs 네 아이디어”에서 “공동의 문제 해결”로 전환돼요.
지난 편에서 의사결정 원칙의 필요성과 함께 “솔루션이 아닌 문제를 소유하라”와 “‘왜’에 집착하라”라는 두 가지 원칙을 살펴봤어요. 이번 편에서는 나머지 세 가지 원칙을 다뤄볼게요. 성과에 책임지는 것, 협업을 공동 문제 해결로 만드는 것, 그리고 통제가 아닌 맥락을 제공하는 것이에요.
원칙 3: 산출물이 아니라, 성과에 집중하라
1) 성과를 책임진다는 것
단순히 기능이나 제품을 출시한다는 것이 중요한 게 아니에요. 출시는 출발선일 뿐이에요.
산출물(Output)은 이런 것들이에요.
- 기능
- 개선된 사용자 흐름 또는 디자인
- 제품
- 마이그레이션된 시스템
성과(Outcome)는 이런 것들이에요.
- 활성화율(Activation Rate)이 개선되었다
- 가치 도달 시간(Time-to-Value)이 줄었다
- 잔존(Retention)이 증가했다
- 고객 지원 티켓이 줄었다
- 계정당 매출이 늘었다
- 이탈률(Churn)이 낮아졌다
성과에 책임지는 PM은 매우 다른 로드맵을 만들어요. 산출물에 책임지는 PM은 그저 바쁘기만 하고 실질적인 성과가 낮은 로드맵을 만들죠.
(1) 로드맵이 잘못되는 방식
로드맵이 의도치 않게 이런 것이 될 수 있어요.
- 약속의 목록
- 정치적 합의
- 보여주기식 문서
더 건강한 로드맵은 가설 목록(Bet List)이에요.
- X 세그먼트의 Y 문제를 해결하면 Z 지표가 개선될 것이라고 믿는다
- 증거가 보일 때까지 테스트하고 반복한다
(2) 실무 도구: 만들기 전에 성공 기준 작성하기
개발이 시작되기 전에 이것을 작성해보세요.
- 핵심 지표: 움직여야 할 하나의 숫자
- 기대 방향: 얼마만큼 올라가거나/내려가야 하는가
- 평가 시점: 언제 평가할 것인가
- 선행 지표: 초기 신호 (예: 기능 채택률)
- 가드레일: 나빠지면 안 되는 것 (예: 레이턴시, 이탈률)
이렇게 하면 명확함이 강제되고, “출시했으니 끝”이라는 사고가 방지돼요.
산출물과 성과의 차이를 비유하면, 다이어트에서 “매일 헬스장에 간다”(산출물)와 “체중이 5kg 줄었다”(성과)의 차이와 같아요. 헬스장에 매일 가도 식단을 관리하지 않으면 체중은 안 줄어요. PM도 마찬가지로, 기능을 많이 출시하는 것 자체가 아니라 그 결과로 고객의 삶이 나아졌는지가 진짜 성과인 거예요.
2. 원칙 4: 협업은 문서 전달이 아닌 공동의 문제 해결이다
1) 공동의 문제 해결로서의 협업
많은 팀이 협업을 “문서를 돌려가며 전달하는 것”으로 혼동하곤 해요.
PM이 요구사항 작성 → 디자이너가 디자인 → 개발자가 개발
이건 협업이 아니에요. 아웃소싱과 다름 없는 릴레이 경주죠.
진짜 협업은 이해와 공유에 기반한 반복적인 과정이예요.
(1) 훌륭한 협업의 모습
문제 이해 → 선택지 탐색 → 가정 검증 → 빌드 → 학습
- PM은 맥락, 고객 인사이트, 비즈니스 제약 조건을 가져온다
- 디자인은 사용자 경험 사고와 사용성 검증을 가져온다
- 엔지니어링은 기술적 실현 가능성, 확장성, 현명한 트레이드오프를 가져온다
모두가 “자기 차례”가 되었을 때가 아니라, 초기부터 참여하는 거예요.
간단한 규칙이 있어요. 디자이너와 엔지니어가 해결책이 결정 및 설계된 후에야 문제를 보게 된다면, 그들이 제공할 수 있는 좋은 피드백들을 놓치고 있는 거예요.
(2) “숙제 기반 협업”
건강한 팀은 협업을 이렇게 다뤄요.
- 각자 자기 숙제를 해온다
- 의견이 아닌 선택지를 가지고 모인다
- 이견은 권위가 아닌 근거로 해결한다
“숙제”의 예시를 볼게요.
- PM: 사용자 고통점, 임팩트 산정, 제약 조건, 성공 지표
- 디자인: 플로우, 프로토타입, 사용성 노트
- 엔지니어링: 아키텍처 옵션, 공수 및 개발 범위, 리스크
PM의 역할은 모든 분야에서 가장 똑똑한 사람이 되는 게 아니에요. 각 전문가가 자신의 최고 역량을 발휘할 수 있는 환경을 만드는 거예요.
협업을 비유하면, 밴드에서 곡을 만드는 과정과 같아요. 보컬이 가사를 쓰고 기타리스트에게 “이거 연주해”라고 건네는 건 협업이 아니에요. 처음부터 함께 모여서 “이 곡의 느낌은 이렇고, 이런 메시지를 전달하고 싶어”라고 공유한 뒤, 각자의 파트를 실험하면서 곡을 완성해가는 게 진짜 협업이죠.
원칙 5: 명령이 아니라, 맥락을 제공하라
1) 맥락을 제공한다는 것
PM은 종종 일을 진행시켜야 한다는 압박감에 통제하려 하게 돼요. 하지만 강한 팀에게 필요한 건 상사와 같은 지시자가 아니에요. 명확함이에요.
맥락은 자율성을 가능하게 하는 것이에요.
- 무엇을 달성하려는가?
- 왜 지금 중요한가?
- 진짜 제약 조건은 무엇인가?
- 어떤 근거가 있는가?
- 어떤 트레이드오프가 수용 가능한가?
통제는 순응을 만들어요. 맥락은 오너십을 만들죠.
(1) 통제는 유혹적이지만 위험하다
사람들을 찍어누르는 것은 단기적으로는 효율적으로 느껴져요. 하지만 다음과 같은 현상이 발생하죠.
- 토론이 줄어든다
- 결정이 빨라진다
- 지시가 명확하다
이러한 현상들이 지속되고 여전히 통제에 지나치게 의존하면 다음과 장기적인 문제가 생겨요.
- 팀의 프로덕트 사고가 약해진다
- 학습된 무력감(Learned Helplessness)이 생긴다
- 낮은 책임감 (“시킨 대로 만들었을 뿐이에요”)
- 번아웃과 이탈
(2) 실무 도구: “맥락” 제공 문서
이니셔티브를 시작할 때, 원페이저(One-pager)를 공유해보세요.
- 문제 프레이밍 (원칙 1에서 다룬 것)
- 우리가 아는 것 (데이터, 사용자 인사이트, 시장 현실)
- 우리가 모르는 것 (리스크, 가정)
- 제약 조건 (시간, 기술, 정책)
- 성공 지표 (원칙 3에서 다룬 것)
- 의사결정 오너와 타임라인
맥락 제공을 비유하면, 내비게이션과 운전대의 차이와 같아요. 운전대를 빼앗아 직접 몰면(통제) 한 명만 운전할 수 있지만, 목적지와 도로 상황을 알려주면(맥락) 누구든 자신의 판단으로 최적의 경로를 찾을 수 있어요. 좋은 PM은 팀의 운전대를 잡는 게 아니라, 최고의 내비게이션을 제공하는 사람이에요.
다음 편에서는 PM이 스스로에게 세워야 할 세 가지 내적 기준을 살펴볼게요.