쏟아지는 업무 속, 정말 중요한 일을 찾는 법

ACE REPORT EP31. 쿠팡 출신 곽나래 PM

오늘도 할 일 목록을 보며 한숨을 쉬었나요?

모든 일이 다 급해 보입니다. 모든 일이 다 중요해 보이죠.

하지만 한정된 시간과 에너지로는
모든 것을 완벽하게 해낼 수 없습니다.

그렇다면 무엇을 먼저 해야 할까요?

ⓒ 건강미디어

사회초년생들에게는 더욱 어려운 문제입니다.

무엇이 정말 중요한 일인지 판단하기 쉽지 않으니까요.

이런 고민에 대한 답을 찾기 위해 저희는 '우선순위'와 떼려야 뗄 수 없는 일잘러를 찾았습니다.

SSG닷컴에서 커리어를 시작해 쿠팡에서 검색 경험을 설계한 곽나래 PM.

현재는 블록체인 스타트업에서 새로운 도전을 이어가고 계신데요.

책『제품을 성공시키는 프로덕트 매니저의 비밀』의 저자이시기도 합니다.

매일 쏟아지는 업무 속에서 정말 중요한 일을 찾는 법.

곽나래 PM님과 함께 알아보겠습니다.

쿠팡 실리콘밸리 팀에서 배운 '일의 순서' 관리하는 법 | 곽나래 PM [ACE REPORT] ep.

▲ 'AND 앤드' 채널에서 오늘의 일잘러를 만나볼 수 있습니다.

---

Q. 자기소개 부탁드립니다.

안녕하세요. 프로덕트 매니저 곽나래라고 합니다.

ⓒ AND

SSG닷컴에서 프로덕트 매니징 커리어를 처음 시작했고,

쿠팡에서 검색 경험을 만드는 시니어 프로덕트 오너로 일했어요.

ⓒ AND

쿠팡에서는 실리콘밸리 팀과 함께 일하며 다양한 업무 방법론들을 배울 수 있었습니다.

현재는 새로 성장 중인 산업에서 더 많은 기회가 있을 거라고 생각해서,

현재는 블록체인 스타트업에서 0 to 1을 만들기 위해 새로운 도전을 하고 있습니다.

---

Product Manager.

왠지 낯설게 느껴지는 직업입니다.

한국에서 알려진 지도 그리 오래되지 않은 직무이죠.

또, 개발, 디자인, 마케팅과 달리 PM의 과업은 잘 그려지지 않는 것 같은데요.

Product Manager는 대체 어떤 일을 하는 사람일까요??

---

Q. PM의 역할에 대해 설명해 주실 수 있을까요?

PM이라는 직무를 낯설게 생각하시는데요.

쉽게 생각하면

우리는 모두 자기 자신이라는 프로덕트를 매니징 하는
Product Manager거든요.

ⓒ AND

우리 모두 달성하고자 하는 목표와 욕구가 있고

본인이 가진 능력과 시간, 돈 등의 자원이 있어요.

우리는 매 순간 이것을 종합적으로 고려해서

어떤 일에 시간과 자원을 투입할 것인지를 결정하죠.

의사 결정하고, 결정한 일이 잘 실행되도록 매니징하고,

결과가 나오면 피드백해서 개선하는 것이 프로덕트 매니저의 일입니다.

입시를 예로 들어볼게요.

개발자가 되고 싶다는 목표가 있다면, 대학을 갈지 말지, 국내 입시를 할지 유학을 할지 등

많은 선택지가 있어요.

ⓒ AND

내가 중시하는 것과 제약 조건을 고려해서 최선의 선택을 하는 거죠.

(ex. 영어가 약하고, 유학 갈 형편이 안되니 국내 입시가 좋겠다.)

목표를 정했다면 성과를 내기 위해 계획을 세우고 실행하면서 계속 점검하고 보완해야 해요.

(ex. 성적관리는 어떻게 하면 좋을까?)

Product Manager는 이 과정을
회사에서 하는 역할이에요.

