PM으로 일하며 느낀, 꼭 필요한 역량 5가지

👋 시작하며

저는 PM, 서비스 기획자로서의 커리어가 아주 길지는 않습니다.
마케터로 시작해, 개발자와 기획을 병행하다가 지금은 본격적으로 PM 역할을 맡고 있기 때문입니다.

PM이 되고자 준비하는 분들이라면 한 번쯤은 이런 검색을 해보셨을 거예요.

“PM이 되려면 어떤 역량이 필요하지?”
“서비스 기획자는 어떤 자격이 있어야 하지?”

저 역시 마찬가지였습니다.
하지만 이 일을 하다보니, 기술적인 스킬보다 더 중요하다고 생각된 역량이 있습니다. 

그건 바로, 소프트 스킬입니다.

PM은 수많은 이해관계자와 끊임없이 커뮤니케이션하고,
부딪히는 문제를 조율하고, 불확실한 상황 속에서도 결정을 내려야 합니다.
그러다 보면 기술적인 능력 외에도, 사람과 함께 일하는 능력이 얼마나 중요한지를 실감하게 되었죠.

그래서 오늘은 제가 PM으로 일하면서 실제로 중요하다고 느낀,
그리고 더 잘하고 싶어 꾸준히 노력하고 있는 ‘PM의 소프트 스킬’에 대해 이야기해보려 합니다.

 

---

 

✍️ 1. 글쓰기
- 문서 하나에 담긴 ‘맥락과 의도’의 힘

기획 일을 하다 보면 가장 많이 쓰는 도구는 사실 ‘말’보다 ‘글’입니다.
회의록, 화면설계서, 슬랙 메시지, 노션 문서…
우리는 매일 무언가를 설명하고 설득하기 위해 글을 씁니다.

그런데 문제는, 글이 말만큼 많은 걸 담아내지는 못한다는 데 있어요.

---

🗣 더 중요해진 것: ‘누가 봐도 같은 의미’로 쓰기

요즘 대부분의 협업은 원격으로 이루어집니다.
회의보다 문서, 얼굴보다 슬랙으로 소통하죠.

비언어적 요소가 사라진 환경에서, 결국 ‘글’이 유일한 커뮤니케이션 수단이 되었죠.

이런 환경에서는
상대방이 내 글을 보고 맥락과 의도를 얼마나 정확하게 이해할 수 있는가,
그리고 누가 읽든 같은 의미로 받아들일 수 있는가가 매우 중요해집니다.

이 기준을 놓치면,
기획 문서 한 줄이 개발자에겐 다르게 읽히고,
슬랙 메시지 하나로 오해가 생기며,
결국 ‘수정’과 ‘되물음’의 악순환이 시작되더군요.

---

💬 PM의 글쓰기는 ‘코드의 재료’다

PM은 작업 지시서(예: 화면 설계서)를 씁니다.
개발자는 그것을 보고 실제 코드를 짭니다. 

즉, PM이 작성한 글은 프로덕트의 설계도이자 작업의 기준선입니다.

그래서 저는 설계서를 작성할 때마다 스스로에게 질문하려 노력합니다.

“이걸 보고 메이커들이(디자이너, 개발자) 나와 같은 생각을 할까?

 

만약 “이건 잘 이해되지 않아요”라는 피드백을 받는다면
다들 어떻게 하시나요? 바로 "어떤게 이해가 되지 않으세요"라고 묻고 있지는 않으신가요?

저 또한 전에는 그랬지만, 이제는 그 전에 먼저 제 문서를 다시 들여다봅니다.

• 맥락이 충분했는지
• 의미가 모호하지 않았는지
• 누구에게나 동일하게 읽힐 수 있는지

이렇게 한 번 더 고민하고 다듬는 것이 오래 걸릴 것 같지만
결국은 수십 번의 커뮤니케이션을 줄여줍니다.

“잘 쓴 글 하나가, 수십 번의 질문을 줄인다”
이건 요즘 제가 실무에서 뼈저리게 느끼고 있는 진실이에요.

 

---

 

🗣 2. 말하기
- 말투보다 중요한 상대의 언어로 말하기 

PM으로 일한다는 건 결국, 수많은 사람들과의 커뮤니케이션을 책임지는 일이라고 생각합니다.
기획자에게 커뮤니케이션 역량이 빠지지 않는 이유죠.

그런데, 같은 말도
누구에게 하느냐에 따라 ‘완전히 다른 언어’가 필요합니다.
마케터로서도 개발자로서도 일하다가 PM이 된
저이기에 누구보다 잘 인지하고 있는 부분이죠.

---

🧑‍💻 개발자에게 말할 때 – ‘두루뭉술’은 금물

개발자에게 요청할 때 가장 경계해야 하는 것은 무엇일까요?
바로, 모호한 설명입니다.

