brunch

라이킷 35 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 맨오브피스 Sep 26. 2021

PM 업무에 꼭 필요한 소프트 스킬 6가지

나는 프로덕트 매니저(PM) 일을 오래 한 것은 아니다. 쭉 사업부에서 일을 하다 PM으로 갈아탄 지 겨우 4년밖에 되지 않았다.

PM이 되고 나서 '소프트 스킬이 정말 중요하구나'라는 것을 여러 번 느꼈다. 여기서 소프트 스킬이란 문해력, 경청하기, 시간 관리 등 스펙에는 나타나지 않는 것을 말한다. 물론 소프트 스킬은 다른 포지션에서도 중요한 요소이지만 PM 일을 하면서 특히 더 자주 느낀다.

개인적으로 생각하는 PM에게 중요한 소프트 스킬을 6개 뽑아보았다.

1. 문해력과 글쓰기 능력

메라비언의 법칙에 따르면 사람 간의 커뮤니케이션에서 언어의 내용이 차지하는 비중은 7%뿐이고, 나머지 93%는 바디랭귀지나 목소리톤 같은 비언어적 요소로 이루어져 있다. 사람은 같은 내용이라도 비언어적 요소에 따라 각자 다르게 받아들인다.

문제는 우리가 서로의 얼굴을 볼 기회가 많이 줄었다는 점이다(100% 원격으로 일할 경우 더욱 그렇다). 모든 걸 디지털 도구로 처리하는 것은 이제 새로울 일도 아니다. 프로젝트는 JIRA나 노션(Notion), 정보는 구글 문서, 전달 사항은 슬랙이나 이메일 같은 툴로 관리하는 것은 당연한 일이 된 지 오래다. 덕분에 비언어적 내용을 확인하기 힘들어졌다.

그러다 보니 커뮤니케이션의 7%밖에 되지 않는 언어적 요소에 무게감이 쏠리게 되었다. 상대방 글의 내용뿐만 아니라 맥락과 의도까지 정확히 파악할 수 있느냐 없느냐가 중요해졌다. 그 반대도 마찬가지다. 내가 전달하고자 하는 내용이 (어느 누가 읽어도) 똑같이 받아들여질 수 있게끔 글을 쓰지 않으면 필연적으로 커뮤니케이션 낭비가 발생하게 되었다.

PM은 티켓을 작성하고 개발자는 그 내용을 바탕으로 프로그램을 만든다. 그러니 같은 티켓을 놓고 '우리 둘 다 같은 이야기를 하고 있는가?'라고 물었을 때 질문을 했을 때 반드시 '예'가 나와야 한다.

개발자가 '1번 내용 이해가 잘 안 되네요'라고 티켓 코멘트를 달았다면, '어떤 부분이 이해 안 되시나요?'라고 되묻기 전에 스스로 검토해보자. 티켓에 맥락과 의도가 잘 드러나있는지, 모호한 부분은 없는지 살펴보고 수정하자. 그러지 않으면 서로 코멘트 주고받느라 한 세월 지나버린다.

2. 상대방의 언어로 말하기

PM 일을 하려면 다양한 사람들과 소통해야 한다. 개발자들과도, 사업부 사람들과 이야기해야 한다. 이때 상대방의 언어로 말해야 비로소 통할 수 있다.

개발자에게 무언가를 요청할 때는 두루뭉술함을 경계해야 한다. 개념을 설명할 때야 잠깐 두루뭉술할 수 있지만 '그래서 어쩌라고' 상태가 되지 않도록 주의해야 한다. 예시를 만들거나 코드의 위치를 명시하여 요청 내용을 명확히 해야 한다. 코드에서는 흑백이 명확해야 한다. PM의 설명이 애매하면 개발자는 그 애매함을 어떻게 처리해야 할지 난감해진다.

[애매함] "FAQ 페이지를 자주 방문하는 유저에게 도우미봇 아이콘 표시"
[명확함] "유저가 FAQ 페이지를 24시간 내에 3번 방문했을 시 도우미봇 아이콘 표시"

