프로덕트 매니저가 피해야 할 3 가지 말

원문: John Micah Reid, "3 things to avoid saying as a Product Manager"

MemeCreator의 이미지

늦은 밤 잠자리에 들어 예전에 했던 바보 같은 말을 떠올리며 다시 주워 담고 싶었던 적이 있나요? 저는 그런 경험이 많은데 직장에서의 상황, 특히 주니어 프로덕트 매니저 시절에 했던 말들을 자주 후회하곤 했습니다.

이 글에서는 제가 실수했던 세 가지 커뮤니케이션 상황을 살펴보고 이를 어떻게 더 나은 방식으로 해결할 수 있었는지 리뷰하겠습니다. PM들이 흔히 하는 실수를 피하도록 도와 드릴게요. 그럼 시작해 봅시다!

1. 곧장 ‘예’라고 답하기

다음은 제가 신입 프로덕트 매니저로 일한 첫 달에 있었던 대화 내용입니다.

CEO: 저기 존, 요즘 우리 온보딩 퍼널에 대해 생각해 봤는데, 모든 신규 가입자가 제품 사용법을 이해할 수 있도록 영상을 시청하도록 만들면 좋을 것 같아. 이 작업 좀 맡아줄 수 있어?

나: (세상에 CEO잖아!) 네, 정말 좋은 기능인 것 같습니다. 당장 착수해서 2주 내에 시연해 보실 수 있도록 준비하겠습니다.

이 대화 후에 저는 기술 팀에게 지금 하던 모든 일을 멈추고 비디오 온보딩 설루션을 개발하도록 지시했습니다. 2주가 지나자 팀원들은 아무 진척이 없는 상황에 점점 지쳐갔고, 저는 유의미한 결과물을 내려면 족히 몇 달은 더 필요하다는 사실을 깨달았습니다. CEO를 다시 찾아가 이를 보고하자 CEO는 이렇게 말했습니다. “아, 굳이 지금 만들 필요는 없었어. 그냥 내 생각을 말하고 싶었을 뿐이야.“ 🙄

어떻게 말해야 했을까요? 몇 년의 경험치가 더 쌓인 지금이라면 다음과 같이 대화해 볼 수 있을 것입니다.

CEO: 저기 존, 요즘 우리 온보딩 퍼널에 대해 생각해 봤는데, 모든 신규 가입자가 제품 사용법을 이해할 수 있도록 영상을 시청하도록 만들면 좋을 것 같아. 이 작업 좀 맡아줄 수 있어?

나: 좋은 아이디어인데요! 그전에 현행 온보딩 과정에 문제가 있다는 근거를 잠시 확인해 볼 수 있을까요? 참고로 말씀드리자면 현재 저희 팀은 기능 X를 작업하고 있습니다. 이 작업을 중단하고 이걸 우선순위로 올릴까요?

CEO: 음, 딱히 고객의 불만은 없었고 그냥 괜찮은 아이디어라고 생각했을 뿐이야. 기능 X가 더 중요하지. 그거부터 먼저 마무리하도록 해.

여기서 저는 1) 아이디어를 인정하고, 2) 맥락과 문제를 더 깊이 파악하며, 3) CEO에게 우선순위를 직접 물었습니다. 결과적으로 이건 지금 당장 해결해야 하는 중요 과제가 아니며 우리 팀은 기존 작업을 계속해서 완수해 낼 수 있습니다.

요점: 실제 문제를 해결하는 것인지 검증하기 전에는 절대 바로 ‘예’라고 답하지 마세요. 설령 CEO의 요청일지라도요.

2. 곧장 ‘아니요’라고 답하기

이전 실수를 유념하며 이후 몇 달간은 팀의 로드맵 관리에 집중하여 온 힘을 다했고, 그로 인해 다음과 같은 대화가 이루어지게 되었습니다.

운영팀 팀원: 안녕하세요. 사용자 리텐션을 개선할 아이디어를 문서로 정리해 봤습니다. 기본적으로 저희가 이메일을 보내 —

