쿼츠의 PM팀에서 일하고 있는 Kevin Kim이 쿼츠에 기고한 글로 주로 영업이나 마케팅 부서에서 상품팀이 무엇인가를 요청해 성과를 내려면 어떻게 해야 효과가 있을 것인지에 대해 알려주고 있습니다.
효과적으로 제품팀 또는 제품팀의 기획에 따라 구현하는 개발자 및 디자이너와 협업하는 방법이 무엇인지를 쿼츠, 페이스북, 구글 그리고 마이크로소프트에서 일했던 경험을 토대로 조언하고 있습니다.
예전 하는 일이 상품기획 업무였으므로 여기서 말하는 제품팀과 비슷한 역활을 했었습니다. 비록 업종이 달라서 소프트웨어 관련 일은 많지는 않았지만 이 글을 호기심을 가지고 함 살펴보았습니다. 회사에서 격은 일들을 되돌려보면 여기서 한 충고들이 상당히 유용하다는 생각입니다.
여기서는 영업, 마케팅 담당은 제품팀 또는 개발 및 디자인팀을 존중하면서 논리적으로 설득하고 상대방이 그 필요성을 인정하고, 이 일을 함으로써 충분히 이익을 얻을 수 있다는 점을 부각하라고 조언합니다.
조금 긴 아티클이긴 합니다만 사내에서 업무 추진 시 참조할만합니다. 특히 IT 기업에서는 필히….
이 글의 원글은 아래 링크를 따라가시면 됩니다.
How to persuade your company’s product team to build something
제품팀이 요청을 받아 과제를 진행하도록 설득하는 방법
자, 여러분은 회사의 제품팀더러 내부 툴(Imternal tool) 또는 어떤 소프트웨어를 구축토록 시키길 원하죠.
만약 여러분이 제품팀이 아닌 판매 또는 마케팅 부서에서 일한다고 가정해 보시죠. 그렇다면 제품팀더러 내부 툴(Imternal tool)이나 어떤 소프트웨어를 만들어 달라고 요청하는 것은 굉장히 어려운 일이 될 수 있습니다. 요청하고 싶은 기능에 대한 기술 세부 정보를 누구에게 요청해야하는 지도 모를 수 있습니다.
쿼츠, 페이스북, 구글 그리고 마이크로소프트에서 일하면서 저는 양쪽 측면을 모두 경험해 봤습니다. 저는 비지니스 측면에서 새로운 소프트웨에 대해 제품 및 디자인팀에 피드백을 주고 있으며, 그 피드백에 대한 결과를 받아보고 있습니다.
제가 말씀드릴 수 있는 것은 당신을 위해서 많은 다른 사람들이 그들의 시간을 소비하도록 설득하는 것은 어렵다는 것입니다.
여기 당신과 함께 일하는 제품 담당자, 엔지니어, 디자이너 그리고 데이타 전문가들이 당신의 요청을 무시하지 않도록 만드는 방법이 있습니다.
해결 방법이 아닌, 문제로 부터 시작하세요
많은 기능 요청들이 이렇게 시작됩니다.
누군가가 왜 필요한지에 대한 별다른 근거도 없이 간단한 “기능”아이디어를 내고(와!! 이런것도 생각해 낸거야라고 생각하며) 어깨를 의쓱합니다. 실상 이 기능은 구현에 많은 시간이 걸릴 수 있는데 말이죠.
그는 이렇게 이야기 합니다. “저기요, 고객 서비스 채팅만하면 고객들과 직접 대화할 수 있습니다. 경쟁 X사도 이 기능을 가지고 있어요.”
제품팀의 관점에서 보면, 이러한 요청 스타일은 마치 짧은 시간에 생각해낸 비지니스 아니디를 구현하는 것이 매우 쉽다고 생각하는 것처럼 들립니다.
제품팀을 모욕하는 것외에 선입감을 불러 일으키는 솔류션을 제안하는 방법은 나중에 더 큰 문제를 야기하는 방향으로 결론이 나기 마련입니다.
먼저 문제를 설명하는 것으로 시작해야 합니다. 이는 보다 협력적인 접근일뿐만이 아니라 기술 솔루션에 대한 여러분의 생각이 최상의 것이 아닐 가능성이 높기 때문입니다.
그리고 괜찮습니다. 그것은 당신이 해야 할 일도 아닙니다. 그것은 바로 당신 회사의 엔지니어, 디자이너, 제품 매니저가 있는 이유입니다. 해결해야 할 문제를 설명하는 것만으로도 충분히 도움이 된다.
다음은 문제 해결책을 제사하는 대신 문제에 집중하는 방법에 대한 예입니다.
헤이! 마케팅팀은 많은 사람들이 검색과 온라인 광고로 우리의 웹사이트를 발견해 방문하지만, 아무도 제품을 사지않는 다는 사실을 발견했어. 우리는 항상 사람들로부터 아주 구체적인 질문을 많이 받지만, 우리가 응답할 때쯤에는 많은 사람들이 다시 연락하지 않거나 경쟁자에게로 가버리거든
우리는 사용자들과 보다 빨리 의사소통을 할 수 있는 방법이 있다면, 이들을 계속 참여시키고 그들의 질문에 답하고 더 많은 매출을 일으킬 수 있을 것이라고 생각해.
사용자가 누구인지 명확히 정의할 것
제품팀은 유용한 솔루션을 구축하기 위해 이 기능을 사용할 사람들의 구체적인 요구 사항을 이해해야합니다.
예를 들어 의도한 사용자가 CEO인 경우(일일 사용자 수 또는 판매량과 같은 매우 일반적인 회사 정보가 필요 하겠죠.)와 일반 관리자인 경우(특정 계약자, 특정 사용자 또는 특정 지역에 대한 상세한 데이타 필요할 수 있겠죠)는 데이터를 보여주는 Dash Board가 달라야 합니다. 요구된 정보 풀질도 물론 달라야겠지요.
다음은 잠재 고객을 적절하게 정의하는 방법의 예입니다.
채팅 플랫폼은 현 고객지원팀 6명이 사용할 겁니다. 이 팀원들은 로그인해 사람들의 질문에 답변합니다. 그리고 모든 팀원들은 교대로 나누어서 이 업무를 진행합니다.
해당 기능을 어떻게 사용할지 구체적으로 설명하세요
이 기능의 사용자가 이 기능에서 원하는 것이 무엇인지를 명확히 설명해야 합니다.
영업팀이 일반 매출 번호를 볼 수 있도록 대시 보드가 필요하다면 이를 정확히 설명해야합니다. 영업팀이 실제로 필요하지 않은 멋진 시각화 그래프 및 맞춤형 날짜 범위 기능은 구축하지 않아도 됩니다.
만약 당신 필요에 대해 솔직하게 밝히지 않는다면 나중에 (“왜 이게 엑셀로 보내지지 않는 거야?”)같이 사후에 자잘한 문제 해결에 매달릴 수 있으며, 나중에 제품팀이 당신을 위해 다른 작업을 하도록 시키는데 지장을 받을 수 있습니다. (신망을 잃었기 때문에)
다음은 요구 사항을 적절하게 정의하는 방법의 예입니다.
우리가 주로 받는 질문은 솔류션 엔지니어가 처리하는 기술적인 통합에 대한 질문이거나, 가격 책정에 대한 질문입니다.
따라서 우리는 고객과 채팅을 해야할 뿐만이 아니라 고객과 채팅 내용을 내부 다른 부서 사람에게 전달할 수 있어야 합니다. 그리고 우린ㄴ 채팅을 통해서 의사 소통을 할 수 있어야 합니다. 우리는 스크린 샷이나 음성 통화 도는 그 이상의 멋진 것을 필요로 하지는 않습니다.
또한 일부 고객은 유럽에 있기 때문에 아침 일찍 메세지에 응답해야 합니다. 또한 직원이 데스크탑 컴퓨터 뿐만이 아니라 스마트폰에서도 메세지에 응답할 수 있다면 도움이 될 것입니다.
데이타, 데이타, 데이타
더 많은 것을 계량화 할수록 좋습니다. 진심으로 저는 아직까지 너무 많은 데이터가 포함된 기능 요청을 아직 보지 못했습니다.
“지원 요청 이메일 대화의 70 %가 15번이상 답변이 오고 갔습니다. “라고 이야기 하는것은 제품팀이 곡개 서비스 챗에서는 개 이상의 앞뒤 메시지를 가지고 있습니다”라고 말하면 고객 서비스 채팅 소프트웨에어에서는 아주 긴 스레드 된 대화를 지원할 수 있어야한다는 것을 알 수 있을 것입니다.
제품 팀에게 “우리의 대화 중 56 %가 솔루션 엔지니어의 기술적인 정보가 필요합니다”라고 알려준다면 진행중인 대화를 다른 직원에게 쉽게 할당 할 수 있는 기능을 추가하는 것이 얼마나 중요한지 강조 할 수 있습니다.
더 중요한 것은 영향을주는 데이터(문제의 규모 나 비즈니스 가치)가 사용자의 기능 요청이 수락 될 가능성을 높인다는 점입니다.
단순히 이 기능이 “매우 중요합니다(very important)”또는 “필수적입니다(critical)”라고 말하는 것만으로는 충분하지 않습니다. 제품팀은 항상 이런 말을 듣습니다.
제품을 담당하는 사람들은 일시적인 사례보다는 양적 측정 지표를 중요시하는 경향이 있으며, 데이터를 사용하여 설득력있는 사례를 만들면 그들이 직면하는 엄청난 양의 버그 픽스 요청과 자잘한 버그 수정 요청 사이에서 여러분의 제안이 도드라져 보일 것입니다.
다음은 맥락과 설득력을 모두 높일 수 있도록 데이타츨 통합하는 방법의 예입니다.
저희가 고객 지원 요청 이메일에 너무 늦게 응답했기 때문에 다음달 우리와 계약하지 않겠다고는 고객이 매달 평균 5명에 달합니다.
고객 한명당 연평균 매출액은 6,000달러입니다. 이 기능이 구현되면 직접적으로 연 36만 달러의 수입 증가를 가져올 수 있습니다. 이는 의사 소통이 느리기 때문에 우리와 계약하지 않겠다고 명시적으로 밝힌 사람들을 계산한 예측치 입니다.
사례를 사용 시, 사용자의 좌절과 그들의 실제적 감정에 강조하세요.
안타깝게도 모든 회사 또는 팀이 데이터에 대한 접근성이 뛰어난 것은 아닙니다. 정량화 항목이 많지 않은 경우 문제로 인한 사용자의 좌절감과 불안감을 강조하는 사용자 사용 스토리가 유용할 수 있습니다.
기술 제품 지향적인 일에 종사하는 사람들은 얼간이처럼 보일 수 있지만 많은 엔지니어와 디자이너들은 소프트웨어와 같은 제품의 문제를 해결하고, 사람들간의 문제를 해결함으로써 만족을 얻는 경우가 종종 있습니다.
상품팀이 솔류션 부족으로 실패를 맛보았던 사람들의 풀 네임과 사진 그리고 그 사람들의 직접적인 요청을 사용한다면 사용자의 생활을 개선할 기회가 점점 더 명확해 집니다.
이 전략은 제품 관리자보다는 실제 제품을 만드는 사람(엔지니어, 디자이너)에게 더 잘 작동합니다. 제품 관리자는 들어오는 사전 기능 요청에 대해 좀 더 냉소하고 경계하므로 주의해야 합니다.
여러분의 요청을 제품팀의 목표나 회사의 목표와 연결하세요.
제품팀은 명확하고 측정 가능한 목표를 가지고 있습니다. 여기에는 사용자 증가, 사용자 참여 및 클릭 광고와 같은 직접 측정 가능한 메트릭을 통해 평가되는 경우가 많습니다.
이러한 제품팀의 리더는 이러한 결과치를 개선하라는 엄청난 압력에 시달리는 경우가 많습니다.
요청 기능 구현을 통해 제품팀의 목표 중의 하나가 개선될 수 있다는 점을 제시하세요. 회사 내 다른 모든 사람들과 마찬가지로 제품팀원들도 좋은 실적을 쌓고, 상사를 기쁘게 하고, 연봉을 높게 받고 싶어 합니다.
요청을 제품팀의목표와 연계할 수 없다면, 다음으로 가장 좋은 방법은 회사 목표와 연결하는 것입니다. 회사의 기본 목표 中 하나에 직접 영향을 미친다면 그 누구도 그 기능의 중요성을 무시할 수 없습니다.
다음은 제품팀의 목표를 통합하는 방법에 대한 예입니다.
이번 분기 제품팀 목표 중 하나가 구매 의향을 가진 사람들이 웹사이트 방문 비율을 향상시키는 것이라는 것을 잘 알고 있습니다.
이 고객 지원 채팅 기능을 구현하면 해당 목표에 직접적인 영향을 미칠 수 있을 뿐만 아니라, 이번 분기 주요 관심사라고 CEO께서 말씀하신 새로운 고객을 확보할 수 있을 것입니다.
30분만 구글을 검색해 보세요
여러분이 소프트웨어 엔지니어가 아닐지라도, 그들의 가장 좋은 기술 중 하나인 구글링을 흉내내는 볼 가치가 충분합니다.
리소스를 읽고, 이를 자신의 작업에 적용하는 것은 개발자가 해야하는 일중의 하나입니다. 그런 지식을 활용해야 합니다. 제품팀에 요청하기던에 인터넷 검색 가치가 있는 몇가지 구체적인 사항이 있습니다.
- 개발 : Medium, Quora, Stack Overflow(프로그래밍 질문용 Quora)와 같은 플랫폼 전반에 걸쳐 “웹 사이트용 고객 서비스 채팅 구축 방법” 또는 “사용자의 로그인 소요 시간”과 같은 질문에 대한 자세한 답변을 찾을 수 있습니다. 일부 아티클들은 기술 수준이 매우 뛰어납니다. 여기에 몇 가지 사항을 조정하면 필요한 복잡성 수준을 높이고, 구현상의 장단점을 이해하고 원하는 기능 구현에 필요한 관련 리소스를 인용할 수 있습니다.
- 디자인 및 전략 : 순수한 기술적 측면을 제외한다면 “고객 서비스 채팅 모범 사례”는 수많은 디자인, 사용자 경험, 전략 지향적인 기사 및 블로그 게시물에서 찾을 수 있습니다. 검색 결과의 처음 두 페이지를 살펴보고 배운 내용을 문서화하십시오. 이것은 여러분의 기능 요청에 업계 모범 사례를 포함시킬 수 있고, 그 기능과 관련해 고려해야할 올바른 사항에 대한 여러분의 지식이 늘어날 것입니다.
여기 구글링으로 검색한 결과를 첨부하는 사례가 있습니다.
저는 고객 채팅 플랫폼 구축에 대해 논의하는 블로그 게시물 몇 개를 찾아 링크를 포함시켰습니다. 또한 고객 서비스 채팅 플랫폼의 일반적인 UX 문제에 대한 흥미로운 디자인 기사를 찾았습니다.
전반적인 컨센서스는 기존 공급업체를 사용하는 것이 가장 좋은 것으로 보입니다. 여러 엔지니어가 처음부터 라이브 플랫폼을 즉각 구축하는 데는 상당한 시간이 걸릴 것이기 때문입니다.
기능을 서비스로 제공하는 회사 찾기
거의 모든 기능을 월별 요금을 내고 사용할 수 있는 상품을 제공하는 여러 회사가 있습니다.
이러한 서비스를 누가 상요하고 있는지를 앙여주는 사이트들도 있습니다. 예를 들어, Spotify는 이메일 관리를 위해 Sendgrid, A / B 테스트를 위해 Optimizely, 인앱 설문 조사를 위해 Qualaroo, 고객 지원 채팅을 위해 Salesforce Desk를 사용합니다.
더 큰 기능 적용을 위해서 저는 “최고의 _ 기업” 또는 “최고 _ 공급자 리뷰”를 검색하고 해당 분야이 기업에 대해 조사하는 것을 강력 추천합니다. 자신만의 기능을 구축하더라도 더 많은 정보를 얻을 수 있고 어떤 부분이 중요한지를 알 수 있습니다.
다음은 제품팀에 솔루션을 추천하는 방법의 예입니다.
고객 서비스 채팅 서비스를 제공하는 몇몇 회사에 대해 조사했습니다. 이들 중 인터콤과 젠데스크는 가장 큰 두 회사입니다. 젠데스크(Zendesk)는 고객 서비스 담당자가 수령 할 수 있는 티켓에 피드백을 넣는 반면, 인터콤(Intercom)은 더 많은 채팅 기반 서비스를 제공합니다. 그들은 둘 다 무료 체험 서비스를 제공하기 때문에 선불을 지불하지 않고서도 우리 요구 사항을 충족시킬 수 있는지 알 수 있습니다.
제품팀 관계자 승인 받기
제품 로드맵에서 우선 순위에 넣는 가장 빠른 방법은 최고 경영진을 움직이는 것입니다.
이를 위한 한 가지 전략은 팀 임원이 요청을 리드할 제품팀 관계자에게 요청 및 중요성을 전달하는 것입니다. 엔지니어링팀은 잠재적인 방어 메커니즘속에서 자기 팀의 누구가에게서 전달을 받아 다른 팀을 위한 작업을 진행하는 것에 매우 익숙합니다.
프로페셔널한 팁: 제품팀 로드맵 계획이 언제 수립되는지를 알아보고 , 이 수립 회의가 이룽어 질때에는 계획의 일부로 기능을 쉽게 추가 할 수 있습니다.
다음은 이해관계자의 승인으로 이루어진 요청의 예입니다.
최근 당신네 제품팀 부사장 Sarah와 이 문제에 대해 이야기를 나누었습니다. 그녀와 저희 영업 팀 상사인 Michael이 만난 자리에서 였습니다. 그녀는 이것이 중요한 문제라고 동의했습니다. 그녀는 이 문제를 해결하기 위해 이번 달말에 팀을 재편하겠다고 했습니다. 에 대역폭이있을 수 있다고 언급했습니다. 따라서 저는 이 업무를 당신과 함께 추진하고 싶습니다.
이러한 일을 하는데 노력이 필요합니다.
여러 사람들이 계획했던 다른 모든 작업들보다도 작업하는데 수십시간이 더 걸린다고 예상된다면 요청 내용을 철저하게 준비해야 합니다.
요청을 처리하는데 너무 많은 작업이 필요하다는 것을 알게되면 아마도 이 기능이 진정으로 필요한 것인지 다시 한번 고려해봐야 합니다.
다시 한번 요청을 재고하면서, 더 효과적으로 만드는 과정을 거친다면 더 나은 직원이 될 것입니다. 점점 더 많은 기업이 기술과 데이터를 강조함에 따라 기술을 다루는 관계자를 설득해 무언가를 만드는 비즈니스 담당자가 점점 더 중요해집니다.
