누구보다 말 많이 하는 사람
서비스기획자의 말하기
학창시절 토론대회나 말하기대회 등 '말'하는 대회라면 모조리 출전하던 나는, 대학교 2학년이 되어 처음으로 발표하면서 덜덜 떠는 스스로를 발견하게 된다. 고작 30명 정도가 수강하는 전공수업 발표에서 염소 목소리와 게다리의 조합을 보여주고는 수치심에 괴로워했던 기억이 아직도 선명하다. 그때의 경험이 트라우마로 남은 것인지 뭔지는 몰라도 그 후로는 학교에서 크고 작은 발표를 했을 때도, 취업 준비에서 수많은 면접을 봤을 때도, 무지하게 떨었다.
신입사원으로 입사하고 가장 스트레스받았던 것 역시 발표였다. 익숙한 동료들과의 회의에서는 문제 없었지만, 낯선 사람들이 많은 회의에서 발언을 하게 되면 꼭 중간쯤 가서부터 목소리가 떨리기 시작했다. 해외광고사업팀에 있어서인지 특히나 말할 기회가 많았는데, '해외'라는 수식어가 붙은 만큼 각국 담당자들과의 주간 회의가 있었고, '사업'팀인 만큼 사업 매출이나 성과, 전략 등에 대해 발표할 일도 많았다. 떨지 않고 유려하게 말하는 다른 팀원들을 보고 있노라면, 나는 사업팀에 있을 사람이 아닌가 보다 자괴감마저 들었다.
그런 내가 서비스기획팀으로 이동하며 은근히 기대했던 것 중 하나는 '말'할 일보다는 '쓸'일이 훨씬 많겠지 했던 것이다. 사업팀에 있을 때는 서비스기획자분들을 직접적으로 대면하기보다는 문서를 통해 협업할 일이 많았기 때문에 생긴 착각이었다. 물론 서비스기획자가 기획서나 보고서 등 문서를 쓸 일이 많긴 하지만, 작성한 문서를 여러 사람들에게 설명하고, 설득하고, 공유하고, 보고할 일이 더 많았다. 게다가 서비스기획자가 프로덕트나 프로젝트의 매니저(PM)로서 회의를 진행하는 일이 많다 보니, 때로는 회의 시작 전의 어색함을 푸는 아이스브레이킹까지도 해야 하지 않은가. 그야말로 세상에 존재하는 모든 말하기를 해야 하는 사람이 서비스기획자 아닐까 싶다.
말하기의 유형에는 그 목적에 따라 '정보 전달적 말하기', '설득적 말하기', '친교적 말하기', '오락적 말하기'가 있다고 한다. 여느 직장인들처럼 서비스기획자 역시 '정보 전달적 말하기'와 '설득적 말하기'를 가장 자주 한다.
정보 전달적 말하기에서는 필요한 정보를 깔끔하게 정리해서 듣는 사람이 이해하기 쉽도록 전달해야 한다. 필요한 정보를 잘 수집하고, 이를 체계적으로 정리(문서화)하는 것도 잘 말하기 위해 꼭 필요한 단계지만, 핵심은 '듣는 사람이 이해하기 쉽도록' 말해야 한다는 것이다.
구현하려는 기능에 법적 이슈가 있을지 문의하려면 개발적인 내용을 법무팀이 잘 이해할 수 있도록 말해야 하며, 어떤 데이터를 보고 싶다는 사업팀의 요구사항이 있다면 어떤 기준으로 어떤 로그를 수집해야 할지 개발자가 이해할 수 있는 언어로 전달해야 한다. 같은 스펙을 설명하더라도 개발팀에는 동작하는 방식과 데이터의 흐름을, 사업팀에는 기대효과와 운영 측면에서의 변화를 중점적으로 말할 수 있으면 좋다. 다양한 직군 사이에서 일의 언어를 해석하고 전달하는 것이 마치 통역사 같기도 하다.
서비스기획자는 앞으로 어떻게 변하면 좋을지, 미래의 모습에 대해 말할 때가 많다. 아직 눈으로 보이지 않는 것에 대해 말로 표현하면 듣는 사람들 머리 위에는 물음표가 생겨난다. 특히 유저 플로우나 프로세스 변경안에 대해 이야기할 때는 시각적으로 이해할 수 있게 도식화하는 것이 좋다. 플로우차트나 테이블 등을 활용하면 언어의 한계를 보완할 수 있다. 새로운 콘셉트처럼 다소 추상적인 내용이 구체적으로 상상될 수 있도록, 비슷한 듯 하지만 다른 케이스가 명확하게 구별될 수 있도록, 수많은 이슈가 얽혀있는 복잡한 문제덩어리의 원인과 결과가 구분될 수 있도록 전달하자.
설득적 말하기의 목적은 듣는 사람이 내가 원하는 방향으로 생각 또는 태도를 바꾸도록 하는 것이다. 누군가를 설득하기 위해서는 주장과 근거가 세트로 있어야 한다. 빅테크 기업에서는 버튼 색깔 하나 바꾸는 데에도 A/B 테스트를 한다지만, 현실에서는 한정적인 리소스 때문에 모든 것을 A/B 테스트나 데이터 분석을 통해 결정하기 어렵다. 하지만 사소한 스펙에도 항상 뚜렷한 주관과 이를 뒷받침할 합리적인 근거가 있어야 한다.
잘 모르는 것에 대해 기획하려면 다른 사례들을 참고하기 마련이고, 그러다 보면 '타사도 그렇게 하니까', '원래 그렇게 해왔으니까'와 같이 내 주관이 쏙 빠진 기획을 할 수 있다. 하지만 수차례 스펙 리뷰를 경험하며, '왜 (하고 많은 위치들 중에서) 버튼을 이곳에 넣고 싶은지', '왜 (다른 UI 컴포넌트들이 아닌) 토스트로 메시지를 표시할지', '왜 댓글을 (3개나 10개가 아닌) 5개씩 불러올지' 등, "왜"로 시작하는 모든 질문에 답할 수 있는 기획을 할 수 있어야 한다는 것을 깨달았다. 설령 위에서 시켜서, 옆에서 요청이 들어와서 해야만 하는 기획이라 하더라도, 내 나름대로 프로덕트팀을 설득할 만한 논리를 만들 수 있어야 일을 진행시킬 수 있다.
어떤 서비스의 새로운 담당자가 되어 새로운 사람들과 일하게 되었다면, 나보다 이 서비스를 더 잘 아는 사람들을 설득하기가 쉽지 않다. 하지만 매사 근거 있는 기획을 하려 노력한다면, 조금씩 나의 신뢰 자산이 쌓여 이들을 설득하는 일 역시 점점 쉬워지지 않을까. ☺︎
