고객들의 피드백을 기반으로 서비스를 성장시키기 위한 인사이트

라인이 인수한 일본 1위 배달 서비스 데마에칸 프로덕트를 담당하고 계신 PM님께서 서비스 내의 유저 피드백을 받아볼 수 있는 기능을 도입하기 까지 경험한 시행착오글입니다. 5년 간 사용자의 피드백에 탄력 있게 반응하도록 만들기 위해 다양한 노력을 해주셨는데 이러한 과정 속에 유저 피드백에 대해 여러 인사이트 공유해주셨습니다. 🎆 '의견을 남겨주셔서 고맙습니다' 라는 건조한 한 줄의 메세지 보다는. '당신의 의견은 몇 번째로 접수되었습니다'라는 수치를 보여주는 방법도 고려해보면 좋습니다. 사용자가 의견을 남겼을 때 '나만 까탈스럽나?' 라는 걱정이 들 수 있는데 이 감정을 조금 줄일 수 있는 방법입니다. 다른 사용자들이 남겼던 의견을 보면서 '나만 느꼈던 문제가 아니구나'라며 안심하게 됩니다. 👁️ 피드백 관리는 명확하게 역할을 정의해야 합니다. 피드백 관리를 CS에서 담당하게 된다면 앵무새 같은 응답만 붙을 수가 있고, 사업부에서 책임을 갖게 된다면 서비스나 사용자를 직접 접하지 않은 부서이기에 적합하지 않습니다. 또한 프로덕트 팀은 프로덕트 제작에 집중할 필요가 있으므로 사용자의 의견 하나하나 수집해 반응하는 것은 부담스럽습니다. 피드백에 간단하게만 응답한다고 하더라도 대외 메세지는 말투 같은 사소한 이유로도 문제가 발생할 수 있기 때문에 아무나 남길 수 없는 영역입니다. 🤾 사용자는 프로덕트에 의견이 조금씩 반영되는 것을 경험하면 다음에는 더 자세한 의견을 말하기 시작합니다. 처음에는 '느린 반응 속도' 라는 피드백이였지만, 개선을 경험시켜주다보니 '느린 알람 팝업'과 '느린 지도 화면' 으로 보다 자세하게 나뉘어졌습니다. 이처럼 자세하게 바뀌어 간다는 것은 사용자의 요구사항이 정밀해진다는 의미고, 사용자가 프로덕트의 언어로 이야기하기 시작했다는 의미입니다. 💁‍♂️ 프로덕트를 사용하는 시간과 과정은 곧 프로세스가 되며, 프로세스는 다시 프로덕트를 좋게 만드는 아이디어를 줍니다. 궁극적으로는 피드백을 남긴 사람들에게 우리 팀이 그 의견을 얼마나 진지하게 생각하는지 우리가 그들에게 피드백을 주는 흐름이 필요합니다. 피드백의 시작부터 끝까지 피드백 하나의 생애 주기를 온전히 가꾸는 데 도움을 줄 수 있다면, 사용자 피드백을 다루는 프로덕트로서 보다 전문적인 의미를 갖게 될 것입니다. 🤔 프로덕트가 사랑받는 법은 간단합니다. 사용자의 목소리를 듣고 아주 작은 요구는 빨리 만들어서 릴리스하고, 큰 요구는 정성스럽게 만들어서 릴리스하는 것입니다. 그리고 피드백을 보낸 사람들의 시간을 소중하게 생각하며 고맙다고 말해 주는게 전부 일지도 모릅니다. 그 경험이 모이면 사용자들도 우리가 만드는 프로덕트에 함께 참여하고 있다고 느끼며 자연스럽게 소속감과 애정을 가질 것입니다.