나: (말을 끊으며) 죄송하지만 지금 이미 저희 로드맵에 너무 많은 작업이 잡혀 있어서요. 게다가 이메일은 저희 팀 소관도 아니고요.

운영팀 팀원: 아, 알겠습니다. 괜히 신경 쓰이게 해서 죄송합니다.

MemeGenerator의 이미지

몇 달 후, 사용자 리텐션이 회사의 주요 이슈로 떠올랐습니다. 문제를 조사하고 해결 방안을 구상하던 중, 전에 운영팀 팀원이 보냈던 문서를 다시 확인하게 되었습니다. 거기에 제가 제안하려던 시스템과 거의 일치하는 내용이 작성되어 있었습니다. 이번엔 큰 문제로 이어지지는 않았지만 (목표에 집중하는 것은 대체로 늘 옳죠) 관계비용과 기회비용이 따르게 되었죠.

앞서 소개한 두 가지 사례에서 제 첫 반응이 대화를 끝내버렸다는 점을 알아차리셨을 겁니다. 이는 종종 실수로 이어집니다. 중요한 세부 사항과 아이디어를 놓치게 되니까요. 질문을 던지는 것은 의미를 명확히 하고 대화를 확장하는 훌륭한 방법입니다. 이번 상황에서 어떻게 이를 적용할 수 있을지 살펴보겠습니다.

운영팀 팀원: 안녕하세요. 사용자 리텐션을 개선할 아이디어를 문서로 정리해 봤습니다. 기본적으로 저희가 이메일을 보내는 방식인데요. 일정 기간 동안 활동하지 않은 사용자가 그 대상입니다.

나: 정말 흥미로운 아이디어네요. 이게 효과를 낼 거라고 보는 근거가 있나요?

운영팀 팀원: 저희가 이미 한 가지 이메일을 수동으로 보내 실험해 봤는데 사용자 리텐션이 5% 증가하는 효과가 있었습니다. 전체적으로 적용하려면 제품팀의 지원이 필요합니다. 이메일을 자동 발송하기 위해서요.

나: 꽤 좋은 결과네요. 주신 문서 검토해 보겠습니다. 미리 말씀드리자면 현재 저희 팀이 여러 다른 프로젝트들로 바쁜 상황이어서요. 그래도 다른 제품팀들과 논의해 보고 다시 알려드리겠습니다.

중요한 점은 여전히 ‘예’라고 답하지 않았다는 것입니다. 하지만 이제는 아이디어를 받아들여 시간 날 때 검토해 볼 수 있게 되었죠. 질문을 던지고 열린 자세로 아이디어를 받아들이면, 해당 분야를 훨씬 깊이 이해할 수 있고 효과적인 해결 방안을 도출할 가능성이 높아집니다. 조직 내 관계를 구축하는 좋은 방법이기도 하고요. PM은 목표 달성을 위해 끊임없이 다른 사람들의 협력을 필요로 하기 때문에 이런 관계 구축은 늘 유용하죠.

3. 맥락 없이 업무 지시하기

마지막은 제가 여전히 자주 저지르는 실수입니다. 특히 바쁘거나 시간이 촉박하다고 느낄 때 더욱 그렇습니다. 이번 사례는 신규 가입자들이 어디서 유입되는지 알아보고자 했던 상황입니다.

나: 저기 애널리스트님, 우리 앱 가입자의 몇 퍼센트가 구글 검색을 통해 웹사이트를 발견했는지 추정해 주실 수 있을까요?

애널리스트: 음, 데이터 소스가 달라서 까다로운데요. 웹사이트 방문 후 앱 설치까지 최대 몇 시간까지 유효 전환으로 간주할까요?

나: 글쎄요, 24시간 정도면 되지 않을까요?

애널리스트: 사용자가 다른 기기를 사용한 경우는 어떻게 처리하죠?

나: (이런, 이거 점점 복잡해지는데…)

makeameme의 이미지