“대충 이런 느낌으로요”는 안 됩니다.
예시가 있든지, 정확한 조건이 있든지, 누가 봐도 명확하게 정의돼 있어야 해요.

예를 들어 이런 식이죠

🟡 [애매한 표현]
"유저가 위치를 인증하면 포토카드를 지급해주세요."

🟢 [명확한 표현]
"유저가 위치 확인 버튼을 클릭했을 때, 반환된 ZIP Code가 미국 10개 지역(비공개)의 유효한 5자리 숫자일 경우에만 포토카드를 지급한다. 유효성 검사는 서버 단에서 수행하며, 유효하지 않을 경우 별도로 A 모달을 노출한다."

 

개발자는 코드로 구현합니다.
우리가 작성한 문장이 애매하면, 그 애매함의 책임은 결국 개발자와 QA에게 떠넘겨집니다.
메이커들이 불필요한 에너지를 사용하게 되는 것이죠.

그래서 전 요청하기 전에 항상 저는 스스로 질문해요

• 조건이 분명한가?
• 예외 케이스는 없나?
• 다른 의미로 해석되지는 않나?

---

🧑‍💼 사업팀과 말할 때 – 디테일은 ‘필요할 때만’

반대로, 사업팀과의 커뮤니케이션은 오히려 디테일을 줄이는 것이 핵심입니다.
그래서 사업팀에게는 그 기능이 어떻게 구현되는가보다, 왜 필요한가, 어떤 효과가 있는가에 집중하죠.

앞서 이야기한 개발자에게 말하는 것처럼 너무 기술적인 용어나 구현 방식까지 얘기하는 것이 좋을까요?
아닙니다 오히려 핵심이 흐려져요

예를 들어 이런 요청 문장은,

🟡 [Before]
"포토카드 지급 로직은 유저가 GPS 기반 위치 권한을 허용하고, ZIP Code 유효성 검증을 통과한 뒤, DB에 저장된 지역 범위 내에 포함되는 경우에만 지급돼요. 클라이언트에서는 위치 API 호출 후 ZIP을 서버로 넘겨야 하고요."

이렇게 바꾸는 게 더 좋습니다

🟢 [After]
"유저가 위치 확인을 눌렀을 때, 설정된 지역 안에 있을 경우에만 포토카드가 지급돼요. 예를 들어, 콘서트가 열리는 LA 디즈니 홀 내에서만 받을 수 있도록 설정해, 실제 방문한 유저들에게만 혜택이 제공되도록 했어요."

핵심은 기술을 말하는 게 아니라,
무엇이 바뀌고, 고객에게 어떤 영향이 있을지를 말하는 것이에요.

---

🎯 결국, ‘상대가 이해하는 게 중요하다’

PM의 커뮤니케이션은 늘 양방향 설계여야 한다고 생각해요.
상대가 어떤 언어에 반응하는지를 먼저 파악하는 게 우선입니다.
뿐만 아니라, 내가 아는 것을 말하는 것이 아니라, 상대가 이해시키는 것이 중요합니다. 

• 개발자와 이야기할 땐, 모호함을 제거하세요.
• 사업팀과 이야기할 땐, 핵심만 전달하세요.

이 작은 차이가
팀의 실행 속도, 품질을 바꾸더군요

---

👂 3. 듣기
– 귀 담아듣기 : 단서와 본심은, 말에 숨어 있다

PM은 끊임없이 말해야 하는 역할이지만,
정말 좋은 PM은 ‘말을 잘하는 사람’이 아니라 ‘잘 듣는 사람’이라고 생각합니다.

📌 듣기는 단순히 조용히 있는 것이 아니라,
진심으로 귀 기울이고, 상대의 말 속에서 단서를 발견하며
숨겨진 맥락을 끄집어내는 능동적인 기술입니다.

많은 분들이 간과하지만,
사실 잘 듣는 건 잘 말하는 것보다 더 어렵습니다.
저 역시 이 부분을 가장 어렵게 느끼는 사람 중 하나예요.

대부분의 사람들은 상대의 말을 들으면서
곧바로 ‘내가 무슨 말을 할까’ 생각하느라
정작 ‘듣는 것’에는 집중하지 못하곤 하죠.

---

👀 ‘요청’은 항상 원하는 형태로 오지 않는다

기획자로 일하다 보면 여러 피드백들이 다양한 형태로 옵니다. 

겉으로 보기엔 그냥 잡담처럼 들릴 수 있지만,
이런 말들 속에는 사용자 불편, 정보 구조의 허점, 개선의 힌트가 숨어 있습니다.

PM이라면 이런 순간을 그냥 넘기지 말고,
한 번 더 묻고 한 줄 더 듣는 사람이 되어야 한다고 생각합니다.