여러 직무의 동료들과 협업하면서 프로덕트의 시작부터 끝까지,

의사 결정하고 분석하고 책임지는 역할입니다.

---

곽나래 PM님의 설명을 들으니 PM이라는 직무가 한결 명확해졌습니다.

"우리 모두는 자신의 인생에 대한 PM"이라는 관점은 특히 인상적인데요.

목표를 설정하고, 자원을 배분하고, 실행하고, 피드백하는 과정이

개인의 삶에서나 회사에서나 본질적으로 동일하다는 통찰이었습니다.

어찌 됐든 Product Manager는 그런 일을 '회사 안에서' 수행하는 사람입니다.

그렇다 보면 다양한 이해관계자들의 상황을 고려해 수많은 의사결정을 해야 할 텐데요.

PM으로서 일하며, 우선순위 설정이 필요하다고 느껴지는 순간들이 궁금해졌습니다.

---

Q. 업무를 하며 우선순위 설정이 필요하다고 느끼는 순간들이 있을까요?

우선순위를 결정하는 일이 PM이 하는 일 중에서 가장 중요한 일이라고 봐도 무방해요.

아무리 뛰어난 개발자, 디자이너, 여러 팀원들이 있어도

목표와 우선순위 설정부터가 잘못되면 뛰어난 항공모함을 가지고 산으로 가는 격이거든요.

핵심은 우리의 리소스는 제한적이라는 거예요.

무언가를 한다는 의사 결정은
다른 것을 하지 않는다는 뜻입니다.

따라서 가장 중요하고, 했을 때 성과가 큰 일을 먼저 해야 해요.

ⓒ AND

예를 들어 커머스에서 일할 때, 전사 목표가 구매 전환율 증가였어요.

검색 전반에 큰 영향을 미치는 프로젝트를 먼저 하고, 매출 볼륨이 큰 카테고리부터 개선했죠.

볼륨이 작은 카테고리는 개선해도 목표 달성에 유의미한 영향을 못 끼칠 수 있어서,

우선순위를 뒤로 미뤘어요.

각 카테고리 리더들의 요청을 많이 거절하곤 했습니다.

제약 조건도 고려해야 하죠.

효과는 좋지만 몇 달 걸리는 방법과

임팩트는 약하지만 가볍게 시도할 수 있는 방안 사이에서 매번 고민해요.

---

업무를 하다 보면 누구나 겪는 상황이죠.

모든 일이 다 중요해 보이고, 모든 일이 다 급해 보이는 순간 말이에요.

곽나래 PM님의 핵심 메시지는

"무언가를 한다는 의사 결정은 다른 것을 하지 않는다는 의사 결정"이라는 점이었습니다.

시간과 에너지는 한정되어 있으니까요.

그렇다면 우리는 어떤 기준으로 우선순위를 정해야 할까요?

---

Q. 우선순위 설정 노하우가 있을까요?

제가 우선순위를 정할 때 쓰는 여러 방법론이 있어요. 상황에 맞게 쓰시면 도움이 됩니다.

#1. 아이젠하워 매트릭스 - 일의 성격 구분하기

상이한 성격의 일들 사이에서 고민될 때는 아이젠하워 매트릭스를 떠올려요.

일을 중요도와 긴급도, 두 가지 축으로 나눠 평가하는 방법이에요.

ⓒ AND

간단해요. 중요하고 급한 일은 먼저 하고,

중요하지만 긴급하지 않은 일은 일정을 정해서 진행하면 돼요.

핵심은 중요하지 않은 일들을 어떻게 다루느냐예요.

중요하지 않은 일은 최대한 하지 않아야 해요.

명확하게 거절하고 설득해서 제거하는 것이 중요합니다.

예를 들어 아젠다 없는 정기 미팅이나 임팩트 낮은 업무 요청 같은 거죠.

중요하지 않지만 급한 일들은 자동화하거나, 문서화하거나, 위임해야 해요.