반대로 사업팀과 이야기할 때는 너무 자세한 내용까지 설명하지 않도록 조심해야 한다. 사업팀 일에 그렇게 디테일한 내용까지는 필요 없다(필요해지면 그때 제공하면 된다). 처음부터 정보를 쏟아부으면 혼란스럽기만 하다. 사업팀이 관심 있는 건 '이 제품은 고객한테 어떤 메리트를 줄 수 있을까' '다른 제품과 비교해 어떤 점이 특별한가'이다.

[Before] "응답 JSON의 오브젝트 개수를 제한할 수 있는 limit 파라미터 추가"
[After] "응답 데이터의 양을 제한할 수 있는 기능 추가"

3. 정말로 귀담아듣기

스테디셀러인 <데일 카네기 인간관계론>에는 사람들이 '자기 이야기를 하는 것을 얼마나 좋아하는지'에 관한 여러 예시가 나온다. 사람들은 자기 이야기를 하느라 바쁘다. 하지만 PM은 다른 사람의 이야기를 듣는 것도 좋아해야 한다.

사업팀과 이야기하다 보면 재미있는 이야기를 많이 들을 수 있다. '고객들이 개발 문서가 어디 있는지 찾기 힘들대' '파트너 계정을 만들 때마다 어떤 값을 입력해야 할지 몰라서 컨닝 페이퍼를 만들었어' 같은 말을 나왔을 때, 더 자세히 이야기해줄 수 없는지 질문하고 경청해야 한다.

기능을 추가 해달라거나 버그를 수정해달라는 요청사항은 항상 예쁘게 포장되어 오지 않는다. 오히려 지나가는 이야기나 메시지에 숨어있는 경우가 많다. 이런 시그널을 빨리 포착할 수 있으면 가설을 세우고 데이터로 검증하는 단계를 여러 개 건너뛸 수 있다.

예전에 미팅 중 개발자 한 명이 '개발팀에겐 별로 자율권이 없잖아? 하하'라며 농담조의 말을 던졌다. 처음에는 '어떤 식으로 개발하는지 전혀 터치하지 않는데 자율권이 없다니?'라는 생각이 들었다. 하지만 그에게 질문을 던지며 계속 들어보니 결국 '개발자가 개발하고 싶은 내용(예: 라이브러리의 판올림 작업 등)도 우선순위에 넣고 싶다'는 뜻이었다.

우리는 그의 의견을 수용해 '우선순위의 20%는 개발팀에서 정한다'라는 룰을 만들었다(다만 개발 내용이 제품에 도움이 된다는 전제 하에). 그가 자율권 이야기를 했을 때 '없긴 왜 없어'라든가 '우리 모두 직장인인데 자율권이 있을 리가~ 하하' 같이 농담으로 넘겼다면 개선할 수 없었을 것이다.

4. 진심으로 공감하기

다른 사람의 의견에 그럭저럭 공감하는 것은 별로 어렵지 않다. 우리 모두 같이 일하는 사이이기 때문에 어느 정도 공감대가 형성되어있기 때문이다.

하지만 다른 사람의 말에 진심으로 공감하기란 참으로 힘들다. 위에서 언급한 '정말로 귀담아듣기'와 연결된 내용인데, 다른 사람의 말에 공감하기보다는 다른 사람들이 내 말에 공감해주는 것이 더 기분 좋기 때문이다.

그러나 '이 사람은 내 말에 귀 기울여주고 공감해주는구나'라는 연결 고리를 형성할 수 있다면 속마음을 나누기 수월해진다. 회의 중에 대충 흘러나오는 피상적인 의견 말고, '사실은…'이라는 운으로 시작하는 진짜 의견을 얻게 된다. 서로의 진심을 나눌 수 있는 순간은 흔치 않기 때문에 귀중하다.

내가 몸담고 있는 팀에서는 원래 2주 단위의 스프린트 형식으로 개발을 진행했었다. 2주마다 스프린트를 점검하며 프로세스를 지속적으로 가다듬었다. 하지만 스프린트 점검 시 개선 의견을 내는 것은 대부분 PM들이었다. 개발팀에서 나오는 의견도 왠지 '의견을 내야 할 것 같아서 낸다'는 느낌을 지울 수 없었다.