---

🧩 신호는 말 끝에 숨는다

기능 추가 요청, 버그 제보, 개선 제안…
이런 이야기는 늘 “이 기능 만들어주세요!”처럼 오진 않아요.
오히려 지나가는 말 한 줄에 더 중요한 신호가 숨어 있는 경우가 많습니다.

예전에 한 CX 담당자와의 미팅 중, 이런 말이 나왔습니다.

“어차피 유저들은 FAQ에 있는 내용 또 물어보고, 우리는 또 기계처럼 똑같이 답하잖아요.”

처음엔 그냥 웃고 넘길 수도 있었지만,
저는 그 말을 붙잡고 다시 물어봤어요. 그리고 계속 듣다 보니…

결국 그의 말 속엔 이런 본심이 있었습니다

• “CS 이메일 주소를 외부에 노출하지 않고, FAQ 내부에서만 보이게 하면 안 될까요?”
• “유저들이 FAQ에 있는 내용을 또 묻는 경우가 너무 많아요.”
• "중복되는 CS 문의가 많이 들어와서 힘들어요."

즉, 불필요한 CS 응대를 줄일 수 있는 방향으로 개선했으면 좋겠다는 요청이었죠.

저는 이 피드백 그대로 
CS 이메일을 단순히 감추기보다는,
이메일 작성 전에 FAQ를 먼저 확인하도록 유도하는 모달과 스텝을 추가했습니다.
유저의 경험을 해치지 않으면서도, 내부 리소스도 고려한 구조로 개선된 셈이죠.

---

💡 PM은 듣고, 끄집어내고, 정리하는 사람

PM은 수많은 사람들의 이야기를 들으며
그 안에 숨은 불편, 의도, 가능성을 발견하고
그걸 요구사항으로 전환해 구조화하는 역할이라고 생각합니다.

단순히 듣는 것만으로는 부족하고,
무엇을, 어디서, 어떻게 캐치할 것인지가 훨씬 중요합니다.

그래서 저는 요즘 이렇게 스스로에게 물으려고 합니다.

• 지금 이 말은 어떤 문제를 담고 있지?
• 여기에서 놓친 개선 포인트가 숨어있지는 않을까?
• 무슨 의도로 말한 것일까?

이런 질문들이,
결국엔 눈앞에 보이지 않던 기회를 발견하는 감각을 키워준다고 믿어요.

 

---

🤝 4. 공감하기
– 진심으로 공감하고, 먼저 기뻐하기

앞서 말했듯, 좋은 PM은 ‘잘 말하는 사람’보다 ‘잘 들어주는 사람’입니다.
그리고 그 듣는 태도의 바탕에는 언제나 공감이 자리합니다.

---

📌 왜 공감이 반드시 필요할까?

프로덕트는 PM 혼자 만드는 게 아닙니다.
여러 사람의 생각과 손이 닿아야만 하나의 서비스가 만들어지죠.
그래서 회의나 리뷰 자리에서 나오는 피드백은 그 자체로 매우 중요합니다.

하지만 똑같은 피드백이라도
‘무언가 말해야 해서 내는 의견’과
‘내 의견이 진심으로 환영받는다는 느낌에서 나오는 의견’은 완전히 다릅니다.

“이 사람, 진짜 내 말에 귀 기울이고 있구나.”
이 감정을 상대가 느끼는 순간, 협업의 문은 열린다고 생각합니다.

---

💬 공감은 ‘기쁨’으로도 연결됩니다

버그가 해결되었을 때, 기능이 무사히 붙었을 때,
“고생하셨어요” 한마디,
“이건 이 분 덕분이에요”라는 한 줄 코멘트.

이런 작고 진심 어린 표현이 팀 전체에 주는 에너지는 생각보다 큽니다.

단순한 이모지나 자동화된 말이 아니라
‘정말 함께 기뻐하는 마음’이 전달될 때
팀원들은 더 몰입하게 되고, 서로를 더 신뢰하게 됩니다.

실제 제가 메이커분과 나눴던 슬랙 중 일부

저는 실제로 요청했던 개선 작업이나 신규 기능이 완료되면,
단순히 결과만 확인하는 게 아니라
그 기능으로 인해 얼마나 좋아졌는지를 메이커분들에게 꼭 공유합니다.

여기에 잊지 않고 누구보다 먼저 기뻐하고,
그 마음을 직접 전달하려고 노력합니다.
이런 저의 작은 행동은 메이커분들의 마음에 동기를 주고, 협업에 대한 태도를 바꿔놓더군요.
생각해보세요, 여러분이라도 이런 사람과 더 오래 일하고 싶지 않으신가요?