반복되는 데이터 요청은 대시보드로 자동화하고, 자주 받는 질문은 문서화해서 공유하는 식으로요.

#2. RICE 프레임워크 - 프로젝트 우선순위 매기기

여러 프로젝트 중 어떤 것을 먼저 할지 판단할 때는 RICE 프레임워크를 써요.

Reach(영향 범위), Impact(효과), Confidence(확신), Effort(노력)를 따져보는 거예요.

ⓒ AND

쉽게 말하면

*Reach(영향 범위) : 얼마나 많은 사람에게 영향을 주는지,

*Impact(효과) : 얼마나 중요한 효과가 있는지,

*Confidence(확신) : 내가 이 판단에 얼마나 확신이 있는지,

*Effort(노력) 얼마나 힘이 드는지

따져보는 거예요.

예를 들어 제가 제약회사 영업사원이고 고혈압 치료제를 담당한다고 해볼게요.

*상황 설정:

A약: 신약인데 효과가 좋은 대신 고가, 처방 조건이 까다로움

B약: 기존 약인데 저렴하고 사용이 쉬워서 시장 인지도도 꽤 있음

*타깃별 특징:

대학병원
: A약 같은 고가 약도 쓸 수 있지만,
의사 결정 구조가 복잡해서 설득이 어렵고 시간이 오래 걸림

중형 종합병원
: 빠른 의사 결정이 가능하지만 예산이 부족해서 고가 약은 부담스러워함

개인 병원
: 의사 결정은 빠르지만 대량 처방은 어려움

*RICE로 비교해 보면:

중형병원 + B약: Reach 높음(많은 환자), Impact 괜찮음, Confidence 높음(빠른 결정), Effort 적음

대학병원 + A약: Impact는 클 수 있지만 Confidence 낮음(복잡한 결정구조), Effort 큼

개인병원: Reach나 Impact가 낮음

ⓒ AND

이렇게 비교하면 중형병원에 기존약 영업부터 시작하는 게 합리적인 선택이 돼요.

RICE 프레임워크를 쓰면 감에 의존하지 않고도 전략적인 선택을 할 수 있죠.

#3. MoSCow 방법론 - 리소스 투입범위 결정

우리가 리소스를 어디까지 투입해야 할지,

혹은 하나의 프로덕트 내 기능들의 우선순위를 정할 때는 MoSCoW 방법론을 써요.

Must have, Should have, Could have, Won't have로 나눠, 중요도를 판별하는 겁니다.

ⓒ AND

Must have : 반드시 해야 할 것

should have : 중요하지만 필수적이진 않은 것

Could have : 하면 좋은 것

Won't have : 하더라도 효과가 미미한 것

신규 은행 앱을 출시한다고 가정할 때,

MoSCow 방법론으로 정리하면 아래와 같이 정리할 수 있죠.

Must have: 계좌 조회, 송금 (없으면 출시 불가)

Should have: 체크카드 신청 (있으면 좋지만 없어도 출시 가능)

Could have: 거래 알림 설정 (우선순위 낮음)

Won't have: 다국어 기능 (이번 버전에서는 제외)

이렇게 정해놓으면 우리가 리소스를 어디까지 투입할지 명확한 기준이 생겨요.

사전에 모든 이해관계자들과 합의하고 갈 수 있고요.

---

수많은 업무들이 쏟아지고, 모든 게 중요해 보일 때

생각 정리를 하는 게 쉽진 않은데요.

감으로 하기보다, 곽나래 PM님께서 소개해주신 다양한 방법론들을 활용하면

보다 체계적으로 업무의 우선순위를 정할 수 있을 것 같습니다.

그런데, 리가 업무를 하며

우선순위만큼, 사실 우선순위보다 더 중요한 것이 있습니다.

바로 '목표'죠.

우리는 모두 목표를 달성하기 위해 일합니다.

우선순위도 목표에 따라 정해지고요.

목표를 효과적으로 달성하기 위해서 우리는 어떻게 일해야 할까요?

---

