토글 ( )을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다.
(전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )
)을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다.
(전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )목차 확인하기
1. 커뮤니케이션을 통해서 PM이 얻어야 할 것
사람은 사람 ‘인’한자에서 볼 수 있듯이 서로 기대어 살아가기 때문에, 커뮤니케이션은 우리의 일상입니다.
하지만 커뮤니케이션 방법은 상황에 따라 다르게 됩니다.
PC방에서 친구들과 커뮤니케이션할 때와 상견례장에서 양가 부모님들과 커뮤니케이션 할 때를 생각 해 본다면..
전자는 아마 남자분들은 공감하실텐데 정상적인 커뮤니케이션이 아닙니다. 여기까지 하겠습니다.
왜 커뮤니케이션 방법이 상황에 따라 다를까요?
•
우리는 커뮤니케이션을 통해서 상대방에게 당시 필요한 무엇인가 얻기를 바라기 때문입니다.
•
여기서 얻는다는 것은 물질적인 것만을 의미하지는 않습니다. 이미지, 즐거움 등등 다양한 것을 의미합니다.
•
PM에게 필요한 커뮤니케이션은 커뮤니케이션을 통해서 무엇을 얻어야하는지 정의하는 것에서 시작합니다.
(1) 제품 개선
PM이 커뮤니케이션을 통해서 얻어야 할 것은 무엇일까요?
당연히 같이 일하는 분들과 친하게 지내는 것도 얻을 수 있는 소중한 관계입니다. 하지만 PM이 커뮤니케이션을 통해서 궁극적으로 얻어야 할 것은 ‘제품개선’입니다. 동료와 친하게 지내는 것도 협업이 잘 돌아갈 수 있는 윤활유로서 작용해야 합니다.
오히려 너무 친해서 해야 할 일을 못하는 경우는 발생해서는 안됩니다.
(2) 메이커들의 기여
이를 가장 빈도가 높은 메이커들과의 커뮤니케이션에 적용한다면, 커뮤니케이션의 목적은 메이커들이 문제해결에 기여할 수 있도록 만드는 것입니다.
누군가는 카리스마에 바탕을 둔 강력한 커뮤니케이션을 하기도 하고, 누군가는 킹스 스피치로 그들을 사로잡는 기적적인 커뮤니케이션을 하기도 합니다.
하지만 위의 두 방법은 지속가능하지 않습니다. 일반적으로 PM은 메이커들이 문제해결에 기여하도록 그들을 설득해야 합니다.
(3) 메이커들의 공감
파워가 아닌 커뮤니케이션으로 누군가의 행동을 이끌어낸다는 것은 참 어렵습니다. 우리는 어떻게 일해야 하는지, 인간적으로 팀원 & 동료가 되는 것이 중요하다는 것을 이해했죠.
그래서 PM은 메이커들이 제품개선을 하게 만들기 보다는 하고 싶게 만들어야 합니다
톰소여의 모험에서 톰이 친구들로 하여금 하기 싫은 페인트 칠을 하게 만든 원칙은 다음과 같습니다.
“노동을 놀이로 바꾸라. 그러기 위해선 하고 싶은 마음, 갖고 싶은 마음이 들도록 만들어라”
물론 원작에서는 여기서 갖고 싶게 만드는 것은 희소성에 있습니다. 하지만 희소성보다 결국 갖고 싶은 마음을 만드는 것이 더욱 중요합니다.
메이커분들에게도 나의 일은 내 마음을 쓰는 일이라고 합니다.
출처: 우아한PM의밤 개발자가 생각하는 좋은 PM 나쁜 PM
메이커분들이 이 일에 마음이 쓰게 하려면 어떻게 해야 할까요?
왜 문제를 해결하고 싶은지 왜 목표를 달성하고 싶은지 그것을 달성했을 때 얼마나 설레는지,
“아 이거 해보면 진짜 재미있을 것 같은데”
PM의 욕심을 메이커들도 공감하게 만들어야 합니다.
(4) 메이커들의 신뢰
메이커들의 공감을 이끌어냈다면 ‘그것이 말뿐만이 아니다’ ‘동료로써 함께 만들어야 한다’는 것을 메이커들이 느끼게 해줘야 합니다. 제품개선을 통한 설레임도 본인이 주체가 되지 못한다면 결국 타성에 젖을 수 밖에 없습니다.
이 때 중요한 것은 이해보다 공감입니다.
PM이 이걸 왜 해야하는지 엄청나게 깊게 생각하고 엄청난 데이터를 동원하는 것도 중요하지만, PM은 우리는 한 팀으로 우리가 공감한 문제를 함께 해결해나간다는 것을 적극적으로 어필해야 합니다.
빽빽하게 정리한 컨플루언스(위키)보다는 쌍방향이고 지속적인 커뮤니케이션이 중요합니다.
그 과정에서 PM은 한 팀으로서 문제 해결의 방향키를 잡음에 있어 신뢰를 얻게 됩니다.
그럼 이제 PM이 어떤 커뮤니케이션을 통해서 구성원들의 공감과 신뢰를 얻을 수 있을지 이야기해볼게요!
2. 커뮤니케이션의 첫 번째 원칙: 방향성
PM이 메이커들의 공감과 신뢰를 얻기 위한 커뮤니케이션 원칙을 이야기 해 보겠습니다.
먼저, 커뮤니케이션이 쌍방향이 되어야 한다는 것입니다.
PM은 보통 문제를 정의하고 왜 개선해야 하는지 그 즐거움을 빠르게 캐치합니다.
→ 그래서 메이커를 설득하기 위해서 갖은 논리, 정보, 데이터를 활용하여 신의 한 수를 위키에 녹이려고 합니다.
저 역시 SSG에서 배민으로 이직했을 때 그랬었습니다. 기획자로서 충분한 고민이 프로덕트 혹은 프로젝트의 성패를 결정한다고 생각했고 - 개발자들을 단 번에 사로잡을, 쪽 팔리지 않는 기획서를 만들기 위해서 많은 시간을 컨플루언스에 머물렀습니다.
메이커들을 설득하기 위해서 불필요한 커뮤니케이션을 최소화하는 것이, 제품개선에 있어서 최선의 커뮤니케이션, 최선의 협업이라고 생각했죠.
하지만 결과는 달랐습니다.
(1) 현실적으로 생각해보기
하지만 그렇게 좋은 기획서가 완성되었다고 가정할게요. 그리고 2가지 질문을 드려보겠습니다.
•
우리가 해결해야 할 문제는 크고 작은 것들이 너무 많은데 매번 그렇게 할 수 있어?
•
네가 열심히 준비했고 빈틈이 없다고 생각한 논리와 데이터 정답이라고 장담할 수 있어?
둘다 YES를 외칠 수 있는 PM이라면, 이미 이 교육을 들을 필요가 없다고 생각합니다.
하지만 PM은 위의 두 가지 질문에 항상 YES를 외칠 수 없습니다. 왜냐하면 …
•
PM에게는 시간적인 제약이 있습니다.
•
메이커마다 생각이 다릅니다. 데이터는 어떻게 해석하느냐에 따라 정반대의 답을 내놓기도 합니다.
즉, 현실적으로 생각해봤을 때 PM이 항상 좋은 기획서, 정답을 만들어낼 수 있는 것은 아닙니다.
(2) 상대방 입장에서 생각해보기
우리가 PM의 엄청난 기획서를 받는 메이커가 되었다고 생각해볼게요.
PM이 저렇게 열심히 논리를 펼치고 있습니다. 그때 반대되는 의견이 머릿속에 떠올랐네요. 비판적인 개발자는 충분히 이야기할 수 있습니다. “저는 좀 다르게 생각하는데요”
하지만 대부분의 동료들은 갈등의 상황을 썩 내켜하지 않습니다.
그래서 ‘그래 뭐, 그럴 수 있지..’ 하고 넘어가곤 합니다.
그럼 이 상황은 애초에 커뮤니케이션에 실패한 것입니다. 상대방의 커뮤니케이션을 이끌어내지 못했기 때문이죠.
리뷰가 끝나고 “궁금하신 점이나 피드백 없으세요?” 물어봐도 보통은 질문이 적습니다.
즉, 우리는 대화와 공유를 했고 서로 이야기할 시간을 충분히 가졌지만 실질적으로 일방적인 커뮤니케이션만 남았습니다.
(3) 쌍방향 커뮤니케이션하는 법
그럼 PM은 위키를 쓰지도 말고 고민도 하지 말라는 것인가요? 그냥 처음부터 다 개발자랑 이야기해요?
라는 의문이 남으실거에요. 저도 그것때문에 엄청나게 화도 났고 고민도 많았거든요
제 대답은 “아니오. 당연히 고민해야죠. 당연히 위키에 내 논리를 적어야죠” 입니다
하지만 문제 해결 과정에서 먼저 문제에 대한 인간적인 공감을 이끌어나가야 합니다
이번에도 우아한 PM의 밤 행사의 명대사를 가져왔어요.
출처: 우아한PM의밤 개발자가 생각하는 좋은 PM 나쁜 PM
그럼 문제가 있을 때마다 개발자들에게 가서 ‘고민이 있어요’ 라고 말해야 하나?
그것은 아닙니다. → 쌍방향은 상대방에 대한 의존이 아닙니다. 서로 대등한 입장에서 소통이 이루어져야 합니다.
그래서 제가 제안 드리는 방법은 PM이 쌍방향 소통의 판을 계속 마련 해 주는 것입니다.
1.
해결해야 할 문제점들에 대해서 PM이 충분히 숙지하고 그룹핑 합니다.
2.
그 문제를 메이커분들이 공감할 수 있도록 사용자 입장에서 해체하여 생각해볼 여지가 있는 주제로 던지세요.
•
ex) ”사용자들이 검색결과에 들어왔을 때 굳이 이 상품/가게/공고를 클릭할 이유가 없는 것 같아요.”
◦
이때 꼭 미팅을 잡지 않아도 괜찮습니다. 밥을 먹으면서 이야기하거나 티타임을 하면서 이야기해도 되고, 도저히 일정이 나오지 않으면 슬랙(혹은 메신저 단톡)을 통해서 소통 합니다.
3.
어느정도 이야기에 진척이 있다면, 같이 논의하는 시간을 정하고 그때까지 생각 해 보기로 합의 합니다.
•
액션 아이템을 명확하게 마련하는 것이 중요합니다.
•
물론 그때까지 생각하는 메이커는 있으면 감사하지만, 없을 가능성이 높습니다. 그래서 중간중간 리마인드할 수 있는 인사이트를 계속해서 제공합니다. (이는 아티클일 수 있고, 유저 데이터일 수도 있습니다.)
4.
PM은 미팅을 주도하여 메이커들이 충분히 많은 이야기를 할 수 있게 합니다.
위의 사례를 봤을 때, 메이커들의 참여를 이끌어내기 위한 눈물겨운 PM의 노력이 보입니다.
저는 효과적인 커뮤니케이션을 위해서는 PM이 더 먼저 움직이고 더 부지런히 움직여야 한다고 생각합니다. 그래서 우아한PM의 밤에 등장한 마법의 단어 “고민이 있어요”도, 모든 상황에서 통할 수는 없을 것입니다.
혹여나 모두를 설득할 수 있는 최상위 마법을 배운다고 해도, 마법을 사용하기 위해서 준비해야 할 것들이 너무나도 많습니다. 왜냐하면 아군도 적군도 모두 다른 사람이고 다르게 생각할 수 있기 때문입니다.
PM은 다른 생각들이 하나가 되도록 그 생각들을 끄집어 내어 서로 융화될 수 있도록 해야 합니다.
이 방법이야 말로 메이커들의 참여를 이끌어 내고, 메이커들의 마음 속에 나의 일이 될 수 있도록 하는 커뮤니케이션의 마법입니다.
3. 커뮤니케이션의 두 번째 원칙: 빈도
쌍방향 커뮤니케이션은 자주 일어나야 합니다.
이제 조금 어떤 느낌이 와 닿으시나요? 방향성은 공감에 대한 이야기, 빈도는 신뢰에 대한 이야기입니다. 소프트 스킬이 필요한 이유. 공감과 신뢰는 계속해서 반복되고 있음을 이해하셔야 합니다.
왜냐하면 팀워크를 리딩하기 위해서 PM이 얻어야 할 중요한 가치이기 때문입니다
(1) 빈도는 커뮤니케이션의 투명성을 보장한다
커뮤니케이션이 단발성으로 일어나고 자주 일어나지 않으면 , 메이커들은 커뮤니케이션이 실제 제품 개선에 반영되고 있는지 알 수 없습니다.
즉 커뮤니케이션 빈도가 높을 수록 커뮤니케이션의 투명성을 보장합니다.
일관된 목소리를 지속적으로 내어 내 의견이 제품에 반영되고 있다는 것을 보여줘야 합니다.
보통 이 과정이 생략되면 ‘지난 미팅에서 이야기했는데, 왜 지금 다른 이야기를 하시는거죠?’ 참사가 벌어집니다.
(2) 행동을 통한 신뢰 얻기
PM은 쌍방향 커뮤니케이션을 통해 얻은 메이커분들이 합의를 이룬 생각을 끊임 없이 리마인드 시켜줘야 합니다.
왜냐하면 모든 사람은 오늘과 내일의 생각이 서로 다를 수 있습니다. 그 간격을 메우는 방법은 바뀔 때마다 커뮤니케이션하는 방법 밖에 없습니다. 그러면 이 PM은 ‘우리의 의견을 적극 수렴하고 있구나’ ‘우리는 한 팀’이구나에서 비롯된 신뢰를 얻을 수 있습니다.
투명성이 PM의 일관성을 의미하고, 일관성에 근거한 신뢰를 PM은 얻게 됩니다.
4. 커뮤니케이션의 공용어: 데이터
커뮤니케이션 과정에서 사용되어야 할 언어는 데이터입니다.
데이터로 설명하지 않는다면 아무리 열심히 커뮤니케이션을 하여도 서로 다른 생각을 할 수 있습니다. 그리고 커뮤니케이션의 과정의 수 많은 의견의 홍수 속에서 아무런 결론도 이끌어내지 못하는 참사가 벌어질 수 있습니다.
저는 메이커들과 일할 때 절대 하지 않는 말이 “이게 더 좋다”로 끝나는 말입니다.
ex) “저는 A보다는 B가 더 좋은 것 같은데, 다른 분들은 어떻게 생각하세요?”
→ 반대로 그렇게 말씀하시는 분께 여쭤봅니다 “그게 왜 더 좋다고 생각하시는지 여쭤봐도 될까요?”
(1) 제품의 품질
여러분은 제품의 품질을 무엇이라고 생각하시나요?
아이폰 vs 갤럭시 두 스마트폰 중 어느 스마트폰의 품질이 좋은가요?
→ 불량이 덜 발생하는 스마트폰을 선택하셨다면 생산자의 마인드입니다.
제품을 사용하는 소비자, 사용자의 입장에서 품질은 “제품이 고객의 기대를 충족하는지”에 따라 달려 있습니다.
•
예를 들어, 안드로이드의 자유도와 삼성페이를 주로 사용하는 사용자에게, 아이폰의 UI는 그다지 높은 품질을 보장하지 않습니다.
•
혹은, iOS의 UI 또는 애플 생태계의 편리함을 선호하는 사용자에게, 갤럭시의 제품성능은 그다지 높은 품질을 보장하지 않습니다.
즉, 품질이 높다 낮다는 상대적이므로 품질을 개선하기 위해서는 고객의 기대와 충족여부를 정량화해야 합니다.
(2) 데이터에 기반한 커뮤니케이션
PM이 만들어가는 프로덕트도 마찬가지 입니다.
이게 왜 문제인지, 이 문제를 왜 해결해야 하는지, 이 문제를 해결하기 위한 방법은 무엇이 있을지, 제품개선에서 이뤄지는 긍정적인 부정적인 표현들은 모두 데이터에 기반해야 합니다.
PM은 “프로세스가 불편해요” 보다는 “프로세스 상 3번째 depth에서 이탈률이 높아서 불편합니다”라고 말해야 합니다. 그래야 모두가 문제해결 과정에서 컨텍스트를 함께 이해하고 오차가 없는 협업을 진행할 수 있습니다.
5. 나쁜/좋은 커뮤니케이션 예시
제가 재직 중인 채용 플랫폼을 사례로 한번 두 가지 예시를 들어 보겠습니다.
1.
함께 공감하고 있는 문제 (Why)
•
이력서 지원이 불편하다
•
why?
◦
이력서 지원 과정의 퍼널이 너무 복잡하다
•
how?
◦
지원하기 → 이력서 업로드 → 내 정보 확인 → 지원완료
2.
단방향 커뮤니케이션 사례 (나쁜 예시)
[클릭해서 열어보기] 킥오프(혹은 개발리뷰)
[클릭해서 열어보기] 개발 진행 중
3.
쌍방향 커뮤니케이션 사례 (좋은 예시)
[클릭해서 열어보기] 킥오프(혹은 개발리뷰) 전
•
(~ 문제 정의를 위한 미팅, 기획안 리뷰 등 생략)
[클릭해서 열어보기] 개발 진행 중
← 이전 주제
다음 주제 →
Copyright 2022. ⓒ TeamSparta All rights reserved.
