회사에서 업무를 진행하다 보면 다양한 사람들과 협업하며 소통할 일이 많습니다. 구체적으로는 업무를 요청하는 과정부터, 중요 방향을 잡아야 하는 회의 등을 진행할 일이 많을 텐데요. 이런 협업 과정에서 서로 이해도가 달라 오해가 발생하기도 하고, 준비되지 않은 질문들로 인해 회의의 논점에서 벗어나는 경우도 있었을 것입니다.
💁♂️회의 진행자: A를 다들 어떻게 생각하시나요?
🙋♀️동료 1: A는 왜 필요한가요?
👨💻동료 2: 회의의 목적이 무엇인가요? A를 하는 것에 대해 확정하는 회의인가요?
🤷♀️동료 3: 회의록에 있는 B는 A와 무슨 연관인가요?
회사에서 내가 예상한 대로 회의나 업무 요청이 진행되지 않는 것은 소통 방식, 즉 스마트한 질문법을 고려하지 못했기 때문입니다. 이런 혼란한 과정이 반복되면 다시 처음부터 업무를 처리해야 하는 상황에 마주하게 되기도 하지요.
특히, PO(Product Owner)/PM(Product Manager) 직무는 다양한 이해관계자와 다양한 상황에서 협업해야 할 일이 많을 텐데요. 크게는 4가지 상황으로 구분해볼 수 있습니다.
- 의사결정자의 의도를 파악한 후 제품 계획 및 로드맵을 그려야 하는 상황
- 다른 부서·팀과 협업이 필요한 상황
- 스쿼드(squad)* 안의 개발자, 디자이너와 협업해야 하는 상황
- 팀원들과 일대일 미팅을 하는 상황
- 조직 단위를 일컫는 말로 10명 내외로 구성된 팀. PO/PM을 비롯해 개발자, 디자이너, 마케터까지 기술과 능력을 갖춘 일종의 미니 스타트업이라고 볼 수 있다.
각 상황마다 PO/PM이 자신의 의도대로 설득하거나 효과적으로 협업하여 주어진 시간에 임팩트를 내기 위해서는 상황별 적절한 질문법을 통해 상황을 리드해야 합니다. 이 아티클에서는 이 4가지 상황별 효과적인 질문법을 통해 일 잘하는 PO/PM로 거듭나기 위한 방법을 공유드리도록 하겠습니다.
의사결정권자의 의도를 파악하기 위한 질문법
의사결정권자의 의도를 파악하기 위한 질문을 잘하는 것이 왜 중요할까요? PO/PM은 회사의 사업 방향에 맞게 한 프로덕트를 책임져야 하는 역할을 맡고 있습니다. 자신이 맡고 있는 프로덕트 안에서는 최종 결정권자의 역할과 그 프로덕트의 성과를 책임지는 역할을 하고 있죠.
하지만, PO/PM이 회사의 사업 방향에서 의사결정 하는 사람들의 의도를 뭉뚱그려서 알고 있다면, 우리 프로덕트가 회사와 다른 방향을 보며 만들어지고 결국 성과를 낼 수 없게 됩니다. 회사의 방향에 자신이 책임지고 있는 프로덕트의 방향을 맞추는 과정을 계속 거쳐서 성과를 내기 위해서는 의사결정권자의 의도를 잘 파악하기 위해 질문하는 것이 중요합니다.
최대한 구체적인 질문으로 방향을 파악하기
광범위하게 '목표'라는 단어를 써서 질문하게 되면, 의사결정자 혹은 CEO 입장에서는 그들이 그리고 있는 큰 그림과 먼 미래의 목표까지 설명하면서 동기부여하려고 할 수도 있습니다.
🐥 초보: 이 프로덕트의 목표가 무엇인가요?
제 경우에도 회사의 방향성을 파악하기 위해 '목표'에 대해 물었을 때, 의사결정자 단에서 생각하는 목표와 비전에 대해서만 대화의 흐름이 이어졌습니다.
회사의 방향에 대해서는 이해했지만, 결국 제가 만들어야 할 프로덕트에 대한 구체적인 액션이 잡히지 않아 구체적인 질문을 이어가야 하는 상황이 발생했었습니다. 그만큼 프로덕트를 구체화하는 시간도 지연되었던 경험이 있습니다.
🐓 고수: A 프로젝트의 성공적인 결과를 얻기 위해 구체적으로 중요한 것 한 가지는 무엇일까요?
PO/PM 입장에서는 자신이 담당하는 프로덕트의 성공 지표를 잡아 그에 집중하는 임팩트를 MVP(Minimum Viable Product, 이하 MVP)*로 뽑아 검증하는 것이 중요합니다. 프로덕트 개선을 위한 프로젝트를 착수하기 전, 이 프로젝트가 성공적으로 평가받고 회사의 매출 및 핵심 지표에 기여하기 위해 가장 중요한 한 가지가 무엇인지 파악하는 것이 중요합니다.
- 최소 기능 제품을 뜻하는 단어로 실제 실행하려는 비즈니스가 올바로 동작하기 위해 최소한의 기능을 갖춘 프로덕트
목표가 애매하거나 얻고자 하는 것이 여러 가지라면 프로젝트 방향성의 갈래가 너무 많아져서 이도 저도 검증하지 못하고 리소스만 몇 개월 동안 쓰게 될 수 있는데요.
가장 중요한 한 가지를 파악할 수 있는 질문을 통해 의사결정권자들이 이 프로젝트를 어떻게 보고 있는지를 확인하세요. 그러면 그들에게도 한번 더 이 프로덕트의 성공 지표를 각인시켜서 하나의 목표점을 볼 수 있도록 방향을 맞출 수 있을 것입니다.
다른 부서·팀과 협업이 필요한 상황에서 질문법
다른 부서·팀과 협업하는 과정에서 질문을 잘하는 것이 왜 중요할까요? PO/PM이 속한 프로덕트팀은 운영팀, 마케팅팀, 영업팀, 사업개발팀 등 다양한 팀과 협업하게 될 경우가 많습니다. 이때 아무래도 부서·팀 간 정보의 격차가 존재할 텐데요. 다른 부서·팀은 우리 팀만큼 우리 팀이 만들어가는 프로덕트에 대한 이해도와 스케줄에 대해 잘 알고 있지 못하는 게 당연합니다.
1) 사업개발팀과 협업 시 문제가 발생한다면
이렇게 되면 사업의 방향성이 제대로 맞지 않아 제품 배포가 지연되고, 시장의 흐름과 타이밍에 맞게 제품을 만들어내지 못하는 문제가 생기게 됩니다. 이럴 경우, 회사의 경쟁력이 다른 경쟁사에 비해 떨어지는 문제까지 이어질 수 있습니다.
2) 운영팀과 마케팅팀과 협업 시 문제가 발생한다면
배포할 기능을 어떻게 유저에게 안내(운영팀)하고 홍보할지(마케팅팀) 협업해야 하는 상황도 빈번하게 발생하는데요. 이 과정에서 문제가 생기면, 프로덕트를 사용하는 유저들에게 혼란이 생기거나, 열심히 개발한 기능의 효과를 제대로 보기 힘든 문제로 이어질 수 있습니다.
이렇게 정보의 차이가 있는 상황을 고려하지 못하고 일단 급하게 협업을 진행할 경우, 서로 다른 방향을 바라보거나 오해가 생길 수 있습니다. 그래서 서로의 이해도를 맞추고 각 팀에서 우려되는 부분을 스마트한 질문법으로 명쾌하게 해소하는 것이 중요합니다.
협업이 왜 필요한지 이해도 맞추기
🐥 초보: A라는 기능이 만들어졌는데, 마케팅 요청드려도 괜찮을까요?
마케팅팀 입장에서는 A라는 기능이 어떤 배경에서 만들어졌는지, A라는 기능을 마케팅했을 때 얻는 기대효과가 무엇인지 알 수 없습니다.
그리고 그냥 '마케팅 요청'이라고 할 경우, 마케팅팀 입장에서도 어떤 부분을 강조하는지 알 수 없기 때문에 중요성이 각인되지 않고 늘 하던 채널에 홍보하는 정도로 생각하게 될 가능성도 큽니다. 정확하게 어떤 부분을 얻고 싶은지 알 수 없다면 마케팅 협업 요청을 드려도 제대로 효과를 얻지 못하죠.
🐓 고수: A라는 기능은 기존 저희 주된 타깃층에서 확장하여 30대 여성 타깃층 유입을 높이기 위해 만들어졌습니다. 기존 대비 30대 여성 타깃의 비율을 30% 이상 확대하는 것이 목표 지표인데요. 이를 위해 어떤 채널에 어떤 메시지로 홍보하는 것이 효과적일까요?
우리 팀에서 현재 마케팅팀에 왜 협업을 요청하는지 목표와 함께 명확히 전달하게 되면 마케팅팀 입장에서도 어떤 것을 해야 하는지 머릿속에 명확하게 각인될 수 있습니다. 각인되는 만큼 중요도도 높아지게 되죠.
그리고 특히 고민을 부탁드리는 부분을 '채널'과 '메시지'로 키워드를 잡아 질문함으로써 마케팅팀에서 집중적으로 기존 타깃에 홍보하던 방식과 다르게 새로운 채널과 메시지를 추가적으로 신경 써줄 부분을 강조할 수 있습니다.
겸손한 질문으로 우려되는 부분을 미리 해소하기
협업 과정에서 우리 팀의 상황을 다른 팀에서 완전히 알지 못하듯이, 우리 팀도 다른 팀의 상황과 노하우를 완전히 알고 있지는 못합니다. 이런 상황에서 다른 팀에서 어떤 업무를 진행할 때 우려되는 부분에 대한 경험치가 있을 텐데요.
이런 점에 대해 적절한 질문으로 미리 짚고 넘어가지 못할 경우, 이미 사건이 발생한 후에 대처해야 하기 때문에 리스크가 커지게 됩니다. 즉, 내가 잘 모르는 영역에 대해서는 겸손한 질문으로 리스크를 미리 감소하도록 대응책까지 이끌어낼 수 있는 것이 중요합니다.
🐥 초보: 유저들이 사용하는 UI에 업데이트 있습니다. 푸시 알림으로 안내해주실 수 있나요?
예를 들어, 프로덕트팀에서 운영팀에게 푸시 알림을 요청하는 상황을 생각해 봅시다. 운영팀 입장에서는 운영팀만의 매뉴얼이 있어 업데이트 사항을 푸시로 알림하지 않거나 푸시 알림을 빈번하게 보낼 경우 유저 피로도가 높아지는 등의 경험치가 있을 것입니다. 혹은 푸시 알림이 갈 경우, 유저 문의가 급 많아지는 경향을 보여 특수한 경우가 아니면 사용하지 않고 있을 수도 있죠.
하지만 팀의 상황과 업무 방식을 잘 모르는 상황에서 어떤 리스크가 있을지 확인하지 않고 요청 질문을 할 경우, 서로 요청 사항에 대해 오해가 발생할 수 있습니다.
🐓 고수: 유저들이 사용하는 구매하기 UI상에 업데이트 사항을 안내하고 싶은데요. 저는 푸시 알림의 파급효과에 대해 잘 모르고 있는 것 같습니다. 혹시 푸시로 갈 경우 운영팀에서 우려되는 부분이나 더 나은 안내 방법이 있을까요?
이렇게 질문하면 '푸시 안내' 요청이 필수라는 뉘앙스보다는 어떻게든 유저들이 사용하는 화면이기에 UI 업데이트 사항을 명확하게 안내하는 것이 목적이라는 것을 확인시킬 수 있습니다. 그리고 '나는 파급효과를 잘 모른다'라는 겸손한 표현을 사용하면 좋습니다.
그러면 운영팀의 전문성에 대한 존중을 표현하고, 전문가의 눈으로 해결 방법과 우려점에 대해 생각해볼 수 있도록 집중을 유도할 수 있게 됩니다. 특히, 다른 팀과의 협업 과정에서는 해당 팀의 업무 플로우를 충분히 존중하는 태도가 질문에 묻어나는 것이 매끄러운 협업에 큰 도움이 됩니다.
스쿼드 안의 개발자, 디자이너와 함께 일할 때의 질문법
스쿼드 안의 개발자, 디자이너와 함께 일할 때 질문을 잘하는 것이 왜 중요할까요? 스쿼드에서 성과를 내려면 오해 없이 서로 한 방향을 바라보며 시간 내에 프로덕트에서 발생하는 문제를 효과적으로 해결하는 것이 필수입니다. 함께 구체적인 해결책을 고민하고, 문제를 효과적으로 해결하는 임파워드 팀(empowered team)*이 되기 위해서는 이런 환경을 조성할 수 있는 질문이 중요합니다.
- 공동 목표를 스스로 설정하고 이의 달성에 요구되는 실질적 권한을 지님으로써 자신들의 일에 대한 주인의식을 갖게 하는 팀 회사의 유형
해결하려는 문제 상황에 대해 이해도를 맞추는 'Why'
🐥 초보: 한 달 동안 A 기능을 만들어서 배포하는 것이 목표입니다. 일정 가능하신가요?
기능 단위로 해야 할 일감들이 내려오는 구조로 돌아가는 프로덕트 팀도 있을 텐데요. 저도 이전에는 기능 단위로 스쿼드 내 개발자, 디자이너 분들에게 전달하면서 기능을 만들고 나서 '왜 이걸 만드는지, 우리가 만드는 게 어떤 곳에 유용하게 쓰이는 건지 모르겠다'라는 의견들이 많았었습니다.
PO/PM만 문제 상황을 인지하고 있고 이를 명확하게 전달하는 과정이 없이 바로 기능 명세서만 내밀어서 각 기능별 배경을 모르고 만들었기 때문입니다.
서로 이해하는 부분이 다를 때 가장 큰 문제는 기능이 문제를 해결하는 것과 다른 방향으로 나와서 다시 문제를 해결하기 위한 기획 및 기능 논의를 하고, 개발도 또다시 해야 하는 것입니다.
그러면 결국 배포 일자에도 지연이 생깁니다. 만약 이 기능이 회사의 사업 방향성 차원에서 중요한 기능이라면 제대로 된 타이밍에 시장에 프로덕트를 내놓지 못해 사업 목표 지표를 맞추는 것에도 문제가 생겨 리스크가 커집니다.
🐓 고수: 우리가 해결하고 하는 문제는 B입니다. B가 '왜' 문제냐면, 이로 인해 유저 및 다른 팀에서 하나의 문의를 처리하는 데 평균 30분 이상 소요되기 때문인데요. 이를 하나의 문의 당 5분 이하로 줄이는 것이 목표인데요. 왜 이것이 문제 상황인지에 대해 공감하시나요?
스쿼드에서 제품으로 해결하고자 하는 문제가 무엇인지에 대해 설명하고, 이에 대해 얼마나 이해하고 공감하는지를 맞추는 질문이 중요합니다. 공감하지 못했을 경우에는 문제 상황을 이해하기 위한 후속 질문을 자연스럽게 이어서 할 것입니다. 그리고 공감한다면 각자의 관점에서 어떻게 구체적으로 솔루션을 고민할 수 있을지 동기 부여할 수 있다고 생각합니다.
〈임파워드〉의 저자 마티 케이건, 크리스 존스에 의하면 임파워드 된 제품팀을 만들려면 팀에게 풀어야 할 시장의 문제를 주고 좋은 결정을 내릴 수 있는 콘텍스트를 제공한다면 더욱 동기 부여된 상태로 효과적인 솔루션이 나올 가능성이 높다고 합니다.
여기서 콘텍스트란 시장에서 왜 이런 부분에 문제가 있고, 우리가 가지고 있는 자원에서는 1,2,3의 큰 솔루션 방향이 있다는 정보를 의미합니다. 그리고 '이 문제를 해결하면 우리는 n원 정도 매출 증대에 기여할 수 있다' 등 구체적인 수치 등을 동반하기도 합니다.
PO/PM은 스쿼드 팀원들에게 우선순위만 적힌 기능 목록을 제공하기보다 어떤 문제인지에 공감하고 의문을 해소하는 질문, 논의를 통해 강력한 제품팀을 구축하는 것을 고민해보면 좋겠습니다.
예상하지 못한 문제에도 팀원들의 고민을 이끄는 질문하기
🐥 초보: 엣지 케이스가 발생했네요. 이 케이스 C로 대응해주세요!
제 경험담을 하나 소개하고 싶습니다. 한 프로젝트에서 기능의 임팩트가 크고 관련된 페이지가 많았기 때문에 킥오프 때 고려하지 못한 엣지 케이스(edge case)*들이 개발 중간에 생겨난 경우가 있었습니다. 당시 저는 어떻게든 해결하기 급급하여 당장 떠오르는 해결책들로 급한 불을 껐는데요. 이렇게 하면 최선의 방법으로 해결되지 않는 경우가 많았습니다.
그 이유는 스쿼드 내에 개발이면 개발자, UX 및 사용성에 대한 부분이면 디자이너라는 각 분야의 전문가들이 있는데 적절한 질문을 통해 소통하지 못했기 때문인데요.
- 예외 케이스라고 부르기도 한다. 기능 기획 시 고려했던 영향 범위에서 벗어난 예상하지 못한 케이스를 의미하며, 발생 빈도가 희박할 수 있다.
🐓 고수: 이 케이스 관련 초반 논의에서 고려하지 못했던 부분이 있네요. OO님께서 솔루션 고민해주실 수 있으신가요? 혹은 C로 처리할 때 우려되는 부분 있으실까요?
좀 더 경험이 쌓인 이후에는 어떤 이슈가 발생했을 때 "OO님께서 솔루션 고민해주셔도 괜찮을까요?" 혹은 "이렇게 처리할 때 혹시 우려되는 부분이나 더 나은 방향이 있을까요?"라고 각 분야의 담당자분들께 질문드리는 방향으로 팀원들과 회고 후, 개선하려고 하였는데요.
그 결과, 급한 불을 끄듯이 임시방편으로 개선하는 것보다 해결책까지 논의 및 의사결정도 훨씬 빠르게 진행되는 과정을 경험할 수 있었습니다. 오히려, 제가 고려하지 못한 상황까지 더 꼼꼼하게 체크해주고, 개발 구조적으로도 엉키지 않게 각자 빠르게 공유하고 해결하는 데까지 더 시간이 단축된 것을 경험했습니다. 미봉책으로 대응하다 보면 추후에 다시 관련 부분에서 또 다른 엣지 케이스가 생길 가능성이 커지기 때문입니다.
예상치 못한 일에서 혼자 모든 것을 해결하려고 하기보다 팀원들을 믿고 적절한 질문으로 최적의 솔루션을 고민하실 수 있도록 유도하는 것이 결과적으로는 더욱 효과적으로 제품을 만들 수 있다고 생각합니다.
일대일 미팅(1 on 1)에서 신뢰를 얻는 질문법
일대일 미팅에서 질문을 잘 하는 것이 왜 중요할까요? PO/PM이 팀 내 동료들과 일대일 미팅하는 목적은 주로 팀원들의 현재 상황을 파악하고 개선점을 이끌고 또한 나 자신에 대한 피드백을 얻기 위함입니다.
일대일 미팅에서 어떤 질문을 할 지 신경쓰지 않고, 커피 한잔하는 시간으로 흘려보내면 팀 내 동료분들이 겪는 어려움을 제대로 파악하기 힘들고 나에 대한 피드백도 적절하게 얻기 힘들어집니다.
꼭 일대일 미팅이 아니더라도, 회사 내에서 팀원과 면담을 나누거나 서로의 업무 관련 고민을 이야기할 시간도 있을 텐데요. 그런 상황에서 효과적으로 대화 및 질문할 수 있는 팁에 대해 설명드리겠습니다.
긍정의 질문으로 잘하고 있는 점에 집중하기
🐥 초보: 이번 OO 마일스톤에서 A부분 개발이 잘 안 된 이유가 뭔가요?
일대일 미팅에서 동료의 상황이나 배경 이해하려고 하지 않고, 결과만 보고 왜 잘 안 되었는지부터 물어보면, 듣는 사람 입장에서는 다소 '부정적인'것에만 집중한다고 느낄 수 있습니다.
특히, 인간은 감정의 동물이기 때문에 부정적인 것으로 시작하고 이에 집중해서 이야기한다면 비교적 위축되고 자존감이 낮아지게 될 수 있습니다. 오히려 개선점을 잡고 싶어 꺼낸 문제 상황이 더욱 팀워크를 해치고 성과를 낮추는 결과를 가져올 수도 있게 되는 거죠.
이런 감정을 느낀 상태로 팀원이 다음 마일스톤을 진행하게 되면, 개발 과정에서 있었던 본질적인 문제를 개선하지 못하고 문제 상황이 반복되거나 혹은 PO/PM입장에서는 문제를 제대로 파악하지 못했기 때문에 다른 환경 탓만 하고 있는 상황이 발생할 수도 있습니다.
저의 경험에 의하면, PO/PM은 팀원들의 성향과 마음을 잘 파악하고 솔직한 이야기를 할 수 있는 상대가 되는 것도 중요합니다. 저도 처음에는 QA(Qualith Assurance)* 팀원과 일대일 미팅할 때, 처음부터 "이 기능 쪽 왜 QA가 잘 안 되었나요?"라고 질문했습니다.
- 제품 출시 전까지 테스트를 반복하며 제품의 품질을 높이는 프로세스
그렇게 하다 보니, 저도 일대일 동안 상대방이 '잘못한 것'에만 집중하게 되고, 상대방도 "제가 그 부분에 대한 이해도가 떨어졌습니다"라고 대답하게 되는 상황이 나왔는데요.
이렇게 되면, '아 이해도가 떨어졌구나' 외에 정확히 어떤 점에서 어려움을 겪으셨고, 혹시 내가 전달하는 방법에서 혼란이 생기는 것인지 등 구체적으로 개선 방향으로 대화를 이어가는 데에 한계가 있었습니다.
🐓 고수: 이번 OO 마일스톤에서 B부분에 개발 리드를 잘해주셔서 프로덕트 배포를 잘할 수 있었습니다. 다시 한 달 전으로 돌아간다면, OO 마일스톤이 잘 되기 위해 어떤 걸 더 고민할 수 있었을까요?
동료분이 잘 진행해주신 긍정적인 부분을 먼저 언급하고 더 잘하려면 어떻게 할지 질문을 하게 되면 듣는 사람이 일단 긍정적인 감정을 가지고 일대일 미팅에 임할 수 있게 됩니다.
그리고 자기가 해당 마일스톤을 진행하며 부족했던 부분은 스스로가 가장 잘 파악하고 있겠죠. 그럼 '더 잘할 수 있는 방법'에 대해 질문했던 부분에서 부족했던 부분이 있었는데 이렇게 개선하고 싶다는 내용이 오히려 솔직히 나올 가능성이 높아진다고 생각합니다.
저의 경우에도 질문을 개선하여 다음과 같이 여쭤봤습니다.
이번에 UI 부분은 꼼꼼하게 QA를 잘해주셔서, 제가 XXX님을 믿고 해당 부분 추가 검증 없이 배포할 수 있었습니다. 혹시 유효성 검증에서 예외 케이스를 확인하는 것 관련해서는 헷갈린 점이 있으셨나요? 혹은 이전으로 돌아간다면 유효성 검증 부분 관련해서 어떤 점들을 저에게 질문 주셨을 것 같으세요?
이렇게 잘해주신 부분에 대해 먼저 언급한 후, 본론을 순차적으로 질문드렸는데요. 같은 동료분이었는데도, 질문을 개선한 후에 훨씬 솔직하게 어떤 부분에서 어려움을 겪으셨는지 솔직한 이야기를 들을 수가 있었습니다.
유효성 검증하는 과정에 대해서 이전에 있던 것을 거의 그대로 사용하는 것으로 이해해서, 로직에 대해서 완전히 이해하지 못한 상태로 임했던 것 같아요. 다음에는 이전에 사용하는 방식을 그대로 쓰더라도, 이전 로직에 대해 한번 더 질문드리고 이해도를 맞춰나가는 과정을 가졌을 것 같습니다.
저도 이 과정을 통해서 '이전 것 그대로'라는 말을 최대한 명세서에 사용하지 않고 한번 더 풀어서 작성해야겠다는 개선점을 도출할 수 있었습니다.
이미 부정적인 부분을 지적하면서 시작하면 업무 성과에 지장이 갈까 두려워 솔직한 내용을 이야기하는 데에 어려움이 있을 수 있는데요. 긍정적인 부분을 강조하면서 질문을 시작하면 더 팀이 잘하기 위한 사항에 대한 아이디어들이 솔직하게 나올 수 있게 되는 거죠.
물론, 잘 진행되지 않는 사항을 파악해서 빠르게 개선하는 것은 중요합니다. 하지만 일대일 미팅 때 어떠한 질문으로 포문을 여느냐에 따라 동료분들이 더욱 솔직하게 이야기를 하고 싶은 환경이 되는지, 혹은 위축되어 부정적인 감정을 얻은 채 솔직한 이야기가 나오지 않게 되는지를 염두에 두면 좋을 것 같습니다.
미래 지향적인 질문으로 솔직하고 편안한 피드백 유도하기
🐥 초보: 저는 어떤 점을 개선하면 좋을까요?
저도 처음에 일대일 미팅을 팀원들과 진행할 때에는 무턱대고 "저의 개선점은 무엇일까요?"라고 한 명씩 질문드렸었습니다. 물론, 솔직한 표현을 잘하시는 분들은 편하게 이야기하시지만 대부분의 팀원들은 살짝 당황해하시며 "잘하고 있습니다" 정도로 짧게 대답해주셨는데요. 다시 생각해보니 제 질문이 모호해서 대답하기 곤란했다는 생각이 들더라고요. 그래서 다음 미팅에서는 질문을 바꿔야겠다고 생각했습니다.
🐓 고수: 저는 다음 마일스톤에서 더욱 임팩트를 내는 팀이 되고 싶습니다. 이번 마일스톤을 돌이켜 보았을 때 다음 마일스톤에서 제가 소통 관련해서 어떤 부분을 신경 쓰면 우리 팀이 더욱 좋은 결과를 낼 수 있을까요?
지금 나를 지적하는 것이 아니라, 다음에 우리 팀이 더 잘하기 위한 피드백을 얻고 함께 개선해나가자는 식으로 질문을 바꿔서 일대일 미팅을 진행해 보았는데요. 다음에 우리 팀이 임팩트를 내기 위해서 PO가 신경 써줘야 할 부분들을 이전보다는 편하게 이야기해주셨고, 실제로 개선점으로 반영하면 유익한 내용들이 일대일 미팅을 통해 나왔습니다.
기존 다양한 툴로 소통하면서 자료들이 산재되어 찾는데 오래 걸리고 뭐가 업데이트된 것인지 확인하기 어려운 문제가 있었는데, 소통 방법에 대한 교통정리를 해주시면 더욱 소통에 드는 코스트(cost)가 줄어들 것 같아요.
추가적으로 "일대일 미팅에서 나온 개선점들을 직접 하나씩 실행해 옮기고 해당 실행으로 임팩트 내는 것에 도움이 되었다"라고 다음 일대일 미팅 때 추가로 공유하면, 피드백을 준 사람 입장에서도 더욱 피드백의 중요성을 체감하고 솔직한 개선점들에 대해 편하게 이야기할 수 있게 될 것이라고 생각합니다.
나만의 질문법을 찾아서
지금까지 PO/PM이 업무 하면서 마주하는 주된 4가지 상황에서 어떤 질문을 하면 좋을지 예시와 경험담을 통해 설명드렸습니다.
저도 주니어 PO로 업무를 시작하면서, 마주하는 상황이 너무 다양하고 업무마다 성격과 맥락이 달라 업무에 빠르게 집중하는 것이 어려웠는데요. 이 때문에 각 상황마다 효율적으로 소통하지 못해 회의가 지연되고 다시 회의를 잡아야 하는 상황이 빈번하게 발생했습니다.
그런 상황이 반복되니, 무작정 회의부터 잡고 백지에서 시작하는 것이 아니라, 어떻게 하면 내가 원하는 대로 업무가 흘러갈 수 있을까를 근본적으로 고민하게 되었던 것 같습니다.
최근에 읽은 〈그렇게 물어보면 원하는 답을 들을 수 없습니다〉를 통해 저의 소통법을 돌아보며 소통 팁을 얻기도 했는데요. 지금도 적절한 소통법을 계속 찾아가고 있는 상황입니다.
이 4가지 상황 외에도 다른 수많은 상황 속에서 소통해야 하는 분들도 많을 텐데요. 각 상황마다 논의하는 방향과 동료분들이 가지고 있는 태도와 감정 상태가 다를 것입니다.
당장 하고 있는 업무에만 집중하는 것에서 확장해 이런 상황과 상대방을 잘 고려해서 나만의 질문법을 찾아본다면 회사 내에서 일잘러가 되는 것은 시간문제일 것입니다.
👀 바쁘다면 이거라도!
• 첫째, 의사결정자의 의도를 파악해서 제품 계획 및 로드맵을 그리는 상황의 질문법
◦ 최대한 구체적인 질문으로 방향을 파악하기
• 둘째, 다른 부서·팀과 협업이 필요한 상황의 질문법
◦ 협업이 왜 필요한지 이해도 맞추기
◦ 겸손한 질문으로 우려되는 부분을 미리 해소하기
• 셋째, 스쿼드 안의 개발자 및 디자이너와 함께 일할 때의 질문법
◦ 해결하려는 문제 상황에 대해 이해도 맞추기
◦ 미봉책보다는 팀원들의 고민을 이끄는 질문하기
• 넷째, 팀원들과 일대일 미팅에서 신뢰를 얻어야 하는 상황의 질문법
◦ 긍정 형태의 질문으로 잘하고 있는 점에 집중하기
◦ 미래 지향적인 질문으로 솔직하고 편안한 피드백 유도하기