Q. 내가 수행하는 업무를 목표와 잘 연결하기 위해서 어떤 관점이 필요할까요?

일단 목표 자체를 잘 잡아야 합니다.

좋은 목표는 똑똑한 사람들이 최선을 다해 노력했을 때
달성할 수도 있는 목표인데요.

너무 비현실적이면 동기 부여가 안 되고, 너무 쉬우면 설정하는 의미가 없죠.

적당히 어렵지만 최선을 다하면 달성할 수도 있는 정도로 잡는 것이 좋아요.

적당한 정도를 파악하기 위해서 현재 내가 어느 수준에 있는가

베이스라인을 정확히 알고 목표를 세우는 것이 좋습니다.

저는 큰 목표(북극성 지표)를 잡고, 그 목표에 다가가기 위해

목표를 쪼개는 방법을 많이 사용하는데요.

ⓒ AND

예를 들어서 저에게 42km 풀 마라톤을 완주겠다는 목표가 있어요.

근데 제가 평소에 2-3km 밖에 못 뛰는 사람인데 무작정 풀마라톤 완주가 목표라고 하면 비현실적이겠죠.

어떻게 해야 할지 잘 모를 수 있고요.

그러면 타임라인을 잡고 마일스톤별 달성해야 할 목표를 쪼개면 도움이 돼요.

10km 마라톤 → 15km → 21km 하프 마라톤 → 42km 풀마라톤.

2-3km밖에 못 뛰던 사람이 42km 풀마라톤을 뛰려면 힘들겠죠.

> 못할 것 같은데요.

하지만 저렇게 단계적으로 접근하면 처음에는 불가능해 보였던 42km 풀마라톤도

비현실적이지 않은 목표가 되는 거예요.

10km 뛰는 사람은 15km가 어렵지만 할만할 것이고,

15km 뛰는 사람은 21km가 어렵지만 할만할 것이고,

그렇게 되면 언젠간 42km 풀마라톤을 뛸 수 있게 되는 거죠.

Q. 우선순위에 따라 업무를 수행한 후 피드백은 어떻게 진행하면 좋을까요?

평가 자체는 성과 지표로 하는 게 맞아요.

업무 투입 전에 목표로 세웠던 핵심 결과가 있었을 것이고,

그것을 달성했는지 여부가 평가 기준이어야 합니다.

중요한 건 실패했을 때 발전할 수 있는 방법이에요. 바로 회고죠.

회고는 비난을 위한 게 아니라
나아지기 위해서 하는 피드백 절차예요.

저는 세 가지 관점으로 회고를 진행해요.

Key(유지): 잘한 점들. 다음에도 계속 유지하면 좋을 것들

Problem(개선): 아쉬웠던 점들. 다음에 고치면 좋을 것들

Try(시도): 다음에는 다르게 해 봐도 좋을 새로운 시도들

이런 식으로 회고를 진행하면, 지식과 경험이 쌓여 다음 프로젝트에 큰 도움이 됩니다.

---

목표 설정과 회고는 우선순위 설정의 시작과 끝을 담당하는 참 중요한 요소입니다.

명확하고 달성 가능한 목표가 있어야 어떤 일이 우선순위가 높은지 판단할 수 있고,

결과에 대한 체계적인 회고가 있어야 다음번 우선순위 결정이 더 정확해질 수 있으니까요.

곽나래 PM님의 마라톤 목표 사례처럼,

큰 목표를 달성 가능한 작은 단위로 쪼개는 방법도 매우 실용적으로 느껴졌습니다.

그런데 여기서 한 가지 궁금한 점이 생겼습니다.

사실 Product Manager는 의사결정 권한이 있는 직무입니다.

그렇기 때문에 목표설정과 우선순위 설정이 가능하죠.

하지만 많은 사회초년생들은 보통 그런 권한이 없습니다.

의사결정 권한이 제한적인 상황에서 우리는 어떻게 일해야 할까요?

---

Q. 업무 통제권이 없는 스타터들이 가져야 할 마인드셋이 있을까요?