그래서 평소 말이 잘 통하는 개발팀 리더와 따로 미팅을 잡았다. 내 우려를 털어놓으니 그는 '사실 개발팀 내에서 스프린트 점검은 그냥 귀찮지만 해야 하는 절차라는 느낌'이라는 진실을 말해주었다. 우리는 긴 대화 끝에 '굳이 스프린트 형식일 필요가 있을까'라는 결론에 도달했고, 개발 프로세스를 칸반 스타일로 바꿨다. 개발 효율이 눈에 띄게 좋아졌고, 제품도 안정성이 중요한 시기로 접어들었기 때문에 프로세스와 잘 맞았다.

사실 진심으로 공감하기보다 그냥 내 일만 착실히 하는 것이 더 편하다. 하지만 나부터 공감해주어야 협업을 이끌어낼 수 있다. 물론 어려운 일이지만 PM이라면 꼭 해야 하는 일이다.

5. 감정 내려놓기

PM은 제품에 대해 수많은 결정을 내린다. 그리고 왜 그런 결정을 내렸는지 사람들에게서 질문을 받는다.

여기서 사람들의 질문을 PM 자신에 대한 공격으로 받아들이지 않는 것이 중요하다. 사실 사람들이 질문하는 것은 당연히 있을 수 일인데, PM이 방어적인 태도를 취해버리면 상대방도 마음 편히 질문할 수 없다. 무례한 질문이 아닌 이상, 제품의 질문을 받으면 차분하게 설명해주어야 한다.

하지만 제품과 나 자신을 분리해서 생각하는 것은 생각보다 쉽지 않은 일이다. 예를 들어 페이지 만들기 버튼을 페이지 상단에 배치한 것에 대해 "왜 상단에 배치했어요?"라는 질문을 받았다고 하자. 상대방은 그냥 궁금해서 질문한 것인데, 괜히 머릿속에서는 '왜 그딴 위치에 배치했어요??'라고 읽힐 수 있다.

그러지 않기 위해 결정을 내릴 때 반드시 근거 데이터를 기반으로 하자. 그리고 '제품과 나는 별개'라는 사실을 계속 상기하자. 그러지 않으면 쓸데없는 자괴감의 연속이다. 질문을 받으면 '어떻게 되받아칠까'에 몰두해버리곤 한다. 질의응답은 이내 자존심 지키기 토크로 변질되어버린다.

6. 기뻐하기

버그가 잡히고 새 기능이 추가되었다면 기뻐하자. 백엔드 퍼포먼스가 얼마나 향상되었는지, 제품이 얼마나 더 팔렸는지는 모두 수치로 측정할 수 있다. 하지만 프로덕트 매니저의 기뻐하는 얼굴과 이모티콘에 비할 바는 아니다.

개발한 사람이나 영업하는 입장에서 누군가를 기쁘게 만들었다는 감정은 강렬하다. 그래프 곡선이 위로 올라가는 것보다 와닿는다. '지난 경기보다 16점 더 높은 점수를 내서 기쁩니다'라는 말보다 '팬들에게 우승으로 보답하게 되어 기쁩니다'라고 말하는 선수에 더 호감이 가는 것과 같다. 그러니 PM이라면 먼저 나서서 기뻐하자. 기쁨은 전염된다.

다만 인위적으로 기뻐하면 안 된다. 억지로 기뻐하면 와닿지 않는다. 사람이다 보니 기쁨이 우러나오지 않을 때가 더 많다. 그때는 소소하게 감사 코멘트나 짤을 보내는 것도 괜찮다. 내가 못하는 영역을 대신해주는 것에 고마움을 전하자. 기쁨과 감사로 이어진 관계가 생산성을 높이고, 공감을 이끌어내고, 같은 언어를 말하게 해 주어 결국 더 좋은 제품 개발로 이어진다.