🎯 결국 PM은,
사람의 말을 잘 듣고, 그 마음에 진심으로 공감하며,
성과 앞에서 가장 먼저 박수칠 줄 아는 사람이 아닐까요?

 

---

 

🧘 5. 감정 배제하기
– 질문을 공격이라고 생각하지 말기

PM은 매일 수많은 결정을 내립니다.
그만큼 다양한 이해관계자들에게 수많은 질문도 받죠.

“왜 그렇게 기획했어요?”
“이 모달을 만든 이유가 있나요?”
“지금 꼭 업데이트해야 하는 기능인가요?”

이런 질문들을 반복해서 듣다 보면
누구라도 방어적으로 반응하고 싶어질 수 있죠.

그런데 저는 이렇게 생각하려고 해요.
“질문은 공격이 아니라, 이해해 나가는 과정이다.”

---

📌 제품과 나를 분리해서 보는 연습

내가 만든 기획안, 설계, 로직은
수많은 고민과 맥락을 거쳐 완성된 결과물입니다.
그래서 누군가 그것에 질문을 던지면
마치 나라는 사람을 부정하는 것처럼 느껴질 때가 있어요.

예를 들어,
“이 모달은 왜 넣었어요?”라는 질문을 받았을 때,
질무자는 그저 궁금해서 던진 말일 수 있지만
제 머릿속에서는 ‘왜 이렇게 말도 안 되게 만들었냐는 건가?’, '따지는건가'라는 식으로
불필요하게 방어 태세를 갖추게 되기도 하죠.

저도 과거에는 프로덕트와 저를 동일시하면서
질문을 받을 때마다 ‘내가 틀렸다는 건가?’라는 감정이 나오곤 했습니다.

그래서 그런 감정에서 벗어나기위해 다양한 노력들을 한 결과, 
결정을 내릴 때마다 ‘기준’과 ‘데이터’를 명확히 남기는 습관이 필요하다는 것을 알게 되었습니다. 

• “우리가 논의한 기준에 따라 이 위치에 배치했어요.”
• “이 데이터를 기반으로 이 기능이 필요하다고 판단했어요.”

이렇게 말할 수 있다면, 그 질문은 더 이상 나에 대한 공격이 아니라는 것을 알게 될거예요. 

---

🙋‍♀️ 방어보다 설명, 감정보다 근거

혹시 질문들이 들어왔을 때 나를 지키기 위한 말을 준비하지는 않으셨나요?

질문이 들어왔을 때,
‘나를 지키기 위한 말’을 준비하는 대신 ‘왜 이 기능을 이렇게 설계했는지’를
이성적이고 차분하게 설명할 수 있다면,
그건 나뿐 아니라 팀 전체에 대한 신뢰를 쌓는 기회가 된다고 생각합니다.

 

또한 질문을 받을 때,
“어떻게 해야 내가 옳다는 걸 설명할 수 있을까?”라는 생각보다,
“어떻게 설명해야 이 방향을 모두가 납득하고 함께 갈 수 있을까?”라고 생각으로 바꿔보는건 어떨까요? 

그 순간부터 질문은 더 이상 방어할 대상이 아니라,
더 나은 협업을 위한 출발점이 될 수 있습니다.

물론 쉽지 않습니다.
저도 아직 그 과정 속에 있고요.
그래서 더더욱, PM은 제품과 자아를 동일시하지 않으려는 노력이 필요하다고 생각합니다.

기획이 수정되었다고 해서 내가 틀린 건 아닙니다.
우리는 그저 더 나은 방향으로 이동하고 있을 뿐이에요.

---

🧵 마치며
– 결국, 사람과 일하는 일

PM이라는 역할은
기획하고, 우선순위를 정하고, 문서를 정리하는 일이기도 하지만
결국은 사람과 함께 일하는 일입니다.

요즘에는 무언가를 빠르게 잘 만드는 것보다
같이 일하는 사람들이 신뢰하고 몰입할 수 있는 환경을 만드는 것이
오히려 더 중요한 역할이라는 생각도 자주 들고 있고요. 

그래서 이번 글에서는
PM으로 일하며 제가 특히 중요하다고 느끼는
‘소프트 스킬’ 여섯 가지를 정리해보았습니다.

• ✍️ 글쓰기
• 🗣 말하기
• 👂 듣기
• 🤝 공감하기
• 🧘 감정 배제하기

물론, 이 모든 걸 항상 잘하기란 쉽지 않습니다.
저도 여전히 실수하고, 놓치고, 돌아보는 중이니까요.

하지만 분명한 건,
이런 태도를 계속 고민하고 실천하는 사람이
더 좋은 협업을 만들고, 더 오래 신뢰받는 PM이 된다는 걸 경험에서 확인해나가고 있습니다. 

오늘은 여기까지입니다.
긴 글 읽어주셔서 감사합니다 :)