몇 분간 논의를 오간 끝에 어설퍼도 작동은 하는 정의를 도출해 냈습니다. 이후 이 데이터를 관리자에게 보고하자 그는 이렇게 말했습니다. “그런데 왜 이런 식의 완전히 새로운 추정치를 만들었어요? 가입할 때 사용자에게 유입 경로를 직접 물어보잖아요.“

이것이 바로 ‘XY 문제’ 상황입니다. 즉 최종 사용자는 문제 X의 해결책을 묻지만 실제 원인은 문제 Y에서 비롯하여 발생하는 문제를 의미합니다. 이 사례에서 저는 해당 데이터가 필요한 이유나 해결하려는 문제를 공유하지 않았고, 결국 불필요한 일을 하는 데 시간을 낭비하게 되었습니다.

애초에 맥락을 제공하면 상대방은 당신이 원하는 게 무엇인지 진의를 파악하는데 힘쓰지 않아도 되므로 더 효과적으로 도움받을 수 있습니다. 맥락을 전달했을 때 대화가 어떻게 흘러가는지 살펴봅시다.

나: 저기 애널리스트님, 신규 가입자 유입 경로를 파악하여, 마케팅팀이 여러 채널에 예산을 어떻게 분배할지 결정하는 데 도움을 주고자 합니다. 우리에게 앱 가입자 유입 경로에 대한 어떤 정보가 있는지, 이를 어떻게 추정할 수 있는지 알려주실 수 있을까요?

애널리스트: 그럼요, 가입할 때 사용자에게 유입 경로를 직접 묻고 있습니다. 여기 기존 대시보드를 참고해 보세요.

이번에는 필요한 것을 더 빠르게 얻을 수 있었습니다. 궁극적인 목표를 공유한 덕이죠. 개방형으로 질문하여 상대방이 잠재적인 해결책을 스스로 생각해 보게 하면 그들의 창의력을 활용할 수 있습니다. PM이 늘 구체적인 업무 지시만 내린다면, 팀은 PM이 가진 이해와 상상의 범위 안에서 움직일 수밖에 없습니다.

결론

이 사례들의 공통점은 커뮤니케이션에서의 배려가 부족해서 발생했다는 점입니다. 일상에서 우리는 항상 빠르게 의사소통하며 살아가고 대개는 크게 문제되지 않습니다. 하지만 프로덕트 매니저에게 커뮤니케이션은 업무의 90%를 차지할 만큼 중요한 요소이므로, 훨씬 더 높은 기준이 요구됩니다. 좋은 커뮤니케이션이란 상대방과 주어진 상황을 고려하여 신중하게 답변을 작성 (혹은 말)하는 데 시간을 들이는 것입니다. 이를 통해 임의의 기능을 무질서하게 만들어내는 개별 개발자 집단을 실제 문제를 해결하는 하나의 강력한 팀으로 바꿀 수 있습니다.

저는 커뮤니케이션을 PM이 갖춰야 할 하나의 ‘하드 스킬’로 인식하는 것이 도움이 되었습니다. 다시 말해 커뮤니케이션 능력은 1) 정량적으로 평가할 수 있으며, 2) 배울 수 있는 기술이라는 것입니다. 무엇이든 곧장 ‘예’라고 답하지 않고, 질문하며, 아이디어를 열린 마음으로 받아들이고, 맥락을 공유함으로써 더욱 효과적인 프로덕트 매니저가 되는 길로 나아갈 수 있을 것입니다.

보너스: 추천 도서

커뮤니케이션 스킬 향상에 관심이 있다면 아래에 제가 가장 좋아하는 관련 도서 두 권을 추천합니다. 모든 훌륭한 책들이 그러하듯 삶의 여러 영역에 적용할 수 있는 교훈을 주는 책입니다.

1. 『데일 카네기 인간관계론(How to Win Friends and Influence People)』 – 데일 카네기(Dale Carnegie)

2. 『우주인들이 인간관계로 스트레스받을 때 우주정거장에서 가장 많이 읽은 대화책(Difficult Conversations)』 – 더글러스 스톤(Douglas Stone), 실라 힌(Sheila Heen)