초년생일 때는 기합이 많이 들어있어요.

어렵게 들어간 회사에서 나를 증명하고 싶고 빨리 성장하고 싶어 해요.

모든 일을 '잘' 하려고 하는 회사 후배들도 많이 봐요.

하지만 이게 함정이에요.

ⓒ AND

초년생일 때는 노하우가 없어서 잘하기 어려워요.

모든 걸 잘하려고 하면
결국 아무것도 못한다는 거죠.

작게 빠르게 시작하고 고치기.

가장 핵심적인 것만 빠르게 보내고 고치는 게 나아요.

아웃라인이 잡히면 빨리 보여줘야 해요.

월요일에 보고 준비 지시를 받았고 데드라인이 금요일이라면,

화요일에는 아웃라인을 잡아서 "이 방향이 맞는지" 간단하게 질문해야 해요.

최악은 그냥 금요일에 완성본을 보여주는 것이에요.

원하는 게 아닐 가능성이 너무 크죠.

화요일에 질문했을 때 방향이 맞으면 상사가 더 구체적인 조언을 해줄 거예요.

"어느 쪽을 더 보완해라" 이런 식으로요.

내가 생각한 방향이 틀렸다면? 오히려 다행이에요.

화요일이니까 상사 피드백 듣고 고치면 되거든요.

상사에게 혼나는 것이나 프로젝트 실패를 두려워하지 마세요.

원래 한 번에 성공을 잘 못해요. AB테스트도 수백 번 해서 30% 성공하면 잘한 거예요.

완벽한 계획보다 중요한 건
빠르게 실행하고 결과를 분석해서 배우는 자세예요.

우선순위 정할 때도 실수할 수 있지만, 실수하면 회고하고 고치면 돼요.

거기서 배우면 나의 자산이 됩니다.

Q. 스타터에게 해주고 싶은 말?

오늘 우선순위에 대한 이야기나 일을 어떻게 하면 잘할 수 있을지에 대해서 이야기를 많이 했는데,

이런 방법론적인 것도 사실 알면 좋지만

더 중요한 건

먼저 해보고, 피드백을 토대로 빠르게 고쳐나가는 거예요.

처음부터 내가 원하는 제일 멋진 모습이 되지 않는다고 실망할 필요가 없는 것 같아요.

ⓒ AND

지금 할 수 있는 것을 해보고,

배움과 회고를 통해서 정리한 뒤 내가 찍은 점들을 연결해 나가면

결국에는 원하는 모습에, 북극성에 언젠가는 도착할 수 있지 않을까라는 생각이 듭니다.

---

매일 쏟아지는 업무 속에서 무엇이 정말 중요한 일인지 찾아내는 것.

생각보다 어려운 일이지만, 곽나래 PM님과의 대화를 통해 구체적인 해답을 얻을 수 있었습니다.

아이젠하워 매트릭스로 일의 성격을 파악하고,
RICE 프레임워크로 프로젝트의 우선순위를 매기고,

MoSCoW 방법론으로 기능의 중요도를 나누는 것.

이런 체계적인 접근이 있다면 감정이나 직감에만 의존하지 않고도 합리적인 선택을 할 수 있을 거예요.

하지만 무엇보다 인상 깊었던 건

"일단 먼저 해보고 빠르게 피드백받아서 고치고 더 나아가라"는 조언이었습니다.

완벽한 방법론을 아는 것보다, 작게라도 시작해서 배우고 개선하는 자세가 더 중요하다는 것.

그리고 처음부터 원하는 모습이 되지 않아도 괜찮다는 것.

지금 할 수 있는 것부터 시작해서 점들을 연결해 나가면

언젠가는 북극성에 도달할 수 있을 거라는 것.

그 말이 큰 위로와 용기가 됩니다.

*곽나래 PM님의 인사이트가 더 궁금하다면?

출처 : yes24

『제품을 성공시키는 프로덕트 매니저의 비밀』 일독을 권합니다.

https://www.youtube.com/@AND_studio

AND 앤드